Network Working Group                                             M. Pei
Internet-Draft                                                  VeriSign
Intended status: Standards Track                              S. Machani
Expires: April 26, 2007                                       Diversinet
                                                        October 23, 2006


              Dynamic Symmetric Key Provisioning Protocol
             draft-pei-dynamic-symkey-prov-protocol-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).













Pei & Machani            Expires April 26, 2007                 [Page 1]

Internet-Draft         Symmetric Key Provisioning           October 2006


Abstract

   This document specifies a symmetric key provisioning protocol that
   supports provisioning of symmetric keys (One Time Password (OTP) keys
   or symmetric cryptographic keys) and associated attributes
   dynamically to already issued different types of strong
   authentication devices.

   This work is a joint effort by the members of OATH (Initiative for
   Open AuTHentication) to specify a protocol that can be freely
   distributed to the technical community.  The authors believe that a
   common and shared specification will facilitate adoption of two-
   factor authentication on the Internet by enabling interoperability
   between commercial and open-source implementations.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.1.  A mobile device user obtains an HOTP symmetric key . .  4
       1.2.2.  A user acquires multiple symmetric keys of
               different types  . . . . . . . . . . . . . . . . . . .  5
       1.2.3.  A key provisioning service imposes a validity
               period policy for provisioning sessions  . . . . . . .  5
       1.2.4.  A symmetric key issuer uses a third party
               provisioning service provider  . . . . . . . . . . . .  5
       1.2.5.  A client application uses a pre-shared transport
               key to communicate with provisioning provider  . . . .  5
       1.2.6.  A user renews its credential with the same
               credential ID  . . . . . . . . . . . . . . . . . . . .  6
       1.2.7.  An administrator initiates a credential
               replacement before it can be used  . . . . . . . . . .  6
       1.2.8.  A user acquires a credential through SMS . . . . . . .  6
       1.2.9.  A client acquires a credential over a transport
               protocol that doesn't ensure data confidentiality  . .  7
       1.2.10. A client acquires a credential over a transport
               protocol that doesn't provide authentication . . . . .  7
     1.3.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  7
     1.4.  Good to have requirements  . . . . . . . . . . . . . . . .  8
     1.5.  Non-Requirements . . . . . . . . . . . . . . . . . . . . .  8
   2.  Notations and Terminology  . . . . . . . . . . . . . . . . . . 10
     2.1.  Conventions used in this document  . . . . . . . . . . . . 10
     2.2.  Acronyms and Abbreviations . . . . . . . . . . . . . . . . 10
     2.3.  XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 10
   3.  Protocol Flow  . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.1.  Request and Response Messages  . . . . . . . . . . . . . . 12



Pei & Machani            Expires April 26, 2007                 [Page 2]

Internet-Draft         Symmetric Key Provisioning           October 2006


     3.2.  Symmetric Key Container Format . . . . . . . . . . . . . . 13
     3.3.  Encryption Key for Credential Response . . . . . . . . . . 13
   4.  Authentication . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Client Authentication  . . . . . . . . . . . . . . . . . . 14
     4.2.  Server Authentication  . . . . . . . . . . . . . . . . . . 15
   5.  Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  SecretContainer  . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  ActivationCode . . . . . . . . . . . . . . . . . . . . . . 16
     5.3.  AuthenticationDataType . . . . . . . . . . . . . . . . . . 18
   6.  Protocol Messages  . . . . . . . . . . . . . . . . . . . . . . 20
     6.1.  GetAuthNonce . . . . . . . . . . . . . . . . . . . . . . . 20
     6.2.  GetAuthNonceResponse . . . . . . . . . . . . . . . . . . . 20
     6.3.  GetSharedSecret  . . . . . . . . . . . . . . . . . . . . . 21
     6.4.  GetSharedSecretResponse  . . . . . . . . . . . . . . . . . 23
   7.  Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 25
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     8.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 26
     8.2.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 27
     8.3.  Integrity  . . . . . . . . . . . . . . . . . . . . . . . . 27
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 29
   Appendix A.  XML Schema  . . . . . . . . . . . . . . . . . . . . . 30
   Appendix B.  Example Requests and Responses  . . . . . . . . . . . 38
     B.1.  Simple client message exchange for acquiring a
           credential with an activation code . . . . . . . . . . . . 38
     B.2.  Full message exchanges for a client over a non-secure
           channel  . . . . . . . . . . . . . . . . . . . . . . . . . 39
   Appendix C.  Transport Consideration . . . . . . . . . . . . . . . 42
     C.1.  No security provided in transport layer  . . . . . . . . . 42
     C.2.  Confidentiality provided in transport layer  . . . . . . . 42
     C.3.  Confidentiality and mutual authentication provided in
           transport layer  . . . . . . . . . . . . . . . . . . . . . 42
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
   Intellectual Property and Copyright Statements . . . . . . . . . . 44

















Pei & Machani            Expires April 26, 2007                 [Page 3]

Internet-Draft         Symmetric Key Provisioning           October 2006


1.  Introduction

1.1.  Overview

   This Internet draft describes a standard client-server protocol that
   enables a client device to download and install authentication
   credentials from a provisioning server in a secure and efficient
   manner.  The prime example of such an authentication credential is a
   shared secret for One-Time-Password (OTP) software token in a device.
   The protocol is for dynamic provisioning of shared secret to a user
   device; it is not a bulk provisioning protocol that transfers token
   records from a provisioning server to an authentication system.

   This protocol will only support the provisioning of symmetric secret
   key types.  Asymmetric key pair provisioning isn't the purpose of
   this protocol.  The protocol is a web services XML-based protocol
   with multiple profiles to support lightweight small footprint clients
   such as smart cards, as well as more advanced device platforms such
   as USB tokens and PDAs/smart phones.

   Existing symmetric key delivery protocols are specific to one
   authentication method, or are proprietary to a particular vendor
   implementation.  The industry needs a simple provisioning protocol
   standard to enable interoperability across vendors and to provision
   multiple shared secret types.

1.2.  Use Cases

   This section describes a comprehensive list of use cases that
   inspired the development of this specification.  These requirements
   were used to derive the primary requirement that drove the design.
   These requirements are covered in the next section.

   In the following, we use words "shared secret" and "credential" to
   mean "symmetric key" when the context is clear.

1.2.1.  A mobile device user obtains an HOTP symmetric key

   A user with a mobile device wants to acquire an HOTP [HOTP] secret
   (symmetric key) to use with a software token in the device.  The
   secret may be pre-generated by a back end issuance server, or
   generated by the provisioning server during the provisioning process.
   A unique Secret ID is assigned to the secret by the provisioning
   server.  This protocol enables the client device to request the
   secret, authenticate to the provisioning server, download the secret
   over-the-air (OTA) and install it on the mobile device.





Pei & Machani            Expires April 26, 2007                 [Page 4]

Internet-Draft         Symmetric Key Provisioning           October 2006


1.2.2.  A user acquires multiple symmetric keys of different types

   A user wants to provision multiple symmetric keys on a device.  The
   symmetric keys may or may not be of the same type.  The keys may be
   used with different algorithms such as HOTP, symmetric challenge-
   response, or others.  The protocol must provide for a mechanism to
   uniquely identify a specific secret in the device using token
   identification to allow device authentication before provisioning.

1.2.3.  A key provisioning service imposes a validity period policy for
        provisioning sessions

   Once a user initiates a symmetric key request, the key provisioning
   service may require that any subsequent actions to complete the
   provisioning cycle within certain time window.  For example, a
   provisioning issuer may provide an authentication code to a user upon
   the user's initial request for a secret key.  Such an authentication
   code is associated with a validity period; a user must consume the
   pick up code to download a secret within the validity window.

