Pei, Mingliang | 13 Oct 22:26 2006
Picon

RE: FW: Updated provisioning doc (RE: OATH Provisioningcall Jul 31: minutes)

This is a reply to ietf-keyprov thread. I am going to incorporate the comments in the version after 10/10/2006 copy.
 
- Ming

From: Salah Machani [mailto:SMachani-0F9wwT7ERbtm9/pnFjKg3w@public.gmane.org]
Sent: Friday, October 13, 2006 11:55 AM
To: Pei, Mingliang; ietf-keyprov-RVczLawcDSlg9hUCZPvPmw@public.gmane.org
Subject: RE: [Ietf-keyprov] FW: Updated provisioning doc (RE: OATH Provisioningcall Jul 31: minutes)

Ming,  Here are additional edits and comments to the October 11th draft.   Please incorporate as appropriate into the final draft.

 

Although many changes have been made since the August version, the document still needs additional work and revisions for clarity and consistency.

 

 

Thanks,

 

 

Salah

 

 

From: ietf-keyprov-bounces-RVczLawcDSlg9hUCZPvPmw@public.gmane.org [mailto:ietf-keyprov-bounces-RVczLawcDSlg9hUCZPvPmw@public.gmane.org] On Behalf Of Kevin Lewis
Sent: Thursday, September 14, 2006 11:35 AM
To: ietf-keyprov-RVczLawcDSlg9hUCZPvPmw@public.gmane.org
Subject: [Ietf-keyprov] FW: Updated provisioning doc (RE: OATH Provisioningcall Jul 31: minutes)

 

Feedback on Provisioning Protocol spec….

 

Due to the large number of edits and comments I have made the changes within the document. Please incorporate as appropriate.

 

In general my feeling is that this document needs additional work to make it easier on the reader and provide additional clarity in describing the use cases, the protocol, the messages, and the message detail. My assessment is that we need at least another round of review and possibly a face-to-face meeting to go over this document in detail. I did not attempt to proof or test the XML schema or examples.

 

Thanks,

 

Kevin

 

From: Pei, Mingliang [mailto:mpei-0nFLJxsdniVWk0Htik3J/w@public.gmane.org]
Sent: Tuesday, August 08, 2006 3:41 AM
To: svaeth-+/OggRDFqlVt1OO0OYaSVA@public.gmane.org; Hallam-Baker, Phillip; Bajaj, Siddharth; Susan Cannon; jon.martinsson-fOKtku6JJ0RWk0Htik3J/w@public.gmane.org; Salah Machani; Chen, Hseuping; Jeffrey Bohren; Philip Hoyer; Ron LaPedis; Kevin Lewis; Robert Zuccherato; Jim Spring; Shuh Chang
Subject: Updated provisioning doc (RE: OATH Provisioning call Jul 31: minutes)

 

Attached please find updated provisioning doc. This version includes the following changes:

 

1. Added a new use case where an outsourced credential issue acquires credentials for its users through its proxy to outsourcing service provider.

 

This is a new use case that is needed for token sharing service provider model such as VeriSign VIP service. See use case #5.

 

2. Re-indexed the use case list, removed the unsupported use case about credential upload, and split the lifecycle management case to other cases for specific need

 

3. Expanded section about "Client authentication" to discuss the new case support and out of band authentication need.

 

4. Made AuthenticationToken optional in GetSharedSecret request to allow out of band authentication.

 

5. Corrected typo about "Nouce" ("Nonce")

 

Thanks Stu and Shuh for their suggestions in this morning's conf call.

 

Please review. Your suggestions and comments are appreciated.

 

- Ming

Notice to Recipient: The information in this message is meant only for the intended recipient of the transmission and may contain confidential or privileged information.
Any copying, retransmittal, taking of action in reliance on, or other use of the information in this communication by persons other than the addressees is prohibited.
If you received this email in error, please immediately notify us and please delete or destroy all copies of this message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors. Thank you.

_______________________________________________
Ietf-keyprov mailing list
Ietf-keyprov@...
http://www.safehaus.org/mailman/listinfo/ietf-keyprov
Pei, Mingliang | 16 Oct 06:45 2006
Picon

FW: [Auto Response] Submission of Internet Draft "Dynamic Symmetric Key Provisioning Protocol"


-----Original Message-----
From: Internet Draft Submission Manager
[mailto:internet-drafts-reply@...] 
Sent: Saturday, October 14, 2006 7:37 PM
To: Pei, Mingliang
Subject: [Auto Response] Submission of Internet Draft "Dynamic Symmetric
Key Provisioning Protocol"

Greetings:

This message is being sent to acknowledge receipt of your Internet-Draft
submission or message to internet-drafts@...
If you submitted an Internet-Draft, then it will be posted on the
Internet-Drafts page of the IETF Web site, and an I-D Action message
will be sent to the I-D-Announce List.  If you need to track the status
of your Internet-Draft submission at a later date, then please send a
note to ietf-action@... (using the suggested subject line Status of
I-D Submission: <filename>) and reference this auto-response
acknowledgement in the body.

Please note that all Internet-Drafts offered for publication as RFCs
must conform to the requirements specified in I-D Checklist
(<http://www.ietf.org/ID-Checklist.html>) or they will be returned to
the author(s) for revision.  Therefore, the IETF Secretariat strongly
recommends that you address all of the issues raised in this document
before submitting a request to publish your Internet-Draft to the IESG.

The IETF Secretariat

Pei, Mingliang | 16 Oct 06:44 2006
Picon

KeyProv IETF Draft from OATH submitted: Dynamica Symmetric Key Provisioning Protocol

Attached is the draft submitted to IETF on 10/15/06. We are thankful for the suggestions and comments posted in this list.
 
Thank you,
 
- Ming
 


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


              Dynamic Symmetric Key Provisioning Protocol
             draft-pei-dynamic-symkey-prov-protocol-00.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 17, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).













Pei & Machani            Expires April 17, 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
               credential . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.2.  A user acquires multiple credentials of different
               types  . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.2.3.  A credential provisioning service imposes a
               validity period policy for provisioning sessions . . .  5
       1.2.4.  A credential 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



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


     3.1.  Request and Response Messages  . . . . . . . . . . . . . . 12
     3.2.  Symmetric Key Container Format . . . . . . . . . . . . . . 12
     3.3.  Encryption Key for Credential Response . . . . . . . . . . 12
   4.  Authentication . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Client Authentication  . . . . . . . . . . . . . . . . . . 14
     4.2.  Server Authentication  . . . . . . . . . . . . . . . . . . 15
   5.  Message Sets . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  SecretContainer  . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  CredentialType . . . . . . . . . . . . . . . . . . . . . . 16
     5.3.  ActivationCode . . . . . . . . . . . . . . . . . . . . . . 16
     5.4.  AuthenticationDataType . . . . . . . . . . . . . . . . . . 19
     5.5.  GetAuthNonce . . . . . . . . . . . . . . . . . . . . . . . 20
     5.6.  GetAuthNonceResponse . . . . . . . . . . . . . . . . . . . 21
     5.7.  GetSharedSecret  . . . . . . . . . . . . . . . . . . . . . 22
     5.8.  GetSharedSecretResponse  . . . . . . . . . . . . . . . . . 24
   6.  Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 26
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
     7.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 27
     7.2.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 28
     7.3.  Integrity  . . . . . . . . . . . . . . . . . . . . . . . . 28
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 30
   Appendix A.  XML Schema  . . . . . . . . . . . . . . . . . . . . . 31
   Appendix B.  Example Requests and Responses  . . . . . . . . . . . 39
     B.1.  Simple client message exchange for acquiring a
           credential with an activation code . . . . . . . . . . . . 39
     B.2.  Full message exchanges for a client over a non-secure
           channel  . . . . . . . . . . . . . . . . . . . . . . . . . 40
   Appendix C.  Transport Consideration . . . . . . . . . . . . . . . 43
     C.1.  No security provided in transport layer  . . . . . . . . . 43
     C.2.  Confidentiality provided in transport layer  . . . . . . . 43
     C.3.  Confidentiality and mutual authentication provided in
           transport layer  . . . . . . . . . . . . . . . . . . . . . 43
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 45
















Pei & Machani            Expires April 17, 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 credentials 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 key
   credential 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 credential 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 credential 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 word "credential" to mean "symmetric key
   credential" when the context is clear.

1.2.1.  A mobile device user obtains an HOTP symmetric key credential

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




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


1.2.2.  A user acquires multiple credentials of different types

   A user wants to provision multiple credentials on a device.  The
   credentials may or may not be of the same type.  The credentials 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 credential in the device using token
   identification to allow device authentication before provisioning.

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

   Once a user initiates a credential request, the credential
   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 credential.  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 credential issuer uses a third party provisioning service
        provider

   A credential issuer outsources its credential provisioning to a third
   party credential provisioning service provider.  The issuer is
   responsible for authenticating and granting rights to users to
   acquire credentials while it may delegate the actual credential
   generation and provisioning to a third party provisioning service.
   The issuer may acquire credentials on behalf of its users from the
   provisioning service provider or redirect the user to acquire the
   credentials 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 credential 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.



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


   This use case requires the protocol to be tunneled and the
   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



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


   through SMS.  The online communication between the desktop computer
   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.







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


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

   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.





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


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

   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 17, 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-kp="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 17, 2007                [Page 10]

Internet-Draft         Symmetric Key Provisioning           October 2006


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


















































Pei & Machani            Expires April 17, 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.

   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
   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:




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


   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 17, 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.

   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)

      - 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:






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


      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 17, 2007                [Page 15]

Internet-Draft         Symmetric Key Provisioning           October 2006


5.  Message Sets

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.  CredentialType

   CredentialType defines the symmetric key container in a response.  It
   uses PSKC <SecretContainer> by default but also allows other format
   such as PKCS12.

   The CredentialType is defined as follows:


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

   The components of the CredentialType have the following meanings:

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

   o  <format> attribute indicates one of supported credential container
      format.

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

5.3.  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.




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


   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:


  <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-kp:DigestAlgorithmType"
                  use="required"/>
        </extension>
      </simpleContent>
  </complexType>

   The components of the ActivationCodeDigestType have the following
   meanings:

   o  <algorithm> attribute indicates one of supported message digest
      methods.  By default, it can use SHA1 with identifier




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


         "http://www.w3.org/2000/09/xmldsig#sha1"

      The other choices are

         "http://www.w3.org/2001/04/xmldsig-more#sha256"

         "http://www.w3.org/2001/04/xmldsig-more#sha512"

   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-kp:NonceType" minOccurs="0"/>
       </sequence>
       <attribute name="algorithm" type="oath-kp:CredentialIdType"
           use="required"/>
           <attribute name="nonceId" type="oath-kp:IdentifierType"
                   use="optional"/>
     </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

   o  <algorithm> attribute indicates one of supported MAC algorithms.
      By default, it can use HMAC-SHA1 with identifier

         "http://www.w3.org/2000/09/xmldsig#hmac-sha1"

      The other choices are

         "http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"






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


         "hhttp://www.w3.org/2001/04/xmldsig-more#hmac-sha512"

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

5.4.  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-kp:ActivationCodeType"/>
           <element name="ActivationCodeDigest"
                   type="oath-kp:ActivationCodeDigestType"/>
           <element name="ActivationCodeMac"
                   type="oath-kp:ActivationCodeMacType"/>
           <any namespace="##other" processContents="strict"/>
         </choice>
       </sequence>
       <attribute name="form" type="oath-kp: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
      element is required when the authentication data uses



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


      <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 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 should use the <any> choice to carry the value.

5.5.  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-kp:GetAuthNonceType"/>
   <complexType name="GetAuthNonceType">
           <complexContent>
                   <extension base="oath-kp:RequestAbstractType">
                           <sequence>
                             <element name="ClientId"
                                   type="anyURI"/>
                           </sequence>
                   </extension>
           </complexContent>
   </complexType>

   The components of the GetAuthNonceType have the following meanings:





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


   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  <id> attribute, inherited from <RequestAbstractType>, is a unique
      identifier to track this request.

5.6.  GetAuthNonceResponse

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

   The GetAuthNonceResponseType is defined as follows:


   <complexType name="GetAuthNonceResponseType">
       <complexContent>
         <extension base="oath-kp:ResponseAbstractType">
           <sequence minOccurs="0" maxOccurs="unbounded">
              <element name="CredentialId"
                           type="oath-kp:CredentialIdType"/>
              <element name="ServiceId" type="oath-kp:IdentifierType"/>
           </sequence>
           <attribute name="serverNonce" type="oath-kp:NonceType"/>
           <attribute name="sessionId" type="oath-kp:IdentifierType"
                   use="optional"/>
         </extension>
       </complexContent>
   </complexType>

   The components of the GetAuthNonceResponseType have the following
   meanings:

   o  <CredentialId> contains server assigned credential 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.




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


   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.

5.7.  GetSharedSecret

   GetSharedRequest is the main request message to request a 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 17, 2007                [Page 22]

Internet-Draft         Symmetric Key Provisioning           October 2006


   <element name="GetSharedSecret" type="oath-kp:GetSharedSecretType"/>
   <complexType name="GetSharedSecretType">
       <complexContent>
         <extension base="oath-kp:RequestAbstractType">
           <sequence maxOccurs="unbounded">
             <element name="CredentialId"
               type="oath-kp:CredentialIdType" minOccurs="0"/>
             <element name="ClientType" type="oath-kp:ClientTypeType"
               minOccurs="0"/>
             <element name="DeviceId" type="oath-pskc:DeviceIdType"
                   minOccurs="0"/>
             <element name="AuthenticationData"
                   type="oath-kp:AuthenticationDataType" minOccurs="0"/>
             <element name="SecretAlgorithm"
               type="oath-pskc:SecretAlgorithmType"
               minOccurs="0"/>
             <element name="OtpAlgorithm"
                   type="oath-pskc:OtpAlgorithmIdentifierType"
                   minOccurs="0"/>
             <element name="SharedSecretDeliveryMethod"
               type="oath-kp: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-kp:ExtensionType"
                   minOccurs="0" maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
   </complexType>

   The components of the GetSharedSecretType have the following
   meanings:

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

   o  <ClientType> indicates the device type.

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




Pei & Machani            Expires April 17, 2007                [Page 23]

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  <OtpAlgorithm> indicates the OTP algorithm 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  <id> 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.

5.8.  GetSharedSecretResponse

   The GetSharedSecretResponse element represents a provisioning service
   response message corresponding to a shared secret request.  Such a
   message contains shared secret container similarly defined by OATH
   [PSKC] 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 17, 2007                [Page 24]

