Re: [oasis-charter-discuss] EKMI

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

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