OASIS Charter Submission Discuss

 View Only

Re: [oasis-charter-discuss] EKMI

  • 1.  Re: [oasis-charter-discuss] EKMI

    Posted 11-19-2006 01:57
    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