Re: [ekmi] SKSML Specification Question

[Anil Saldhana <Anil.Saldhana@redhat.com>]

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.

Isn't this an operational aspect?  Cluster/Farms of Key Management Servers?


> 
>  
> 
> 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.

We should chart out use cases and plug in auxiliary artifacts to the 
v1.0 specification over time.
> 
>  
> 
> 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
---------------------------------------