< draft-hoyer-keyprov-portable-symmetric-key-container-01.txt   draft-hoyer-keyprov-portable-symmetric-key-container-02.txt >
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Expires: January 10, 2008 VeriSign Expires: January 10, 2008 VeriSign
S. Machani S. Machani
Diversinet Diversinet
A. Vassilev A. Vassilev
Axalto Axalto
J. Martinsson J. Martinsson
PortWise PortWise
July 9, 2007 July 9, 2007
Portable Symmetric Key Container Portable Symmetric Key Container
draft-hoyer-keyprov-portable-symmetric-key-container-01.txt draft-hoyer-keyprov-portable-symmetric-key-container-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 45 skipping to change at page 2, line 45
3.2.3. Online update of an existing authentication token 3.2.3. Online update of an existing authentication token
credential . . . . . . . . . . . . . . . . . . . . . . 8 credential . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11 5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11
5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11 5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11 5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11
5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11 5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11
5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 11 5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 11
5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 12 5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 12
5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 12 5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 12
5.1.6. FriendlyName OPTIONAL . . . . . . . . . . . . . . . . 12 5.1.6. FriendlyName (OPTIONAL) . . . . . . . . . . . . . . . 12
5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 12 5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 12
5.1.8. EncryptionMethod (MANDATORY) . . . . . . . . . . . . . 12 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute
is encrypted)) . . . . . . . . . . . . . . . . . . . . 12
5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 13 5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 13
5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 13 5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 13
6. Key container XML schema definitions . . . . . . . . . . . . . 17 6. Key container XML schema definitions . . . . . . . . . . . . . 17
6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17 6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 17
6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 18 6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 20 6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 20
6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22 6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22
6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22 6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 22
6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23 6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 23
6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 24 6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 24
6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 25 6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 25
6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 26 6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 27
6.1.9. AlgorithmIdentifierType . . . . . . . . . . . . . . . 27 6.1.9. AlgorithmIdentifierType . . . . . . . . . . . . . . . 28
6.2. EncryptionAlgorithmType . . . . . . . . . . . . . . . . . 28 6.2. EncryptionAlgorithmType . . . . . . . . . . . . . . . . . 28
6.3. HashAlgorithmType . . . . . . . . . . . . . . . . . . . . 30 6.3. HashAlgorithmType . . . . . . . . . . . . . . . . . . . . 30
6.4. DigestAlgorithmType . . . . . . . . . . . . . . . . . . . 30 6.4. DigestAlgorithmType . . . . . . . . . . . . . . . . . . . 30
6.5. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 31 6.5. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 31
6.6. valueFormat . . . . . . . . . . . . . . . . . . . . . . . 32 6.6. valueFormat . . . . . . . . . . . . . . . . . . . . . . . 33
6.7. Data elements . . . . . . . . . . . . . . . . . . . . . . 33 6.7. Data elements . . . . . . . . . . . . . . . . . . . . . . 33
6.7.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 33 6.7.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 33
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 34 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 40 8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 41
8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 41 8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 42
8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 41 8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 42
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
10. Appendix A - Example Symmetric Key Containers . . . . . . . . 43 10. Appendix A - Example Symmetric Key Containers . . . . . . . . 44
10.1. Symmetric Key Container with a single Non-Encrypted 10.1. Symmetric Key Container with a single Non-Encrypted
HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 43 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 44
10.2. Symmetric Key Container with a single Password-based 10.2. Symmetric Key Container with a single Password-based
Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 44 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 45
11. Normative References . . . . . . . . . . . . . . . . . . . . . 45 11. Normative References . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . . . . 50
1. Introduction 1. Introduction
With increasing use of symmetric key based authentication systems With increasing use of symmetric key based authentication systems
such as systems based one time password (OTP) and challenge response such as systems based one time password (OTP) and challenge response
mechanisms, there is a need for vendor interoperability and a mechanisms, there is a need for vendor interoperability and a
standard format for importing, exporting or provisioning symmetric standard format for importing, exporting or provisioning symmetric
key based credentials from one system to another. Traditionally key based credentials from one system to another. Traditionally
authentication server vendors and service providers have used authentication server vendors and service providers have used
proprietary formats for importing, exporting and provisioning these proprietary formats for importing, exporting and provisioning these
skipping to change at page 9, line 33 skipping to change at page 9, line 33
* Algorithm ID * Algorithm ID
* Algorithm mode * Algorithm mode
* Issuer Name * Issuer Name
* Issuer logo * Issuer logo
* Credential friendly name * Credential friendly name
* Event counter value * Event counter value (moving factor for OTP algorithms)
* Time value * Time value
R3: The format SHOULD support both offline and online scenarios. R3: The format SHOULD support both offline and online scenarios.
That is it should be serializable to a file as well as it That is it should be serializable to a file as well as it
should be possible to use this format in online provisioning should be possible to use this format in online provisioning
protocols protocols
R4: The format SHOULD allow bulk representation of symmetric key R4: The format SHOULD allow bulk representation of symmetric key
credentials. credentials.
skipping to change at page 12, line 28 skipping to change at page 12, line 28
Additional attributes that are specific to the usage type MAY be Additional attributes that are specific to the usage type MAY be
required. Section 6.1 describes OTP and CR specific attributes. required. Section 6.1 describes OTP and CR specific attributes.
5.1.4. KeyId (MANDATORY) 5.1.4. KeyId (MANDATORY)
A unique and global identifier of the symmetric key. The identifier A unique and global identifier of the symmetric key. The identifier
is defined as a string of alphanumeric characters. is defined as a string of alphanumeric characters.
5.1.5. Issuer (MANDATORY) 5.1.5. Issuer (MANDATORY)
The key issuer name. The Issuer is defined as a String. The key issuer name, this is normally the name of the organisation
that issues the key to the end user of the key. For example MyBank
issuing hardware tokens to their retail banking users 'MyBank' would
be the issuer. The Issuer is defined as a String.
5.1.6. FriendlyName OPTIONAL 5.1.6. FriendlyName (OPTIONAL)
The user friendly name that is assigned to the secret key for easy The user friendly name that is assigned to the secret key for easy
reference. The FriendlyName is defined as a String. reference. The FriendlyName is defined as a String.
5.1.7. AccessRules (OPTIONAL) 5.1.7. AccessRules (OPTIONAL)
Defines a set of access rules and policies for the protection of the Defines a set of access rules and policies for the protection of the
key on the host Device. Currently only the userPIN policy is key on the host Device. Currently only the userPIN policy is
defined. The userPIN policy specifies whether the user MUST enter a defined. The userPIN policy specifies whether the user MUST enter a
PIN (for devices with PIN input capability) in order to unlock or PIN (for devices with PIN input capability) in order to unlock or
authenticate to the device hosting the key container. The userPIN is authenticate to the device hosting the key container. The userPIN is
defined as a Boolean (TRUE or FALSE). When the user PIN is required, 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, the policy MUST be set to TRUE. If the userPIN is NOT provided,
implementations SHALL default the value to FALSE. implementations SHALL default the value to FALSE.
5.1.8. EncryptionMethod (MANDATORY) 5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute is encrypted))
Identifies the encryption algorithm and possible parameters used to Identifies the encryption algorithm and possible parameters used to
protect the Secret Key data in the container and MUST be set to one protect the Secret Key data in the container and MUST be set to one
of the values defined in Section 6.2. If 'OTHER' is specified an of the values defined in Section 6.2. If 'OTHER' is specified an
extension value MUST be set in the 'ext-algorithm' attribute. extension value MUST be set in the 'ext-algorithm' attribute.
When the value is set to NONE, implementations SHALL ensure the When the value is set to NONE, implementations SHALL ensure the
privacy of the key data through other standard mechanisms e.g. privacy of the key data through other standard mechanisms e.g.
transport level encryption. transport level encryption.
skipping to change at page 14, line 42 skipping to change at page 14, line 46
If the Format attribute is 'BASE64' or 'BINARY', this value If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the maximum number of bytes of the unencoded value. indicates the maximum number of bytes of the unencoded value.
Value MUST be: Value MUST be:
Unsigned integer. Unsigned integer.
5.1.10.2. ResponseFormat (MANDATORY) 5.1.10.2. ResponseFormat (MANDATORY)
The ResponseFormat attribute defines the characteristics of the The ResponseFormat attribute defines the characteristics of the
result of a computation. The Response attribute is defined by the result of a computation. This defines the format of the OTP or of
following sub-attributes: the response to a challenge. The Response attribute is defined by
the following sub-attributes:
1. Format (MANDATORY) 1. Format (MANDATORY)
Defines the format of the response generated by the device and Defines the format of the response generated by the device and
MUST be one of the values defined in Section 6.6 MUST be one of the values defined in Section 6.6
2. CheckDigit (OPTIONAL) 2. CheckDigit (OPTIONAL)
Defines if the device needs to append a Luhn check digit to Defines if the device needs to append a Luhn check digit to
the response. This is only valid if the Format attribute the response. This is only valid if the Format attribute
is'DECIMAL'. Value MUST be: is'DECIMAL'. Value MUST be:
TRUE device will append a Luhn check digit to the response. TRUE device will append a Luhn check digit to the response.
skipping to change at page 22, line 16 skipping to change at page 22, line 16
once provisioned on the Device. Currently only the userPIN once provisioned on the Device. Currently only the userPIN
attribute is defined. The userPIN indicates whether the user MUST attribute is defined. The userPIN indicates whether the user MUST
provide a PIN to unlock the key. provide a PIN to unlock the key.
o <AppProfileId> Is the unique shared identifier for out of band o <AppProfileId> Is the unique shared identifier for out of band
shared common parameters. shared common parameters.
6.1.3. DeviceType 6.1.3. DeviceType
The DeviceType type represents the Device entity in the Container. A The DeviceType type represents the Device entity in the Container. A
key is recommended to be bound to one Device only. A Device MAY be Device MAY be bound to a user and MAY contain more than one keys. It
bound to a user and MAY contain more than one keys. is recommended that a key is bound to one and only one Device.
The DeviceType is defined as follows: The DeviceType is defined as follows:
<complexType name="DeviceType"> <complexType name="DeviceType">
<sequence> <sequence>
<element name="DeviceId" type="pskc:DeviceIdType" <element name="DeviceId" type="pskc:DeviceIdType"
minOccurs="0"/> minOccurs="0"/>
<element name="Key" type="pskc:KeyType" <element name="Key" type="pskc:KeyType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<element name="User" type="pskc:UserType" minOccurs="0"/> <element name="User" type="pskc:UserType" minOccurs="0"/>
skipping to change at page 22, line 48 skipping to change at page 22, line 48
o <User>, optionally identifies the owner or the user of the Device, o <User>, optionally identifies the owner or the user of the Device,
as defined by the UserType . as defined by the UserType .
6.1.4. DeviceIdType 6.1.4. DeviceIdType
The DeviceId type represents the identifying criteria to uniquely The DeviceId type represents the identifying criteria to uniquely
identify the device that contains the associated keys. Since devices identify the device that contains the associated keys. Since devices
can come in different form factors such as hardware tokens, can come in different form factors such as hardware tokens,
smartcards, soft tokens in a mobile phone or PC etc this type allows smartcards, soft tokens in a mobile phone or PC etc this type allows
different criteria to be used. Combined though the criteria MUST different criteria to be used. Combined though the criteria MUST
identify uniquely the device. uniquely identify the device. For example for hardware tokens the
combination of SerialNo and Manufacturer will uniquely identify a
device but not serialNo alone since two different token manufacturers
might issue devices with the same serialnumber (similar to the
IssuerDN and serialnumber of a certificate). For keys hold on
banking cards the identification of the device is often done via the
Primary Account Number (PAN, the big number printed on the front of
the card) and an expiry date of the card. DeviceId is an extensible
type that allows all these different ways to uniquely identify a
specific key containing device.
The DeviceIdType is defined as follows: The DeviceIdType is defined as follows:
<complexType name="DeviceIdType"> <complexType name="DeviceIdType">
<sequence> <sequence>
<element name="Manufacturer" type="string"/> <element name="Manufacturer" type="string"/>
<element name="SerialNo" type="string"/> <element name="SerialNo" type="string"/>
<element name="Model" type="string" minOccurs="0"/> <element name="Model" type="string" minOccurs="0"/>
<element name="IssueNo" type="string" minOccurs="0"/> <element name="IssueNo" type="string" minOccurs="0"/>
<element name="Expiry" type="string" minOccurs="0"/> <element name="Expiry" type="string" minOccurs="0"/>
skipping to change at page 31, line 37 skipping to change at page 32, line 7
6.5. KeyAlgorithmType 6.5. KeyAlgorithmType
The KeyAlgorithmType defines the algorithms in which the Secret Key The KeyAlgorithmType defines the algorithms in which the Secret Key
data is used. data is used.
The KeyAlgorithmType is defined as follows: The KeyAlgorithmType is defined as follows:
<simpleType name="KeyAlgorithmType"> <simpleType name="KeyAlgorithmType">
<restriction base="string"> <restriction base="string">
<enumeration value="DES"/>
<enumeration value="3DES112"/> <enumeration value="3DES112"/>
<enumeration value="3DES168"/> <enumeration value="3DES168"/>
<enumeration value="ACTI"/>
<enumeration value="AES128"/> <enumeration value="AES128"/>
<enumeration value="AES192"/> <enumeration value="AES192"/>
<enumeration value="AES256"/> <enumeration value="AES256"/>
<enumeration value="ANSIX9.9"/>
<enumeration value="DES"/>
<enumeration value="HOTP"/> <enumeration value="HOTP"/>
<enumeration value="MKEYLABEL"/> <enumeration value="MKEYLABEL"/>
<enumeration value="RSASECUREID"/>
<enumeration value="VASCO"/>
<enumeration value="OTHER"/> <enumeration value="OTHER"/>
</restriction> </restriction>
</simpleType> </simpleType>
HOTP, as defined in [HOTP]
MKEYLABEL, master key abel or name when an embedded device key is
used to derive the Key
DES, a standard DES key
3DES112, a 112-bit 3DES key (a.k.a. two-key 3DES) 3DES112, a 112-bit 3DES key (a.k.a. two-key 3DES)
3DES168, a 168-bit parity-checked 3DES key 3DES168, a 168-bit parity-checked 3DES key
ACTI, algorithm family from ActivIdentity
AES128, a 128-bit AES key AES128, a 128-bit AES key
AES192, a 192-bit AES key AES192, a 192-bit AES key
AES256, a 256-bit AES key AES256, a 256-bit AES key
ANSIX9.9, ANSI X9.9 algorithm
DES, a standard DES key
HOTP, as defined in [HOTP]
MKEYLABEL, master key abel or name when an embedded device key is
used to derive the Key
RSASECUREID, SecureId algorithm family from RSA
VASCO, algorithm family from Vasco
OTHER extension point for not already defined algorithms in this OTHER extension point for not already defined algorithms in this
list. list.
6.6. valueFormat 6.6. valueFormat
The valueFormat defines allowed formats for challenges or responses The valueFormat defines allowed formats for challenges or responses
in the OTP algorithms. in the OTP algorithms.
The valueFormat is defined as follows: The valueFormat is defined as follows:
skipping to change at page 39, line 9 skipping to change at page 40, line 9
<simpleType name="HashAlgorithmType"> <simpleType name="HashAlgorithmType">
<restriction base="string"> <restriction base="string">
<enumeration value="SHA1"/> <enumeration value="SHA1"/>
<enumeration value="SHA256"/> <enumeration value="SHA256"/>
<enumeration value="SHA512"/> <enumeration value="SHA512"/>
</restriction> </restriction>
</simpleType> </simpleType>
<simpleType name="KeyAlgorithmType"> <simpleType name="KeyAlgorithmType">
<restriction base="string"> <restriction base="string">
<enumeration value="DES"/>
<enumeration value="3DES112"/> <enumeration value="3DES112"/>
<enumeration value="3DES168"/> <enumeration value="3DES168"/>
<enumeration value="ACTI"/>
<enumeration value="AES128"/> <enumeration value="AES128"/>
<enumeration value="AES192"/> <enumeration value="AES192"/>
<enumeration value="AES256"/> <enumeration value="AES256"/>
<enumeration value="ANSIX9.9"/>
<enumeration value="DES"/>
<enumeration value="HOTP"/> <enumeration value="HOTP"/>
<enumeration value="MKEYLABEL"/> <enumeration value="MKEYLABEL"/>
<enumeration value="RSASECUREID"/>
<enumeration value="VASCO"/>
<enumeration value="OTHER"/> <enumeration value="OTHER"/>
</restriction> </restriction>
</simpleType> </simpleType>
<simpleType name="valueFormat"> <simpleType name="valueFormat">
<restriction base="string"> <restriction base="string">
<enumeration value="DECIMAL"/> <enumeration value="DECIMAL"/>
<enumeration value="HEXADECIMAL"/> <enumeration value="HEXADECIMAL"/>
<enumeration value="ALPHANUMERIC"/> <enumeration value="ALPHANUMERIC"/>
<enumeration value="BASE64"/> <enumeration value="BASE64"/>
<enumeration value="BINARY"/> <enumeration value="BINARY"/>
 End of changes. 27 change blocks. 
35 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/