Internet-Draft         Symmetric Key Provisioning           October 2006


   <element name="GetSharedSecretResponse"
           type="oath-kp:GetSharedSecretResponseType"/>
   <complexType name="GetSharedSecretResponseType">
       <complexContent>
         <extension base="oath-kp:ResponseAbstractType">
           <sequence minOccurs="0">
             <element name="SharedSecretDeliveryMethod"
               type="oath-kp:SharedSecretDeliveryMethodType"
               minOccurs="0"/>
             <element name="Credential" type="oath-kp:CredentialType"
                   minOccurs="0"/>
             <element name="Extension" type="oath-kp:ExtensionType"
                   minOccurs="0" maxOccurs="unbounded"/>
           </sequence>
         </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  <Credential> contains credential related information.  It can be
      one or many credentials.  The default format of credential is
      PSKC.  Other credential format such as PKCS12 can also be used by
      a provisioning server.

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




















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


6.  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 17, 2007                [Page 26]

Internet-Draft         Symmetric Key Provisioning           October 2006


7.  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.

7.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 17, 2007                [Page 27]

Internet-Draft         Symmetric Key Provisioning           October 2006


7.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.

7.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 17, 2007                [Page 28]

Internet-Draft         Symmetric Key Provisioning           October 2006


8.  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 17, 2007                [Page 29]

Internet-Draft         Symmetric Key Provisioning           October 2006


9.  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 17, 2007                [Page 30]

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-kp="http://www.openauthentication.org/OATH/2006/10/DSKPP"
 xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/08/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/08/PSKC"
  schemaLocation="http://www.openauthentication.org/OATH/2006/08/PSKC/
  oath_pskc_schema_v1.1.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-kp:VersionType"
    use="required"/>
  </complexType>

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



Pei & Machani            Expires April 17, 2007                [Page 31]

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-kp:MessageAbstractType">
        <sequence>
          <element ref="ds:Signature" minOccurs="0"/>
        </sequence>
        <attribute name="id" type="oath-kp:IdentifierType"
        use="optional"/>
      </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-kp:MessageAbstractType">
        <sequence>
          <element name="Status" type="oath-kp:StatusType"/>
        </sequence>
        <attribute name="requestId" type="oath-kp:IdentifierType"
        use="optional"/>
      </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>



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


    </annotation>
    <sequence>
      <element name="StatusCode" type="oath-kp: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-kp:ActivationCodeType"/>
        <element name="ActivationCodeDigest"
                type="oath-kp:ActivationCodeDigestType"/>
        <element name="ActivationCodeMac"
                type="oath-kp:ActivationCodeMacType"/>
        <any namespace="##other" processContents="strict"/>
      </choice>
    </sequence>
    <attribute name="form" type="oath-kp:AuthDataFormType"
    use="optional" default="ACTIVATIONCODE"/>
  </complexType>



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


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

  <simpleType name="CredentialFormatType">
    <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-kp:GetAuthNonceType"/>

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

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

  <complexType name="GetAuthNonceResponseType">
    <complexContent>
      <extension base="oath-kp:ResponseAbstractType">
        <sequence minOccurs="0" maxOccurs="unbounded">
           <element name="CredentialId"
                type="oath-kp:CredentialIdType"/>
           <element name="ServiceId" type="oath-kp:IdentifierType"/>
        </sequence>
        <attribute name="serverNonce" type="oath-kp:NonceType"/>
        <attribute name="sessionId" type="oath-kp:IdentifierType"
                use="optional"/>
      </extension>



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


    </complexContent>
  </complexType>

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

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

  <complexType name="GetSharedSecretType">
    <complexContent>
      <extension base="oath-kp:RequestAbstractType">
        <sequence maxOccurs="unbounded">
          <element name="CredentialId"
            type="oath-kp:CredentialIdType" minOccurs="0"/>
          <element name="ClientType" type="oath-kp:ClientTypeType"
            minOccurs="0"/>
          <element name="DeviceId" type="oath-pskc:DeviceIdType"
                minOccurs="0"/>
          <element name="AuthenticationData"
                type="oath-kp:AuthenticationDataType" minOccurs="0"/>
          <element name="SecretAlgorithm"
            type="oath-pskc:SecretAlgorithmType"
            minOccurs="0"/>
          <element name="OtpAlgorithm"
                type="oath-pskc:OtpAlgorithmIdentifierType"
                minOccurs="0"/>
          <element name="SharedSecretDeliveryMethod"
            type="oath-kp: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-kp:ExtensionType"
                minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <complexType name="ExtensionType" abstract="true">
    <sequence>
      <element name="ExtensionId" type="anyURI"/>
      <element name="ExtensionValue" type="base64Binary"/>



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


    </sequence>
    <attribute name="critical" type="boolean"/>
  </complexType>

  <simpleType name="CredentialIdType">
    <annotation>
      <documentation xml:lang="en">
        Credential identifier. Limited to 40 characters.
      </documentation>
    </annotation>
    <restriction base="string">
      <maxLength value="40"/>
    </restriction>
  </simpleType>

  <simpleType name="ClientTypeType">
    <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="HMACAlgorithmType">
    <annotation>
      <documentation xml:lang="en">
        List of supported HMAC algorithms.
      </documentation>
    </annotation>
    <restriction base="string">
      <enumeration value="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
      <enumeration
        value="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>
      <enumeration
        value="http://www.w3.org/2001/04/xmldsig-more#hmac-sha512"/>
    </restriction>
  </simpleType>

  <simpleType name="DigestAlgorithmType">
    <annotation>
      <documentation xml:lang="en">
        List of supported message digest algorithms.
      </documentation>



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


    </annotation>
    <restriction base="string">
      <enumeration value="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <enumeration
        value="http://www.w3.org/2001/04/xmldsig-more#sha256"/>
      <enumeration
        value="http://www.w3.org/2001/04/xmldsig-more#sha512"/>
    </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-kp:DigestAlgorithmType"
                use="required"/>
      </extension>
    </simpleContent>
  </complexType>

  <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-kp:NonceType" minOccurs="0"/>
    </sequence>
    <attribute name="algorithm" type="oath-kp:CredentialIdType"
        use="required"/>
    <attribute name="nonceId" type="oath-kp:IdentifierType"



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


        use="optional"/>
  </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-kp:CredentialFormatType"
        default="PSKC"/>
  </complexType>

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

  <complexType name="GetSharedSecretResponseType">
    <complexContent>
      <extension base="oath-kp:ResponseAbstractType">
        <sequence minOccurs="0">
          <element name="SharedSecretDeliveryMethod"
            type="oath-kp:SharedSecretDeliveryMethodType"
            minOccurs="0"/>
          <element name="Credential" type="oath-kp:CredentialType"
                minOccurs="0"/>
          <element name="Extension" type="oath-kp:ExtensionType"
                minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>
</schema>






Pei & Machani            Expires April 17, 2007                [Page 38]

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"
xsi:schemaLocation="http://www.openauthentication.org/OATH/2006/10/DSKPP
 oath_dskpp_schema_v1.0.xsd"
 xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/08/PSKC"
 xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
 xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
 id="1234abcd"
 version="1.0">
    <ClientType>MOBILEPHONE</ClientType>
    <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>
    <OtpAlgorithm type="HMAC-SHA1-TRUNC-6DIGITS" mode="PLAIN-SINGLE"/>
    <SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
    <SupportedEncryptionAlgorithm>PBE-3DES168-CBC
    </SupportedEncryptionAlgorithm>
</GetSharedSecret>

   Server responses with an encrypted credential in
   GetSharedSecretResponse upon approval.










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


<?xml version="1.0" encoding="UTF-8"?>
<GetSharedSecretResponse
xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.openauthentication.org/OATH/2006/10/DSKPP
oath_dskpp_schema_v1.0.xsd"
    requestId="1234abcd" version="1.0">
    <Status>
        <StatusCode>Success</StatusCode>
        <StatusMessage>Success</StatusMessage>
    </Status>
    <SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
    <Credential format="PSKC">
        <SecretContainer version="1.0"
        xmlns="http://www.openauthentication.org/OATH/2006/08/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">
                        <Counter>0</Counter>
                        <Response format="DECIMAL" length="6"/>
                    </Usage>
                    <FriendlyName>MyFirstToken</FriendlyName>
                    <Data>
                        <Value>
           7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==
                        </Value>
                        <ValueDigest>WldjTHZwRm9YTkhBRytseDMrUnc=
                        </ValueDigest>
                    </Data>
                    <AccessRules/>
                    <Expiry>2007-04-30T12:00:00</Expiry>
                </Secret>
            </Device>
         </SecretContainer>
    </Credential>
</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 17, 2007                [Page 40]

Internet-Draft         Symmetric Key Provisioning           October 2006


   <?xml version="1.0" encoding="UTF-8"?>
   <GetAuthNonce
     xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
     id="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 17, 2007                [Page 41]

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/08/PSKC"
  xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
  xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
  id="1234abcd"
  version="1.0">
    <ClientType>MOBILEPHONE</ClientType>
    <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>
    <OtpAlgorithm type="HMAC-SHA1-TRUNC-6DIGITS" mode="PLAIN-SINGLE"/>
    <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 17, 2007                [Page 42]

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 17, 2007                [Page 43]

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 <at> 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 <at> diversinet.com






























Pei & Machani            Expires April 17, 2007                [Page 44]

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 <at> ietf.org.


Acknowledgment

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





Pei & Machani            Expires April 17, 2007                [Page 45]


<div>
<div><span class="027554004-16102006">Attached is the 
draft submitted to IETF on 10/15/06. We are thankful for the suggestions and 
comments posted in this list.</span></div>
<div>
<span class="027554004-16102006"></span>&nbsp;</div>
<div><span class="027554004-16102006">Thank 
you,</span></div>
<div>
<span class="027554004-16102006"></span>&nbsp;</div>
<div><span class="027554004-16102006">- 
Ming</span></div>
<div>
<span class="027554004-16102006"></span>&nbsp;</div>
</div>
Salah Machani | 13 Oct 20:54 2006

RE: FW: Updated provisioning doc (RE: OATH Provisioningcall Jul 31: minutes)

Ming,  Here are additional edits and comments to the October 11th draft.
Please incorporate as appropriate into the final draft.

Although many changes have been made since the August version, the
document still needs additional work and revisions for clarity and
consistency. 

Thanks,

Salah

________________________________

From: ietf-keyprov-bounces@...
[mailto:ietf-keyprov-bounces@...] On Behalf Of Kevin Lewis
Sent: Thursday, September 14, 2006 11:35 AM
To: ietf-keyprov@...
Subject: [Ietf-keyprov] FW: Updated provisioning doc (RE: OATH
Provisioningcall Jul 31: minutes)

Feedback on Provisioning Protocol spec....

Due to the large number of edits and comments I have made the changes
within the document. Please incorporate as appropriate. 

In general my feeling is that this document needs additional work to
make it easier on the reader and provide additional clarity in
describing the use cases, the protocol, the messages, and the message
detail. My assessment is that we need at least another round of review
and possibly a face-to-face meeting to go over this document in detail.
I did not attempt to proof or test the XML schema or examples.

Thanks,

Kevin

________________________________

From: Pei, Mingliang [mailto:mpei@...] 
Sent: Tuesday, August 08, 2006 3:41 AM
To: svaeth@...; Hallam-Baker, Phillip; Bajaj, Siddharth;
Susan Cannon; jon.martinsson@...; Salah Machani; Chen,
Hseuping; Jeffrey Bohren; Philip Hoyer; Ron LaPedis; Kevin Lewis; Robert
Zuccherato; Jim Spring; Shuh Chang
Subject: Updated provisioning doc (RE: OATH Provisioning call Jul 31:
minutes)

Attached please find updated provisioning doc. This version includes the
following changes:

1. Added a new use case where an outsourced credential issue acquires
credentials for its users through its proxy to outsourcing service
provider. 

This is a new use case that is needed for token sharing service provider
model such as VeriSign VIP service. See use case #5.

2. Re-indexed the use case list, removed the unsupported use case about
credential upload, and split the lifecycle management case to other
cases for specific need

3. Expanded section about "Client authentication" to discuss the new
case support and out of band authentication need.

4. Made AuthenticationToken optional in GetSharedSecret request to allow
out of band authentication.

5. Corrected typo about "Nouce" ("Nonce")

Thanks Stu and Shuh for their suggestions in this morning's conf call.

Please review. Your suggestions and comments are appreciated.

- Ming

Notice to Recipient:  The information in this message is meant only for the intended recipient of the
transmission and may contain confidential or privileged information. 
Any copying, retransmittal, taking of action in reliance on, or other use of the information in this
communication by persons other than the addressees is prohibited.  
If you received this email in error, please immediately notify us and please delete or destroy all copies of
this message.
This message may have been altered without your or our knowledge and the sender does not accept any
liability for any errors.  Thank you.

Attachment (dskpp-draft-00-sm2.doc): application/msword, 482 KiB
Ming,  Here are additional edits and comments to the October 11th draft.
Please incorporate as appropriate into the final draft.

Although many changes have been made since the August version, the
document still needs additional work and revisions for clarity and
consistency. 

Thanks,

Salah

________________________________

From: ietf-keyprov-bounces@...
[mailto:ietf-keyprov-bounces@...] On Behalf Of Kevin Lewis
Sent: Thursday, September 14, 2006 11:35 AM
To: ietf-keyprov@...
Subject: [Ietf-keyprov] FW: Updated provisioning doc (RE: OATH
Provisioningcall Jul 31: minutes)

Feedback on Provisioning Protocol spec....

Due to the large number of edits and comments I have made the changes
within the document. Please incorporate as appropriate. 

In general my feeling is that this document needs additional work to
make it easier on the reader and provide additional clarity in
describing the use cases, the protocol, the messages, and the message
detail. My assessment is that we need at least another round of review
and possibly a face-to-face meeting to go over this document in detail.
I did not attempt to proof or test the XML schema or examples.

Thanks,

Kevin

________________________________

From: Pei, Mingliang [mailto:mpei@...] 
Sent: Tuesday, August 08, 2006 3:41 AM
To: svaeth@...; Hallam-Baker, Phillip; Bajaj, Siddharth;
Susan Cannon; jon.martinsson@...; Salah Machani; Chen,
Hseuping; Jeffrey Bohren; Philip Hoyer; Ron LaPedis; Kevin Lewis; Robert
Zuccherato; Jim Spring; Shuh Chang
Subject: Updated provisioning doc (RE: OATH Provisioning call Jul 31:
minutes)

