Re: Fw: [oasis-charter-discuss] EKMI Pre-Launch Teleconference

[Arshad Noor <arshad.noor@strongauth.com>]

Thank you for your comments, Anthony.  I apologize for the delay
in responding but I had been traveling last week and am just now
getting caught up.  However, your comments were discussed in the
OASIS con-call and we are incorporating some of your suggestions
in the charter document.

For the record, I do want to respond to your comments on the forum,
so that you are aware of how we're addressing them.

It appears that I may not have explained the premise on which the
EKMI architecture and the SKSML protocol is based, and that would
explain the conclusion to which you have arrived.  I will attempt
to correct that error.

The architecture and protocol are based on the premise that a
company:

1) wants to define encryption policy centrally;
2) wants to manage symmetric keys centrally and uniformly; and
3) wants to optimize the TCO of such an infrastructure;

While there are many models that can meet these requirements, we
based the architecture of SKMS on that of Domain Name Service (DNS).

DNS, as I'm sure you're familiar with, requires that the namespace
and IP addresses be defined on centrally-managed DNS servers, and
that clients only query the nameservers for information.  DNS
clients do not add/update/delete nameservice information on the
servers (except within the limited scope of DHCP, which is but a
variation of the centralized policy definition and name-IP address
management principle); so their protocol is mostly limited to
querying the DNS server for name-service information.

The implementation requirements that we heard from customers were
that:

a) the server must do all the heavy-lifting of key-generation, key-
    management, access-control, etc.;
b) client applications must require minimal modifications to
    participate in this architecture and process;

Given these, while it is possible to have a client generate symmetric
keys and send it to a server for addition/update/deletion, it would
require far more of the client-application and of the security
infrastructure to trust such add/update/deletes from client devices.
Secondly, ensuring that all clients conform to policy would require
that all clients be continually updated to know of such policies and
when such policies are updated.

By having the server perform ALL the work wrt key-generation, policy
conformance and key-management, it simplifies client-requirements to
using just one call - that of requesting a symmetric key (new or
existing) and using that key within the policy-constraints embedded
inside each key (the SKSML protocol embeds a KeyUsePolicy inside each
symmetric key).  The server handles the rest.

Consequently, client applications in a Symmetric Key Management System
(SKMS) need only know how to request a key and where to request it from.
The Symmetric Key Client Library (SKCL) handles the rest - just like the
nameservice library in DNS handles all name-resolution activties for all
applications on a machine.

WRT to your comments in the scope section:

1) The "space" in which the SKSML protocol will be used is between
    any client and server that needs symmetric key-management services
    in any domain.  The need for asymmetric key-management services are
    currently addressed by IETF-PKIX protocols and are not within scope
    of the EKMI charter;

2) Sending of keys TO the server is not within the initial scope of
    this TC, given the premise described earlier.  However, as the TC
    addresses the initial problem and evolves, business requirements
    from constituents may expand the scope to address sending keys to
    the server;

3) Yes, the interoperability test suite is a compliance suite;

4) WRT scope item D, this TC has heard business requirements from
    customers that would like to see implementation, operational and
    audit guidelines for building, operating and auditing EKMI
    infrastructures for compliance to specific regulations such as
    PCI-DSS (as an example).  This TC intends to create papers that
    provide such guidelines for implementing and operating EKMI's.
    WRT the audit requirements, it is the intention of this TC to
    work cooperatively with organizations such as ISACA to create
    audit guidelines that would be used by auditors to audit EKMI
    infrastructures.

WRT timelines, the original draft of this charter was written up in
August; the timelines are being revised to recognize the passage of
time to create this TC.

The EKMI-TC will have a liaison relationship with the WS-Trust TC.
I have already addressed the XKMS question in response to Phillip
Hallam-Baker's comments on this forum.

I trust the above helps clarify some of the confusion that may have
been caused by the charter.  We anticipate writing up use-cases as
part of the documentation produced by the TC to further clarify how
and where the SKSML protocol may be used.

Regards,

Arshad Noor
StrongAuth, Inc.