1.2.4.  A symmetric key issuer uses a third party provisioning service
        provider

   A symmetric key issuer outsources its key provisioning to a third
   party key provisioning service provider.  The issuer is responsible
   for authenticating and granting rights to users to acquire keys while
   it may delegate the actual key generation and provisioning to a third
   party provisioning service.  The issuer may acquire secret keys on
   behalf of its users from the provisioning service provider or
   redirect the user to acquire the secrets directly from provisioning
   service provider.  In the later case, it is often necessary for a
   user to authenticate to the provisioning service provider.

1.2.5.  A client application uses a pre-shared transport key to
        communicate with provisioning provider

   An HOTP application is loaded to a smart card after the card is
   issued.  The OTP secret for the HOTP application will then be
   provisioned using a secure channel mechanism present in many smart
   card platforms.  This allows a direct secure channel to be
   established between the smart card chip and the provisioning server.
   For example, the card commands (APDU - Application Protocol Data
   Unit) are encrypted with a pre-shared transport key and sent directly
   to the smart card chip, allowing secure post issuance in-the-field
   provisioning.  This secure flow can pass SSL and other transport
   security boundaries.

   This use case requires the protocol to be tunneled and the



Pei & Machani            Expires April 26, 2007                 [Page 5]

Internet-Draft         Symmetric Key Provisioning           October 2006


   provisioning server to know the correct pre-established transport
   key.

1.2.6.  A user renews its credential with the same credential ID

   A user wants to renew its credential with the same credential ID.
   Such a need may occur in the case when a user wants to upgrade its
   token device or a credential has expired.  When a user uses the same
   OTP token in multiple web login sites, keeping the same credential ID
   removes the need for the user to register a new ID to each site.

1.2.7.  An administrator initiates a credential replacement before it
        can be used

   This use case represents a special case of credential renewal in
   which a local administrator can authenticate the user procedurally
   before initiating the dynamic provisioning.  It also allows for keys
   on physical tokens to be issued with a restriction that the key must
   be replaced with a new key prior to token use.

   Bulk initialization under controlled conditions during manufacture is
   likely to meet the security needs of most applications.  However,
   reliance on a pre-disclosed secret is unacceptable in some
   circumstances.  One circumstance is when tokens are issued for
   classified government use or high security applications.  In such
   cases the token issuer requires the ability to remove all the secret
   information installed on the token during manufacture and replace it
   with secret keys established under conditions controlled by the
   issuer.  It is however in most cases impractical for the
   administrator to apply a physical marking to the token itself such as
   a serial number.  It is therefore necessary for the enrollment
   process to communicate the token serial number to the provisioning
   service.

   Another variation of this use case is that some enterprises may
   prefer to re-provision a new secret to an existing token if they
   decide to reuse the token that was with one user and for a new user.

   This case is essentially the same as the last use case where the same
   credential ID is used for renewal.

1.2.8.  A user acquires a credential through SMS

   A mobile device may be able to receive SMS but is not able to support
   a data service allowing for HTTP or HTTPS transports.  In such a
   case, the user may initiates a credential request from a desktop
   computer and asks the server to send the credential to a mobile phone
   through SMS.  The online communication between the desktop computer



Pei & Machani            Expires April 26, 2007                 [Page 6]

Internet-Draft         Symmetric Key Provisioning           October 2006


   and the server can carry out user authentication.

1.2.9.  A client acquires a credential over a transport protocol that
        doesn't ensure data confidentiality

   Some devices are not able to support a secure transport channel such
   as Transport Layer Security (TLS) to provide data confidentiality.  A
   user wants to provision a credential to such a device.  It is up to
   this symmetric key provisioning protocol to ensure data
   confidentiality over non-secure networks.

1.2.10.  A client acquires a credential over a transport protocol that
         doesn't provide authentication

   Some devices are not able to use a transport protocol that provides
   server authentication such as TLS.  A user wants to be sure that it
   acquires a credential from an authentic service provider.  It is up
   to this symmetric key provisioning protocol to provide proper client
   and server authentication.

1.3.  Requirements

   This section outlines the most relevant requirements that are the
   basis of this work.

   R1:   The protocol SHOULD support multiple types of credentials for
         symmetric key based authentication methods.

   R2:   The protocol SHOULD support pre-generated credentials (by
         separate credential issuance service) or locally generated
         credentials in real-time (by provisioning server)

   R3:   The protocol SHOULD allow devices to host multiple credentials;
         each credential may be acquired in a separate provisioning
         session

   R4:   The protocol SHOULD support renewal of a credential with the
         same credential ID.

   R5:   The protocol SHOULD allow clients to specify their
         cryptographic and security capabilities to the server and the
         server to indicate the cryptography and algorithm types that
         will be using.

   R6:   The protocol SHOULD support mutual authentication and
         confidentiality of sensitive provisioning data.





Pei & Machani            Expires April 26, 2007                 [Page 7]

Internet-Draft         Symmetric Key Provisioning           October 2006


   R7:   The protocol SHOULD not require a public-key infrastructure and
         the use of client certificates for device authentication or
         symmetric key data protection.  It must allow for other
         mechanisms such as symmetric key based techniques to be used.

   R8:   The protocol SHOULD not rely on transport layer security (e.g.
         SSL/TLS) for core security requirements.  It should be SSL-
         compatible when available.

   R9:   The protocol SHOULD allow for the transport of the credential
         expiration date set by the credential issuer.

   R10:  The protocol SHOULD allow the server to use pre-loaded
         symmetric transport keys on a device by device basis (smart
         card update keys, e.g. secure channel in Global platform).

   R11:  The protocol SHOULD enable simple user experience for the
         provisioning process.

   R12:  The protocol SHOULD protect against replay attacks.

   R13:  The protocol SHOULD protect against man-in-the middle attacks.

1.4.  Good to have requirements

   This section describes non-mandatory requirements.  These good-to-
   have requirements may be considered in future versions.

   GR1:  The protocol MAY support mutually generated secrets by both
         client and server.

   GR2:  The protocol MAY support a device request to acquire multiple
         credentials in the same session.

   GR3:  The protocol MAY allow the provisioning server to verify that
         the key has been correctly provisioned to the client.

   GR4:  The protocol MAY support a client to notify the server upon
         credential deletion.

1.5.  Non-Requirements

   This section describes not required features.

   NR1:  Support for client generated credential upload to a
         provisioning server





Pei & Machani            Expires April 26, 2007                 [Page 8]

Internet-Draft         Symmetric Key Provisioning           October 2006


   NR2:  Support for other credential lifecycle management functions
         such as credential suspension, lock and activation.  These
         functions are supported in the authentication system

   NR3:  Support for asymmetric key pair provisioning.














































Pei & Machani            Expires April 26, 2007                 [Page 9]

Internet-Draft         Symmetric Key Provisioning           October 2006


2.  Notations and Terminology

2.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In the text below, OTP refers to one time password.  Credential is
   interchangeable with phrase "Symmetric Key Credential" unless it is
   specifically qualified.

2.2.  Acronyms and Abbreviations

   The following (non-normative) list defines acronyms and abbreviations
   for this document.

   OTP  One Time Password

   HMAC  Hashing for Message Authentication

   PSKC  Portable Symmetric Key Container

   SHA1  Secure Hash Algorithm 1

   SOAP  Simple Object Access Protocol

   XML  Extensible Markup Language

2.3.  XML Namespaces

   XML namespace for types defined in this document uses the following:

      xmlns:oath-dskpp="http://www.openauthentication.org/OATH/2006/10/
      DSKPP"

   The protocol also uses XML types defined in [PSKC] for symmetric key.
   We use the following namespace.

      xmlns:oath-pskc=http://www.openauthentication.org/OATH/2006/08/
      PSKC

   It also uses types in [XMLSIG] for XML signature related types.  The
   following namespace is used.







Pei & Machani            Expires April 26, 2007                [Page 10]