Attached please find updated provisioning doc. This version includes the
following changes:

1. Added a new use case where an outsourced credential issue acquires
credentials for its users through its proxy to outsourcing service
provider. 

This is a new use case that is needed for token sharing service provider
model such as VeriSign VIP service. See use case #5.

2. Re-indexed the use case list, removed the unsupported use case about
credential upload, and split the lifecycle management case to other
cases for specific need

3. Expanded section about "Client authentication" to discuss the new
case support and out of band authentication need.

4. Made AuthenticationToken optional in GetSharedSecret request to allow
out of band authentication.

5. Corrected typo about "Nouce" ("Nonce")

Thanks Stu and Shuh for their suggestions in this morning's conf call.

Please review. Your suggestions and comments are appreciated.

- Ming

Notice to Recipient:  The information in this message is meant only for the intended recipient of the
transmission and may contain confidential or privileged information. 
Any copying, retransmittal, taking of action in reliance on, or other use of the information in this
communication by persons other than the addressees is prohibited.  
If you received this email in error, please immediately notify us and please delete or destroy all copies of
this message.
This message may have been altered without your or our knowledge and the sender does not accept any
liability for any errors.  Thank you.

Hallam-Baker, Phillip | 16 Oct 17:26 2006
Picon

Proposed BOF Agenda

We have been given a 2.5 hour slot on Thursday. 

THIS IS THE DRAFT AGENDA AND MAY CHANGE.

THURSDAY, November 9, 2006
0800-0900 Continental Breakfast - 
0900-1130 Morning Session I
SEC   keyprov   Provisioning of Symmetric Keys BOF

Hopefully the time/date should be fixed now that we are two weeks out.

Provisional agenda:

BOF Co-Chairs:
	Phillip Hallam-Baker (VeriSign)
	Susan Cannon (Sandisk) 

 5 mins	Agenda Bashing
30 mins	Problem Statements
			OTP Provisioning
			Kerberos Key Provisioning
30 mins	Protocol Proposals
			CT-KIP (Andrea Doherty)
			DSKPP (Mingliang Pei, Salah  Machani)
45 mins	Open Discussion

10 mins	Questions
			Who would contribute to a KEYPROV working group?
			Should it produce a Shared Symmetric Key token binding?
			Should it produce a Kerberos binding?

Feel free to propose additional agenda items to the chairs.
Doherty, Andrea | 18 Oct 16:33 2006

RE: Proposed BOF Agenda

As preparation for the meeting, please clarify the intent of including
Kerberos in the Proposed Charter and agenda.
Andrea 

-----Original Message-----
From: ietf-keyprov-bounces@...
[mailto:ietf-keyprov-bounces@...] On Behalf Of Hallam-Baker,
Phillip
Sent: Monday, October 16, 2006 11:26 AM
To: ietf-keyprov@...
Cc: Susan Cannon
Subject: [Ietf-keyprov] Proposed BOF Agenda

We have been given a 2.5 hour slot on Thursday. 

THIS IS THE DRAFT AGENDA AND MAY CHANGE.

THURSDAY, November 9, 2006
0800-0900 Continental Breakfast - 
0900-1130 Morning Session I
SEC   keyprov   Provisioning of Symmetric Keys BOF

Hopefully the time/date should be fixed now that we are two weeks out.

Provisional agenda:

BOF Co-Chairs:
	Phillip Hallam-Baker (VeriSign)
	Susan Cannon (Sandisk) 

 5 mins	Agenda Bashing
30 mins	Problem Statements
			OTP Provisioning
			Kerberos Key Provisioning
30 mins	Protocol Proposals
			CT-KIP (Andrea Doherty)
			DSKPP (Mingliang Pei, Salah  Machani)
45 mins	Open Discussion

10 mins	Questions
			Who would contribute to a KEYPROV working group?
			Should it produce a Shared Symmetric Key token
binding?
			Should it produce a Kerberos binding?

Feel free to propose additional agenda items to the chairs.
_______________________________________________
Ietf-keyprov mailing list
Ietf-keyprov@...
http://www.safehaus.org/mailman/listinfo/ietf-keyprov
Hallam-Baker, Phillip | 18 Oct 17:13 2006
Picon

RE: Proposed BOF Agenda

It is merely an issue that was proposed as a potential application having similar requirements.

At this point I am not sure if it is still being proposed. I will check.

> -----Original Message-----
> From: Doherty, Andrea [mailto:adoherty@...] 
> Sent: Wednesday, October 18, 2006 10:33 AM
> To: Hallam-Baker, Phillip
> Cc: Susan Cannon; ietf-keyprov@...
> Subject: RE: [Ietf-keyprov] Proposed BOF Agenda
> 
> As preparation for the meeting, please clarify the intent of 
> including Kerberos in the Proposed Charter and agenda.
> Andrea 
> 
> -----Original Message-----
> From: ietf-keyprov-bounces@...
> [mailto:ietf-keyprov-bounces@...] On Behalf Of 
> Hallam-Baker, Phillip
> Sent: Monday, October 16, 2006 11:26 AM
> To: ietf-keyprov@...
> Cc: Susan Cannon
> Subject: [Ietf-keyprov] Proposed BOF Agenda
> 
> We have been given a 2.5 hour slot on Thursday. 
> 
> THIS IS THE DRAFT AGENDA AND MAY CHANGE.
> 
> THURSDAY, November 9, 2006
> 0800-0900 Continental Breakfast -
> 0900-1130 Morning Session I
> SEC   keyprov   Provisioning of Symmetric Keys BOF
> 
> Hopefully the time/date should be fixed now that we are two weeks out.
> 
> 
> Provisional agenda:
> 
> BOF Co-Chairs:
> 	Phillip Hallam-Baker (VeriSign)
> 	Susan Cannon (Sandisk) 
> 
>  5 mins	Agenda Bashing
> 30 mins	Problem Statements
> 			OTP Provisioning
> 			Kerberos Key Provisioning
> 30 mins	Protocol Proposals
> 			CT-KIP (Andrea Doherty)
> 			DSKPP (Mingliang Pei, Salah  Machani)
> 45 mins	Open Discussion
> 
> 10 mins	Questions
> 			Who would contribute to a KEYPROV working group?
> 			Should it produce a Shared Symmetric 
> Key token binding?
> 			Should it produce a Kerberos binding?
> 
> Feel free to propose additional agenda items to the chairs.
> _______________________________________________
> Ietf-keyprov mailing list
> Ietf-keyprov@...
> http://www.safehaus.org/mailman/listinfo/ietf-keyprov
> 
> 
Pei, Mingliang | 23 Oct 13:01 2006
Picon

FW: [Auto Response] Submission of updated Internet Draft "draft-pei-dynamic-symkey-prov-protocol-01.txt"


OATH submission of I-D DSKPP is updated with v1.1 (-01). Attached is the
version submitted.

- Ming

-----Original Message-----
From: Internet Draft Submission Manager
[mailto:internet-drafts-reply@...] 
Sent: Monday, October 23, 2006 3:58 AM
To: Pei, Mingliang
Subject: [Auto Response] Submission of updated Internet Draft
"draft-pei-dynamic-symkey-prov-protocol-01.txt"

Greetings:

This message is being sent to acknowledge receipt of your Internet-Draft
submission or message to internet-drafts@...  Please note that the
pre-meeting cutoff date for new documents (i.e., version -00
Internet-Drafts) was Monday, October 16 at 9:00 AM ET.
Your submission was received after this time.  The Internet-Drafts
administrator will examine your submission, and the posting decision
will be made as follows:

* If you submitted a version -00 Internet-Draft before the cutoff
  deadline, then your document will be posted on the Internet-Drafts
  page of the IETF Web site as soon as possible, and an I-D Action
  message will be sent to the I-D Announce List.  If your document was
  submitted before the cutoff deadline, but was rejected due to
  boilerplate or format issues, then the Internet-Drafts administrator
  will work with you to attempt to resolve these issues and post the
  document in time for the meeting. 

* If you submitted a version -00 Internet-Draft after the cutoff
  deadline, then your document will NOT be processed until on or after
  Monday, November 6 at 9:00 AM ET, when Internet-Draft
  posting resumes.

* If you submitted a version -01 or higher Internet-Draft, then your
  document will be posted on the Internet-Drafts page of the IETF Web
  site as soon as possible, and an I-D Action message will be sent to
  the I-D Announce List.

As you may be aware, the pre-meeting cutoff date for updated submissions
is Monday, October 23 at 9:00 AM ET.  Since the Secretariat receives a
large number of Internet-Drafts in the week preceding the cutoff date
for updated submissions, your document may not be processed and
announced for a number of days.  Our goal is to process and announce all
valid pre-meeting Internet-Draft submissions by Friday, October 27 at
the latest.  
If you need to track the status of your Internet-Draft submission, then
please send a note to ietf-action@... (using the suggested subject
line Status of I-D Submission: <filename>) and reference this
auto-response acknowledgement in the body.

Please note that all Internet-Drafts offered for publication as RFCs
must conform to the requirements specified in the ID-Checklist
(http://www.ietf.org/ID-Checklist.html) or they will be returned to the
author(s) for revision.  Therefore, the IETF Secretariat strongly
recommends that you address all of the issues raised in this document
before submitting a request to publish your Internet-Draft to the IESG.

The IETF Secretariat

Attachment (oath_dskpp_schema_v1.1.xsd): application/octet-stream, 14 KiB


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 <at> 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 <at> 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 <at> 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]


Attachment (oath_pskc_schema_v1.2.xsd): application/octet-stream, 13 KiB

OATH submission of I-D DSKPP is updated with v1.1 (-01). Attached is the
version submitted.

- Ming

-----Original Message-----
From: Internet Draft Submission Manager
[mailto:internet-drafts-reply@...] 
Sent: Monday, October 23, 2006 3:58 AM
To: Pei, Mingliang
Subject: [Auto Response] Submission of updated Internet Draft
"draft-pei-dynamic-symkey-prov-protocol-01.txt"

Greetings:

This message is being sent to acknowledge receipt of your Internet-Draft
submission or message to internet-drafts@...  Please note that the
pre-meeting cutoff date for new documents (i.e., version -00
Internet-Drafts) was Monday, October 16 at 9:00 AM ET.
Your submission was received after this time.  The Internet-Drafts
administrator will examine your submission, and the posting decision
will be made as follows:

* If you submitted a version -00 Internet-Draft before the cutoff
  deadline, then your document will be posted on the Internet-Drafts
  page of the IETF Web site as soon as possible, and an I-D Action
  message will be sent to the I-D Announce List.  If your document was
  submitted before the cutoff deadline, but was rejected due to
  boilerplate or format issues, then the Internet-Drafts administrator
  will work with you to attempt to resolve these issues and post the
  document in time for the meeting. 

* If you submitted a version -00 Internet-Draft after the cutoff
  deadline, then your document will NOT be processed until on or after
  Monday, November 6 at 9:00 AM ET, when Internet-Draft
  posting resumes.

* If you submitted a version -01 or higher Internet-Draft, then your
  document will be posted on the Internet-Drafts page of the IETF Web
  site as soon as possible, and an I-D Action message will be sent to
  the I-D Announce List.

As you may be aware, the pre-meeting cutoff date for updated submissions
is Monday, October 23 at 9:00 AM ET.  Since the Secretariat receives a
large number of Internet-Drafts in the week preceding the cutoff date
for updated submissions, your document may not be processed and
announced for a number of days.  Our goal is to process and announce all
valid pre-meeting Internet-Draft submissions by Friday, October 27 at
the latest.  
If you need to track the status of your Internet-Draft submission, then
please send a note to ietf-action@... (using the suggested subject
line Status of I-D Submission: <filename>) and reference this
auto-response acknowledgement in the body.

