RE: [Ietf-keyprov] Re: [oasis-charter-discuss] EKMI

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

The reason I abandonded that line was that you told me about your difficulties clearing the IPR minefield in a two pass protocol like XKMS.

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
> Sent: Saturday, November 18, 2006 9:11 PM
> To: Arshad Noor
> Cc: Hallam-Baker, Phillip; June Leung; ken@adler.net; 
> ietf-keyprov@safehaus.org; Terwilliger, Ann; John Messing; 
> oasis-charter-discuss@lists.oasis-open.org; Davi Ottenheimer
> Subject: Re: [Ietf-keyprov] Re: [oasis-charter-discuss] EKMI
> 
> 
> I guess this isn't quite the right list, but since I didn't start
> it:-)
> 
> The only reason I can think of to not extend xkms to 
> encompass symmetric key management is not-invented-here.
> 
> I'd be quite interested in knowing why that's wrong, and 
> slightly interested in whether or not oasis has acquired 
> enough sophistication to make a considered decision rather 
> than simply do whatever N members want.
> 
> To be clear: I think keyprov has a clear scope though of 
> course it could go wrong if it crossed over into emu or (the 
> now dead) sacred territory. Ekmi doesn't make much sense to 
> me fwiw, extending xkms does.
> 
> S.
> 
> Arshad Noor wrote:
> > Phillip,
> > 
> > I have reviewed these Internet-Drafts (I-D) that have been 
> published 
> > so far:
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-vassilev-portable-symmetric-
> > key-container-02.txt
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-pei-dynamic-symkey-prov-prot
> > ocol-01.txt
> > 
> > 
> > and believe the goals of the KEYPROV IETF WG and the 
> EKMI-TC are quite 
> > different.
> > 
> > KEYPROV is targeting a protocol for provisioning credentials that, 
> > amongst other meta-data, consist of "shared secrets".  These
> > *credential-secrets* (referred to as symmetric keys in the 
> I-D's) are 
> > used for primarily authenticating resources against validating 
> > systems.
> > 
> > The EKMI-TC is targeting a protocol - Symmetric Key Services Markup 
> > Language (SKSML) - for the life-cycle management (provisioning, 
> > escrow, recovery, caching, destruction, etc.) of *symmetric 
> encryption
> > keys* (such as 3DES, AES, etc.).  These keys are used for 
> encryption 
> > of business data and not for authentication.
> > 
> > The confusion between the WG and TC charters arises because of the 
> > industry's (sometimes misguided) notion for referring to 
> the "shared 
> > secrets" of authentication credentials as "symmetric keys" 
> - which is 
> > similar to the term used by cryptographers when referring to 
> > encryption/decryption keys used with symmetric ciphers.
> > 
> > In addition, the use of such algorithms (3DES, AES) and symmetric- 
> > encryption keys by the KEYPROV protocols to protect the "shared 
> > credential secret" during provisioning, adds to the confusion.
> > Some might be misled into thinking that 3DES/AES keys are being 
> > provisioned by the Provisioning System for general use by business 
> > applications, as opposed to the use of those symmetric 
> encryption keys 
> > by the Provisioning System and the Credential Container for 
> securely 
> > transporting the credential-secret between the two.
> > 
> > (Think of SKSML as the protocol that *might* be used by the 
> > implementers of a KEYPROV-based Provisioning  System, to acquire 
> > symmetric encryption keys from a centralized Symmetric Key Sevices 
> > server, rather than generating one itself.  The 
> implementers might do 
> > this if there is a need for long-lived symmetric-encryption key 
> > management rather than just for the transient need during the 
> > credential-provisioning process).
> > 
> > Given the goals and the details in the I-D's, what is misleading, 
> > consequently, are the terms in use for the WG and the I-D's.  More 
> > appropriate terms might have been "CREDPROV", "Portable Credential 
> > Container" and "Dynamic Credential Provisioning Protocol" 
> for the WG 
> > and the I-D's respectively.
> > 
> > If the WG is wedded to the name and terms in the I-D, I would 
> > encourage a paragraph or two in the charter and the Drafts, that 
> > articulates the difference between the "credential-secrets"
> > provisioned through the protocols in the I-D's, and symmetric 
> > encryption keys such as DES, 3DES and AES used for 
> encryption of data 
> > like social-security numbers, credit-card numbers, etc.
> > If we are agreed on my understanding of the KEYPROV goals, it is 
> > almost certain that the documentation produced by the EKMI-TC will 
> > highlight this difference.
> > 
> > While XKMS is more closer to the focus of the SKSML, given 
> that XKMS 
> > was architected on the premise of provisioning asymmetric 
> keys, trying 
> > to extend XKMS to accomodate symmetric-encryption keys 
> would be akin 
> > to hammering a round peg into a square hole - while it can 
> be done, it 
> > may not look pretty and might become cumbersome to implementers who 
> > wish to focus on only one or the other form of 
> key-management.  There 
> > is nothing to prevent an implementer from implementing both 
> protocols 
> > in a single application if two distinct libraries took care of the 
> > mechanics; most applications do this today rather than try to 
> > shoe-horn every need into a single protocol.
> > 
> > SAML, once again, is focused more on authentication rather 
> than on a 
> > life-cycle management protocol for symmetric-encryption 
> keys; as such, 
> > I see no overlap.
> > 
> > I trust this addresses the questions raised.  If I have mis- 
> > understood the I-D's, and it was indeed, the KEYPROV WG's 
> intention to 
> > provision and manage symmetric encryption keys, please 
> point me to the 
> > relevant sections of the I-D that focuses on that.  I will re-read 
> > those sections more carefully and respond again.
> > 
> > Thanks.
> > 
> > Arshad Noor
> > StrongAuth, Inc.
> > 
> > Hallam-Baker, Phillip wrote:
> >> In addition to the issue raised re XKMS and SAML I would 
> like to make 
> >> the members of this group aware of KEYPROV a group proposed to do 
> >> similar work that has already begun the chatering process 
> in the IETF.
> >> A BOF was held last week and a charter is currently being 
> discussed 
> >> on the mailing list:
> >>  
> >> To join the mailing list:
> >>
> >> _http://www.safehaus.org/mailman/listinfo/ietf-keyprov_
> >>
> >>  
> >> Provisional draft charter:
> >>  
> >> Current developments in inter-domain Shared Symmetric Key 
> tokens and 
> >> inter-domain use of Kerberos have highlighted the need for 
> a standard 
> >> protocol for provisioning symmetric keys.
> >>
> >> The need for provisioning protocols in PKI architectures has been 
> >> recognized for some time. Although the existence and 
> architecture of 
> >> these protocols provides a feasibility proof for the KEYPROV, 
> >> assumptions built into these protocols make them inapplicable to 
> >> symmetric keys.
> >>
> >> In particular the ability to provision symmetric keys and 
> associated 
> >> attributes dynamically to already issued devices such as 
> cell phones 
> >> and USB drives is highly desirable. The working group will develop 
> >> the necessary protocols and data formats required to support 
> >> provisioning and management of symmetric key 
> authentication tokens, 
> >> both proprietary and standards based.
> >>
> >> Deliverables:
> >>
> >>     * Requirements and use cases
> >>     * Protocol specification
> >>     * Key Container specification
> > 
> > _______________________________________________
> > Ietf-keyprov mailing list
> > Ietf-keyprov@safehaus.org
> > http://www.safehaus.org/mailman/listinfo/ietf-keyprov
> > 
> 
> 
>