Internet-Draft         Symmetric Key Provisioning           October 2006


      xmlns:ds=http://www.w3.org/2000/09/xmldsig#


















































Pei & Machani            Expires April 26, 2007                [Page 11]

Internet-Draft         Symmetric Key Provisioning           October 2006


3.  Protocol Flow

3.1.  Request and Response Messages

   The provisioning protocol consists of two pairs of request and
   response message exchanges between the client and the provisioning
   server.

   The first pair of messages, called GetAuthNonce and
   GetAuthNonceResponse, enables a client to request a nonce value from
   a provisioning server before it sends authentication data in the
   credential request.  The nonce data is used for two purposes: (1) by
   the client to generate the authentication data in a way that it does
   not expose any sensitive information over non-secure networks. (2) by
   the server to mitigate replay attacks.

   The second pair of messages, called GetSharedSecret and
   GetSharedSecretResponse, are the actual credential download messages.
   The client request message may include client authentication data,
   credential type and the client preferences.  The server response
   message includes the encrypted credential and associated
   configuration data.


   |-------------------------------------------------------|
   |                                                       |
   |   Provisioning                          Provisioning  |
   |    Client                                Server       |
   |                                                       |
   |      |                                      |         |
   |      |- - - - - GetAuthNonce - - - - - - -> |         |
   |      |                                      |         |
   |      |<- - - - GetAuthNonceResponse - - - - |         |
   |      |                                      |         |
   |      |                                      |         |
   |      |                                      |         |
   |      |-------- GetSharedSecret -----------> |         |
   |      |                                      |         |
   |      |<------- GetSharedSecretResponse ---- |         |
   |      |                                      |         |
   |                                                       |
   |-------------------------------------------------------|

   The GetAuthNonce is optional in the protocol.  When the protocol runs
   over a secure transport channel, the GetAuthNonce and
   GetAuthNonceResponse message exchange between the client and the
   server may be omitted: The client may initiate the protocol by
   sending the GetSharedSecret request to the server and the server must



Pei & Machani            Expires April 26, 2007                [Page 12]

Internet-Draft         Symmetric Key Provisioning           October 2006


   respond with a GetSharedSecretResponse message.  When the protocol
   runs over a non-secure transport channel, client and server
   implementations must support the GetAuthNonce and
   GetAuthNonceResponse messages: The client must initiate the protocol
   by sending a GetAuthNonce request to the server and the server must
   respond with a GetAuthNonceResponse message containing nonce data
   before the client can send the GetSharedSecret message.

3.2.  Symmetric Key Container Format

   The protocol uses the Portable Symmetric Key Container (PSKC) [PSKC]
   to carry the provisioned symmetric key data to the client.  It also
   allows for other formats such as PKCS#12 [PKCS12] or PKCS#5 XML
   format [PKCS5XML] through a general extension.

3.3.  Encryption Key for Credential Response

   A credential response from a provisioning server may be encrypted
   using one of the following keys:

   o  A pre-established secret key between the client and the server.
      This key may be derived from the activation code that the
      credential issuer provides to a device owner or pre-generated and
      stored on both the server side and the client side.

   o  The public-key of the client certificate when a device certificate
      is used for authentication.

   o  Other server specified keys

   Information about the encryption key used such as the key identifier,
   is provided in the server response message or in the symmetric key
   container.  When PSKC format is used, the encryption method is
   defined by "EncryptionMethodType".  See [PSKC] for more details.

















Pei & Machani            Expires April 26, 2007                [Page 13]

Internet-Draft         Symmetric Key Provisioning           October 2006


4.  Authentication

4.1.  Client Authentication

   The credential provisioning process typically requires client
   authentication prior to a credential being issued.  However, client
   authentication may be in-band or out-of-band.  When authentication is
   required in-band, the client must provide the authentication data in
   the request message to the server and the server must verify the
   authentication data before issuing the credential.  When out-of-band
   authentication is used, the client may send a request to the server
   message without authentication data.  The client in this case must
   have been authenticated by the server through another mean before
   sending the client request message to the server.  For example, a
   provisioning web application for desktop software token may
   authenticate the user first, and then accept a provisioning request
   message; the client application doesn't need to send any
   authentication data inside the credential request message.

   When authentication data is required in the client request, such data
   is typically a device certificate or an one time use authentication
   code, called activation code, acquired out of band by the device user
   owner from the credential issuer.  The following diagram indicates
   relationships among related entities.


    ------------    Get Activation Code   ------------
   |   User     |----------------------->|   Issuer   |
    ------------                          ------------
         |                                     |
         |                                     |
         |                                     |
         V                                     V
    --------------                       --------------
   | Provisioning |                     | Provisioning |
   |   Client     |<------------------->|   Server     |
    --------------                       --------------

   Considering an activation code as a special form of shared secret
   between a user and a provisioning service, the authentication data
   can have one of the following three forms:

      - AuthenticationData = HASH (activation code)

      - AuthenticationData = HMAC (activation code, serverNonce)






Pei & Machani            Expires April 26, 2007                [Page 14]

Internet-Draft         Symmetric Key Provisioning           October 2006


      - AuthenticationData = <Signed data with a client certificate>

   When an activation code is used to initiate the provisioning session,
   the activation code must be sent to the provisioning server in a
   secure way.  If the underlying transport channel is secure, the
   authentication data may contain the plaintext format or the hashed
   format of the activation code using a hash function as follows:

      AuthenticationData = HASH (activation code)

   If the underlying transport is not secure, the client must use both
   the server nonce in the server GetAuthNonceResponse message and the
   activation code to derive authentication data as follows:

      AuthenticationData = HMAC (activation code, serverNonce)

   When a certificate is used for authentication, the authentication
   data may be client signed data.  Authentication data may be omitted
   if client certificate authentication has been provided by the
   transport channel such as TLS.

   When a credential issuer delegates credential provisioning to a third
   party provisioning service provider, both client authentication and
   issuer authentication are required by the provisioning sever.  Client
   authentication to the Issuer may be in-band or out-of-band as
   described above.  The issuer acts a proxy for the provisioning
   server.  The issuer authenticates to the provisioning service
   provider either using a certificate or a pre-established secret key.

4.2.  Server Authentication

   A client can authenticate a provisioning service through either the
   server response verification defined in the protocol or leverage
   transport layer server authentication if it is available.

   Symmetric key container response is typically encrypted with a shared
   secret.  A client can authenticate the service by verification of the
   correct response encryption with expected encryption key.

   In the case where a device certificate is used for authentication,
   server authentication by underlying transport layer should be used
   between the client and the provisioning service.









Pei & Machani            Expires April 26, 2007                [Page 15]

Internet-Draft         Symmetric Key Provisioning           October 2006


5.  Data Types

5.1.  SecretContainer

   This represents the default symmetric key container in a response
   uses <SecretContainerType> define in XML schema namespace "oath-pskc"
   by [PSKC].

5.2.  ActivationCode

   Activation code represents a one time use authentication code given
   by the issuer to the user to acquire a credential.

   An activation code may or may not contain alpha letters in addition
   to numerical digits depending on the device type and issuer policy.
   For a mobile phone, it is often a good practice that only numerical
   digits are used for easy to input.

   An activation code can be sent to the provisioning server in (1)
   plaintext form or (2) hashed data form, or (3) keyed hash data form
   depending on the underlying transport.  These three forms are defined
   respectively by the following types:

   o  <ActivationCodeType>

   o  <ActivationCodeDigestType>

   o  <ActivationCodeMacType>

   The ActivationCodeType is defined as follows:


     <simpleType name="ActivationCodeType">
       <annotation>
         <documentation xml:lang="en">
           Maximum length of activation code restricted to 20 bytes
         </documentation>
       </annotation>
       <restriction base="string">
         <maxLength value="20"/>
       </restriction>
     </simpleType>

   The ActivationCodeDigestType is defined as follows:







Pei & Machani            Expires April 26, 2007                [Page 16]

Internet-Draft         Symmetric Key Provisioning           October 2006


  <complexType name="ActivationCodeDigestType">
      <annotation>
        <documentation xml:lang="en">
          Includes a digest of activation code.
        </documentation>
      </annotation>
      <simpleContent>
        <extension base="base64Binary">
          <attribute name="algorithm" type="oath-pskc:HashAlgorithmType"
            use="required"/>
        </extension>
      </simpleContent>
  </complexType>

   The components of the ActivationCodeDigestType have the following
   meanings:

   o  <algorithm> attribute indicates one of supported message digest
      methods. <HashAlgorithmType> is defined in [PSKC].

   The ActivationCodeMacType is defined as follows:


 <complexType name="ActivationCodeMacType">
     <annotation>
       <documentation xml:lang="en">
         Includes a HMAC of activation code with nonce as key.
       </documentation>
     </annotation>
     <sequence>
       <element name="Data" type="base64Binary"/>
       <element name="Nonce" type="oath-dskpp:NonceType" minOccurs="0"/>
     </sequence>
     <attribute name="algorithm" type="oath-pskc:DigestAlgorithmType"
       use="required"/>
     <attribute name="nonceId" type="oath-dskpp:IdentifierType"/>
 </complexType>

   The components of the ActivationCodeMacType have the following
   meanings:

   o  <Data> carries the HMAC authentication data derived from
      activation code and nonce value.

   o  <Nonce> contains a nonce value.  The value is acquired through a
      request <GetAuthNonce> to the server.  The <Nonce> element can be
      omitted




Pei & Machani            Expires April 26, 2007                [Page 17]

Internet-Draft         Symmetric Key Provisioning           October 2006


   o  <algorithm> attribute indicates one of supported MAC algorithms.
      <DigestAlgorithmType> is defined in [PSKC].

   o  <nonceId> should have the value of <sessionId> returned in a
      response message <GetAuthNonceResponse> if it is used.

5.3.  AuthenticationDataType

   AuthenticationDataType represents a client's authentication data sent
   to a provisioning server.  It is optional element in a request
   message when out of band authentication is done outside of
   provisioning process.

   The AuthenticationDataType is defined as follows:


   <complexType name="AuthenticationDataType">
       <sequence>
         <element name="ClientId" type="anyURI" minOccurs="0"/>
         <choice minOccurs="0">
           <element name="ActivationCode"
             type="oath-dskpp:ActivationCodeType"/>
           <element name="ActivationCodeDigest"
             type="oath-dskpp:ActivationCodeDigestType"/>
           <element name="ActivationCodeMac"
             type="oath-dskpp:ActivationCodeMacType"/>
           <any namespace="##other" processContents="strict"/>
         </choice>
       </sequence>
       <attribute name="form" type="oath-dskpp:AuthDataFormType"
           default="ACTIVATIONCODE"/>
   </complexType>

   <simpleType name="AuthDataFormType">
       <restriction base="string">
         <enumeration value="ACTIVATIONCODE"/>
         <enumeration value="CERTIFICATE"/>
       </restriction>
   </simpleType>

   The components of the AuthenticationDataType have the following
   meanings:

   o  <ClientId> represents a requestor's identifier.  The value may be
      a user ID, a credential ID, or a device ID associated with the
      requestor's authentication value.  When the authentication data is
      based on a certificate, <ClientId> can be omitted; the certificate
      itself is typically sufficient to indicate the requestor.  This



Pei & Machani            Expires April 26, 2007                [Page 18]

Internet-Draft         Symmetric Key Provisioning           October 2006


      element is required when the authentication data uses
      <ActivationCodeMac>.  The server relies on this value to identify
      corresponding activation code, and the nonce when the nonce is
      omitted in the element.

   o  <ActivationCode> is used when an activation code is used and sent
      in clear to the server.

   o  <ActivationCodeDigest> is used when an activation code is used and
      sent in the server with its hashed form.

   o  <ActivationCodeMac> is used when an activation code is used along
      with a server nonce to produce authentication data value.

   o  <any> represents other form of authentication data not defined
      here.  It can be XML signed data defined by [XMLSIG] when a client
      certificate is used to act authentication credential.

   o  <form> attribute indicates the authentication credential value
      form type <AuthDataFormType>.  When this attribute has value
      "ACTIVATIONCODE", the data can be any one of the three activation
      code related types.  If the attribute has value "CERTIFICATE", the
      authentication data value will be a certificate signed data; it
      may use the <any> choice to carry the value, or the XML signature
      element according to XML signature specification [XMLSIG] for the
      request.

























Pei & Machani            Expires April 26, 2007                [Page 19]

Internet-Draft         Symmetric Key Provisioning           October 2006


6.  Protocol Messages

6.1.  GetAuthNonce

   GetAuthNonce with GetAuthNonceType represents a request to acquire a
   server nonce value.  It is often used when a client needs to securely
   send user authentication data to a server.

   The GetAuthNonceType is defined as follows:


   <element name="GetAuthNonce" type="oath-dskpp:GetAuthNonceType"/>
   <complexType name="GetAuthNonceType">
     <complexContent>
       <extension base="oath-dskpp:RequestAbstractType">
         <sequence>
           <element name="ClientId" type="anyURI"/>
         </sequence>
       </extension>
     </complexContent>
   </complexType>

   The components of the GetAuthNonceType have the following meanings:

   o  <ClientId>, a unique identifier associated with the requestor's
      activation code.  This identifier must also be used in the
      subsequent authentication data element <AuthenticationData> that
      uses <ActivationCodeMac> when it is submitted to download a
      credential with <GetSharedSecret>

   o  <version> attribute, inherited from <RequestAbstractType>, is the
      message version used in the client.

   o  <requestId> attribute, inherited from <RequestAbstractType>, is a
      unique identifier to track this request.

6.2.  GetAuthNonceResponse

   GetAuthNonceReponse with GetAuthNonceResponseType represents a
   response to a request of type GetAuthNonceType.  It can optionally
   return secret ID for the secret to issue, and service ID for service
   information

   The GetAuthNonceResponseType is defined as follows:







Pei & Machani            Expires April 26, 2007                [Page 20]

Internet-Draft         Symmetric Key Provisioning           October 2006


 <complexType name="GetAuthNonceResponseType">
     <complexContent>
       <extension base="oath-dskpp:ResponseAbstractType">
         <sequence minOccurs="0" maxOccurs="unbounded">
            <element name="SecretId" type="string"/>
            <element name="ServiceId" type="oath-dskpp:IdentifierType"/>
         </sequence>
         <attribute name="serverNonce" type="oath-dskpp:NonceType"
           use="required"/>
         <attribute name="sessionId" type="oath-dskpp:IdentifierType"/>
       </extension>
     </complexContent>
 </complexType>

   The components of the GetAuthNonceResponseType have the following
   meanings:

   o  <SecretId> contains server assigned secret ID

   o  <ServiceId> indicates service information.

   o  <serverNonce> is a pseudorandom string generated by the
      provisioning server.  It will be used along with activation code
      to construct authentication token to acquire a credential.

   o  <sessionId> is a server generated ID for this request.  The server
      typically accepts the request ID from the request and won't
      generate a new ID.  This allows a server to choose its own session
      ID to identify a request.

   o  <requestId> attribute, inherited from <ResponseAbstractType>, is
      the ID that the corresponding request sent.

   o  <version> attribute, inherited from <ResponseAbstractType>, is the
      message version used in the response.

6.3.  GetSharedSecret

   GetSharedRequest is the main request message to request a secret
   (symmetric key credential) by a client to a provisioning server.  It
   is defined by the type GetSharedSecretType.

   The GetSharedSecret is defined as follows:








Pei & Machani            Expires April 26, 2007                [Page 21]

Internet-Draft         Symmetric Key Provisioning           October 2006


 <element name="GetSharedSecret" type="oath-dskpp:GetSharedSecretType"/>
 <complexType name="GetSharedSecretType">
     <complexContent>
       <extension base="oath-dskpp:RequestAbstractType">
         <sequence maxOccurs="unbounded">
           <element name="SecretId"
             type="string" minOccurs="0"/>
           <element name="ClientForm" type="oath-dskpp:ClientFormType"
             minOccurs="0"/>
           <element name="DeviceId" type="oath-pskc:DeviceIdType"
             minOccurs="0"/>
           <element name="AuthenticationData"
             type="oath-dskpp:AuthenticationDataType"
             minOccurs="0"/>
           <element name="SecretAlgorithm"
             type="oath-pskc:SecretAlgorithmType"
             minOccurs="0"/>
           <element name="Usage"
             type="oath-pskc:UsageType"
             minOccurs="0"/>
           <element name="SharedSecretDeliveryMethod"
             type="oath-dskpp:SharedSecretDeliveryMethodType"
             minOccurs="0"/>
           <element name="SupportedEncryptionAlgorithm"
             type="oath-pskc:EncryptionAlgorithmType"
             minOccurs="0"/>
           <element name="LogoPreference"
             type="oath-logo:LogoImageInfoType" minOccurs="0"/>
           <element name="Extension" type="oath-dskpp:ExtensionType"
             minOccurs="0" maxOccurs="unbounded"/>
         </sequence>
       </extension>
     </complexContent>
 </complexType>

   The components of the GetSharedSecretType have the following
   meanings:

   o  <SecretId> can be either client supplied or server assigned.  If a
      SecretId isn't given in a request, the server will assign one in
      its response to such a request.  If a server returns an existing
      secret ID in a device, the client should replace the secret.

   o  <ClientForm> indicates the device type.

   o  <DeviceId> conveys the device information.  It is defined in OATH
      [PSKC] specification.




Pei & Machani            Expires April 26, 2007                [Page 22]

Internet-Draft         Symmetric Key Provisioning           October 2006


   o  <AuthenticationData> carries authentication data that can be a
      pre-acquired authentication credential by the user for the service
      authorization, a server nonce mixed hash data, or device
      certificate signed data.

   o  <SecretAlgorithm> indicates the requested type of symmetric key
      credential type.

   o  <Usage> indicates the usage of the HOTP secret supported by the
      token device.  It is used when the requested SecretAlgorithm is
      HOTP.

   o  <SharedSecretDeliveryMethod> specifies the mechanism to be used
      for delivering the shared-secret e.g. via HTTPS or SMS .  For
      example, a request may be initiated from a desktop environment,
      and asks the server to send the secret to a cell phone through SMS
      for those phones that doesn't support internet access.

   o  <SupportedEncryptionAlgorithm> indicates the algorithm that the
      service should use to encrypt the shared-secret.  The inherited
      optional element Signature may contain the signature over the
      entire request document depending upon the capabilities of the
      device and the presence of a device certificate.

   o  <LogoPreference> describes preferred logo that the issuer should
      return.

   o  <Extension> allows additional request information.

   o  <requestId> attribute is inherited from <RequestAbstractType>.
      There is also <version> inherited.  They indicate respectively the
      client protocol version and a unique identifier to track this
      request.

6.4.  GetSharedSecretResponse

   The GetSharedSecretResponse element represents a provisioning service
   response message corresponding to a shared secret request.  Such a
   message contains shared secret container defined by OATH [PSKC] by
   default and a field that specifies the mechanism being used for
   delivering the shared-secret e.g. via HTTPS or SMS.  Either the user
   Activation Code derived key or public key of a device certificate can
   act as the encryption key in SecretContainer to encrypt the secret.

   The GetSharedSecretResponse is defined as follows:






Pei & Machani            Expires April 26, 2007                [Page 23]

Internet-Draft         Symmetric Key Provisioning           October 2006


  <element name="GetSharedSecretResponse"
    type="oath-dskpp:GetSharedSecretResponseType"/>
  <complexType name="GetSharedSecretResponseType">
      <complexContent>
        <extension base="oath-dskpp:ResponseAbstractType">
          <sequence minOccurs="0">
            <element name="SharedSecretDeliveryMethod"
              type="oath-dskpp:SharedSecretDeliveryMethodType"
              minOccurs="0"/>
              <choice>
              <element name="SecretContainer"
                type="oath-pskc:SecretContainerType"/>
              <any namespace="##other" processContents="strict"/>
            </choice>
            <element name="Extension" type="oath-dskpp:ExtensionType"
              minOccurs="0" maxOccurs="unbounded"/>
          </sequence>
          <attribute name="format"
            type="oath-dskpp:SecretContainerFormatType" default="PSKC"/>
        </extension>
      </complexContent>
  </complexType>

   The components of the GetSharedSecretResponseType have the following
   meanings:

   o  <SharedSecretDeliveryMethod> specifies the shared secret delivery
      method.  The value can be HTTP, HTTPS or SMS.

   o  <SecretContainer> indicates the PSKC secret container.  It should
      be used when the value of <format> attribute is "PSKC".

   o  <any> is used to represent the other format of credential
      container type when the value of <format> attribute isn't "PSKC".

   o  <Extension> allows a server to return additional information.  A
      provisioning service provider may specify its own extensions.

   o  <format> attribute indicates one of supported credential container
      format.  The default format of credential is PSKC.  Other
      credential format such as PKCS12 can also be used by a
      provisioning server.









Pei & Machani            Expires April 26, 2007                [Page 24]

Internet-Draft         Symmetric Key Provisioning           October 2006


7.  Protocol Binding

   The provisioning messages can support HTTP and SOAP binding to enable
   web service support.

   For HTTP binding, the requests can be simply posted with HTTP header
   application/xml.  The server parses message content to determine the
   request type.  SOAP binding uses standard SOAP header.  The protocol
   doesn't require special headers.










































Pei & Machani            Expires April 26, 2007                [Page 25]

Internet-Draft         Symmetric Key Provisioning           October 2006


8.  Security Considerations

   The protocol messages contain sensitive information such as user
   authentication data and symmetric keys that are transported between a
   provisioning service provider and end user device.  The protocol has
   defined mechanisms to protect the messages for confidentiality,
   authenticity, and integrity.  An implementation must pay attention to
   the different choices and their strengths according to standard
   security best practices, in particular, when data is sent over non-
   secure channel.

8.1.  Authentication

   Mutual authentication MUST be used between a client and the
   provisioning service.  A service provider should authenticate a
   client to ensure that an issued credential is delivered to the
   intended device.

   When a device certificate is used for client authentication, the
   provisioning server should follow standard certificate verification
   processes to ensure that it is a trusted device.

   When an activation code is used for authentication, the
   authentication data is subject to typical password dictionary attack.
   When a secure channel (e.g., HTTPS) between a client and the service
   is used, a successful activation code guess would allow a user to get
   a free credential; but it won't leak a legitimate user's credential
   to another user.  An expiration window and proper length to mitigate
   such misuse risks can be used according to standard best practice.

   It is recommended that a secure channel such as HTTPS be used unless
   a device isn't able to support it.  In the case that a non-secure
   channel has to be used, a nonce value acquired from provisioning
   service is used to prevent replay attack and man-in-the-middle
   spoofing of the activation code.  The sensitive activation code and
   nonce value must be strong enough to prevent offline brute force
   recovery of the activation code from the HMAC data.  Because the
   nonce value is almost public across a non-secure channel, the key
   strength lies in the activation code.  The activation code length
   used with a non-secure channel should be longer than what is used
   over a secure channel.  When a device cannot handle a long activation
   code in a user friendly manner such as some mobile phones with small
   screens, it is necessary to use only the secure channel to
   communicate with a provisioning service.

   See section Section 4.2