Please note that all Internet-Drafts offered for publication as RFCs
must conform to the requirements specified in the ID-Checklist
(http://www.ietf.org/ID-Checklist.html) or they will be returned to the
author(s) for revision.  Therefore, the IETF Secretariat strongly
recommends that you address all of the issues raised in this document
before submitting a request to publish your Internet-Draft to the IESG.

The IETF Secretariat

Stuart Vaeth | 23 Oct 15:36 2006

RE: [Auto Response] Submission of updated Internet Draft "draft-pei-dynamic-symkey-prov-protocol-01.txt"

Thanks for submitting v1.1 for deadline.
Stu

-----Original Message-----
From: Pei, Mingliang [mailto:mpei@...] 
Sent: Monday, October 23, 2006 7:02 AM
To: Stu Vaeth; Salah Machani; Hallam-Baker, Phillip; Bajaj, Siddharth; Susan
Cannon; jon.martinsson@...; Jeffrey Bohren; Philip Hoyer; Ron
LaPedis; Kevin Lewis; Robert Zuccherato; Jim Spring; Shuh Chang;
ietf-keyprov@...
Subject: FW: [Auto Response] Submission of updated Internet Draft
"draft-pei-dynamic-symkey-prov-protocol-01.txt"

 
OATH submission of I-D DSKPP is updated with v1.1 (-01). Attached is the
version submitted.

- Ming

-----Original Message-----
From: Internet Draft Submission Manager
[mailto:internet-drafts-reply@...] 
Sent: Monday, October 23, 2006 3:58 AM
To: Pei, Mingliang
Subject: [Auto Response] Submission of updated Internet Draft
"draft-pei-dynamic-symkey-prov-protocol-01.txt"

Greetings:

This message is being sent to acknowledge receipt of your Internet-Draft
submission or message to internet-drafts@...  Please note that the
pre-meeting cutoff date for new documents (i.e., version -00
Internet-Drafts) was Monday, October 16 at 9:00 AM ET.
Your submission was received after this time.  The Internet-Drafts
administrator will examine your submission, and the posting decision
will be made as follows:

* If you submitted a version -00 Internet-Draft before the cutoff
  deadline, then your document will be posted on the Internet-Drafts
  page of the IETF Web site as soon as possible, and an I-D Action
  message will be sent to the I-D Announce List.  If your document was
  submitted before the cutoff deadline, but was rejected due to
  boilerplate or format issues, then the Internet-Drafts administrator
  will work with you to attempt to resolve these issues and post the
  document in time for the meeting. 

* If you submitted a version -00 Internet-Draft after the cutoff
  deadline, then your document will NOT be processed until on or after
  Monday, November 6 at 9:00 AM ET, when Internet-Draft
  posting resumes.

* If you submitted a version -01 or higher Internet-Draft, then your
  document will be posted on the Internet-Drafts page of the IETF Web
  site as soon as possible, and an I-D Action message will be sent to
  the I-D Announce List.

As you may be aware, the pre-meeting cutoff date for updated submissions
is Monday, October 23 at 9:00 AM ET.  Since the Secretariat receives a
large number of Internet-Drafts in the week preceding the cutoff date
for updated submissions, your document may not be processed and
announced for a number of days.  Our goal is to process and announce all
valid pre-meeting Internet-Draft submissions by Friday, October 27 at
the latest.  
If you need to track the status of your Internet-Draft submission, then
please send a note to ietf-action@... (using the suggested subject
line Status of I-D Submission: <filename>) and reference this
auto-response acknowledgement in the body.

Please note that all Internet-Drafts offered for publication as RFCs
must conform to the requirements specified in the ID-Checklist
(http://www.ietf.org/ID-Checklist.html) or they will be returned to the
author(s) for revision.  Therefore, the IETF Secretariat strongly
recommends that you address all of the issues raised in this document
before submitting a request to publish your Internet-Draft to the IESG.

The IETF Secretariat

Hallam-Baker, Phillip | 23 Oct 18:22 2006
Picon

New version of the draft of Portable Symmetric Key Container

From: Philip Hoyer
Sent: 20 October 2006 19:21
To: 'internet-drafts-EgrivxUAwEY@public.gmane.org'
Cc: Salah Machani; Bajaj, Siddharth; Stu Vaeth; 'Pei, Mingliang'; Shuh Chang
Subject: New version of the draft of Portable Symmetric Key Containe

 

Please find attached the new version of the draft

 

________________________________

Philip Hoyer

 

Senior Architect - Office of CTO

 

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL

 

Telephone: +44 (0) 20 7744 6248

Direct: +44 (0) 20 7744 6455

Fax: +44 (0) 20 7744 6249

 

Private and confidential: This message and any attachments may contain

privileged / confidential information. If you are not an intended recipient,

you must not copy, distribute, discuss or take any action in reliance on it.

If you have received this communication in error, please notify the sender

and delete this message immediately.

 




Network Working Group                                        A. Vassilev
Internet-Draft                                                    Axalto
Intended status: Standards Track                           J. Martinsson
Expires: February 2, 2007                                       PortWise
                                                                  M. Pei
                                                                VeriSign
                                                                P. Hoyer
                                                           ActivIdentity
                                                              S. Machani
                                                              Diversinet
                                                             August 2006


                    Portable Symmetric Key Container
         draft-vassilev-portable-symmetric-key-container-02.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 February 2, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).







Vassilev, et al.        Expires February 2, 2007                [Page 1]

Internet-Draft      Portable Symmetric Key Container         August 2006


Abstract

   This document specifies a shared secret token format for transport
   and provisioning of shared secrets (One Time Password (OTP) keys or
   symmetric cryptographic keys) to different types of strong
   authentication devices.  The standard token format enables
   enterprises to deploy best-of-breed solutions combining components
   from different vendors into the same infrastructure.

   This work is a joint effort by the members of OATH (Initiative for
   Open AuTHentication) to specify a format 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
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Offline Use Cases  . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Credential migration by end-user . . . . . . . . . . .  6
       3.1.2.  Bulk import of new credentials . . . . . . . . . . . .  6
       3.1.3.  Bulk migration of existing credentials . . . . . . . .  6
       3.1.4.  Credential upload case . . . . . . . . . . . . . . . .  7
     3.2.  Online Use Cases . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  Online provisioning a credential to end-user's
               authentication token . . . . . . . . . . . . . . . . .  7
       3.2.2.  Server to server provisioning of credentials . . . . .  8
       3.2.3.  Online update of an existing authentication token
               credential . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Shared Secret Attributes . . . . . . . . . . . . . . . . . . . 11
     5.1.  Common Attributes  . . . . . . . . . . . . . . . . . . . . 11
       5.1.1.  Data (OPTIONAL)  . . . . . . . . . . . . . . . . . . . 11
       5.1.2.  SecretAlgorithm (MANDATORY)  . . . . . . . . . . . . . 11
       5.1.3.  Usage (MANDATORY)  . . . . . . . . . . . . . . . . . . 11
       5.1.4.  SecretId (MANDATORY) . . . . . . . . . . . . . . . . . 12
       5.1.5.  Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 12
       5.1.6.  AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 12
       5.1.7.  EncryptionMethod (MANDATORY) . . . . . . . . . . . . . 12
       5.1.8.  DigestMethod (MANDATORY when Digest is present)  . . . 13
       5.1.9.  OTP and CR specific Attributes . . . . . . . . . . . . 13
   6.  Secret container XML schema definitions  . . . . . . . . . . . 17
     6.1.  XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17
       6.1.1.  SecretType . . . . . . . . . . . . . . . . . . . . . . 18



Vassilev, et al.        Expires February 2, 2007                [Page 2]

Internet-Draft      Portable Symmetric Key Container         August 2006


       6.1.2.  UsageType  . . . . . . . . . . . . . . . . . . . . . . 20
       6.1.3.  DeviceType . . . . . . . . . . . . . . . . . . . . . . 22
       6.1.4.  DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22
       6.1.5.  UserType Type  . . . . . . . . . . . . . . . . . . . . 23
       6.1.6.  SecretContainerType  . . . . . . . . . . . . . . . . . 24
       6.1.7.  EncryptionMethodType . . . . . . . . . . . . . . . . . 25
       6.1.8.  DigestMethodType . . . . . . . . . . . . . . . . . . . 26
       6.1.9.  OtpAlgorithmIdentifierType . . . . . . . . . . . . . . 27
     6.2.  EncryptionAlgorithmType  . . . . . . . . . . . . . . . . . 28
     6.3.  HashAlgorithmType  . . . . . . . . . . . . . . . . . . . . 30
     6.4.  DigestAlgorithmType  . . . . . . . . . . . . . . . . . . . 30
     6.5.  SecretAlgorithmType  . . . . . . . . . . . . . . . . . . . 31
     6.6.  valueFormat  . . . . . . . . . . . . . . . . . . . . . . . 32
     6.7.  Data elements  . . . . . . . . . . . . . . . . . . . . . . 33
       6.7.1.  SecretContainer  . . . . . . . . . . . . . . . . . . . 33
   7.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 34
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
     8.1.  Payload confidentiality  . . . . . . . . . . . . . . . . . 40
     8.2.  Payload integrity  . . . . . . . . . . . . . . . . . . . . 41
     8.3.  Payload authenticity . . . . . . . . . . . . . . . . . . . 41
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
   10. Appendix A - Example Symmetric Key Containers  . . . . . . . . 43
     10.1. Symmetric Key Container with a single Non-Encrypted
           HOTP Secret Key  . . . . . . . . . . . . . . . . . . . . . 43
     10.2. Symmetric Key Container with a single Password-based
           Encrypted HOTP Secret Key  . . . . . . . . . . . . . . . . 44
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 45
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
   Intellectual Property and Copyright Statements . . . . . . . . . . 49






















Vassilev, et al.        Expires February 2, 2007                [Page 3]

Internet-Draft      Portable Symmetric Key Container         August 2006


1.  Introduction

   With increasing use of symmetric key based authentication systems
   such as systems based one time password (OTP) and challenge response
   mechanisms, there is a need for vendor interoperability and a
   standard format for importing, exporting or provisioning symmetric
   key based credentials from one system to another.  Traditionally
   authentication server vendors and service providers have used
   proprietary formats for importing, exporting and provisioning these
   credentials into their systems making it hard to use tokens from
   vendor A with a server from vendor B.

   This Internet draft describes a standard format for serializing
   symmetric key based credentials such as OTP shared secrets for system
   import, export or network/protocol transport, promoted by [OATH].
   The goal is that the format will facilitate dynamic provisioning of
   OTP credentials using an OTP provisioning protocol to different
   flavors of embedded tokens or allow customers to import new or
   existing tokens in batch or single instances into a compliant system.

   This draft also specifies the token attributes required for
   interoperability such as the initial event counter used in the HOTP
   algorithm [HOTP].  It is also applicable for other time-based or
   proprietary algorithms.

   To provide an analogy, in public key environments the PKCS#12 format
   [PKCS12] is commonly used for importing and exporting private keys
   and certificates between systems.  In the environments outlined in
   this document where OTP credentials may be transported directly down
   to smartcards or devices with limited computing capabilities, a small
   (size in bytes) and more shared secret oriented format is desirable,
   avoiding the complexity in PKCS#12.  One example of PKCS#12 limits is
   that to carry the shared secret attributes used for OTP calculations
   one would use the opaque data within PKCS#12, wherears a more
   explicit attribute schema definition is desirable.
















Vassilev, et al.        Expires February 2, 2007                [Page 4]

Internet-Draft      Portable Symmetric Key Container         August 2006


2.  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 examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   In the text below, OTP refers to one time password.









































Vassilev, et al.        Expires February 2, 2007                [Page 5]

Internet-Draft      Portable Symmetric Key Container         August 2006


3.  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.

   These use cases also help in understanding the applicability of this
   specification to real world situations.

3.1.  Offline Use Cases

   This section describes the use cases relating to offline transport of
   credentials from one system to another, using some form of export and
   import model.

3.1.1.  Credential migration by end-user

   A user wants to migrate a credential from one authentication token
   (container) to a different authentication token.  For example, the
   authentication tokens may be soft tokens on two different systems
   (computers or mobile phones).  The user can export the credential in
   a standard format for import into the other authentication token.

   The key protection mechanism may rely on password-based encryption
   for soft tokens, a pre-placed hardware-protected transfer key shared
   between the two systems or may also rely on asymmetric keys/ PKI if
   available.

3.1.2.  Bulk import of new credentials

   Tokens are manufactured in bulk and associated credentials (key
   records) need to be loaded into the validation system through a file
   on portable media.  The manufacturer provides the credentials in the
   form of a file containing records in standard format, typically on a
   CD.  Note that the token manufacturer and the vendor for the
   validation system may be the same or different.

   In this case the file usually is protected by a symmetric transport
   key which was communicated separately outside of the file between the
   two parties.

3.1.3.  Bulk migration of existing credentials

   An enterprise wants to port credentials from an existing validation
   system A into a different validation system B. The existing
   validation system provides the enterprise with a functionality that
   enables export of credentials (OTP tokens) in a standard format.



Vassilev, et al.        Expires February 2, 2007                [Page 6]

Internet-Draft      Portable Symmetric Key Container         August 2006


   Since the OTP tokens are in the standard format, the enterprise can
   import the token records into the new validation system B and start
   using the existing tokens.  Note that the vendors for the two
   validation systems may be the same or different.

   In this case the file usually is protected by a symmetric transport
   key which was communicated separately outside of the file between the
   two validation systems.

3.1.4.  Credential upload case

   User wants to activate and use a new credential against a validation
   system that is not aware of this credential.  This credential may be
   embedded in the authentication token (e.g.  SD card, USB drive) that
   the user has purchased at the local electronics retailer.  Along with
   the authentication token, the user may get the credential on a CD or
   a floppy in a standard format.  The user can now upload via a secure
   online channel or import this credential into the new validation
   system and start using the credential.

   The key protection mechanism may rely on password-based encryption,
   or a pre-placed hardware-protected transfer key shared between the
   token manufacturer and the validation system(s) if available.

3.2.  Online Use Cases

   This section describes the use cases related to provisioning the
   credentials using some form of a online provisioning protocol.

3.2.1.  Online provisioning a credential to end-user's authentication
        token

   A mobile device user wants to obtain an HOTP credential (shared
   secret) for use with an OTP soft token on the device.  The soft token
   client from vendor A initiates the provisioning process against a
   provisioning system from vendor B using a standards-based
   provisioning protocol as described in the OATH Reference Architecture
   [OATHRefArch].  The provisioning system delivers an OTP credential in
   a standard format that can be processed by the mobile device.  The
   user can download more than one credential in a single session if the
   provisioning server holds multiple credentials for that user.

   In a variation of the above, instead of the user's mobile phone, a
   credential is provisioned in the user's soft token application on a
   laptop using a network-based online protocol.  As before, the
   provisioning system delivers an OTP credential in a standard format
   that can be processed by the soft token on the PC.




Vassilev, et al.        Expires February 2, 2007                [Page 7]

Internet-Draft      Portable Symmetric Key Container         August 2006


3.2.2.  Server to server provisioning of credentials

   Sometimes, instead of importing token information from manufacturer
   using a file, an OTP validation server may download the credential
   seed records using an online protocol.  The credentials can be
   downloaded in a standard format that can be processed by a validation
   system.

   In another scenario, an OTA (over-the-air) credential provisioning
   gateway that provisions credentials to mobile phones may obtain
   credentials from the credential issuer using an online protocol.  The
   credentials are delivered in a standard format that can be processed
   by the OTA credential provisioning gateway and subsequently sent to
   the end-user's mobile phone.

3.2.3.  Online update of an existing authentication token credential

   The end-user or the credential issuer wants to update or configure an
   existing credential in the authentication token and requests a
   replacement credential container.  The container may or may not
   include a new secret key and may include new or updated secret key
   attributes such as a new counter value in HOTP credential case, a new
   logo, a modified response format or length, a new friendly name, etc.




























Vassilev, et al.        Expires February 2, 2007                [Page 8]

Internet-Draft      Portable Symmetric Key Container         August 2006


4.  Requirements

   This section outlines the most relevant requirements that are the
   basis of this work.  Several of the requirements were derived from
   use cases described above.

   R1:   The format MUST support transport of multiple types of
         symmetric key credentials including HOTP, other OTP, challenge-
         response, etc.

   R2:   The format MUST handle the symmetric key itself as well of
         attributes that are typically associated with symmetric keys.
         Some of these attributes may be

         *  Unique Key Identifier

         *  Issuer information

         *  Algorithm ID

         *  Algorithm mode

         *  Issuer Name

         *  Issuer logo

         *  Credential friendly name

         *  Event counter value

         *  Time value

   R3:   The format SHOULD support both offline and online scenarios.
         That is it should be serializable to a file as well as it
         should be possible to use this format in online provisioning
         protocols

   R4:   The format SHOULD allow bulk representation of symmetric key
         credentials.

   R5:   The format SHOULD be portable to various platforms.
         Furthermore, it SHOULD be computationally efficient to process.

   R6:   The format MUST provide appropriate level of security in terms
         of data encryption and data integrity.






Vassilev, et al.        Expires February 2, 2007                [Page 9]

Internet-Draft      Portable Symmetric Key Container         August 2006


   R7:   For online scenarios the format SHOULD NOT rely on transport
         level security (e.g., SSL/TLS) for core security requirements.

   R8:   The format SHOULD be extensible.  It SHOULD enable extension
         points allowing vendors to specify additional attributes in the
         future.

   R9:   The format SHOULD allow for distribution of key derivation data
         without the actual symmetric key itself.  This is to support
         symmetric key management schemes that rely on key derivation
         algorithms based on a pre-placed master key.  The key
         derivation data typically consists of a reference to the key,
         rather than the key value itself.

   R10:  The format SHOULD allow for additional lifecycle management
         operations such as counter resynchronization.  Such processes
         require confidentiality between client and server, thus could
         use a common secure container format, without the transfer of
         key material.

   R11:  The format MUST support the use of pre-shared symmetric keys to
         ensure confidentiality of sensitive data elements.

   R12:  The format MUST support a password-based encryption (PBE)
         [PKCS5] scheme to ensure security of sensitive data elements.
         This is a widely used method for various provisioning
         scenarios.

   R13:  The format SHOULD support asymmetric encryption algorithms such
         as RSA to ensure end-to-end security of sensitive data
         elements.  This is to support scenarios where a pre-set shared
         encryption key is difficult to use.



















Vassilev, et al.        Expires February 2, 2007               [Page 10]

Internet-Draft      Portable Symmetric Key Container         August 2006


5.  Shared Secret Attributes

   The shared secret includes a number of data attributes that define
   the type of the secret, its usage and associated meta-information
   required during the provisioning, configuration, access or usage in
   the host device.

5.1.  Common Attributes

5.1.1.  Data (OPTIONAL)

   Defines the data attributes of the secret.  Each is a name value pair
   which has both a base64 encoded value and a base 64 encoded
   valueDigest.  The value can be encrypted.  If the container has been
   encrypted the valueDigest MUST be populated with the digest of the
   unencrypted value.

   This is also where the key value is held, therefore the follwoing
   list of attribute names have been reserved:

      SECRET: the shared secret key value in binary, base64 encoded

      COUNTER: the event counter for event based OTP algorithms. 8 bytes
      unsigned integer in big endian (i.e. network byte order) form
      base64 encoded

      TIME: the time for time based OTP algorithms. 8 bytes unsigned
      integer in big endian (i.e. network byte order) form base64
      encoded (Number of seconds since 1970)

      TIME_INTERVAL: the time interval value for time based OTP
      algorithms. 8 bytes unsigned integer in big endian (i.e. network
      byte order) form base64 encoded.

5.1.2.  SecretAlgorithm (MANDATORY)

   Defines the type of algorithm of the secret key and MUST be set to
   one of the values defined in Section 6.5.  If 'OTHER' is specified an
   extension value MUST be set in the 'ext-SecretAlgorithm' attribute.

5.1.3.  Usage (MANDATORY)

   Defines the intended usage of the shared secret and is a combination
   of one or more of the following (set to true):







Vassilev, et al.        Expires February 2, 2007               [Page 11]

Internet-Draft      Portable Symmetric Key Container         August 2006


      OTP: the shared secret will be used for OTP generation

      CR: the shared secret will be used for Challenge/Response purposes

      ENCRYPT: the shared secret will be used for data encryption
      purposes

      SIGN: the shared secret will be used to generate a signature or
      keyed hashing for data integrity or authentication purposes.

      UNLOCK: the shared secret will be used for an inverse challenge
      response in the case a user has locked the device by entering a
      wrong PIN too many times (for devices with PIN-input capability)

   Additional attributes that are specific to the usage type MAY be
   required.  Section 6.1 describes OTP and CR specific attributes.

5.1.4.  SecretId (MANDATORY)

   A unique and global identifier of the shared secret.  The identifier
   is defined as a string of alphanumeric characters.

5.1.5.  Issuer (MANDATORY)

   The shared secret issuer name.  The Issuer is defined as a String.

5.1.6.  AccessRules (OPTIONAL)

   Defines a set of access rules and policies for the protection of the
   shared secret on the host Device.  Currently only the userPIN policy
   is defined.  The userPIN policy specifies whether the user MUST enter
   a PIN (for devices with PIN input capability) in order to unlock or
   authenticate to the device hosting the secret container.  The userPIN
   is defined as a Boolean (TRUE or FALSE).  When the user PIN is
   required, the policy MUST be set to TRUE.  If the userPIN is NOT
   provided, implementations SHALL default the value to FALSE.

5.1.7.  EncryptionMethod (MANDATORY)

   Identifies the encryption algorithm and possible parameters used to
   protect the Secret Key data in the container and MUST be set to one
   of the values defined in Section 6.2.  If 'OTHER' is specified an
   extension value MUST be set in the 'ext-algorithm' attribute.

   When the value is set to NONE, implementations SHALL ensure the
   privacy of the shared secret data through other standard mechanisms
   e.g. transport level encryption.




Vassilev, et al.        Expires February 2, 2007               [Page 12]

Internet-Draft      Portable Symmetric Key Container         August 2006


   When the SecretContainer contains more than one shared secret and
   EncryptionMethod is different from NONE, the same encryption key MUST
   be used to encrypt all the secret data elements in the container.

5.1.8.  DigestMethod (MANDATORY when Digest is present)

   Identifies the algorithm and possible parameters used to generate a
   digest of the the Secret Key data.  The digest guarantees the
   integrity and the authenticity of the shared secret data.  The Digest
   algorithm MUST be set to one of the values defined in Section 6.4.
   If 'OTHER' is specified an extension value MUST be set in the 'ext-
   algorithm' attribute.

   See Section 6.1.8 for more information on Digest data value type.

5.1.9.  OTP and CR specific Attributes

   When the shared secret usage is set to OTP or CR, additional
   attributes MUST be provided to support the OTP and/or the response
   computation as required by the underlying algorithm and to customize
   or configure the outcome of the computation (format, length and usage
   modes).

5.1.9.1.  ChallengeFormat (MANDATORY)

   The ChallengeFormat attribute defines the characteristics of the
   challenge in a CR usage scenario.  The Challenge attribute is defined
   by the following sub-attributes:

   1.  Format (MANDATORY)

          Defines the format of the challenge accepted by the device and
          MUST be one of the values defined in Section 6.6

   2.  CheckDigit (OPTIONAL)

          Defines if the device needs to check the appended Luhn check
          digit contained in a provided challenge.  This is only valid
          if the Format attribute is'DECIMAL'.  Value MUST be:

             TRUE device will check the appended Luhn check digit in a
             provided challenge

             FALSE device will not check appended Luhn check digit in
             challenge






Vassilev, et al.        Expires February 2, 2007               [Page 13]

Internet-Draft      Portable Symmetric Key Container         August 2006


   3.  Min (MANDATORY)

          Defines the minimum size of the challenge accepted by the
          device for CR mode.

          If the Format attribute is 'DECIMAL','HEXADECIMAL' or
          'ALPHANUMERIC' this value indicates the minimum number of
          digits/characters.

          If the Format attribute is 'BASE64' or 'BINARY', this value
          indicates the minimum number of bytes of the unencoded value.

          Value MUST be:



             Unsigned integer.

   4.  Max (MANDATORY)

          Defines the maximum size of the challenge accepted by the
          device for CR mode.

          If the Format attribute is 'DECIMAL','HEXADECIMAL' or
          'ALPHANUMERIC' this value indicates the maximum number of
          digits/characters.

          If the Format attribute is 'BASE64' or 'BINARY', this value
          indicates the maximum number of bytes of the unencoded value.

          Value MUST be:



             Unsigned integer.

5.1.9.2.  ResponseFormat (MANDATORY)

   The ResponseFormat attribute defines the characteristics of the
   result of a computation.  The Response attribute is defined by the
   following sub-attributes:

   1.  Format (MANDATORY)

          Defines the format of the response generated by the device and
          MUST be one of the values defined in Section 6.6





Vassilev, et al.        Expires February 2, 2007               [Page 14]

Internet-Draft      Portable Symmetric Key Container         August 2006


   2.  CheckDigit (OPTIONAL)

          Defines if the device needs to append a Luhn check digit to
          the response.  This is only valid if the Format attribute
          is'DECIMAL'.  Value MUST be:

             TRUE device will append a Luhn check digit to the response.

             FALSE device will not append a Luhn check digit to the
             response.

   3.  Length (MANDATORY)

          Defines the length of the response generated by the device.

          If the Format attribute is 'DECIMAL','HEXADECIMAL' or
          'ALPHANUMERIC' this value indicates the number of digits/
          characters.

          If the Format attribute is 'BASE64' or 'BINARY', this value
          indicates the number of bytes of the unencoded value.

          Value MUST be:



             Unsigned integer.

5.1.9.3.  AppProfileId (OPTIONAL)

   Defines the application profile id related to attributes present on a
   smart card that have influence when computing a response.  An example
   could be an EMV MasterCard CAP [CAP] application on a card that
   contains attributes or uses fixed data for a specific batch of cards
   such as:

      IAF Internet authentication flag

      CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA
      13, VISA14)

      AIP (Application Interchange Profile), 2 bytes

      TVR Terminal Verification Result, 5 bytes







