[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pki-tc] Re: [ekmi] SKSML Specification Question
Yes, indeed. The current XML namespace for EKMI is proposed to be: http://docs.oasis-open.org/ekmi/2008/01 This allows us to come up with multiple versions in the same year also, if necessary. Arshad Tomas Gustavsson wrote: > > 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: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 >> --------------------------------------- >> >> --------------------------------------------------------------------- >> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]