Network Working Group M. Pei Internet-Draft VeriSign Intended status: Standards Track S. Machani Expires: August 13, 2007 Diversinet February 9, 2007 Dynamic Symmetric Key Provisioning Protocol draft-pei-keyprov-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 August 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Pei & Machani Expires August 13, 2007 [Page 1] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 2] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 3] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 4] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 5] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 6] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 7] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 8] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 9] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 10] Internet-Draft Symmetric Key Provisioning February 2007 xmlns:ds=http://www.w3.org/2000/09/xmldsig# Pei & Machani Expires August 13, 2007 [Page 11] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 12] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 13] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 14] Internet-Draft Symmetric Key Provisioning February 2007 - AuthenticationData = 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 August 13, 2007 [Page 15] Internet-Draft Symmetric Key Provisioning February 2007 5. Data Types 5.1. SecretContainer This represents the default symmetric key container in a response uses 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 o o The ActivationCodeType is defined as follows: Maximum length of activation code restricted to 20 bytes The ActivationCodeDigestType is defined as follows: Pei & Machani Expires August 13, 2007 [Page 16] Internet-Draft Symmetric Key Provisioning February 2007 Includes a digest of activation code. The components of the ActivationCodeDigestType have the following meanings: o attribute indicates one of supported message digest methods. is defined in [PSKC]. The ActivationCodeMacType is defined as follows: Includes a HMAC of activation code with nonce as key. The components of the ActivationCodeMacType have the following meanings: o carries the HMAC authentication data derived from activation code and nonce value. o contains a nonce value. The value is acquired through a request to the server. The element can be omitted Pei & Machani Expires August 13, 2007 [Page 17] Internet-Draft Symmetric Key Provisioning February 2007 o attribute indicates one of supported MAC algorithms. is defined in [PSKC]. o should have the value of returned in a response message 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: The components of the AuthenticationDataType have the following meanings: o 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, can be omitted; the certificate itself is typically sufficient to indicate the requestor. This Pei & Machani Expires August 13, 2007 [Page 18] Internet-Draft Symmetric Key Provisioning February 2007 element is required when the authentication data uses . The server relies on this value to identify corresponding activation code, and the nonce when the nonce is omitted in the element. o is used when an activation code is used and sent in clear to the server. o is used when an activation code is used and sent in the server with its hashed form. o is used when an activation code is used along with a server nonce to produce authentication data value. o 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
attribute indicates the authentication credential value form type . 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 choice to carry the value, or the XML signature element according to XML signature specification [XMLSIG] for the request. Pei & Machani Expires August 13, 2007 [Page 19] Internet-Draft Symmetric Key Provisioning February 2007 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: The components of the GetAuthNonceType have the following meanings: o , a unique identifier associated with the requestor's activation code. This identifier must also be used in the subsequent authentication data element that uses when it is submitted to download a credential with o attribute, inherited from , is the message version used in the client. o attribute, inherited from , 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 August 13, 2007 [Page 20] Internet-Draft Symmetric Key Provisioning February 2007 The components of the GetAuthNonceResponseType have the following meanings: o contains server assigned secret ID o indicates service information. o 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 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 attribute, inherited from , is the ID that the corresponding request sent. o attribute, inherited from , 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 August 13, 2007 [Page 21] Internet-Draft Symmetric Key Provisioning February 2007 The components of the GetSharedSecretType have the following meanings: o 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 indicates the device type. o conveys the device information. It is defined in OATH [PSKC] specification. Pei & Machani Expires August 13, 2007 [Page 22] Internet-Draft Symmetric Key Provisioning February 2007 o 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 indicates the requested type of symmetric key credential type. o indicates the usage of the HOTP secret supported by the token device. It is used when the requested SecretAlgorithm is HOTP. o 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 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 describes preferred logo that the issuer should return. o allows additional request information. o attribute is inherited from . There is also 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 August 13, 2007 [Page 23] Internet-Draft Symmetric Key Provisioning February 2007 The components of the GetSharedSecretResponseType have the following meanings: o specifies the shared secret delivery method. The value can be HTTP, HTTPS or SMS. o indicates the PSKC secret container. It should be used when the value of attribute is "PSKC". o is used to represent the other format of credential container type when the value of attribute isn't "PSKC". o allows a server to return additional information. A provisioning service provider may specify its own extensions. o 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 August 13, 2007 [Page 24] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 25] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 26] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 27] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 28] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 29] Internet-Draft Symmetric Key Provisioning February 2007 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 Schema for OATH Dynamical Symmetric Key Provisioning Web Services Abstract class for all messages in this protocol. Pei & Machani Expires August 13, 2007 [Page 30] Internet-Draft Symmetric Key Provisioning February 2007 Abstract class for all request messages. Id is a pseudo-random number used for request-response matching. 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. Contains a status code indicating success or causes of failure, and a status message that includes a brief description. Pei & Machani Expires August 13, 2007 [Page 31] Internet-Draft Symmetric Key Provisioning February 2007 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. Pei & Machani Expires August 13, 2007 [Page 32] Internet-Draft Symmetric Key Provisioning February 2007 Pei & Machani Expires August 13, 2007 [Page 33] Internet-Draft Symmetric Key Provisioning February 2007 Pei & Machani Expires August 13, 2007 [Page 34] Internet-Draft Symmetric Key Provisioning February 2007 List of supported device types. Maximum length of activation code restricted to 20 bytes Includes a digest of activation code. Pei & Machani Expires August 13, 2007 [Page 35] Internet-Draft Symmetric Key Provisioning February 2007 Includes a HMAC of activation code with nonce as key. List of supported transport protocols. Pei & Machani Expires August 13, 2007 [Page 37] Internet-Draft Symmetric Key Provisioning February 2007 Appendix B. Example Requests and Responses All examples are syntactically correct and compatible with the XML schema in Appendix B. However, , Secret and Secret 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. MOBILEPHONE ManufacturerABC XL0000000001234 U2 12345678 HOTP HTTPS PBE-3DES168-CBC Server responses with an encrypted credential in GetSharedSecretResponse upon approval. Pei & Machani Expires August 13, 2007 [Page 38] Internet-Draft Symmetric Key Provisioning February 2007 Success Success HTTPS y6TzckeLRQw= 999 CredentialIssuer MyFirstToken 7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA== WldjTHZwRm9YTkhBRytseDMrUnc= 9TD4yaItFZg= HuYEuuk9K/oZPgfZS7kD+dwmiDg= 10/30/2009 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 August 13, 2007 [Page 39] Internet-Draft Symmetric Key Provisioning February 2007 FA0033F4550B01FFDA05 Server replies with a nonce for the session with the following message. Continue The client requests a credential with authentication data constructed from an activation code and the nonce. Pei & Machani Expires August 13, 2007 [Page 40] Internet-Draft Symmetric Key Provisioning February 2007 MOBILEPHONE ManufacturerABC FA0033F4550B01FFDA05 SPH-A900 SS00000001 WldjTHZwRm9YTkhBRytseDMrUnc= HOTP HTTPS PBE-3DES168-CBC The server response message for this request is similar to the example in the last section. Pei & Machani Expires August 13, 2007 [Page 41] Internet-Draft Symmetric Key Provisioning February 2007 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 August 13, 2007 [Page 42] Internet-Draft Symmetric Key Provisioning February 2007 Authors' Addresses Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA Phone: +1 650 426 5173 Email: mpei@verisign.com Salah Machani Diversinet, Inc. 2225 Sheppard Avenue East Suite 1801 Toronto, Ontario M2J 5C2 Canada Phone: +1 416 756 2324 Ext. 321 Email: smachani@diversinet.com Pei & Machani Expires August 13, 2007 [Page 43] Internet-Draft Symmetric Key Provisioning February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Pei & Machani Expires August 13, 2007 [Page 44]