Vassilev, et al.        Expires February 2, 2007               [Page 15]

Internet-Draft      Portable Symmetric Key Container         August 2006


      CVR The card verification result

      AmountOther

      TransactionDate

      TerminalCountryCode

      TransactionCurrencyCode

      AmountAuthorised

      IIPB

   These values are not contained within attributes in the container but
   are shared between the manufacturing and the validation service
   through this unique AppProfileId.


































Vassilev, et al.        Expires February 2, 2007               [Page 16]

Internet-Draft      Portable Symmetric Key Container         August 2006


6.  Secret container XML schema definitions

   The portable shared secret container is defined by the following
   entities:

   1.  SecretContainer entity

   2.  Device entity

   3.  Secret entity

   4.  User entity

   A SecretContainer MAY contain one or more Device entities.  A Device
   MAY contain one or more Secret entities and may be associated to one
   or more User entities.

   The figure below indicates a possible relationship diagram of a
   container.

   --------------------------------------------
   | SecretContainer                          |
   |                                          |
   |  -----------------    -----------------  |
   |  | Device 1       |   | Device n      |  |
   |  |                |   |               |  |
   |  |  -----------   |   |  -----------  |  |
   |  |  | Secret 1 |  |   | | Secret n |  |  |
   |  |  -----------   |   |  -----------  |  |
   |  |     |   |      |   | |             |  |
   |  |     |   |      |   | |             |  |
   |  |  -----------   |   |  -----------  |  |
   |  |  | Secret m |  |   | | Secret p |  |  |
   |  |  -----------   |   |  -----------  |  |
   |  -----------------    -----------------  |
   |      |                  |        |       |
   |      |                  |        |       |
   |  ---------         ---------  ---------  |
   |  | User 1 |        | User 1 | | User n | |
   |  ---------         ---------  ---------  |
   |                                          |
   --------------------------------------------

6.1.  XML Schema Types

   The following types are defined to represent the portable shared
   secret container entities and associated attributes.




Vassilev, et al.        Expires February 2, 2007               [Page 17]

Internet-Draft      Portable Symmetric Key Container         August 2006


6.1.1.  SecretType

   The SecretType represents the shared Secret entity in the
   SecretContainer.  The SecretType is defined as follows:


   <complexType name="SecretType">
     <sequence>
        <element name="Issuer" type="string"/>
        <element name="Usage" type="oath-pskc:UsageType"/>
        <element name="FriendlyName" type="string" minOccurs="0"/>
        <element name="Data" type="oath-pskc:DataType" minOccurs="0"/>
        <element name="AccessRules" minOccurs="0">
           <complexType>
             <simpleContent>
             <extension base="string">
               <attribute name="userPIN" type="boolean" use="optional"
               default="false"/>
             </extension>
            </simpleContent>
           </complexType>
        </element>
        <element name="Logo" type="oath-logo:LogoType" minOccurs="0"/>
        <element name="Expiry" type="string" minOccurs="0"/>
     </sequence>
     <attribute name="SecretId" type="string" use="required"/>
     <attribute name="SecretAlgorithm" type=
     "oath-pskc:SecretAlgorithmType" use="required"/>
     <attribute name="ext-SecretAlgorithm" type="string"/>
   </complexType>

   The components of the SecretType have the following meanings (see
   Section 5 for further information):

   o  <Usage> of type UsageType defines the usage of the Secret Key. The
      Usage attribute is described in Section 5.1.3.

   o  <Issuer> identifies the issuer of the Secret Key. The Issuer
      attribute is described in Section 5.1.5.

   o  <FriendlyName> is a user friendly name that is assigned to the
      Secret Key for easy reference.

   o  <Data> conveys the data attributes (eg the Secret Key) in name
      (string) value (base64 encoded) pairs.  The value can be
      encrypted, in this case a digest of the non-encrypted data is
      present.  The <Data> component is further described below.




Vassilev, et al.        Expires February 2, 2007               [Page 18]

Internet-Draft      Portable Symmetric Key Container         August 2006


   o  <AccessRules> Defines the rules for accessing the credential on
      the device e.g. a password must be provided by the user to view
      credential info or use the credential to generate an OTP response

   o  SecretId is a global identifier of the Secret Key. See
      Section 5.1.4.

   o  SecretAlgorithm defines the algorithm used with the Secret Key.
      The type values are defined in Section 6.5.  If 'OTHER' is
      specified an extension value MUST be set in the 'ext-
      SecretAlgorithm' attribute.

   o  ext-SecretAlgorithm is the extension point for SecretAlgorithms
      not already defined Section 6.5

   o  Logo of type LogoType associates display logos with this Secret
      Key

   o  Expiry defines the expiry date of the Secret Key in format DD/MM/
      YYYY

   The <Data> element is of type <DataType> and is defined as follows:


   <complexType name="DataType">
     <sequence>
       <element name="Value" type="base64Binary"/>
       <element name="ValueDigest" type="base64Binary" minOccurs="0"/>
       <attribute name="Name" type="string" use="required"/>
     </sequence>
   </complexType>

   The 'Name' attribute defines the name of the name-value pair, the
   follwoing list of attribute names have been reserved:

      SECRET: the shared secret key value in binary, base64 encoded

      COUNTER: the event counter for event based OTP algorithms. 8 bytes
      unsigned integer in big endian (i.e. network byte order) form
      base64 encoded

      TIME: the time for time based OTP algorithms. 8 bytes unsigned
      integer in big endian (i.e. network byte order) form base64
      encoded (Number of seconds since 1970)







