Network Working Group A. Vassilev
Internet-Draft Axalto
Expires: August 18, 2006 J. Martinsson
PortWise
M. Pei
VeriSign
P. Hoyer
ActivIdentity
S. Machani
Diversinet
February 14, 2006
Portable Symmetric Key Container
draft-vassilev-portable-symmetric-key-container-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 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a shared secret token format for transport
Vassilev, et al. Expires August 18, 2006 [Page 1]
Internet-Draft Portable Symmetric Key Container February 2006
and provisioning of shared secrets (One Time Password (OTP) keys or
symmetric cryptographic keys) to different types of strong
authentication devices. The standard token format enables
enterprises to deploy best-of-breed solutions combining components
from different vendors into the same infrastructure.
This work is a joint effort by the members of OATH (Initiative for
Open AuTHentication) to specify a format that can be freely
distributed to the technical community. The authors believe that a
common and shared specification will facilitate adoption of two-
factor authentication on the Internet by enabling interoperability
between commercial and open-source implementations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Credential migration by end-user . . . . . . . . . . . 6
3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6
3.1.3. Bulk migration of existing credentials . . . . . . . . 6
3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7
3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Online provisioning a credential to end-user's
authentication token . . . . . . . . . . . . . . . . . 7
3.2.2. Server to server provisioning of credentials . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Shared Secret Attributes . . . . . . . . . . . . . . . . . . . 11
5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Type (MANDATORY) . . . . . . . . . . . . . . . . . . . 11
5.1.2. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 11
5.1.3. Id (MANDATORY) . . . . . . . . . . . . . . . . . . . . 12
5.1.4. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 12
5.1.5. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 12
5.1.6. EncryptionMethod (MANDATORY) . . . . . . . . . . . . . 12
5.1.7. Digest algorithm (MANDATORY when Digest is present) . 13
5.1.8. OTP and CR specific Attributes . . . . . . . . . . . . 13
5.1.9. Counter (OPTIONAL) . . . . . . . . . . . . . . . . . . 14
5.1.10. Time (OPTIONAL) . . . . . . . . . . . . . . . . . . . 14
5.1.11. Challenge (MANDATORY) . . . . . . . . . . . . . . . . 14
5.1.12. Response (MANDATORY) . . . . . . . . . . . . . . . . . 15
5.1.13. AppProfileId (OPTIONAL) . . . . . . . . . . . . . . . 16
6. Secret container XML schema definitions . . . . . . . . . . . 17
6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17
6.1.1. SecretType . . . . . . . . . . . . . . . . . . . . . . 17
6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 19
Vassilev, et al. Expires August 18, 2006 [Page 2]
Internet-Draft Portable Symmetric Key Container February 2006
6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 21
6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22
6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23
6.1.6. SecretContainerType . . . . . . . . . . . . . . . . . 23
6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 24
6.1.8. DigestValueType . . . . . . . . . . . . . . . . . . . 26
6.1.9. OtpAlgorithmIdentifierType . . . . . . . . . . . . . . 26
6.2. Data elements . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1. SecretContainer . . . . . . . . . . . . . . . . . . . 27
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 35
8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 36
8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 40
Vassilev, et al. Expires August 18, 2006 [Page 3]
Internet-Draft Portable Symmetric Key Container February 2006
1. Introduction
With increasing use of symmetric key based authentication systems
such as systems based one time password (OTP) and challenge response
mechanisms, there is a need for vendor interoperability and a
standard format for importing, exporting or provisioning symmetric
key based credentials from one system to another. Traditionally
authentication server vendors and service providers have used
proprietary formats for importing, exporting and provisioning these
credentials into their systems making it hard to use tokens from
vendor A with a server from vendor B.
This Internet draft describes a standard format for serializing
symmetric key based credentials such as OTP shared secrets for system
import, export or network/protocol transport, promoted by [OATH].
The goal is that the format will facilitate dynamic provisioning of
OTP credentials using an OTP provisioning protocol to different
flavors of embedded tokens or allow customers to import new or
existing tokens in batch or single instances into a compliant system.
This draft also specifies the token attributes required for
interoperability such as the initial event counter used in the HOTP
algorithm [HOTP]. It is also applicable for other time-based or
propriatery algorithms.
To provide an analogy, in public key environments the PKCS#12 format
[PKCS12] is commonly used for importing and exporting private keys
and certificates between systems. In the environments outlined in
this document where OTP credentials may be transported directly down
to smartcards or devices with limited computing capabilities, a small
(size in bytes) and computationally efficient format is crucial,
making it unfeasible to re-use PKCS#12.
Vassilev, et al. Expires August 18, 2006 [Page 4]
Internet-Draft Portable Symmetric Key Container February 2006
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
In the text below, OTP refers to one time password.
Vassilev, et al. Expires August 18, 2006 [Page 5]
Internet-Draft Portable Symmetric Key Container February 2006
3. Use Cases
This section describes a comprehensive list of use cases that
inspired the development of this specification. These requirements
were used to derive the primary requirement that drove the design.
These requirements are covered in the next section.
These use cases also help in understanding the applicability of this
specification to real world situations.
3.1. Offline Use Cases
This section describes the use cases relating to offline trasnport of
credentials from one system to another, using some form of export and
import model.
3.1.1. Credential migration by end-user
A user wants to migrate a credential from one authentication token
(container) to a different authentication token. For example, the
authentication token may be soft tokens on two different systems
(computers or mobile phones). User can export the credential in a
standard format for import into the other authentication token.
The key protection mechanism may rely on password-based encryption
for soft tokens, or a pre-placed hardware-protected transfer key
shared between the two systems if available.
3.1.2. Bulk import of new credentials
Tokens are manufactured in bulk and associated credentials (key
records) need to be loaded into the validation system through a file
on portable media. The manufacturer provides the credentials in the
form of a file containing records in standard format, typically on a
CD. Note that the token manufacturer and the vendor for the
validation system may be the same or different.
In this case the file usually is protected by a symmetric transport
key which was communicated separately outside of the file between the
two parties.
3.1.3. Bulk migration of existing credentials
An enterprise wants to port credentials from an existing validation
system A into a different validation system B. The existing
validation system provides the enterprise with a functionality that
enables export of credentials (OTP tokens) in a standard format.
Since the OTP tokens are in the standard format, the enterprise can
Vassilev, et al. Expires August 18, 2006 [Page 6]
Internet-Draft Portable Symmetric Key Container February 2006
import the token records into the new validation system B and start
using the existing tokens. Note that the vendors for the two
validation systems may be the same or different.
In this case the file usually is protected by a symmetric transport
key which was communicated separately outside of the file between the
two validation systems.
3.1.4. Credential upload case
User wants to activate and use a new credential against a validation
system that is not aware of this credential. This credential may be
embedded in the authentication token (e.g. SD card, USB drive) that
the user has purchased at the local electronics retailer. Along with
the authentication token, the user may get the credential on a CD or
a floppy in a standard format. The user can now upload via a secure
online channel or import this credential into the new validation
system and start using the credential.
The key protection mechanism may rely on password-based encryption,
or a pre-placed hardware-protected transfer key shared between the
token manufacturer and the validation system(s) if available.
3.2. Online Use Cases
This section describes the use cases related to provisioning the
credentials using some form of a online provisioning protocol.
3.2.1. Online provisioning a credential to end-user's authentication
token
A mobile device user wants to obtain an HOTP credential (shared
secret) for use with an OTP soft token on the device. The soft token
client from vendor A initiates the provisioning process against a
provisioning system from vendor B using a standards-based
provisioning protocol as described in the OATH Reference Architecture
[OATHRefArch]. The provisioning system delivers an OTP credential in
a standard format that can be processed by the mobile device. The
user can download more than one credential in a single session if the
provisioning server holds multiple credentials for that user.
In a variation of the above, instead of the user's mobile phone, a
credential is provisioned in the user's soft token application on a
laptop using a network-based online protocol. As before, the
provisioning system delivers an OTP credential in a standard format
that can be processed by the soft token on the PC.
Vassilev, et al. Expires August 18, 2006 [Page 7]
Internet-Draft Portable Symmetric Key Container February 2006
3.2.2. Server to server provisioning of credentials
Sometimes, instead of importing token information from manufacturer
using a file, an OTP validation server may download the credential
seed records using an online protocol. The credentials can be
downloaded in a standard format that can be processed by a validation
system.
In another scenario, an OTA (over-the-air) credential provisioning
gateway that provisions credentials to mobile phones may obtain
credentials from the credential issuer using an online protocol. The
credentials are delivered in a standard format that can be processed
by the OTA credential provisioning gateway and subsequently sent to
the end-user's mobile phone.
Vassilev, et al. Expires August 18, 2006 [Page 8]
Internet-Draft Portable Symmetric Key Container February 2006
4. Requirements
This section outlines the most relevant requirements that are the
basis of this work. Several of the requirements were derived from
use cases described above.
R1: The format MUST support transport of multiple types of symmetric
key credentials including HOTP, other OTP, challenge-response,
etc.
R2: The format MUST handle the symmetric key itself as well of
attributes that are typically associated with symmetric keys.
Some of these attributes may be
* Unique Key Identifier
* Issuer information
* Algorithm ID
* Algorithm mode
* Issuer Name
* Issuer logo
* Credential friendly name
* Initial event counter value
R3: The format SHOULD support both offline and online scenarios.
That is it should be serializable to a file as well as it should
be possible to use this format in online provisioning protocols
R4: The format SHOULD allow bulk representation of symmetric key
credentials.
R5: The format SHOULD be portable to various platforms.
Furthermore, it SHOULD be computationally efficient to process.
R6: The format MUST provide appropriate level of security in terms
of data encryption and data integrity.
R7: For online scenarios the format SHOULD NOT rely on transport
level security (e.g., SSL/TLS) for core security requirements.
Vassilev, et al. Expires August 18, 2006 [Page 9]
Internet-Draft Portable Symmetric Key Container February 2006
R8: The format SHOULD be extensible. It SHOULD enable extension
points allowing vendors to specify additional attributes in the
future.
R9: The format SHOULD allow for distribution of key derivation data
without the actual symmetric key itself. This is to support
symmetric key management schemes that rely on key derivation
algorithms based on a pre-placed master key. The key derivation
data typically consists of a reference to the key, rather than
the key value itself.
R10: The format SHOULD allow for additional lifecycle management
operations such as counter resynchronization. Such processes
require confidentiality between client and server, thus could
use a common secure container format, without the transfer of
key material.
R11: The format MUST support the use of pre-shared symmetric keys to
ensure confidentiality of sensitive data elements.
R12: The format MUST support a password-based encryption (PBE)
[PKCS5] scheme to ensure security of sensitive data elements.
This is a widely used method for various provisioning scenarios.
R13: The format SHOULD support asymmetric encryption algorithms such
as RSA to ensure end-to-end security of sensitive data elements.
This is to support scenarios where a pre-set shared encryption
key is difficult to use.
Vassilev, et al. Expires August 18, 2006 [Page 10]
Internet-Draft Portable Symmetric Key Container February 2006
5. Shared Secret Attributes
The shared secret includes a number of data attributes that define
the type of the secret, its usage and associated meta-information
required during the provisioning, configuration, access or usage in
the host device.
5.1. Common Attributes
5.1.1. Type (MANDATORY)
Defines the type of the shared secret and MUST be one of the
following:
HOTP, as defined in [HOTP]
MKEYNAME, master key name or label when an embedded device key is
used to derive the Shared Secret
DES, a standard DES key
3DES112, a 112-bit 3DES key (a.k.a. two-key 3DES)
3DES168, a 168-bit parity-checked 3DES key
AES128, a 128-bit AES key
AES192, a 192-bit AES key
AES256, a 256-bit AES key
5.1.2. Usage (MANDATORY)
Defines the intended usage of the shared secret and is a combination
of one or more of the following (set to true):
OTP, the shared secret will be used for OTP generation
CR, the shared secret will be used for Challenge/Response purposes
ENCRYPT, the shared secret will be used for data encryption
purposes
SIGN, the shared secret will be used to generate a signature or
keyed hashing for data integrity or authentication purposes.
Vassilev, et al. Expires August 18, 2006 [Page 11]
Internet-Draft Portable Symmetric Key Container February 2006
UNLOCK, the shared secret will be used for an inverse challenge
response in the case a user has locked the device by entering a
wrong PIN too many times (for devices with PIN-input capability)
Additional attributes that are specific to the usage type MAY be
required. Section 6.1 describes OTP and CR specific attributes.
5.1.3. Id (MANDATORY)
A unique and global identifier of the shared secret. The identifier
is defined as a string of alphanumeric characters.
5.1.4. Issuer (MANDATORY)
The shared secret issuer name. The Issuer is defined as a String.
5.1.5. AccessRules (OPTIONAL)
Defines a set of access rules and policies for the protection of the
shared secret on the host Device. Currently only the userPIN policy
is defined. The userPIN policy specifies whether the user MUST enter
a PIN (for devices with PIN input capability) in order to unlock or
authenticate to the device hosting the secret container. The userPIN
is defined as a Boolean (TRUE or FALSE). When the user PIN is
required, the policy MUST be set to TRUE. If the userPIN is NOT
provided, implementations SHALL default the value to FALSE.
5.1.6. EncryptionMethod (MANDATORY)
Identifies the encryption algorithm used to protect the shared secret
in the container and MUST be set to one of the following values:
NONE when no encryption is applied on the shared secret
PBE-3DES112-CBC when password-based encryption is applied using a
112-bit 3DES key in CBC mode
PBE-3DES168-CBC when password-based encryption is applied using a
168-bit 3DES key in CBC mode
PBE-AES128-CBC when password-based encryption is applied using a
128-bit AES key in CBC mode
PBE-AES192-CBC when password-based encryption is applied using a
192-bit AES key in CBC mode is applied.
Vassilev, et al. Expires August 18, 2006 [Page 12]
Internet-Draft Portable Symmetric Key Container February 2006
PBE-AES256-CBC password-based encryption is applied using a 256-
bit AES key in CBC mode is applied.
3DES112-CBC encryption using a pre-shared 112-bit 3DES key in CBC
mode is applied.
3DES168-CBC encryption using a pre-shared 168-bit 3DES key in CBC
mode is applied.
AES128-CBC encryption using a pre-shared 128-bit AES key in CBC
mode is applied.
AES192-CBC encryption using a pre-shared 192-bit AES key in CBC
mode is applied.
AES256-CBC encryption using a pre-shared 256-bit AES key in CBC
mode is applied.
When the value is set to NONE, implementations SHALL ensure the
privacy of the shared secret data through other standard mechanisms
e.g. transport level encryption.
When the SecretContainer contains more than one shared secret and
EncryptionMethod is different from NONE, the same encryption key MUST
be used to encrypt all the secret data elements in the container.
5.1.7. Digest algorithm (MANDATORY when Digest is present)
Identifies the algorithm used to sign the shared secret data. The
digest guarantees the integrity and the authenticity of the shared
secret data. The Digest algorithm MUST be set one of the following
values:
HMAC-SHA1
HMAC-SHA192
HMAC-SHA256
See Section 6.1.8 for more information on Digest data value type.
5.1.8. OTP and CR specific Attributes
When the shared secret usage is set to OTP or CR, additional
attributes MUST be provided to support the OTP and/or the response
computation as required by the underlying algorithm and to customize
or configure the outcome of the computation (format, length and usage
modes).
Vassilev, et al. Expires August 18, 2006 [Page 13]
Internet-Draft Portable Symmetric Key Container February 2006
5.1.9. Counter (OPTIONAL)
Defines the initial event counter value for OTP generation in counter
based OTP generation algorithm [HOTP] computation. When the Counter
attribute is specified, the value MUST be of type long integer and
MAY be set to any number that is greater than or equal to 0. When
the Counter is NOT specified, implementations of HOTP algorithm SHALL
default the value to 0.
5.1.10. Time (OPTIONAL)
Defines the value of the time attribute used for a time based
algorithm. The attribute value MUST be:
Unsigned long
Implementation MAY use the Time attribute value to reset the clock on
the Device.
5.1.11. Challenge (MANDATORY)
The Challenge attribute defines the characteristics of the challenge
in a CR usage scenario. The Challenge attribute is defined by the
following sub-attributes:
1. Format (MANDATORY)
Defines the format of the challenge accepted by the device and
MUST be one of the following:
DECIMAL Only numerical digits
HEXADECIMAL Hexadecimal response
ALPHANUMERIC All letters and numbers (case sensitive)
BASE64 Base 64 encoded
BINARY Binary data, this is mainly used in case of
connected devices
2. CheckDigit (OPTIONAL)
Defines if the device needs to check the appended Luhn check
digit contained in a provided challenge. Value MUST be:
Vassilev, et al. Expires August 18, 2006 [Page 14]
Internet-Draft Portable Symmetric Key Container February 2006
TRUE device will check the appended Luhn check digit in a
provided challenge
FALSE device will not check appended Luhn check digit in
challenge
3. Min (MANDATORY)
Defines the minimum size of the challenge accepted by the
device for CR mode. Value MUST be:
Unsigned integer.
4. Max (MANDATORY)
Defines the maximum size of the challenge accepted by the
device for CR mode. Value MUST be:
Unsigned integer.
5.1.12. Response (MANDATORY)
The Response attribute defines the characteristics of the result of a
computation. The Response attribute is defined by the following sub-
attributes:
1. Format (MANDATORY)
Defines the format of the response generated by the device and
MUST be one of the following:
DECIMAL Only numerical digits
HEXADECIMAL Hexadecimal response
ALPHANUMERIC All letters and numbers (case sensitive)
BASE64 Base 64 encoded
BINARY Binary data, this is mainly used in case of
connected devices
2. CheckDigit (OPTIONAL)
Defines if the device needs to append a Luhn check digit to
the response. Value MUST be:
Vassilev, et al. Expires August 18, 2006 [Page 15]
Internet-Draft Portable Symmetric Key Container February 2006
TRUE device will append a Luhn check digit to the response.
FALSE device will not append a Luhn check digit to the
response.
3. Length (MANDATORY)
Defines the lenght of the response generated by the device.
Value MUST be:
Unsigned integer.
5.1.13. AppProfileId (OPTIONAL)
Defines the application profile id related to attributes present on a
smart card that have influence when computing a response. An example
could be an EMV MasterCard CAP [CAP] application on a card that
contains attributes or uses fixed data for a specific batch of cards
such as:
IAF Internet authentication flag
CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA
13, VISA14)
AIP (Application Interchange Profile), 2 bytes
TVR Terminal Verification Result, 5 bytes
CVR The card verification result
AmountOther
TransactionDate
TerminalCountryCode
TransactionCurrencyCode
AmountAuthorised
IIPB
CVRMask
These values are not contained within attributes in the container but
are shared between the manufacturing and the validation service
through this unique AppProfileId.
Vassilev, et al. Expires August 18, 2006 [Page 16]
Internet-Draft Portable Symmetric Key Container February 2006
6. Secret container XML schema definitions
The portable shared secret container is defined by the following
entities:
1. SecretContainer entity
2. Device entity
3. Secret entity
4. User entity
A SecretContainer MAY contain one or more Device entities. A Device
MAY contain one or more Secret entities and may be associated to one
or more User entities.
6.1. XML Schema Types
The following types are defined to represent the portable shared
secret container entities and associated attributes.
6.1.1. SecretType
The SecretType represents the shared Secret entity in the
SecretContainer. The SecretType is defined as follows:
Vassilev, et al. Expires August 18, 2006 [Page 17]
Internet-Draft Portable Symmetric Key Container February 2006
The components of the SecretType have the following meanings (see
Section 5 for further information):
o of type UsageType defines the usage of the Secret Key. The
Usage attribute is described in Section 5.1.2.
o identifies the issuer of the Shared Secret. The Issuer
attribute is described in Section 5.1.4.
o is a user friendly name that is assigned to the
Shared Secret for easy reference.
Vassilev, et al. Expires August 18, 2006 [Page 18]
Internet-Draft Portable Symmetric Key Container February 2006
o conveys the shared secret octet data in encrypted or non
encrypted format and a digest of the non-encrypted secret octet.
The component is further described below.
o Id is a global identifier of the Shared Secret. See
Section 5.1.3.
o Type defines the type the Secret. The type values are defined in
Section 5.1.1.
The element is of type and is defined as follows:
The element in the SecretType conveys the secret octets in
base 64 encoding. The secret data MAY be encrypted or in clear text
as per the EncrytpionMethod data element in the SecretContainer (see
Section 6.1.6 for details about SecretContainerType). When the
secret data is encrypted, the Digest value MUST be provided. The
digest MUST be calculated on the unencrypted secret data and MUST use
one of the Digest algorithms specified in DigestValueType algorithm
attribute (see Section 6.1.8). When the secret data is in clear
text, the SecretContaier payload signature MAY be used to check the
integrity of the secret octets.
6.1.2. UsageType
The UsageType defines the usage attribute of the shared secret
entity. The UsageType is defined as follows:
Vassilev, et al. Expires August 18, 2006 [Page 19]
Internet-Draft Portable Symmetric Key Container February 2006
The UsageType components have the following meanings:
o defines the key usage for the shared Secret.
o the AI bit string in [MutualAuth]].
o sets the initial moving factor in HOTP or other event
based algorithms computation.
o