OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pki-tc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ekmi] SKSML Specification Question

Excellent questions, Tim.

EKMI/SKML is viewing the world of SymKey Management way up in the stack 
(Application space). So I am sure there are tons of things that need to 
be looked at in the long run. One common pitfall of specs is that a lot 
is attempted for the v1.0 such that it gives rise to schedule slippage, 
complications in comprehension etc. The approach suggested by Arshad is 
valuable because we need to shed some light in this dark tunnel called 
as symmetric key management.


Some of the concerns that you have raised (primarily the keyclass 
classification) do aptly fall under the category of profiles/bindings 
etc with the specification. The specification as I see it needs to be 
just about structures (no details).  All the details (use cases) etc 
come under the auxiliary artifacts of the specification. Just like the 
Non-normative stuff was separated from the normative specification, we 
certainly can have profiles concerning browser cookies, tape drives etc, 
as real world use cases of SKML.

There are a few sceptics of EKMI:

Bruce, Timothy R wrote:
> Thank you, Sir.  That answers a lot of questions but I am not sure yet
> whether or not there is a need for an additional subcommittee to
> consider further extending the standard.
> I am concerned about the implication of assumption 5 and your statement
> (which I agree with) that "It is my personal belief that within 10
> years, ALL data will get encrypted..."
> In that world 10 years from now, the Security Officer might be a very
> busy person if that person has to be involved in identifying,
> classifying and assigning key classes to every application, appliance
> and device in an enterprise (every hardware device, software
> application, smart card, memory stick, PDA, cell phone, card key, car
> keys, etc).  Tools can help an SO with this classification into key
> classes and policies, but only if standardized classification
> information is embedded within the protocol packet.  The protocol
> absolutely should be open to vendor exploitation and innovation, but
> that does not preclude a protocol that also facilitates automatic
> discovery, registration and classification into policies set up by the
> SO.
> So it seems to me that some additional standards work is needed
> somewhere so that the EKM infrastructure can automatically identify and
> classify key consumers based upon policies established by the SO.  Those
> additional standards may be needed in the SKSML, the PKI or in some
> umbrella standard.
> Tim Bruce 
> Principal Software Architect, Development 
> 5465 Legacy Drive 
> Plano, Tx.  75024 
> tel:  214-473-1917 
> fax:  214-473-1069
> -----Original Message-----
> From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
> Sent: Wednesday, June 18, 2008 6:42 PM
> To: Bruce, Timothy R
> Cc: ekmi@lists.oasis-open.org; PKI TC
> Subject: Re: [ekmi] SKSML Specification Question
> You haven't gone wrong anywhere, Tim; you just have an incomplete
> picture of how SKSML can be implemented to address the needs you
> describe.
> Lets establish some assumptions before we delve into the details
> of how SKSML will be used in an enterprise:
> Assumptions
> -----------
> 1) An enterprise will establish an EKMI which consists of two sub-
>     systems: a PKI to issue digital certificates to all client and
>     server devices, and an SKMS to issue and manage symmetric keys;
> 2) Through a process - not in scope for this TC, but within the
>     scope of the PKI Adoption TC which is part of the same IDtrust
>     Member Section we belong to - the clients and servers are issued
>     digital certificates to establish their identity;
> 3) Each of these clients and servers is known to the SKMS through
>     the trusted hierarchy of their digital certificates.  How the
>     SKMS gets that information is an implementation detail left upto
>     the vendors;
>     (StrongKey 1.0 - which implements an SKMS using the DRAFT 1 version
>     of SKSML - requires that each client/server be entered manually into
>     a webform of the SKS server; StrongKey 2.0 intends to change that by
>     integrating into an LDAP store of published certificates, or front-
>     ending a CA as an Registration Authority to ease that process);
> 4) The Security Officer at the enterprise defines KeyUsePolicies and
>     corresponding KeyClasses for some standard encryption policies.
>     So, to use your example, one KeyClass might be "TapeLibraryClass"
>     and its corresponding KeyUsePolicy might be "AES 256-bit key valid
>     for 10 years".  Another KeyClass might be "Web Server Cookie Class"
>     and its KeyUsePolicy might be "AES 128-bit and valid for 30-days".
>     (In StrongKey, the SO also defines a "Default" KeyClass and a
>     "Default" KeyUsePolicy, which might be "3-DES and 1-year" validity,
>     or whatever is decided by that enterprise to be their default;
> 5) Now the SO will assign all computers, LTOs and Management Consoles
>     of tape-devices (which have been previously issued certificates in
>     step #2) are assigned to the "TapeLibraryClass" KeyUsePolicy.  The
>     SO will also assign all *web-servers* and *web-applications* to the
>     "Web Server Cookie Class" KeyUsePolicy.
>     All these definitions are done BEFORE a client has requested even a
>     single key.
>     The reason the TC probably would not want to standardize on KeyClass
>     definitions, is because they imply a KeyUsePolicy - what type of
>     algorithm to use, for how long, with what applications, at what time
>     of day, in which location, etc.  These decisions are unique for
> every
>     enterprise, and really not within the scope of the TC's work
> product.
>     Every enterprise must decide these for themselves as part of their
>     SKMS deployment.  (But, if there is a plug-and-play way of doing it,
>     you should propose it for a sub-committee deliverable - see below).
> Now lets look at the mechanics:
> A) When the SKMS is turned on, client applications - which have
>     integrated an SKCL and the keystore/certificate-store that has their
>     digital certificate credential (this can be a smartcard, TPM, HSM,
>     or - yikes - a file-based software module) - will just request a
>     key from the pre-configured SKS servers list.
>     (In StrongKey, this list is a .properties file, and can be
> configured
>      in advance and distributed through SMS - for Windows machines, or
>      NFS for Linux/UNIX machines, or equivalent mechanisms for
> MVS/OS400)
>      much like the resolv.conf file for DNS server information;
> B)  The client application can choose to either specify a KeyClass, or
>      not designate a KeyClass in its SymkeyRequest to the SKS server.
> If
>      it does request a specific KeyClass, it makes sense for it to only
>      ask for classes that it knows it is authorized to request - the
>      developers of the application can learn that through the .property
>      files, if necessary.  But, I believe, it is best to leave the
>      KeyClass out unless it absolutely needs it to specify it;
> C) The SKS server, upon receiving the request and verifying the identity
>     and authorization of the client (through the certificate validation
>     process and a lookup of the DN in its own database), will determine
>     ALL the authorized KeyClasses for that client.
>     If the client did NOT request a specific KeyClass, the SKS server
>     will choose the most rigorous KeyClass from its list of authorized
>     key-classes for *that* client to generate the key.  If there is not
>     a single specific key-class that applies to that client, the Default
>     KeyClass will be used;
> D) SKS Server now generates the key, escrows it, and returns the object
>     in a SymkeyResponse using the SKSML protocol.
> Some important things to note:
> i) The SKS server NEVER deletes a key on its own regardless of when it
>     expires.  The SO can choose to deactivate keys they don't use, or
>     delete them either through the Administration Console or through a
>     scheduled job.  In any case, a client cannot just automatically get
>     an existing symmetric key because it asked for it.  It must be
>     explicitly authorized to get a specific key, through an individual
>     KeyGrant or a group KeyGrant (where the client is part of a group of
>     clients that are authorized to get a specific key.  Groups can also
>     be granted access to all keys within a KeyGroup, thereby avoiding
>     the need to keep providing explicit grants to every key in the
> SKMS).
> ii) An SKMS is designed to not just manage millions, but trillions -
>     2^64 actually - of keys (subject to hardware limitations).  It is my
>     personal belief that within 10 years, ALL data will get encrypted,
>     since it will be less expensive to encrypt all data than to make a
>     decision of what to encrypt and what not to encrypt.  As a result,
>     there will be an EKMI in every enterprise serving up billions of
> keys
>     for every application in their infrastructure.  So, the design is
>     deliberate and conscious.
> iii) A client is NEVER expected to generate a key on its own.  Why?
>     Here is an excerpt from the ACM paper I published some months ago,
>     which answers the question:
> -----
> An alternative architecture is to define policies centrally and push 
> them down to the clients, and similarly have the clients generate keys 
> locally and push them up to the server.  However, the SKMS architecture 
> avoided this design for one reason: to avoid the possibility of 
> catastrophic data-loss.
> If a client were to generate a symmetric key locally, encrypt the 
> plaintext, delete the plaintext (to eliminate the vulnerability), but 
> cannot persist or send the generated symmetric key to the server for any
> reason, the plaintext might be lost forever.
> While it is possible to design around such conditions, the complexity of
> the SKCL increases significantly because it is difficult to predict 
> potential catastrophic conditions on a client machine - especially 
> mobile devices.  With centralized policy-definition and key-generation, 
> this loss is avoided altogether by escrowing the symmetric key first, 
> and then sending it to the client for use.
> -----
> In conclusion, there are a number of things that are not explicit in the
> SKSML protocol.  This is deliberate because vendors need the flexibility
> to innovate above the protocol.  All the capability I've described above
> are in StrongKey 1.0 (whose source is available openly, as you know).
> But, if another wants to above and beyond this, they should feel free to
> do so, while conforming to the SKSML protocol (if they want to be OASIS
> standards compliant).
> If the TC believes that more of this capability needs to be in an OASIS
> standard, this can be done in a sub-committee of the EKMI TC.  As a
> member of the TC, you are entitled to - and even encouraged - to start
> new sub-committees that focus on new aspects of EKMI if you wish.  The
> only thing you need to be cognizant of, are the OASIS rules for how it
> needs to get done; that's all.
> For the initial goal, this TC decided that standardizing SKSML 1.0 was a
> priority.  It also decided that it will create Implementation and Audit
> Guidelines as its next steps.  But, there's nothing to prevent a new
> sub-committee from spinning up and starting a new activity at any time.
> (That's exactly what we did with the Flash Demo subcommittee a couple of
> months ago).
> I apologize for this long e-mail response, Tim, but I hope it gave you
> the answers you were looking for.  If not, keep asking even if it
> appears you are sinking the boat - you won't be, I assure you. :-)
> Arshad Noor
> StrongAuth, Inc.
> Bruce, Timothy R wrote:
>> Forgive me if I am seen as, "rocking the boat," but I do need some 
>> clarification on the current SKSML specification.  I do see how the 
>> current specification could be employed to implement a network enabled
>> symmetric key management architecture, but I am concerned about the
> lack 
>> of information about the client application or device as seem from the
> SKS.
>> The vision as described by the OASIS TC assumes the existence of a 
>> variety of traditional and non-traditional applications and devices 
>> scattered about within an enterprise all capable of cryptography and 
>> therefore all needing an integrated key management solution.  The 
>> proposed architectural solution from the TC involves the client-server
>> model enabled by a standardized protocol for requesting and delivering
>> key materials. 
>> Clearly the proposed SKSML specification delivers such a protocol, but
>> what I am concerned about is how well the server will scale based upon
>> the proposed specification.  To get right to the point, what I see as 
>> missing from an SKS server standpoint is the ability to intelligently 
>> create and maintain policy-based key pools at the server where
> different 
>> pools or types of pools have different characteristics based upon how 
>> the key is used by the application requesting the key.
>> Take a simple scenario where I have a need to encrypt at-rest data on 
>> backup tape devices and ensure that the keys are retained for 10-years
>> from their last use in encrypting data, and I have a second need like 
>> the one Arshad mentioned during the June meeting where I want to
> encrypt 
>> browser cookies across every desktop and laptop in my enterprise (say 
>> 60,000).  Clearly from a server perspective I probably do not need to 
>> keep the key used to encrypt cookies for 10-years, and with 60,000 
>> desktops and laptops running browsers and requesting new keys on a 
>> regular basis this could result in millions of keys being retained at 
>> the server way beyond their usefulness.
>> Now I could define key classes on the server and establish policies
> for 
>> how to manage the keys based upon the key class, but that means that
> for 
>> every application or device I want to bring on-line and manage in
> unique 
>> ways I will need to define a new key class at the server and every 
>> instance of that application or device would need to be configured to 
>> request keys from that key class.
>> What I was hoping to see in terms of an EKMI specification was one
> which 
>> supported plug-and-play as well as customized configurations.  To be 
>> plug-and-play, I believe the standard needs to also contemplate 
>> standardized protocol elements and values to place client applications
>> and devices into a finite series of classifications.  And so backup 
>> applications and/or devices could be easily identified as such by the 
>> SKS server and a policy at the server could associate all backup 
>> applications and devices with a specific key class (key pool with
> common 
>> management characteristics).  A web browser would also have a assigned
>> value that was part of the SKSML specification, which again would
> allow 
>> the SKS server to properly classify the client application and assign 
>> the proper key class without having to configure anything outside of
> the 
>> SKS server (plug-and-play).  The SKSML already allows an application
> to 
>> request a key from a specific key class, so the flexibility is there
> to 
>> customize applications and SKS policies could choose to honor keys
> from 
>> specific classes or could decide to ignore the key class requested by 
>> the application and based upon other controlling SKS server policies
> and 
>> the application's "classification" the SKS server would decide upon
> the 
>> proper key class.  SKS server policies could also be written to
> combine 
>> information based upon the application's or device's classification
> with 
>> information from the CN of its X.509 certificate and/or it's requested
>> key class to provide a more granular set of managed key classes.  But
> if 
>> the SKS server is not provided with some sort of information that
> would 
>> allow the server to classify the type of application or device, then 
>> plug-and-play becomes very difficult without treating all keys as
> equals 
>> in terms of retention, access and caching policies.
>> In the interest of plug-and-play, I also believe it is necessary for
> the 
>> SKSML to allow the client to request a key for a specific algorithm in
> a 
>> strength that is supported by the client application.  Of course, one 
>> implementation would be to have key classes associated with specific 
>> algorithms and key strengths but if we are to enable industry-wide 
>> plug-and-play then the SKSML should establish standardized key classes
>> that are part of the specification and must therefore be supported by 
>> any SKS server implementation.
>> To achieve some of this application and device awareness at the SKS 
>> server, the key class is one possibility or this information could be 
>> passed via the CN information of the X.509 certificate, but either way
>> if the values to classify the generic types of applications and
> devices 
>> as well as the algorithms supported by the client are not industry 
>> standardized values then I do not see how this could foster a 
>> plug-and-play key management capability.
>> Where have I gone wrong?
>> */Tim Bruce/*
>> /Principal Software Architect, Development/
>> /5465 Legacy Drive/
>> /Plano, Tx.  75024/
>> /tel:  214-473-1917/
>> /fax:  214-473-1069/
>> <http://www.ca.com/>

Anil Saldhana
Leader, JBoss Security & Identity Management
Red Hat Inc
URL: http://jboss.org/jbosssecurity
BLOG: http://anil-identity.blogspot.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]