Vassilev, et al.        Expires February 2, 2007               [Page 19]

Internet-Draft      Portable Symmetric Key Container         August 2006


      TIME_INTERVAL: the time interval value for time based OTP
      algorithms. 8 bytes unsigned integer in big endian (i.e. network
      byte order) form base64 encoded.

   The <Value> element in the DataType conveys the value of the name-
   value pair in base 64 encoding.  The value MAY be encrypted or in
   clear text as per the EncryptionMethod data element in the
   SecretContainer (see Section 6.1.6 for details about
   SecretContainerType).  When the value is encrypted, the digest value
   in 'ValueDigest' MUST be provided.  The digest MUST be calculated on
   the unencrypted value and MUST use one of the Digest algorithms
   specified in DigestMethodType element of the SecretContainer.  When
   the secret data is in clear text, the SecretContainer payload
   signature MAY be used to check the integrity of the secret octets.

6.1.2.  UsageType

   The UsageType defines the usage attribute of the shared secret
   entity.  The UsageType is defined as follows:
































Vassilev, et al.        Expires February 2, 2007               [Page 20]

Internet-Draft      Portable Symmetric Key Container         August 2006


   <complexType name="UsageType">
     <sequence>
       <element name="AlgorithmIdentifier"
       type="oath-pskc:AlgorithmIdentifierType" minOccurs="0"/>
       <element name="ResponseFormat">
         <complexType>
           <attribute name="format" type="oath-pskc:valueFormat"
           use="required"/>
           <attribute name="length" type="unsignedInt"
           use="required"/>
           <attribute name="checkDigits" type="boolean"
           use="optional"  default="false"/>
         </complexType>
       </element>
       <element name="ChallengeFormat" minOccurs="0">
         <complexType>
           <attribute name="format" type="oath-pskc:valueFormat"
           use="required"/>
           <attribute name="min" type="unsignedInt" use="required"/>
           <attribute name="max" type="unsignedInt" use="required"/>
           <attribute name="checkDigits" type="boolean" use="optional"
           default="false"/>
         </complexType>
       </element>
       <element name="AppProfileId" type="string" minOccurs="0"/>
     </sequence>
     <attribute name="otp" type="boolean" use="optional"
     default="false"/>
     <attribute name="cr" type="boolean" use="optional"
     default="false"/>
     <attribute name="sign" type="boolean" use="optional"
     default="false"/>
     <attribute name="encrypt" type="boolean" use="optional"
     default="false"/>
     <attribute name="unlock" type="boolean" use="optional"
     default="false"/>
   </complexType>

   The UsageType components have the following meanings:

   o  <AlgorithmIdentifier> the AlgorithmIdentifier as defined in
      [OCRA]].

   o  <ChallengeFormat> hold the challenge attributes in CR based
      algorithm computations.

   o  <ResponseFormat> holds the algorithm response attributes.




Vassilev, et al.        Expires February 2, 2007               [Page 21]

Internet-Draft      Portable Symmetric Key Container         August 2006


   o  <AccessRules> holds a set of access rules and policies for the
      shared secret once provisioned on the Device.  Currently only the
      userPIN attribute is defined.  The userPIN indicates weather the
      user MUST provide a PIN to unlock the secret.

   o  <AppProfileId> Is the unique shared identifier for out of band
      shared common parameters.

6.1.3.  DeviceType

   The DeviceType type represents the Device entity in the Container.  A
   shared secret MUST be bound to one Device only.  A Device MAY be
   bound to a user and MAY contain more than one shared secrets.

   The DeviceType is defined as follows:


   <complexType name="DeviceType">
     <sequence>
       <element name="DeviceId" type="oath-pskc:DeviceIdType"
       minOccurs="0"/>
       <element name="Secret" type="oath-pskc:SecretType"
       maxOccurs="unbounded"/>
       <element name="User" type="oath-pskc:UserType" minOccurs="0"/>
     </sequence>
   </complexType>

   The components of the DeviceType have the following meanings:

   o  <DeviceId>, a unique identifier for the device, defined by the
      DeviceId type.

   o  <Secret>, represents the shared secret entity defined by the
      SecretType.

   o  <User>, optionally identifies the owner or the user of the Device,
      as defined by the UserType .

6.1.4.  DeviceIdType

   The DeviceId type represents the identifying criteria to uniquely
   identify the device that contains the associated shared secrets.
   Since OATH devices can come in different form factors such as
   hardware tokens, smartcards, soft tokens in a mobile phone or PC etc
   this type allows different criteria to be used.  Combined though the
   criteria MUST identify uniquely the device.

   The DeviceIdType is defined as follows:



Vassilev, et al.        Expires February 2, 2007               [Page 22]

Internet-Draft      Portable Symmetric Key Container         August 2006


   <complexType name="DeviceIdType">
    <sequence>
     <element name="Manufacturer" type="string"/>
     <element name="SerialNo" type="string"/>
     <element name="Model" type="string" minOccurs="0"/>
     <element name="IssueNo" type="string" minOccurs="0"/>
     <element name="Expiry" type="string" minOccurs="0"/>
    </sequence>
   </complexType>

   The components of the DeviceId type have the following meanings:

   o  <Manufacturer>, the manufacturer of the device.

   o  <Model>, the model of the device (e.g one-button-OATH-token-V1)

   o  <SerialNo>, the serial number of the device or the PAN (primary
      account number) in case of EMV (Europay-MasterCard-Visa) smart
      cards.

   o  <IssueNo>, the issue number in case of smart cards with the same
      PAN, equivalent to a PSN (PAN Sequence Number).

   o  <Expiry>, the expiry date of a device (such as the one on an EMV
      card,used when issue numbers are not printed on cards).  In format
      DD/MM/YYYY

6.1.5.  UserType Type

   The UserType represents the identifying criteria to uniquely identify
   the user who is bound to this device.

   The UserType is defined as follows:


   <complexType name="UserType">
     <sequence>
       <sequence>
         <element name="UserId" type="string" minOccurs="0"/>
         <element name="FirstName" type="string" minOccurs="0"/>
         <element name="LastName" minOccurs="0"/>
       </sequence>
       <element name="Org" type="string" minOccurs="0"/>
     </sequence>
   </complexType>

   The components of the UserType type have the following meanings:




Vassilev, et al.        Expires February 2, 2007               [Page 23]

Internet-Draft      Portable Symmetric Key Container         August 2006


   o  <FirstName>, user first name.

   o  <LastName>, user last name.

   o  <UserId>, user id (UID) or user name.

   o  <Org>, user organization name.

6.1.6.  SecretContainerType

   The SecretContainerType represents the shared secret container
   entity.  A Container MAY contain more than one Device entity; each
   Device entity MAY contain more than one Shared Secret entity.

   The SecretContainerType is defined as follows:


   <complexType name="SecretContainerType">
     <sequence>
       <element name="EncryptionMethod">
         <complexType>
           <complexContent>
             <extension base="oath-pskc:EncryptionMethodType"/>
           </complexContent>
         </complexType>
       </element>
       <element name="DigestMethod">
         <complexType>
           <complexContent>
             <extension base="oath-pskc:DigestMethodType"/>
           </complexContent>
         </complexType>
       </element>
       <element name="Device" type="oath-pskc:DeviceType"
       maxOccurs="unbounded"/>
       <element name="Signature" type="ds:SignatureType"
       minOccurs="0"/>
     </sequence>
     <attribute name="version" type="oath-pskc:VersionType"
     use="required"/>
   </complexType>

   The components of the SecretContainer have the following meanings:

   o  version, the version number for the portable shared secret
      container format (the XML schema defined in this document).





Vassilev, et al.        Expires February 2, 2007               [Page 24]

Internet-Draft      Portable Symmetric Key Container         August 2006


   o  <EncryptionMethod>, the encryption method used to protect the
      Secret data attributes

   o  <DigestMethod>, the digest method used to sign the unencrypted the
      Secret Key data attributes

   o  <Device>, the host Device for one or more Shared Secrets.

   o  <Signature>, contains the signature value of the Container.  When
      the signature is applied to the entire container, it MUST use XML
      Signature methods as defined in [XMLSIG].  The signature is
      enveloped.

6.1.7.  EncryptionMethodType

   The EncryptionMethodType defines the algorithm and parameters used to
   encrypt the Secret Key data attributes in the Container.  The
   encryption is applied on each individual Secret Key data in the
   Container.  The encryption method MUST be the same for all Secret Key
   data in the container.

   The EncryptionMethodType is defined as follows:


<complexType name="EncryptionMethodType">
  <sequence>
    <element name="EncKeyLabel" minOccurs="0"/>
    <choice>
        <sequence>
          <element name="KeyInfo" type="ds:KeyInfoType" minOccurs="0"/>
          <element name="OAEPParams" type="base64Binary" minOccurs="0"/>
          <element name="HashAlgorithm"
          type="oath-pskc:HashAlgorithmType" minOccurs="0"/>
        </sequence>
      <sequence>
        <element name="PBESalt" type="base64Binary" minOccurs="0"/>
        <element name="PBEIterationCount" type="int" minOccurs="0"/>
        <element name="IV" type="base64Binary" minOccurs="0"/>
      </sequence>
    </choice>
  </sequence>
  <attribute name="algorithm" type="oath-pskc:EncryptionAlgorithmType"
  use="required"/>
  <attribute name="ext-algorithm" type="string"/>
</complexType>

   The components of the EncryptionMethodType have the following
   meanings:



Vassilev, et al.        Expires February 2, 2007               [Page 25]

Internet-Draft      Portable Symmetric Key Container         August 2006


   o  algorithm: identifies the encryption algorithm used to protect the
      Secret Key data.  When 'NONE' is specified, implementations MUST
      guarantee the privacy of the Secret Key Data through other
      mechanisms e.g. through transport level security.  If 'OTHER' is
      specified an extension value MUST be set in the 'ext-algorithm'
      attribute.  Please see EncryptionAlgorithmType for more
      information on supported algorithms

   o  <PBESalt>: conveys the Salt when [PKCS5] password-based encryption
      is applied.

   o  <PBEIterationCount>: conveys the iteration count value in [PKCS5]
      password-based encryption if it is different from the default
      value.

   o  <IV>: conveys the initialization vector for CBC based encryption
      algorithms.  It is recommended for security reasons to transmit
      this value out of band and treat it the same manner as the key
      value.

   o  <EncKeyLabel>: identifies a unique label for a pre-shared
      encryption key.

   o  <KeyInfo>: conveys the information of the key if an RSA algorithm
      has been used.

   o  <OAEPParams>: conveys the OAEP parameters if an RSA algorithm has
      been used.

   o  <HashAlgorithm>: conveys the digest algorithm if an RSA algorithm
      has been used.

6.1.8.  DigestMethodType

   The DigestMethodType defines the algorithm and parameters used to
   create the digest on the unencrypted Secret Key data in the
   Container.  The digest is applied on each individual Secret Key data
   in the Container before encryption.  The digest method MUST be the
   same for all Secret Key data in the container.  Unless a different
   digest key is specified it is assumed that keyed digest algorithms
   will use the same key as for encryption

   The DigestMethodType is defined as follows:








Vassilev, et al.        Expires February 2, 2007               [Page 26]

Internet-Draft      Portable Symmetric Key Container         August 2006


   <complexType name="DigestMethodType">
     <sequence>
       <element name="DigestKeyLabel" minOccurs="0"/>
     </sequence>
     <attribute name="algorithm" type="oath-pskc:DigestAlgorithmType"
     use="required"/>
   </complexType>

   The components of the DigestMethodType have the following meanings:

   o  algorithm, identifies the digest algorithm used to protect the
      Secret Key data.  Please see DigestAlgorithmType for more
      information on supported algorithms

   o  <DigestKeyLabel>: identifies a unique label for a pre-shared
      digest key.

6.1.9.  OtpAlgorithmIdentifierType

   The AlgorithmIdentiferType defines the Algorithm identifier (AI)
   specified in [OCRA].

   The AlgorithmIdentifierType is defines as follows:




























Vassilev, et al.        Expires February 2, 2007               [Page 27]

Internet-Draft      Portable Symmetric Key Container         August 2006


   <complexType name="AlgorithmIdentifierType">
       <sequence>
         <element name="Algorithm">
           <simpleType>
             <restriction base="string">
               <enumeration value="OCRA-HOTP"/>
             </restriction>
           </simpleType>
         </element>
         <element name="CryptoFunction"
         type="oath-pskc:DigestAlgorithmType"/>
         <element name="Truncation">
           <simpleType>
             <restriction base="decimal">
               <minInclusive value="4"/>
               <maxInclusive value="10"/>
             </restriction>
           </simpleType>
         </element>
         <element name="Pin" type="boolean"/>
         <element name="Counter" type="boolean"/>
         <element name="Time" type="boolean"/>
         <element name="Session" type="boolean"/>
         <element name="Challenge" type="boolean"/>
       </sequence>
     </complexType>

   See [OCRA] for a full description of the components of the
   AlgorithmIdentifierType.

6.2.  EncryptionAlgorithmType

   The EncryptionAlgorithmType defines the allowed algorithms for
   encrypting the Secret Key data in the Container.

   The EncryptionAlgorithmType is defined as follows:















Vassilev, et al.        Expires February 2, 2007               [Page 28]

