Regarding future versions. I guess the xmlns can be used by the SKS to
support different versions of the protocol in parallel right?
/Tomas
Anil Saldhana wrote:
> 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.
>
> http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd82ccc6716bbe36ec/index
>
>
> 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:
> http://tinyurl.com/5ostxm
>
>
> 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:] Sent: Wednesday,
>> June 18, 2008 6:42 PM
>> To: Bruce, Timothy R
>> Cc: ; 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
> ---------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
