Dynamic Symmetric Key Provisioning Protocol

Dynamic Symmetric Key Provisioning Protocol

(DSKPP)

v0.9

August 1, 2006

Open AuTHentication (OATH)

Editors

Mingliang Pei, VeriSign

Salah Machani, Diversinet

Table of Contents

1 Introduction 3

1.1 Overview 3

1.2 Use Cases 3

1.3 Requirements 5

1.3.1 Good to have 6

1.3.2 Non-Requirements 6

2 Notations and Terminology 6

2.1 Conventions used in this document 6

2.2 Acronyms and Abbreviations 6

3 Protocol flow 6

3.1 Shared secret response format 7

3.2 Client Authentication 7

3.3 Server Authentication 10

3.4 Encryption Key for Credential Response 10

3.5 Simple request and response with secure channel 10

3.6 Full message exchanges with non-secure channel 12

4 Protocol messages 12

4.1 GetAuthNonce 12

4.2 GetAuthNonceResponse 13

4.3 GetSharedSecret 13

4.4 GetSharedSecretResponse 15

4.5 ActivationCode 16

5 Protocol Binding 17

6 Security Consideration 17

6.1 Authentication 17

6.2 Confidentiality 18

6.3 Integrity 18

7 Schema 18

8 References 26

9 Acknowledgments 26

Appendix A: Web Service Definition 26

1 Introduction

1.1 Overview

This document describes a 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 provisioning for symmetric key credential types. Asymmetric key pair provisioning isn’t the purpose of this protocol. It 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

1) Use Case #1: A mobile device user wants to obtain an HOTP credential (shared secret) for use with an OTP software token on the device.

The credential may be pre-generated by a back end issuance server, or generated by the provisioning server at the start of 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.

2) Use Case #2: A device user acquires multiple credentials of different types to its device

The provisioning process should allow a user to acquire multiple credentials to its device such as a flash drive or a desktop. The credentials may or may not be the same type such as HOTP, symmetric challenge-response, or other algorithms. The protocol must provide for a mechanism to uniquely identify a specific credential in the device using a token identification to allow device authentication before provisioning.

3) Use Case 3: Credential renewal with the same credential ID

The provisioning allows a user to get a new key using the same Credential ID, in the case of a lost/failed/locked or upgraded token device.

4) Use Case #4: A credential is associated with a validity period

After a user acquires a credential, the credential consuming application is able to check whether the credential should be terminated after certain period of time. Instead of defining such validity by the consuming or credential authentication system, the provisioning service defines validity for credentials that it issues.

5) Use case #5: A user acquires credentials for its device from an issuer as a Relying Party of a credential provisioning service provider

A credential issuer leverages third party credential provisioning and validation service provider to offer its user software tokens. This is a case different from a fully hosted enterprise customer case where an enterprise hosts its own provisioning server. In the current case, the end user client application communicates with the issuer proxy server that delegates request to provisioning service to acquire a credential after it authenticates the user. The issuer entity is responsible to authenticate its users but not manufacturing credentials; it acquires credentials from service provider. The case falls into dynamical provisioning scenario instead of bulk provisioning between credential manufacturers and authentication system providers.

Mutual authentication is typically needed between an issuing relying party and a provisioning service provider. Because these are typically machine to machine authentication, a certificate based authentication is good candidate. If a shared secret is used, the shared secret can be long strong one.

6) Use Case #6: Administrator initialization before use

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.

While bulk initialization under controlled conditions during manufacture is likely to meet the security needs of most applications reliance on a pre-disclosed secret is unacceptable to some circumstances, in particular tokens 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 situation in which initialization before use may be required is the case where the OTP functionality is installed on a previously manufactured device as software.

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.

7) Use Case #7: Post issuance smart card update

A smart card has been issued to a user. After issuance the smart card is updated with an HOTP application. The key 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. EG the card commands (APDUs Application Protocol Data Unit) is encrypted with a pre-shared transport key and sent directly to the smart card chip allowing secure in-the-field post issuance provisioning even passing different SSL or other transport security boundaries.

This use case in therefore not in bulk but will require the protocol to be tunneled and the provisioning server to know the correct previously set up transport key.

1.3 Requirements

The protocol addresses the following requirements.