Internet-Draft      Portable Symmetric Key Container         August 2006


   <simpleType name="EncryptionAlgorithmType">
     <restriction base="string">
       <enumeration value="NONE"/>
       <enumeration value="PBE-3DES112-CBC"/>
       <enumeration value="PBE-3DES168-CBC"/>
       <enumeration value="PBE-AES128-CBC"/>
       <enumeration value="PBE-AES256-CBC"/>
       <enumeration value="PBE-AES192-CBC"/>
       <enumeration value="3DES112-CBC"/>
       <enumeration value="3DES168-CBC"/>
       <enumeration value="AES128-CBC"/>
       <enumeration value="AES192-CBC"/>
       <enumeration value="AES256-CBC"/>
       <enumeration value="RSA-1_5"/>
       <enumeration value="RSA-OAEP-MGF1P"/>
       <enumeration value="OTHER"/>
     </restriction>
   </simpleType>

      NONE when no encryption is applied on the shared secret

      PBE-3DES112-CBC when password-based encryption is applied using a
      112-bit 3DES key in CBC mode

      PBE-3DES168-CBC when password-based encryption is applied using a
      168-bit 3DES key in CBC mode

      PBE-AES128-CBC when password-based encryption is applied using a
      128-bit AES key in CBC mode

      PBE-AES192-CBC when password-based encryption is applied using a
      192-bit AES key in CBC mode is applied.

      PBE-AES256-CBC password-based encryption is applied using a 256-
      bit AES key in CBC mode is applied.

      3DES112-CBC encryption using a pre-shared 112-bit 3DES key in CBC
      mode is applied.

      3DES168-CBC encryption using a pre-shared 168-bit 3DES key in CBC
      mode is applied.

      AES128-CBC encryption using a pre-shared 128-bit AES key in CBC
      mode is applied.







Vassilev, et al.        Expires February 2, 2007               [Page 29]

Internet-Draft      Portable Symmetric Key Container         August 2006


      AES192-CBC encryption using a pre-shared 192-bit AES key in CBC
      mode is applied.

      AES256-CBC encryption using a pre-shared 256-bit AES key in CBC
      mode is applied.

      RSA-1_5 The RSAES-PKCS1-v1_5 algorithm, specified in [PKCS1],
      takes no explicit parameters.

      RSA-OAEP-MGF1P The same algorithm as defined in section 5.4.2 RSA-
      OAEP in [XMLENC] It is the RSAES-OAEP-ENCRYPT algorithm, as
      specified in [PKCS1], it takes three parameters.  The two user
      specified parameters are a MANDATORY message digest function and
      an OPTIONAL encoding octet string OAEPparams.  The message digest
      function is indicated by the Algorithm attribute of a child ds:
      DigestMethod element and the mask generation function, the third
      parameter, is always MGF1 with SHA1 (mgf1SHA1Identifier).

      OTHER extension point for not already defined algorithms in this
      list.

6.3.  HashAlgorithmType

   The HashAlgorithmType defines the allowed algorithms for generating a
   digest in the RSA algorithms.

   The HashAlgorithmType is defined as follows:


     <simpleType name="HashAlgorithmType">
       <restriction base="string">
         <enumeration value="SHA1"/>
         <enumeration value="SHA256"/>
         <enumeration value="SHA512"/>
       </restriction>
     </simpleType>

      SHA1 when the digest was performed using the SHA1 algorithm

      SHA192 when the digest was performed using the SHA192 algorithm

      SHA256 when the digest was performed using the SHA256 algorithm

6.4.  DigestAlgorithmType

   The DigestAlgorithmType defines the allowed algorithms for generating
   a digest on the unencrypted Secret Key data in the Container.




Vassilev, et al.        Expires February 2, 2007               [Page 30]

Internet-Draft      Portable Symmetric Key Container         August 2006


   The DigestAlgorithmType is defined as follows:


   <simpleType name="DigestAlgorithmType">
     <restriction base="string">
       <enumeration value="HMAC-SHA1"/>
       <enumeration value="HMAC-SHA256"/>
       <enumeration value="HMAC-SHA512"/>
       <enumeration value="OTHER"/>
     </restriction>
   </simpleType>

      HMAC-SHA1 when the digest was performed using the HMAC-SHA1
      algorithm

      HMAC-SHA192 when the digest was performed using the HMAC-SHA192
      algorithm

      HMAC-SHA256 when the digest was performed using the HMAC-SHA256
      algorithm

      OTHER extension point for not already defined algorithms in this
      list.

6.5.  SecretAlgorithmType

   The SecretAlgorithmType defines the algorithms in which the Secret
   Key data is used.

   The SecretAlgorithmType is defined as follows:


   <simpleType name="SecretAlgorithmType">
     <restriction base="string">
       <enumeration value="DES"/>
       <enumeration value="3DES112"/>
       <enumeration value="3DES168"/>
       <enumeration value="AES128"/>
       <enumeration value="AES192"/>
       <enumeration value="AES256"/>
       <enumeration value="HOTP"/>
       <enumeration value="MKEYLABEL"/>
       <enumeration value="OTHER"/>
     </restriction>
   </simpleType>






Vassilev, et al.        Expires February 2, 2007               [Page 31]

Internet-Draft      Portable Symmetric Key Container         August 2006


      HOTP, as defined in [HOTP]

      MKEYLABEL, master key abel or name when an embedded device key is
      used to derive the Shared Secret

      DES, a standard DES key

      3DES112, a 112-bit 3DES key (a.k.a. two-key 3DES)

      3DES168, a 168-bit parity-checked 3DES key

      AES128, a 128-bit AES key

      AES192, a 192-bit AES key

      AES256, a 256-bit AES key

      OTHER extension point for not already defined algorithms in this
      list.

6.6.  valueFormat

   The valueFormat defines allowed formats for challenges or responses
   in the OTP algorithms.

   The valueFormat is defined as follows:


   <simpleType name="valueFormat">
     <restriction base="string">
       <enumeration value="DECIMAL"/>
       <enumeration value="HEXADECIMAL"/>
       <enumeration value="ALPHANUMERIC"/>
       <enumeration value="BASE64"/>
       <enumeration value="BINARY"/>
     </restriction>
   </simpleType>

      DECIMAL Only numerical digits

      HEXADECIMAL Hexadecimal response

      ALPHANUMERIC All letters and numbers (case sensitive)

      BASE64 Base 64 encoded






Vassilev, et al.        Expires February 2, 2007               [Page 32]

Internet-Draft      Portable Symmetric Key Container         August 2006


      BINARY Binary data, this is mainly used in case of connected
      devices

6.7.  Data elements

6.7.1.  SecretContainer

   The SecretContainer data element is defined as:


  <element name="SecretContainer" type="oath-pskc:SecretContainerType"/>

   The SecretContainer data element is of type SecretContainerType
   defined in Section 6.1.6.

   The EncryptionMethod data element in the SecretContainer defines the
   encryption algorithm used to protect the Shared Secret data.  In a
   multi-secret SecretContainer, the same encryption method and the same
   encryption key MUST be used for all secret data elements.

   The SecretContainer data element MAY contain multiple Device data
   elements, allowing for bulk provisioning of shared secrets.

   The Signature data element is of type <ds:Signature> as defined in
   [XMLSIG] and MAY be omitted in the SecretContainer data element when
   application layer provisioning or transport layer provisioning
   protocols provide the integrity and authenticity of the payload
   between the sender and the recipient of the container.  When
   required, this specification recommends using a symmetric key based
   signature with the same key used in the encryption of the secret
   data.  The signature is enveloped.




















Vassilev, et al.        Expires February 2, 2007               [Page 33]

Internet-Draft      Portable Symmetric Key Container         August 2006