Pei & Machani            Expires April 26, 2007                [Page 26]

Internet-Draft         Symmetric Key Provisioning           October 2006


8.2.  Confidentiality

   The credential payload is encrypted by either a client's public key
   or a key derived from a mutual secret (activation code or pre-
   generated key) between a user and the service.  When data is sent
   over a non-secure channel, the encryption key may be subject to brute
   force attack if the underlying key material isn't properly chosen.
   In addition to strong activation code choice, the service should
   follow standard practice in adopting the proper encryption algorithm.

8.3.  Integrity

   The provisioning request message has an optional signature element to
   ensure the integrity of message and the request.  In an environment
   where credentials are tracked according to device IDs and there is no
   binding relationship between a device ID and authentication data
   (e.g., Activation Code), it is recommended that the use of a digital
   signature is enforced to prevent a user from binding a credential to
   another user device.
































Pei & Machani            Expires April 26, 2007                [Page 27]

Internet-Draft         Symmetric Key Provisioning           October 2006


9.  Acknowledgements

   The use cases and requirements are extended from early list created
   by OATH [OATH] provisioning work group.  The protocol is developed
   from some work contributed to OATH [OATH] from its members.  The
   authors would like to thank the following people for their
   contribution during use case developing, protocol conception and
   review: Stu Vaeth (Diversinet), Salil Sane (VeriSign), Panna
   Chowdhury (VeriSign), Shuh Chang (Gemalto), Kevin Lewis (SanDisk),
   Jim Spring (Ironkey), Phillip Hallam-Baker (VeriSign), Philip Hoyer
   (ActiveIdentity), Siddharth Bajaj (VeriSign), Susan Cannon (SanDisk),
   Jon Martinsson (Portwise), Jeffrey Bohren (BMC), Ron LaPedis
   (SanDisk) and Robert Zuccherato (Entrust).






































Pei & Machani            Expires April 26, 2007                [Page 28]

Internet-Draft         Symmetric Key Provisioning           October 2006


10.  Normative References

   [HOTP]     MRaihi, D., "HOTP: An HMAC-Based One Time Password
              Algorithm", RFC 4226,
              URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
              December 2005.

   [OATH]     "Initiative for Open AuTHentication",
              URL: http://www.openauthentication.org.

   [PKCS12]   RSA Laboratories, "PKCS #12: Personal Information Exchange
              Syntax Standard", Version 1.0,
              URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/.

   [PKCS5XML]
              RSA Laboratories, "XML Schema for PKCS #5 Version 2.0",
              Version PKCS#5 2.0 Amd.1, URL: ftp://ftp.rsasecurity.com/
              pub/pkcs/pkcs-5v2/pkcs-5v2-0a1d2.pdf, October 2006.

   [PSKC]     Vassilev, A., "Portable Symmetric Key Container",
              RFC Draft, Version 1.1, URL: http://www.ietf.org/
              internet-drafts/
              draft-vassilev-portable-symmetric-key-container-01.txt,
              August 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [XMLSIG]   Eastlake, D., "XML-Signature Syntax and Processing",
              URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
              W3C Recommendation, February 2002.




















Pei & Machani            Expires April 26, 2007                [Page 29]

Internet-Draft         Symmetric Key Provisioning           October 2006


