[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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/>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]