7.  Formal Syntax

   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 implentations of this standard must comply with the schema below.


 <?xml version="1.0" encoding="UTF-8"?>
 <!-- edited with XMLSpy v2006 rel. 3 sp1 (http://www.altova.com)
 by Philip Hoyer (ActivIdentity) -->
 <schema xmlns="http://www.w3.org/2001/XMLSchema"
 xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/08/PSKC"
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
 xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
 targetNamespace="http://www.openauthentication.org/OATH/2006/10/PSKC"
 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/08/Logo"
 schemaLocation="oath_logotype_v1.0.xsd"/>
 <complexType name="SecretContainerType">
 <sequence>
 <element name="EncryptionMethod">
 <complexType>
 <complexContent>
 <extension base="oath-pskc:EncryptionMethodType"/>
 </complexContent>
 </complexType>
 </element>
 <element name="DigestMethod">
 <complexType>
 <complexContent>
 <extension base="oath-pskc:DigestMethodType"/>
 </complexContent>
 </complexType>
 </element>
 <element name="Device" type="oath-pskc:DeviceType"
 maxOccurs="unbounded"/>
 <element name="Signature" type="ds:SignatureType"
 minOccurs="0"/>
 </sequence>
 <attribute name="version" type="oath-pskc:VersionType"
 use="required"/>
 </complexType>



Vassilev, et al.        Expires February 2, 2007               [Page 34]

Internet-Draft      Portable Symmetric Key Container         August 2006


   <complexType name="AlgorithmIdentifierType">
     <sequence>
       <element name="Algorithm">
         <simpleType>
           <restriction base="string">
             <enumeration value="OCRA-HOTP"/>
           </restriction>
         </simpleType>
       </element>
       <element name="CryptoFunction"
       type="oath-pskc:DigestAlgorithmType"/>
       <element name="Truncation">
         <simpleType>
           <restriction base="decimal">
             <minInclusive value="4"/>
             <maxInclusive value="10"/>
           </restriction>
         </simpleType>
       </element>
       <element name="Pin"
       type="boolean"/>
       <element name="Counter"
       type="boolean"/>
       <element name="Time"
       type="boolean"/>
       <element name="Session"
       type="boolean"/>
       <element name="Challenge"
       type="boolean"/>
     </sequence>
   </complexType>
 <complexType name="SecretType">
 <sequence>
 <element name="Issuer" type="string"/>
 <element name="Usage" type="oath-pskc:UsageType"/>
 <element name="FriendlyName" type="string"
 minOccurs="0"/>
 <element name="Data" type="oath-pskc:DataType"
 minOccurs="0"/>
 <element name="AccessRules" minOccurs="0">
 <complexType>
 <simpleContent>
 <extension base="string">
 <attribute name="userPIN" type="boolean"
 use="optional" default="false"/>
 </extension>
 </simpleContent>
 </complexType>



Vassilev, et al.        Expires February 2, 2007               [Page 35]

Internet-Draft      Portable Symmetric Key Container         August 2006


 </element>
 <element name="Logo" type="oath-logo:LogoType"
 minOccurs="0"/>
 <element name="Expiry" type="string" minOccurs="0"/>
 </sequence>
 <attribute name="SecretId" type="string" use="required"/>
 <attribute name="SecretAlgorithm"
 type="oath-pskc:SecretAlgorithmType" use="required"/>
 <attribute name="ext-SecretAlgorithm" type="string"/>
 </complexType>
 <complexType name="DeviceIdType">
 <sequence>
 <element name="Manufacturer" type="string"/>
 <element name="SerialNo" type="string"/>
 <element name="Model" type="string" minOccurs="0"/>
 <element name="IssueNo" type="string" minOccurs="0"/>
 <element name="Expiry" type="string" minOccurs="0"/>
 </sequence>
 </complexType>
 <complexType name="DeviceType">
 <sequence>
 <element name="DeviceId" type="oath-pskc:DeviceIdType"
 minOccurs="0"/>
 <element name="Secret" type="oath-pskc:SecretType"
 maxOccurs="unbounded"/>
 <element name="User" type="oath-pskc:UserType"
 minOccurs="0"/>
 </sequence>
 </complexType>
 <complexType name="UserType">
 <sequence>
 <sequence>
 <element name="UserId" type="string" minOccurs="0"/>
 <element name="FirstName" type="string" minOccurs="0"/>
 <element name="LastName" minOccurs="0"/>
 </sequence>
 <element name="Org" type="string" minOccurs="0"/>
 </sequence>
 </complexType>
 <complexType name="UsageType">
 <sequence>
 <element name="AlgorithmIdentifier"
 type="oath-pskc:AlgorithmIdentifierType" minOccurs="0"/>
 <element name="ResponseFormat">
 <complexType>
 <attribute name="format" type="oath-pskc:valueFormat"
 use="required"/>
 <attribute name="length" type="unsignedInt" use="required"/>



Vassilev, et al.        Expires February 2, 2007               [Page 36]

Internet-Draft      Portable Symmetric Key Container         August 2006


 <attribute name="checkDigits" type="boolean" use="optional"
 default="false"/>
 </complexType>
 </element>
 <element name="ChallengeFormat" minOccurs="0">
 <complexType>
 <attribute name="format" type="oath-pskc:valueFormat"
 use="required"/>
 <attribute name="min" type="unsignedInt" use="required"/>
 <attribute name="max" type="unsignedInt" use="required"/>
 <attribute name="checkDigits" type="boolean" use="optional"
 default="false"/>
 </complexType>
 </element>
 <element name="Time" type="unsignedLong" minOccurs="0"/>
 <element name="AppProfileId" type="string" minOccurs="0"/>
 </sequence>
 <attribute name="otp" type="boolean" use="optional"
 default="false"/>
 <attribute name="cr" type="boolean" use="optional"
 default="false"/>
 <attribute name="sign" type="boolean" use="optional"
 default="false"/>
 <attribute name="encrypt" type="boolean" use="optional"
 default="false"/>
 <attribute name="unlock" type="boolean" use="optional"
 default="false"/>
 </complexType>
 <complexType name="AttributeType">
 <simpleContent>
 <extension base="string">
 <attribute name="name" type="string" use="required"/>
 </extension>
 </simpleContent>
 </complexType>
 <complexType name="EncryptionMethodType">
 <sequence>
 <element name="EncKeyLabel" minOccurs="0"/>
 <choice>
         <sequence>
           <element name="KeyInfo"
           type="ds:KeyInfoType" minOccurs="0"/>
           <element name="OAEPParams"
           type="base64Binary" minOccurs="0"/>
           <element name="HashAlgorithm"
           type="oath-pskc:HashAlgorithmType" minOccurs="0"/>
         </sequence>
 <sequence>



Vassilev, et al.        Expires February 2, 2007               [Page 37]

Internet-Draft      Portable Symmetric Key Container         August 2006


 <element name="PBESalt" type="base64Binary"
 minOccurs="0"/>
 <element name="PBEIterationCount" type="int"
 minOccurs="0"/>
 <element name="IV" type="base64Binary" minOccurs="0"/>
 </sequence>
 </choice>
 </sequence>
 <attribute name="algorithm"
 type="oath-pskc:EncryptionAlgorithmType" use="required"/>
 </complexType>
 <complexType name="DigestMethodType">
 <sequence>
 <element name="DigestKeyLabel" minOccurs="0"/>
 </sequence>
 <attribute name="algorithm"
 type="oath-pskc:DigestAlgorithmType" use="required"/>
 <attribute name="ext-algorithm" type="string"/>
 </complexType>
 <simpleType name="EncryptionAlgorithmType">
 <restriction base="string">
 <enumeration value="NONE"/>
 <enumeration value="PBE-3DES112-CBC"/>
 <enumeration value="PBE-3DES168-CBC"/>
 <enumeration value="PBE-AES128-CBC"/>
 <enumeration value="PBE-AES256-CBC"/>
 <enumeration value="PBE-AES192-CBC"/>
 <enumeration value="3DES112-CBC"/>
 <enumeration value="3DES168-CBC"/>
 <enumeration value="AES128-CBC"/>
 <enumeration value="AES192-CBC"/>
 <enumeration value="AES256-CBC"/>
 <enumeration value="RSA-1_5"/>
 <enumeration value="RSA-OAEP-MGF1P"/>
 <enumeration value="OTHER"/>
 </restriction>
 </simpleType>
 <simpleType name="DigestAlgorithmType">
 <restriction base="string">
 <enumeration value="HMAC-SHA1"/>
 <enumeration value="HMAC-SHA256"/>
 <enumeration value="HMAC-SHA512"/>
 <enumeration value="OTHER"/>
 </restriction>
 </simpleType>
   <simpleType name="HashAlgorithmType">
     <restriction base="string">
       <enumeration value="SHA1"/>



Vassilev, et al.        Expires February 2, 2007               [Page 38]

Internet-Draft      Portable Symmetric Key Container         August 2006


       <enumeration value="SHA256"/>
       <enumeration value="SHA512"/>
     </restriction>
   </simpleType>
 <simpleType name="SecretAlgorithmType">
 <restriction base="string">
 <enumeration value="DES"/>
 <enumeration value="3DES112"/>
 <enumeration value="3DES168"/>
 <enumeration value="AES128"/>
 <enumeration value="AES192"/>
 <enumeration value="AES256"/>
 <enumeration value="HOTP"/>
 <enumeration value="MKEYLABEL"/>
 <enumeration value="OTHER"/>
 </restriction>
 </simpleType>
 <simpleType name="valueFormat">
 <restriction base="string">
 <enumeration value="DECIMAL"/>
 <enumeration value="HEXADECIMAL"/>
 <enumeration value="ALPHANUMERIC"/>
 <enumeration value="BASE64"/>
 <enumeration value="BINARY"/>
 </restriction>
 </simpleType>
 <simpleType name="VersionType" final="restriction">
 <restriction base="string">
 <pattern value="\d{1,9}\.\d{0,9}"/>
 </restriction>
 </simpleType>
 <element name="SecretContainer"
 type="oath-pskc:SecretContainerType"/>
 <complexType name="DataType">
 <sequence>
 <element name="Value" type="base64Binary"/>
 <element name="ValueDigest"
 type="base64Binary" minOccurs="0"/>
 </sequence>
 </complexType>
 </schema>










Vassilev, et al.        Expires February 2, 2007               [Page 39]

Internet-Draft      Portable Symmetric Key Container         August 2006


8.  Security Considerations

   The portable shared secret container carries sensitive information
   (e.g., cryptographic keys) and may be transported across the
   boundaries of one secure perimeter to another.  For example, a
   container residing within the secure perimeter of a back-end
   provisioning server in a secure room may be transported across the
   internet to an end-user device attached to a personal computer.  This
   means that special care must be taken to ensure the confidentiality,
   integrity, and authenticity of the information contained within.

8.1.  Payload confidentiality

   By design, the container allows two main approaches to guaranteeing
   the confidentiality of the information it contains while transported.

   First, the container shared secret key data payload may be encrypted.

   In this case no transport layer security is required.  However,
   standard security best practices apply when selecting the strength of
   the cryptographic algorithm for payload encryption.  Symmetric
   cryptographic cipher should be used - the longer the cryptographic
   key, the stronger the protection.  At the time of this writing both
   3DES and AES are recommended algorithms but 3DES may be dropped in
   the relatively near future.  Applications concerned with algorithm
   longevity are advised to use AES.  In cases where the exchange of
   encryption keys between the sender and the receiver is not possible,
   asymmetric encryption of the secret key payload may be employed.
   Similarly to symmetric key cryptography, the stronger the asymmetric
   key, the more secure the protection is.

   If the payload is encrypted with a method that uses one of the
   password-based encryption methods provided above, the payload may be
   subjected to password dictionary attacks to break the encryption
   password and recover the information.  Standard security best
   practices for selection of strong encryption passwords apply
   [Schneier].

   Practical implementations should use PBESalt and PBEIterationCount
   when PBE encryption is used.  Different PBESalt value per credential
   record should be used for best protection.

   The second approach to protecting the confidentiality of the payload
   is based on using transport layer security.  The secure channel
   established between the source secure perimeter (the provisioning
   server from the example above) and the target perimeter (the device
   attached to the end-user computer) utilizes encryption to transport
   the messages that travel across.  No payload encryption is required



Vassilev, et al.        Expires February 2, 2007               [Page 40]

Internet-Draft      Portable Symmetric Key Container         August 2006


   in this mode.  Secure channels that encrypt and digest each message
   provide an extra measure of security, especially when the signature
   of the payload does not encompass the entire payload.

   Because of the fact that the plain text payload is protected only by
   the transport layer security, practical implementation must ensure
   protection against man-in-the-middle attacks [Schneier].  Validating
   the secure channel end-points is critically important for eliminating
   intruders that may compromise the confidentiality of the payload.

8.2.  Payload integrity

   The portable symmetric key container provides a mean to guarantee the
   integrity of the information it contains through digital signatures.
   For best security practices, the digital signature of the container
   should encompass the entire payload.  This provides assurances for
   the integrity of all attributes.  It also allows verification of the
   integrity of a given payload even after the container is delivered
   through the communication channel to the target perimeter and channel
   message integrity check is no longer possible.

8.3.  Payload authenticity

   The digital signature of the payload is the primary way of showing
   its authenticity.  The recipient of the container may use the public
   key associated with the signature to assert the authenticity of the
   sender by tracing it back to a preloaded public key or certificate.
   Note that the digital signature of the payload can be checked even
   after the container has been delivered through the secure channel of
   communication.

   A weaker payload authenticity guarantee may be provided by the
   transport layer if it is configured to digest each message it
   transports.  However, no authenticity verification is possible once
   the container is delivered at the recipient end.  This approach may
   be useful in cases where the digital signature of the container does
   not encompass the entire payload.














Vassilev, et al.        Expires February 2, 2007               [Page 41]

Internet-Draft      Portable Symmetric Key Container         August 2006


9.  Acknowledgements

   The authors of this draft would like to thank the following people
   for their contributions and support to make this a better
   specification: Shuh Chang, Siddhart Bajaj, Stu Veath and Kevin Lewis.














































Vassilev, et al.        Expires February 2, 2007               [Page 42]

Internet-Draft      Portable Symmetric Key Container         August 2006


10.  Appendix A - Example Symmetric Key Containers

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

10.1.  Symmetric Key Container with a single Non-Encrypted HOTP Secret
       Key


 <?xml version="1.0" encoding="UTF-8"?>
 <SecretContainer
 xmlns="http://www.openauthentication.org/OATH/2006/08/PSKC"
 xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.openauthentication.org/OATH/2006/10/PSKC
 .\oath_pskc_schema_v1.2.xsd" version="1.2">
   <EncryptionMethod algorithm="NONE"/>
   <DigestMethod algorithm="HMAC-SHA1"></DigestMethod>
   <Device>
     <DeviceId>
       <Manufacturer>Token Manufacturer</Manufacturer>
       <SerialNo>98765432187</SerialNo>
       <Expiry>01/01/2008</Expiry>
     </DeviceId>
     <Secret SecretAlgorithm="HOTP"  SecretId="98765432187">
       <Issuer>Credential Issuer</Issuer>
       <Usage>
        <ResponseFormat format="DECIMAL" length="6"/>
       </Usage>
       <FriendlyName>MyFirstToken</FriendlyName>
       <Data Name="SECRET">
         <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
         <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
       </Data>
       <Data Name="COUNTER">
         <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
         <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
       </Data>
     </Secret>
   </Device>
 </SecretContainer>








Vassilev, et al.        Expires February 2, 2007               [Page 43]

Internet-Draft      Portable Symmetric Key Container         August 2006


10.2.  Symmetric Key Container with a single Password-based Encrypted
       HOTP Secret Key


 <?xml version="1.0" encoding="UTF-8"?>
 <SecretContainer
 xmlns="http://www.openauthentication.org/OATH/2006/08/PSKC"
 xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.openauthentication.org/OATH/2006/10/PSKC
 .\oath_pskc_schema_v1.2" version="1.2">
   <EncryptionMethod algorithm="PBE-3DES112-CBC">
     <PBESalt>y6TzckeLRQw=</PBESalt>
     <PBEIterationCount>999</PBEIterationCount>
   </EncryptionMethod>
   <DigestMethod algorithm="HMAC-SHA1"></DigestMethod>
   <Device>
     <DeviceId>
       <Manufacturer>Token Manufacturer</Manufacturer>
       <SerialNo>98765432187</SerialNo>
       <Expiry>01/01/2008</Expiry>
     </DeviceId>
   <Secret SecretAlgorithm="HOTP"  SecretId="77654321870">
     <Issuer>Credential Issuer</Issuer>
     <Usage>
       <ResponseFormat format="DECIMAL" length="6"/>
     </Usage>
     <FriendlyName>MySecondToken</FriendlyName>
       <Data Name="SECRET">
 <Value>7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==</Value>
       <ValueDigest>WldjTHZwRm9YTkhBRytseDMrUnc=</ValueDigest>
       </Data>
       <Data Name="COUNTER">
 <Value>7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==</Value>
       <ValueDigest>WldjTHZwRm9YTkhBRytseDMrUnc=</ValueDigest>
       </Data>
     </Secret>
   </Device>
 </SecretContainer>











Vassilev, et al.        Expires February 2, 2007               [Page 44]

Internet-Draft      Portable Symmetric Key Container         August 2006


11.  Normative References

   [CAP]      MasterCard International, "Chip Authentication Program
              Functional Architecture", September 2004.

   [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.

   [OATHRefArch]
              OATH, "Reference Architecture",
              URL: http://www.openauthentication.org, Version 1.0, 2005.

   [OCRA]     MRaihi, D., "OCRA: OATH Challenge Response Algorithm",
              Internet Draft Informational, URL: http://www.ietf.org/
              internet-drafts/
              draft-mraihi-mutual-oath-hotp-variants-01.txt,
              December 2005.

   [PKCS1]    Kaliski, B., "RFC 2437: PKCS #1: RSA Cryptography
              Specifications Version 2.0.",
              URL: http://www.ietf.org/rfc/rfc2437.txt, Version: 2.0,
              October 1998.

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

   [PKCS5]    RSA Laboratories, "PKCS #5: Password-Based Cryptography
              Standard", Version 2.0,
              URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/,
              March 1999.

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

   [Schneier]
              Schneier, B., "Secrets and Lies: Digitial Security in a
              Networked World",  Wiley Computer Publishing, ISBN 0-8493-
              8253-7, 2000.

   [XMLENC]   Eastlake, D., "XML Encryption Syntax and Processing.",
              URL: http://www.w3.org/TR/xmlenc-core/, December 2002.




Vassilev, et al.        Expires February 2, 2007               [Page 45]

Internet-Draft      Portable Symmetric Key Container         August 2006


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
















































Vassilev, et al.        Expires February 2, 2007               [Page 46]

Internet-Draft      Portable Symmetric Key Container         August 2006


Authors' Addresses

   Apostol T. Vassilev
   Axalto Inc.
   8311 N. FM 620
   Austin, TX  78726
   USA

   Phone: +1 512 331 3723
   Email: vassilev <at> axalto.com


   Jon Martinsson
   PortWise AB
   F?gatan 33 / Kista Science Tower
   Kista, SE  164 21
   Sweden

   Phone: +46 8 562 914 55
   Email: jon.martinsson <at> portwise.com


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

   Phone: +1 650 426 5173
   Email: mpei <at> verisign.com


   Philip Hoyer
   ActivIdenity, Inc.
   109 Borough High Street
   London, SE1  1NL
   UK

   Phone: +44 (0) 20 7744 6455
   Email: Philip.Hoyer <at> actividentity.com











Vassilev, et al.        Expires February 2, 2007               [Page 47]

Internet-Draft      Portable Symmetric Key Container         August 2006


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

   Phone: +1 416 756 2324 Ext. 321
   Email: smachani <at> diversinet.com










































Vassilev, et al.        Expires February 2, 2007               [Page 48]

Internet-Draft      Portable Symmetric Key Container         August 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 <at> ietf.org.


Acknowledgment

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





Vassilev, et al.        Expires February 2, 2007               [Page 49]

<div>
<div dir="ltr" align="left">
<p class="MsoNormal"><span><p></p></span></p>
<span>
</span>
</div>
<div class="Section1">
<div>
<p class="MsoNormal"><span>From:</span><span> 
Philip Hoyer<br><span>Sent:</span> 20 October 2006 19:21<br><span>To:</span> 'internet-drafts@...'<br><span>Cc:</span> Salah Machani; Bajaj, Siddharth; Stu 
Vaeth; 'Pei, Mingliang'; Shuh Chang<br><span>Subject:</span> New version of the draft of 
Portable Symmetric Key Containe</span><p></p></p>
</div>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Please find attached the new version 
of the draft<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>________________________________</span><p></p></p>
<p class="MsoNormal"><span>Philip 
Hoyer</span><span> 
</span><p></p></p>
<p class="MsoNormal"><span>&nbsp;<p></p></span></p>
<p class="MsoNormal"><span>Senior&nbsp;Architect - 
Office of CTO<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>ActivIdentity&nbsp;(UK)</span><p></p></p>
<p class="MsoNormal"><span>109 Borough High 
Street</span><span><p></p></span></p>
<p class="MsoNormal"><span>London</span><span> SE1 
1NL<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Telephone: +44 (0) 20 7744 
6248<p></p></span></p>
<p class="MsoNormal"><span>Direct: +44 (0) 20 7744 
6455<p></p></span></p>
<p class="MsoNormal"><span>Fax: +44 (0) 20 7744 
6249<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Private and confidential: 
This message and any attachments may contain<p></p></span></p>
<p class="MsoNormal"><span>privileged / confidential 
information. If you are not an intended recipient,<p></p></span></p>
<p class="MsoNormal"><span>you must not copy, 
distribute, discuss or take any action in reliance on 
it.<p></p></span></p>
<p class="MsoNormal"><span>If you have received this 
communication in error, please notify the sender<p></p></span></p>
<p class="MsoNormal"><span>and delete this message 
immediately.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
</div>
</div>

Gmane