Appendix A.  XML Schema

   The following syntax specification uses the widely adopted XML schema
   format as defined by a W3C recommendation
   (http://www.w3.org/TR/xmlschema-0/).  It is a complete syntax
   definition in the XML Schema Definition format (XSD)

   All implementations of this standard must comply with the schema
   below.


<?xml version="1.0" encoding="UTF-8" ?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
 xmlns:oath-dskpp="http://www.openauthentication.org/OATH/2006/10/DSKPP"
 xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/10/PSKC"
 xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
 targetNamespace="http://www.openauthentication.org/OATH/2006/10/DSKPP"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
  <import namespace="http://www.w3.org/2000/09/xmldsig#"
  schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
  xmldsig-core-schema.xsd"/>
  <import
  namespace="http://www.openauthentication.org/OATH/2006/10/PSKC"
  schemaLocation="http://www.openauthentication.org/OATH/2006/10/PSKC/
  oath_pskc_schema_v1.2.xsd"/>
  <import
  namespace="http://www.openauthentication.org/OATH/2006/08/Logo"
  schemaLocation="http://www.openauthentication.org/OATH/2006/08/Logo/
  oath_logotype_v1.0.xsd"/>

  <annotation>
    <documentation xml:lang="en">XML Schema for OATH Dynamical
    Symmetric Key Provisioning Web Services</documentation>
  </annotation>

  <complexType name="MessageAbstractType" abstract="true">
    <annotation>
      <documentation xml:lang="en">
        Abstract class for all messages in this protocol.
      </documentation>
    </annotation>
    <attribute name="version" type="oath-dskpp:VersionType"
    use="required"/>
  </complexType>

  <simpleType name="VersionType" final="restriction">
    <restriction base="string">



Pei & Machani            Expires April 26, 2007                [Page 30]

Internet-Draft         Symmetric Key Provisioning           October 2006


      <pattern value="\d{1,9}\.\d{0,9}"/>
    </restriction>
  </simpleType>

  <complexType name="RequestAbstractType" abstract="true">
    <annotation>
      <documentation xml:lang="en">
        Abstract class for all request messages. Id is a pseudo-random
        number used for request-response matching.
      </documentation>
    </annotation>
    <complexContent>
      <extension base="oath-dskpp:MessageAbstractType">
        <sequence>
          <element ref="ds:Signature" minOccurs="0"/>
        </sequence>
        <attribute name="requestId" type="oath-dskpp:IdentifierType"/>
      </extension>
    </complexContent>
  </complexType>

  <complexType name="ResponseAbstractType" abstract="true">
    <annotation>
      <documentation xml:lang="en">
        Abstract class for all responses messages.
        RequestId contains the Id received in the request.
        Response messages also contains a status indicating success
        or cause of failure.
      </documentation>
    </annotation>
    <complexContent>
      <extension base="oath-dskpp:MessageAbstractType">
        <sequence>
          <element name="Status" type="oath-dskpp:StatusType"/>
        </sequence>
        <attribute name="requestId" type="oath-dskpp:IdentifierType"/>
      </extension>
    </complexContent>
  </complexType>

  <complexType name="StatusType">
    <annotation>
      <documentation xml:lang="en">
        Contains a status code indicating success or causes of failure,
        and a status message that includes a brief description.
      </documentation>
    </annotation>
    <sequence>



Pei & Machani            Expires April 26, 2007                [Page 31]

Internet-Draft         Symmetric Key Provisioning           October 2006


      <element name="StatusCode" type="oath-dskpp:StatusCodeType"/>
      <element name="StatusMessage" type="string" minOccurs="0"/>
    </sequence>
  </complexType>

  <simpleType name="StatusCodeType">
    <restriction base="string">
      <enumeration value="Continue"/>
      <enumeration value="Success"/>
      <enumeration value="Abort"/>
      <enumeration value="UnsupportedVersion"/>
      <enumeration value="UnsupportedKeyType"/>
      <enumeration value="UnsupportedEncryptionAlgorithm"/>
      <enumeration value="AccessDenied"/>
      <enumeration value="MalformedRequest"/>
      <enumeration value="SessionExpired"/>
      <enumeration value="CredentialNotFound"/>
      <enumeration value="UnknownClient"/>
      <enumeration value="UnknownRequest"/>
      <enumeration value="OtherFailure"/>
    </restriction>
  </simpleType>

  <complexType name="AuthenticationDataType">
    <annotation>
      <documentation xml:lang="en">
        Authentication data holder for a request. When authentication
        credential is of type "ACTIVATIONCODE", the data can be any
        one of the three activation code related types.
      </documentation>
    </annotation>
    <sequence>
      <element name="ClientId" type="anyURI" minOccurs="0"/>
      <choice minOccurs="0">
        <element name="ActivationCode"
                type="oath-dskpp:ActivationCodeType"/>
        <element name="ActivationCodeDigest"
                type="oath-dskpp:ActivationCodeDigestType"/>
        <element name="ActivationCodeMac"
                type="oath-dskpp:ActivationCodeMacType"/>
        <any namespace="##other" processContents="strict"/>
      </choice>
    </sequence>
    <attribute name="form" type="oath-dskpp:AuthDataFormType"
      default="ACTIVATIONCODE"/>
  </complexType>

  <simpleType name="AuthDataFormType">



Pei & Machani            Expires April 26, 2007                [Page 32]

Internet-Draft         Symmetric Key Provisioning           October 2006


    <restriction base="string">
      <enumeration value="ACTIVATIONCODE"/>
      <enumeration value="CERTIFICATE"/>
    </restriction>
  </simpleType>

  <simpleType name="SecretContainerFormatType">
    <restriction base="string">
      <enumeration value="PSKC"/>
      <enumeration value="PKCS12"/>
      <enumeration value="XMLPKCS5"/>
    </restriction>
  </simpleType>

  <simpleType name="NonceType">
    <restriction base="base64Binary">
      <minLength value="8"/>
    </restriction>
  </simpleType>

  <element name="GetAuthNonce" type="oath-dskpp:GetAuthNonceType"/>

  <complexType name="GetAuthNonceType">
     <complexContent>
        <extension base="oath-dskpp:RequestAbstractType">
          <sequence>
             <element name="DeviceId" type="oath-pskc:DeviceIdType"/>
          </sequence>
        </extension>
     </complexContent>
  </complexType>

  <element name="GetAuthNonceResponse"
        type="oath-dskpp:GetAuthNonceResponseType"/>

  <complexType name="GetAuthNonceResponseType">
    <complexContent>
      <extension base="oath-dskpp:ResponseAbstractType">
        <sequence minOccurs="0" maxOccurs="unbounded">
           <element name="SecretId"
                type="string"/>
           <element name="ServiceId" type="oath-dskpp:IdentifierType"/>
        </sequence>
        <attribute name="serverNonce" type="oath-dskpp:NonceType"
          use="required"/>
        <attribute name="sessionId" type="oath-dskpp:IdentifierType"/>
      </extension>
    </complexContent>



Pei & Machani            Expires April 26, 2007                [Page 33]

Internet-Draft         Symmetric Key Provisioning           October 2006


  </complexType>

  <simpleType name="IdentifierType">
    <restriction base="string">
      <maxLength value="128"/>
    </restriction>
  </simpleType>

  <element name="GetSharedSecret"
    type="oath-dskpp:GetSharedSecretType"/>

  <complexType name="GetSharedSecretType">
    <complexContent>
      <extension base="oath-dskpp:RequestAbstractType">
        <sequence maxOccurs="unbounded">
          <element name="SecretId"
            type="string" minOccurs="0"/>
          <element name="ClientForm" type="oath-dskpp:ClientFormType"
            minOccurs="0"/>
          <element name="DeviceId" type="oath-pskc:DeviceIdType"
                minOccurs="0"/>
          <element name="AuthenticationData"
                type="oath-dskpp:AuthenticationDataType" minOccurs="0"/>
          <element name="SecretAlgorithm"
            type="oath-pskc:SecretAlgorithmType"
            minOccurs="0"/>
          <element name="Usage"
                type="oath-pskc:UsageType"
                minOccurs="0"/>
          <element name="SharedSecretDeliveryMethod"
            type="oath-dskpp:SharedSecretDeliveryMethodType"
            minOccurs="0"/>
          <element name="SupportedEncryptionAlgorithm"
            type="oath-pskc:EncryptionAlgorithmType"
            minOccurs="0"/>
          <element name="LogoPreference"
                type="oath-logo:LogoImageInfoType" minOccurs="0"/>
          <element name="Extension" type="oath-dskpp:ExtensionType"
                minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <complexType name="ExtensionType" abstract="true">
    <attribute name="critical" type="boolean"/>
  </complexType>




Pei & Machani            Expires April 26, 2007                [Page 34]

Internet-Draft         Symmetric Key Provisioning           October 2006


  <complexType name="PropertyExtensionType">
    <complexContent>
      <extension base="oath-dskpp:ExtensionType">
        <sequence>
          <element name="Name" type="string"/>
          <element name="Value" type="string" minOccurs="0"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <simpleType name="ClientFormType">
    <annotation>
      <documentation xml:lang="en">
        List of supported device types.
      </documentation>
    </annotation>
    <restriction base="string">
      <enumeration value="DEVICE"/>
      <enumeration value="MOBILEPHONE"/>
      <enumeration value="DESKTOP"/>
    </restriction>
  </simpleType>

  <simpleType name="ActivationCodeType">
    <annotation>
      <documentation xml:lang="en">
        Maximum length of activation code restricted to 20 bytes
      </documentation>
    </annotation>
    <restriction base="string">
      <maxLength value="20"/>
    </restriction>
  </simpleType>

  <complexType name="ActivationCodeDigestType">
    <annotation>
      <documentation xml:lang="en">
        Includes a digest of activation code.
      </documentation>
    </annotation>
    <simpleContent>
      <extension base="base64Binary">
        <attribute name="algorithm" type="oath-dskpp:HashAlgorithmType"
                use="required"/>
      </extension>
    </simpleContent>
  </complexType>



Pei & Machani            Expires April 26, 2007                [Page 35]

Internet-Draft         Symmetric Key Provisioning           October 2006


  <complexType name="ActivationCodeMacType">
    <annotation>
      <documentation xml:lang="en">
        Includes a HMAC of activation code with nonce as key.
      </documentation>
    </annotation>
    <sequence>
      <element name="Data" type="base64Binary"/>
      <element name="Nonce" type="oath-dskpp:NonceType" minOccurs="0"/>
    </sequence>
    <attribute name="algorithm" type="oath-pskc:DigestAlgorithmType"
        use="required"/>
    <attribute name="nonceId" type="oath-dskpp:IdentifierType"/>
  </complexType>

  <simpleType name="SharedSecretDeliveryMethodType">
    <annotation>
      <documentation xml:lang="en">
        List of supported transport protocols.
      </documentation>
    </annotation>
    <restriction base="string">
      <enumeration value="HTTP"/>
      <enumeration value="HTTPS"/>
      <enumeration value="SMS"/>
    </restriction>
  </simpleType>

  <complexType name="CredentialType">
    <choice>
      <element name="SecretContainer"
        type="oath-pskc:SecretContainerType"/>
      <any namespace="##other" processContents="strict"/>
    </choice>
    <attribute name="format"
      type="oath-dskpp:SecretContainerFormatType"
        default="PSKC"/>
  </complexType>

  <element name="GetSharedSecretResponse"
        type="oath-dskpp:GetSharedSecretResponseType"/>

  <complexType name="GetSharedSecretResponseType">
    <complexContent>
      <extension base="oath-dskpp:ResponseAbstractType">
        <sequence minOccurs="0">
          <element name="SharedSecretDeliveryMethod"
            type="oath-dskpp:SharedSecretDeliveryMethodType"



Pei & Machani            Expires April 26, 2007                [Page 36]

Internet-Draft         Symmetric Key Provisioning           October 2006


            minOccurs="0"/>
          <choice>
            <element name="SecretContainer"
              type="oath-pskc:SecretContainerType"/>
            <any namespace="##other" processContents="strict"/>
          </choice>
          <element name="Extension" type="oath-dskpp:ExtensionType"
            minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
        <attribute name="format"
          type="oath-dskpp:SecretContainerFormatType" default="PSKC"/>
      </extension>
    </complexContent>
  </complexType>
</schema>




































Pei & Machani            Expires April 26, 2007                [Page 37]

Internet-Draft         Symmetric Key Provisioning           October 2006


Appendix B.  Example Requests and Responses

   All examples are syntactically correct and compatible with the XML
   schema in Appendix B.  However, <Signature>, Secret <Value> and
   Secret <ValueDigest> data values are fictitious.

B.1.  Simple client message exchange for acquiring a credential with an
      activation code

   A client can directly acquire a credential with request message type
   GetSharedSecret with an activation code for authentication over a SSL
   enabled provisioning service.


 <?xml version="1.0" encoding="UTF-8"?>
 <GetSharedSecret xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/10/PSKC"
   xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
   xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
   requestId="1234abcd" version="1.0">
   <ClientForm>MOBILEPHONE</ClientForm>
   <DeviceId>
     <oath-pskc:Manufacturer>ManufacturerABC</oath-pskc:Manufacturer>
     <oath-pskc:SerialNo>XL0000000001234</oath-pskc:SerialNo>
     <oath-pskc:Model>U2</oath-pskc:Model>
   </DeviceId>
   <AuthenticationData form="ACTIVATIONCODE">
     <ActivationCode>12345678</ActivationCode>
   </AuthenticationData>
   <SecretAlgorithm>HOTP</SecretAlgorithm>
   <SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
   <SupportedEncryptionAlgorithm>PBE-3DES168-CBC
   </SupportedEncryptionAlgorithm>
 </GetSharedSecret>

   Server responses with an encrypted credential in
   GetSharedSecretResponse upon approval.














Pei & Machani            Expires April 26, 2007                [Page 38]

Internet-Draft         Symmetric Key Provisioning           October 2006


   <?xml version="1.0" encoding="UTF-8"?>
   <GetSharedSecretResponse
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
     requestId="1234abcd" version="1.0" format="PSKC">
     <Status>
       <StatusCode>Success</StatusCode>
       <StatusMessage>Success</StatusMessage>
     </Status>
     <SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
     <SecretContainer version="1.0"
       xmlns="http://www.openauthentication.org/OATH/2006/10/PSKC">
       <EncryptionMethod algorithm="PBE-3DES168-CBC">
         <PBESalt>y6TzckeLRQw=</PBESalt>
         <PBEIterationCount>999</PBEIterationCount>
       </EncryptionMethod>
       <DigestMethod algorithm="HMAC-SHA1"/>
       <Device>
         <Secret SecretAlgorithm="HOTP" SecretId="SDU312345678">
           <Issuer>CredentialIssuer</Issuer>
           <Usage otp="true">
             <ResponseFormat format="DECIMAL" length="6"/>
           </Usage>
           <FriendlyName>MyFirstToken</FriendlyName>
           <Data Name="SECRET">
             <Value>
               7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==
             </Value>
             <ValueDigest>WldjTHZwRm9YTkhBRytseDMrUnc=</ValueDigest>
           </Data>
           <Data Name="COUNTER">
             <Value>9TD4yaItFZg=</Value>
             <ValueDigest>HuYEuuk9K/oZPgfZS7kD+dwmiDg=</ValueDigest>
           </Data>
           <Expiry>10/30/2009</Expiry>
         </Secret>
       </Device>
     </SecretContainer>
   </GetSharedSecretResponse>

B.2.  Full message exchanges for a client over a non-secure channel

   A client first sends a request to acquire server nonce.








Pei & Machani            Expires April 26, 2007                [Page 39]

Internet-Draft         Symmetric Key Provisioning           October 2006


   <?xml version="1.0" encoding="UTF-8"?>
   <GetAuthNonce
     xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
     requestId="1234abcd"
     version="1.0">
     <ClientId>FA0033F4550B01FFDA05</ClientId>
   </GetAuthNonce>

   Server replies with a nonce for the session with the following
   message.


   <?xml version="1.0" encoding="UTF-8"?>
   <GetAuthNonceResponse
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
     version="1.0"
     requestId="1234abcd"
     serverNonce="cmFuZG9tc2VlZA0K"
     sessionId="SS00000001">
     <Status>
       <StatusCode>Continue</StatusCode>
     </Status>
   </GetAuthNonceResponse>

   The client requests a credential with authentication data constructed
   from an activation code and the nonce.
























Pei & Machani            Expires April 26, 2007                [Page 40]

Internet-Draft         Symmetric Key Provisioning           October 2006


 <?xml version="1.0" encoding="UTF-8"?>
 <GetSharedSecret xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/10/PSKC"
   xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
   xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
   requestId="1234abcd" version="1.0">
   <ClientForm>MOBILEPHONE</ClientForm>
   <DeviceId>
     <oath-pskc:Manufacturer>ManufacturerABC</oath-pskc:Manufacturer>
     <oath-pskc:SerialNo>FA0033F4550B01FFDA05</oath-pskc:SerialNo>
     <oath-pskc:Model>SPH-A900</oath-pskc:Model>
   </DeviceId>
   <AuthenticationData form="ACTIVATIONCODE">
     <ClientId>SS00000001</ClientId>
     <ActivationCodeMac algorithm="HMAC-SHA1">
       <Data>WldjTHZwRm9YTkhBRytseDMrUnc=</Data>
     </ActivationCodeMac>
   </AuthenticationData>
   <SecretAlgorithm>HOTP</SecretAlgorithm>
   <SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
   <SupportedEncryptionAlgorithm>PBE-3DES168-CBC
   </SupportedEncryptionAlgorithm>
 </GetSharedSecret>

   The server response message for this request is similar to the
   example in the last section.

























Pei & Machani            Expires April 26, 2007                [Page 41]

Internet-Draft         Symmetric Key Provisioning           October 2006


Appendix C.  Transport Consideration

   The transport layer security may affect how a client can choose its
   authentication choice and whether it can leverage some from the
   transport layer.  We consider the following three typical cases.

   o  Transport layer provides no security

   o  Transport layer provides confidentiality and server authentication
      only

   o  Transport layer provides confidentiality and mutual authentication
      (both client and server)

C.1.  No security provided in transport layer

   A provisioning service can support this by using nonce based
   authentication and response encryption with a pre-shared encryption
   key between a client and the server.

C.2.  Confidentiality provided in transport layer

   A provisioning service can support this by using any client
   authentication specified in the protocol and response encryption with
   a pre-shared encryption key between a client and the server.  The
   server authentication can use either response message authentication
   or transport layer authentication.

C.3.  Confidentiality and mutual authentication provided in transport
      layer

   A provisioning service can support this by optionally using any
   client authentication specified in the protocol and optional response
   encryption with a pre-shared encryption key or client's public key.
   The server authentication can use either response message
   authentication or transport layer authentication.















Pei & Machani            Expires April 26, 2007                [Page 42]

Internet-Draft         Symmetric Key Provisioning           October 2006


Authors' Addresses

   Mingliang Pei
   VeriSign, Inc.
   487 E. Middlefield Road
   Mountain View, CA  94043
   USA

   Phone: +1 650 426 5173
   Email: mpei@verisign.com


   Salah Machani
   Diversinet, Inc.
   2225 Sheppard Avenue East
   Suite 1801
   Toronto, Ontario  M2J 5C2
   Canada

   Phone: +1 416 756 2324 Ext. 321
   Email: smachani@diversinet.com






























Pei & Machani            Expires April 26, 2007                [Page 43]

Internet-Draft         Symmetric Key Provisioning           October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Pei & Machani            Expires April 26, 2007                [Page 44]