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.
[OATHRefArch]
OATH, "Reference Architecture",
URL: http://www.openauthentication.org, Version 1.0, 2005.
[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.
[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@verisign.com
Salah Machani
Diversinet, Inc.
2225 Sheppard Avenue East
Suite 1801
Toronto, Ontario M2J 5C2
Canada
Phone: +1 416 756 2324 Ext. 321
Email: smachani@diversinet.com
Pei & Machani Expires April 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@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]