Re: [ekmi] FW: SKSML draft

[Arshad Noor <arshad.noor@strongauth.com>]

Thank you for your questions, Sandi.  Its obvious that you've
given this a lot of thought and I appreciate that - it helps
towards creating a stronger protocol.  

I have embedded the answers within your e-mail.  To a 
large extent, I will be referencing StrongKey - the open-source
implementation of SKSML, when discussing implementation
details to show how a specific issue was addressed.  Of
course, anything outside of the actual protocol leaves a lot
of room for implementers for creativity - as it should be.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: "Roddy, Sue A." <s.roddy@radium.ncsc.mil>
Date: Tuesday, July 3, 2007 4:03 am
Subject: [ekmi] FW: SKSML draft

> Some comments on the SKSML draft.
> 
> Sandi Roddy
> I5 Technical Leader for IA Infrastructure Transformation
> National Security Agency
> 
> EKMICoreLibrary.xsd:
> 1.
> The gkid element:
> Comment a:
> The current naming scheme (gkid) doesn't seem to easily allow for
> interoperability (sharing symmetric keys) between multiple enterprises
> & their clients.  There would easily be collisions where multiple
> enterprises use the same gkid for their own, different symmetric keys.
> Has  true global collision-free naming scheme been considered to
> identify symmetric keys so that the keys can be shared between
> enterprises?  This same concern also applies to the sharing of the key
> policy
> information.
> 

I realized this a few months ago and have already started
the work to include a "Domain ID" within the GKID.  A
Domain ID is just another sequential number that is pre-
pended to the Server ID and Key ID.  Since it is anticipated
that a specific SKMS could serve multiple organizations,
the implementers can divide up the SKMS space using
unique Domain IDs for each organization - or even a group
within an organization.

So a sample GKID - in the next iteration of the protocol as
I'm preparing it - will look like the following:

10514-7-213

where 10514 represents the Domain ID, 7 represents the
Server ID and 213 represents the Key ID.  Collectively, the
three hyphenated numbers will represent a truly global key
as long as the Domain IDs are unique.  