Supports multiple types of credentials for symmetric key based authentication methods
Supports pre-generated credentials (by separate credential issuance server/service) or locally generated credentials in real-time (by provisioning server)
Supports a device to host multiple credentials; each credential can be acquired in its own session
Supports renewal of credential with the same credential ID
Allows the client to specify its cryptographic and security capabilities to the server.
Provides mutual authentication and confidentiality of sensitive provisioning data
Does not require client-side digital certificates to be supported for all client types (e.g., allows for protocol options/profiling that supports use of PKI in some cases and not others for symmetric key protection and device authentication)
Does not rely on transport level security (e.g., SSL/TLS) for core security requirements (since not all devices have SSL support). Should be SSL-compatible when available
Allows an issuer to set credential expiry for its tokens
Allows on the server side to use pre-loaded symmetric transport keys on a device by device basis (smart card update keys, e.g. secure channel in Global platform)
Enables simple user experience for provisioning process
Protects against replay attacks
Protects against man-in-the middle attacks

1.3.1 Good to have

Supports mutually generated secrets by both client and server
Supports a device to acquire multiple credentials in the same session
Should allow the provisioning server to verify that the key has been correctly provisioned to the client
Allow a client to notify credential deletion

1.3.2 Non-Requirements

Supports client generated credentials to upload to provisioning server
Supports credential lifecycle management, for example, disabling a token when an owner reports that it is lost; it is an authentication system function.
Supports asymmetric key pair provisioning

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

2.2 Acronyms and Abbreviations

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

Term / Definition
OTP / One Time Password
HMAC / Hashing for Message Authentication
SHA1 / Secure Hash Algorithm 1
SOAP / Simple Object Access Protocol
URI / Uniform Resource Identifier
XML / Extensible Markup Language

3 Protocol flow

The basic protocol consists of two pair request and response message exchanges between a client and a provisioning server. The first pair of messages, namely, GetAuthNonce and GetAuthNonceResponse, enables a client to contact server for a nonce value before it sends authentication data in the actual credential request. The server nonce is used to construct client authentication data that cannot be replayed. This round trip is only needed when a non-secure transport channel is used and client authentication is required. The second pair of messages (GetSharedSecret and GetSharedSecretResponse) is the actual credential provisioning round trip where a client authentication data is sent in the request. For typical provisioning web service implementation where secure transport (TLS) is enabled, a client only needs to send one request, namely the message “GetSharedSecret”. Of course, a client can use the two round trips even if secure transport layer is used.

3.1 Shared secret response format

The protocol uses Portal Symmetric Key Container (PSKC) defined by OATH submission to RFC to carry a resulting shared secret value. It also allows other formats such as PKCS#12 or PKCS#5 XML format through a general extension.

3.2 Client Authentication

Credential provisioning process typically needs to determine whether a given client is allowed to acquire a token credential. The client authentication, however, may or may not be in-band where authentication data is part of request message and authentication must be carried out by the provisioning server. Client authentication may be done out of band before provisioning flow occurs. For example, a provisioning web application for desktop software token may authenticate user first, and then accepts a provisioning request message; the client application doesn’t need to send any authentication data inside the credential request message.

When authentication data is expected from a request, such data is typically a device certificate or an activation code acquired out of band by the device owner from credential issuer. For the later case, a user typically goes to a credential issuer to pay and get an activation code; the user downloads a credential to its device after submitting such an activation code.

When a credential issuer is actually an issuing relying party of a provisioning service provider, the authentication also happens between the issuer and the service provider. The authentication between the client and the relying party proxy server can be done as if the proxy server is the actual provisioning service. The authentication between the proxy and service provider may depend on either an enterprise certificate or a shared secret between the two parties. Because it is machine to machine authentication, an enterprise certificate is often more secure and convenient. If a shared secret is used, the shared secret can be long strong one in comparison with end user activation code that needs to be entered into some UI.

Considering an activation code as a special form of shared secret between user and provisioning service, we have two kinds of authentication data: shared secret and a certificate for either a user or an organization.

When a user has an authentication activation code, it must be sent to provisioning server in a secure way. If underlying transport channel is secure, the authentication data can be the original activation code or hashed form:

AuthenticationData = HASH (activation code)

where some server information such as server IP or URL could be optionally used along with activation code for hashing. Otherwise, the authentication data is derived from the activation code and a server provided nonce value:

AuthenticationData = HMAC (activation code, serverNonce)

This prevents man-in-the-middle attack because the hashed data doesn’t expose original activation code to the hacker and the data cannot be replayed due to server nonce.

When a certificate is used for authentication, the authentication data can be client signed data.

In addition to the authentication data, the full authentication token element may contain an identifier such as username, account ID, device ID or a server issued ID. Thus the authentication token element for the credential request has the following form.

Authentication data holder for a request. When authentication type

is "PASSCODE", the data can be any one of the three activation

code related types.

</documentation>

</annotation>