Anthony Nadalin wrote:
> After reading the charter, and reading the related information the 
> charter pointed (StongAuth SKML description from here: 
> http://www.strongkey.org/resources/documentation/misc/skcl-sks-protocol.html) 
> to I have the following general comments:
> 
> This thing looks to me like it is addressing only a VERY SMALL subset of 
> what is needed. It looks to me like what is there right now covers ONLY 
> the case of requesting retrieval (i.e. "List"/"read" operation) of a 
> symmetric key. This one seems like the relatively EASY one to solve. The 
> others ( add/modify/delete/query ) will require much more work and don't 
> seemed to covered in the related material or in the charter
> 
> It is good to see that StrongAuth has shown examples of using "SOAP 
> bindings" but stopped short, as protocols like WS-Trust already handle 
> symmetric and asymmetric keys and provide for a better transport. For 
> Key management/administration though, I think there is quite a bit more 
> that needs to be defined that is not covered in the related material or 
> in the charter. There is no real in/out of scope items for this TC which 
> makes me think that the will be far too much uncertainty.
> 
> There is other standards work in this space and there is no clear 
> relationship called out in the charter.
> 
> Specific Charter comments marked <ajn>:
> 
> PROPOSED CHARTER
> FOR REVIEW AND COMMENT
> OASIS ENTERPRISE KEY MANAGEMENT INFRASTRUCTURE TECHNICAL COMMITTEE
> 
> Name
> 
> OASIS Enterprise Key Management Infrastructure (EKMI) TC
> 
> Statement of Purpose
> 
> Public Key Infrastructure (PKI) technology has been around for more
> than a decade, and many companies have adopted it to solve specific
> problems in the area of public-key cryptography.  Public-key
> cryptography has been embedded in some of the most popular tools --
> web clients and servers, VPN clients and servers, mail user agents,
> office productivity tools and many industry-specific applications --
> and underlies many mission-critical environments today.
> Additionally, there are many commercial and open-source
> implementations of PKI software products available in the market
> today.  However, many companies across the world have recognized
> that PKI by itself, is not a solution.
> 
> <ajn> Also, it seems that the use of PKI for SSL/TLS communications link 
> protection is the most
> common usage (to protect various protocols - HTTP, LDAP - and to 
> implement VPN with
> SSL-based VPN solutions). </ajn>
> 
> There is also the perception that most standards in PKI have already
> been established by ISO and the PKIX (IETF), and most companies are
> in operations-mode with their PKIs -- just using it, and adopting it
> to other business uses within their organizations. Consequently,
> there is not much left to architect and design in the PKI community.
> 
> <ajn> While companies are "using PKI", they are not, in wide usage, 
> deploying their own PKI - rather
> they are procuring certificates from that subset of CAs (PKIs) that are 
> held within browser
> default trusted signers lists. Other usages are "hidden"/"buried" inside 
> products. The current
> situation, IMO, with public/private keys is that companies don't know 
> how fragmented
> their usage really is. </ajn>
> 
> Simultaneously, there is a new interest on the part of many
> companies in the management of symmetric keys used for encrypting
> sensitive data in their computing infrastructure. While symmetric
> keys have been traditionally managed by applications doing their own
> encryption and decryption, there is no architecture or protocol that
> provides for symmetric key management services across applications,
> operating systems, databases, etc. While there are many industry
> standards around protocols for the life-cycle management of
> asymmetric (or public/private) keys -- PKCS10, PKCS7, CRMF, CMS,
> <ajn> XKMS?  </ajn>etc.
> 
> <ajn> (also, the protocols/formats listed here seem tied to CA/RA <-> 
> Entity communication - not the
> management of keys/certs distributed across a variety of key storage 
> media within an organization.
> This latter problem still requires attention.) </ajn>
> 
> -- however, there is no standard that describes how applications may
> request similar life-cycle services for symmetric keys, from a
> server and how public-key cryptography may be used to provide such
> services.
> <ajn> similar problems exist for both symmetric and asymmetric key 
> management. </ajn>
> 
> Key management needs to be addressed by enterprises in its
> entirety -- for both symmetric and asymmetric keys.  While each type
> of technology will require specific protocols, controls and
> management disciplines, there is sufficient common ground in the
> discipline justifying the approach to look at key-management as a
> whole, rather than in parts.  Therefore, this TC will address the
> following:
> 
> Scope
> 
> <ajn> 0) TC will publish a Note defining the "space" for these 
> protocols, as distinct from existing work
> in areas of CA/RA <-> Entity communications </ajn>
> 
> A) The TC will define the request/response protocols for:
> 
> 1. Requesting a new or existing symmetric key <ajn> (why just 
> symmetric?)  </ajn> from a server;
> 2. Requesting policy information from a server related to caching of
> keys on the client;
> 3. Sending a symmetric key <ajn> (why just symmetric?) </ajn> to a 
> requestor, based on a request;
> 4. Sending policy information to a requestor, based on a request;
> 5. Other protocol pairs as deemed necessary.
> 
> <ajn> What about sending keys TO the server?
> Query of keys (and/or information about such keys) in a server?
> Add/Generate/Modify/Delete/List/Query of key(s) </ajn>
> 
> B) To ensure cross-implementation interoperability, the TC will
> create a test suite (as described under 'Deliverables' below) that
> will allow different implementations of this protocol to be
> certified against the OASIS standard (when ratified);
> 
> </ajn> Is this a compliance suite ? </ajn>
> 
> C) The TC will provide guidance on how a symmetric (and 
> asymmetric) key-management
> (key management as distinct from CA/RA <-> Entity communications).
> infrastructure may be secured using asymmetric keys, using secure
> and generally accepted practices;
> 
> D) Where appropriate, and if possible in conjunction with other
> standards organizations that focus on disciplines
> outside the purview of OASIS, the TC will provide input on how such
> enterprise key-management infrastructures may be managed, operated
> and audited;
> 
> </ajn> You have lost me here </ajn>
> 
> 
> E) The TC may conduct other activities that educate users about,
> and promote, securing sensitive data with appropriate cryptography,
> and the use of proper key-management techniques and disciplines to
> ensure appropriate protection of the infrastructure.
> 
> List of Deliverables
> 
> 1. XSchema Definitions (XSD) of the request and response protocols
> (by April 2007)
> 2. A Test Suite of conformance clauses and sample transmitted keys
> and content that allows for clients and servers to be tested for
> conformance to the defined protocol (by September 2007)
> 3. Documentation that explains the communication protocol (by
> April 2007)
> 4. Documentation that provides guidelines for how an EKMI may be
> built, operated, secured and audited (by June 2007)
> 5. Resources that promote enterprise-level key-management: white
> papers, seminars, samples, and information for developer and public
> use. (beginning January 2007, continuing at least through 2008)
> 
> </ajn> Based upon what I have seen in the related material this is a far 
> too aggressive
> schedule </ajn>
> 
> 
> Anticipated Audiences:
> 
> Any company or organization that has a need for managing
> cryptographic keys <ajn> which are used </ajn> across applications, 
> databases, operating systems
> and devices, yet desires centralized policy-driven management of all
> cryptographic keys <ajn> (and multiple copies of such keys) </ajn> in 
> the enterprise. Retail, health-care,
> government, education, finance - every industry has a need to
> protect the confidentiality of sensitive data. The TC's
> deliverables will provide an industry standard for protecting
> sensitive information across these, and other, industries.
> Security services vendors and integrators should be able to fulfill
> their use cases with the TC's key management methodologies.
> Members of the OASIS PKI TC should be very interested in this new TC,
> since the goals of this TC potentially may fulfill some of the
> goals in the charter of the PKI TC. <ajn> Also coordinate with WS-SX TC. 
> </ajn>
> 
> <ajn> Coordination with other standards bodies' efforts - known work 
> underway or existing:
> - TCG ESSG subgroup of Storage WG
> - IETF Keyprov BOF
> - W3C existing XKMS work </ajn>
> 
> Language:
> 
> English
> 
> IPR Policy:
> 
> Royalty Free on Limited Terms under the OASIS IPR Policy
> 
> ----
> Additional Non-normative information regarding the start-up of the TC:
> 
> a. Identification of similar or applicable work:
> 
> The proposers are unaware of any similar work being carried on in
> this exact area. <ajn> (See above - there is other work 
> underway) </ajn>  However,
> this TC intends to leverage the
> products of, and seek liaison with, a number of other existing
> projects that may interoperate with or provide functionality to the
> EKMI TC's planned outputs, including:
> 
> OASIS Web Services Security TC
> W3C XMLSignature and XMLEncryption protocols and working group
> OASIS Digital Signature Services TC
> OASIS Public Key Infrastructure TC
> OASIS XACML TC (and other methods for providing granular
> access-control permissions that may be consumed or enforced by
> symmetic key management)
> 
> b.  Anticipated contributions:
> 
> StrongAuth, Inc. anticipates providing a draft proposal for the EKMI
> protocol, at the inception of the TC.  The current draft can be
> viewed at:
> 
> http://www.strongkey.org/resources/documentation/misc/skcl-sks-protocol.html
> and a working implementation of this protocol is available at:
>   http://sourceforge.net/projects/strongkey for interested parties.
> 
> c. Proposed working title and acronym for specification:
> 
> Symmetric Key Services Markup Language (SKSML), subject to TC's
> approval or change.
> 
> d.  Date, time, and location of the first meeting:
> 
> First meeting will be by teleconference, with an optional face-to-
> face gathering as one conference call node, at:
> Date:  [December ____, 2006]
> Time:  [____ UTC]
> Call in details'; to be posted to TC list
> F2F Location:  San Francisco Bay Area.  StrongAuth has agreed to
> host this meeting.
> 
> e. Projected meeting schedule:
> 
> Subject to TC's approval, we anticipate monthly telephone meetings
> for the first year. First version of the protocol to be voted on by
> Summer 2007. StrongAuth is willing to assist by arranging for the
> teleconferences; we anticipate using readily available free
> teleconference services.
> 
> f. Names, electronic mail addresses, of supporters:
> 
> Ken Adler, individual member, ken@adler.net
> June Leung, FundSERV, June.Leung@FundServ.com
> John Messing, American Bar Association, jmessing@law-on-line.com
> Arshad Noor, individual member, arshad.noor@strongauth.com
> Davi Ottenheimer, individual member, davi@poetry.org
> Ann Terwilliger, Visa International, aterwil@visa.com
> 
> g. TC Convener:
> 
> Arshad Noor, arshad.noor@strongauth.com
> 
> END DRAFT
> 
> 
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>