I was planning to recommend using the registered Private
Enterprise Numbers from IANA, where more than 29000
companies have already registered themselves and been
assigned unique PENs.  
(http://www.iana.org/assignments/enterprise-numbers)

If IANA had a problem with the use of these numbers for a
different purpose, StrongAuth would be willing to maintain
a similar registry (free, of course) that would assign such
numbers to registrants through a simple web registration
process.

I thought about using DNS names as an alternative, but a
FQDN doesn't look as elegant as a simple, sequential
number that is consistent with the ServerID-KeyID tuple.


> Comment b:
> Has the group considered multiple "editions" of the symmetric key 
> to ease
> rollover to the next key?  For example, users of the same
> symmetric key "5-9" might roll to a new key once a week.  Could the
> first week's key be called "5-9-1", second week's key "5-9-2", etc.
> 

I thought about this 12-15 months ago, but rejected it.  Since an application will always need to know the GKID it
used to encrypt data, it really doesn't matter what the GKID
is, as long as the application can legitimately retrieve it from
an SKS server.  There is no need to assign any relationship between keys, since it serves no purpose to
the application.  It can deal with 5-9 just as easily as it can
deal with 23-34344.  Humans might be curious about the
GKID used by a specific application, but in the end, as long
as the SKS server is making the right access control decisions
based on defined ACLs, any GKID is as good as another.


> 2.
> The algorithm element:
> If I'm reading the XML Schema correctly the choices for the symmetric
> key's algorithm seem to be limited to the ones explicitly defined 
> in the xsd
> file
> (3DES-CBC, AES128-CBC, AES192-CBC, AES256-CBC).  I can think of others
> that would be nice to list (AES Key Wrap of various bit lengths, HMAC
> with various hash algorithms, AES operating in other modes).  But, in
> general, there needs to be
> flexibility for organizations to use this schema to distribute
> symmetric keys for *any* algorithm.  I do agree that it would be great
> if the organizations all refer to the same URIs for the same
> algorithms, rather than making up their own algorithm URIs (which 
> wouldcause interoperability nightmares), but can this practice be 
> enforcedanother way?
> 

I thought about this too for a long time.  The reason I settled
on these 3 URIs was because they were codified as a
standard in XMLEncryption.  I realize that there are many
other encryption algorithms that are useful, and in use.  But
I didn't want to get into the business of codifying URIs when
there appears to be a process to do so within W3C or
OASIS.  

While we in the TC can come up with standardized URIs
for other algorithms, I think it makes more sense to have
them standardized through the W3C since they're more
closely related to XMLEncyrption.  However, if the SC/TC
believes that OASIS should codify these URIs, as long as
we believe that XMLEncryption will not countermand that
later on, I am open to it.


> 3.
> The keysize element:
> Is it necessary to have a keysize element if the algorithm implies 
> the key
> size?
> 

Not really necessary, but its one less thing for the Symmetric Key Client Library (SKCL) to figure out each
time it gets a key.  

It is my belief that, initially, application developers are going
to look for any way to overcome the slight delays in 
transaction processing that encryption  introduces.  Having
the SKCL "know" this immediately rather than derive it can
help with that objective.


> 4.
> The duration element:
> Is this duration timed from when the key is first generated by the
> server or from when the client receives it?
> 

The SKCL interprets this as - from the time the SKCL first
uses the key for an encryption.

It is reasonable to expect that a KeyCachingPolicy will allow
clients to download and cache - lets say 12 keys - each 
lasting for 1 week.  This will allow the client to remain off-line,
if necessary, for as long as 3 months without connecting to
the SKMS for new keys.  While all keys may have been
issued on the same date by the SKS server, the SKCL will
start counting down the timer only when it first starts using
each key.



> 5. 
> Organizations may want the flexibility to add additional elements
> to describe the properties of a symmetric key.  Does the schema allow
> for custom elements/extensions?  One example of another desirable
> element would be "key usage", indicating whether the symmetric key is
> to be used as a key encryption key (key wrapping), traffic / data
> encryption, integrity protection, etc., (though the algorithm choice
> might imply these), or perhaps even indicating the specific types of
> applications the key is for use in (examples: encrypting an IPSec 
> tunnel,encrypting documents, encrypting blocks on a hard drive,
> integrity-protecting a document, etc.)
> 
> In the government sector we would want to label the symmetric keys 
> withclassification labels indicating up to what level of data the 
> key can be
> used to protect (and what level the key itself needs to be 
> protected to).  
> 

This is an interesting and new requirement.  I  would be open
to suggestions on new elements that can be added to the
KeyUsagePolicy element that will serve these needs.


> 
> General comments:
> 6.
> Has there been consideration of specific mechanisms to be used for
> encrypting the symmetric key & its properties (ie: key wrapping 
> with a
> key encryption key, asymmetrically encrypting with the key consumer's
> public key, etc.) or are all of the options of XML-Encryption open for
> use?  It would be good to force the symmetric key, in transmission 
> usingXML-Encryption, to be protected by an algorithm & bit size of 
> equal or
> greater strength of the key being transported.
> 

The SKSML package containing the symmetric key is
ALWAYS encrypted using the recipients' RSA Public Key.
So, within StrongKey, a 3DES or AES-256 symmetric key
is encrypted with an RSA-1024 or RSA-2048 asymmetric
key, based on the implementation.  Symmetric keys are
never in the clear on the wire or in the database.  They are
accessible in the clear only when the appropriate Private
Key is available to decrypt it for use.


> 7.
> How much work has gone into access control for determining which
> clients can access which symmetric keys, as well as how to identify
> the consumers (ie: using X.509 certificates? SAML assertions?), 
> includingpotentially allowing clients from other enterprises to 
> request keys,
> or passing symmetric keys between enterprise systems run by different
> organizations.
> 

While the SKSML protocol itself doesn't define access control
rules, the StrongKey implementation has taken significant
pains to ensure that every request for a symmetric key is
authorized.

So, within StrongKey, the default policy is that an authorized
entity - as defined by a record in the database with an X509
digital certificate issued by a trusted authority - is authorized
to request NEW symmetric keys automatically (if the default KeyUsagePolicy allows it).  However, once a key has
been issued NO ONE is allowed to access the key unless
it is explicitly authorized through a KeyGrant.  KeyGrants can be issued to individual clients, a group of clients, or groups of groups of clients.  Without such explicit authorization, 
all requests for existing keys are denied.

I am looking at SAML and XACML for a future implementation 
in StrongKey.  However, since SKSML is already using the
WSS header, the protocol needs no change, since WSS
already supports SAML.


> 8.
> Has there been consideration of a need to sometimes supply symmetric
> keys to disconnected devices?  An intermediary with network access
> would pick up the key from the key management server, then supply
> it to the disconnected device physically or via an isolated network.
> The symmetric key would perhaps be encrypted for the final destination
> but carried by the intermediary.
> 
> 

Yes.  This is precisely the recommendation I made to the
IEEE 1619.3 Working Group (who are working on key-
management standards for storage devices).   Take a look
at this e-mail, and the PDF presentation at the bottom of
that e-mail:
http://lists.oasis-open.org/archives/ekmi/200706/msg00030.html
The last 2 slides discusses how a Management Console
for the storage devices can use SKSML to get policies and
keys from the SKS server, and then use the 1619.3 defined
protocols to push the keys down to the storage devices (who
may not have the capability to communicate with the SKS
server on their own).