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

[Stephen Farrell]

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-protocol-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 at safehaus.org
> http://www.safehaus.org/mailman/listinfo/ietf-keyprov
>