< draft-ietf-keyprov-pskc-07.txt   draft-ietf-keyprov-pskc-08.txt >
keyprov P. Hoyer keyprov P. Hoyer
Internet-Draft ActivIdentity Internet-Draft ActivIdentity
Intended status: Standards Track M. Pei Intended status: Standards Track M. Pei
Expires: December 30, 2010 VeriSign Expires: February 3, 2011 VeriSign
S. Machani S. Machani
Diversinet Diversinet
June 28, 2010 August 2, 2010
Portable Symmetric Key Container (PSKC) Portable Symmetric Key Container (PSKC)
draft-ietf-keyprov-pskc-07 draft-ietf-keyprov-pskc-08
Abstract Abstract
This document specifies a symmetric key format for transport and This document specifies a symmetric key format for transport and
provisioning of symmetric keys to different types of crypto modules. provisioning of symmetric keys to different types of crypto modules.
For example, One Time Password (OTP) shared secrets or symmetric For example, One Time Password (OTP) shared secrets or symmetric
cryptographic keys to strong authentication devices. A standard key cryptographic keys to strong authentication devices. A standard key
transport format enables enterprises to deploy best-of-breed transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same solutions combining components from different vendors into the same
infrastructure. infrastructure.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2010. This Internet-Draft will expire on February 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3. Portable Key Container Entities Overview and Relationships . . 8 3. Portable Key Container Entities Overview and Relationships . . 8
4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 10 4. <KeyContainer> Element: The Basics . . . . . . . . . . . . . . 10
4.1. <Key>: Embedding Keying Material and Key Related 4.1. <Key>: Embedding Keying Material and Key Related
Information . . . . . . . . . . . . . . . . . . . . . . . 10 Information . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Key Value Encoding . . . . . . . . . . . . . . . . . . . . 12 4.2. Key Value Encoding . . . . . . . . . . . . . . . . . . . . 12
4.2.1. AES Key Value Encoding . . . . . . . . . . . . . . . . 13 4.2.1. AES Key Value Encoding . . . . . . . . . . . . . . . . 13
4.2.2. Triple DES Key Value Encoding . . . . . . . . . . . . 13 4.2.2. Triple DES Key Value Encoding . . . . . . . . . . . . 13
4.3. Transmission of supplementary Information . . . . . . . . 14 4.3. Transmission of supplementary Information . . . . . . . . 14
4.3.1. <DeviceInfo> Element: Unique Device Identification . . 15 4.3.1. <DeviceInfo> Element: Unique Device Identification . . 15
4.3.2. <CryptoModuleInfo> Element: CryptoModule 4.3.2. <CryptoModuleInfo> Element: CryptoModule
Identification . . . . . . . . . . . . . . . . . . . . 16 Identification . . . . . . . . . . . . . . . . . . . . 17
4.3.3. <UserId> Element: User Identification . . . . . . . . 17 4.3.3. <UserId> Element: User Identification . . . . . . . . 17
4.3.4. <AlgorithmParameters> Element: Supplementary 4.3.4. <AlgorithmParameters> Element: Supplementary
Information for OTP and CR Algorithms . . . . . . . . 17 Information for OTP and CR Algorithms . . . . . . . . 17
4.4. Transmission of Key Derivation Values . . . . . . . . . . 19 4.4. Transmission of Key Derivation Values . . . . . . . . . . 19
5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. PIN Algorithm definition . . . . . . . . . . . . . . . . . 25 5.1. PIN Algorithm definition . . . . . . . . . . . . . . . . . 26
6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 26 6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 27
6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 26 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 27
6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 28 6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Encryption based on Passphrase-based Keys . . . . . . . . 29 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 30
6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 32 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 33
6.4. Padding of Encrypted Values for Non-Padded Encryption 6.4. Padding of Encrypted Values for Non-Padded Encryption
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 33 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 34 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 35
8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 36 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 37
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 39 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 40
10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 40 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 41
10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.2. PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.2. PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
12.1. Content-type registration for 'application/pskc+xml' . . . 49 12.1. Content-type registration for 'application/pskc+xml' . . . 50
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 50 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 51
12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 50 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 51
12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 51 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 52
12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 52 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 53
12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 52 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 53
13. Security Considerations . . . . . . . . . . . . . . . . . . . 54 13. Security Considerations . . . . . . . . . . . . . . . . . . . 55
13.1. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 54 13.1. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 55
13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 55 13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 56
13.3. PSKC Authenticity . . . . . . . . . . . . . . . . . . . . 55 13.3. PSKC Authenticity . . . . . . . . . . . . . . . . . . . . 56
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 56 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 57
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
16.1. Normative References . . . . . . . . . . . . . . . . . . . 58 16.1. Normative References . . . . . . . . . . . . . . . . . . . 59
16.2. Informative References . . . . . . . . . . . . . . . . . . 59 16.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 61 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 62
A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 61 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 62
A.1.1. Transport of keys from Server to Cryptographic A.1.1. Transport of keys from Server to Cryptographic
Module . . . . . . . . . . . . . . . . . . . . . . . . 61 Module . . . . . . . . . . . . . . . . . . . . . . . . 62
A.1.2. Transport of keys from Cryptographic Module to A.1.2. Transport of keys from Cryptographic Module to
Cryptographic Module . . . . . . . . . . . . . . . . . 61 Cryptographic Module . . . . . . . . . . . . . . . . . 62
A.1.3. Transport of keys from Cryptographic Module to A.1.3. Transport of keys from Cryptographic Module to
Server . . . . . . . . . . . . . . . . . . . . . . . . 62 Server . . . . . . . . . . . . . . . . . . . . . . . . 63
A.1.4. Server to server Bulk import/export of keys . . . . . 62 A.1.4. Server to server Bulk import/export of keys . . . . . 63
A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 62 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 63
A.2.1. Server to server Bulk import/export of keys . . . . . 62 A.2.1. Server to server Bulk import/export of keys . . . . . 63
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 64 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction 1. Introduction
With increasing use of symmetric key based systems, such as With increasing use of symmetric key based systems, such as
encryption of data at rest, or systems used for strong encryption of data at rest, or systems used for strong
authentication, such as those based on one-time-password (OTP) and authentication, such as those based on one-time-password (OTP) and
challenge response (CR) mechanisms, there is a need for vendor challenge response (CR) mechanisms, there is a need for vendor
interoperability and a standard format for importing and exporting interoperability and a standard format for importing and exporting
(provisioning) symmetric keys. For instance, traditionally, vendors (provisioning) symmetric keys. For instance, traditionally, vendors
of authentication servers and service providers have used proprietary of authentication servers and service providers have used proprietary
skipping to change at page 16, line 11 skipping to change at page 16, line 11
alone is insufficient since two different token manufacturers might alone is insufficient since two different token manufacturers might
issue devices with the same serial number (similar to the Issuer issue devices with the same serial number (similar to the Issuer
Distinguished Name and serial number of a certificate). Distinguished Name and serial number of a certificate).
The <DeviceInfo> element has the following child elements: The <DeviceInfo> element has the following child elements:
<Manufacturer>: This element indicates the manufacturer of the <Manufacturer>: This element indicates the manufacturer of the
device. Values for Manufacturer SHOULD be taken from either device. Values for Manufacturer SHOULD be taken from either
[OATHMAN] prefixes (i.e., the left column) or they SHOULD be taken [OATHMAN] prefixes (i.e., the left column) or they SHOULD be taken
from IANA Private Enterprise Number Registry [IANAPENREG], using from IANA Private Enterprise Number Registry [IANAPENREG], using
the Organisation value. the Organisation value. When the value is taken from [OATHMAN]
"oath." MUST be prepended to the value (e.g. "oath.<prefix value
from [OATHMAN]>"). When the value is taken from [IANAPENREG]
"iana." MUST be prepended to the value (e.g. "iana.<Organisation
value from [IANAPENREG]>").
<SerialNo>: This element contains the serial number of the device. <SerialNo>: This element contains the serial number of the device.
<Model>: This element describes the model of the device (e.g., one- <Model>: This element describes the model of the device (e.g., one-
button-HOTP-token-V1). button-HOTP-token-V1).
<IssueNo>: This element contains the issue number in case devices <IssueNo>: This element contains the issue number in case devices
with the same serial number that are distinguished by different with the same serial number that are distinguished by different
issue numbers. issue numbers.
skipping to change at page 16, line 33 skipping to change at page 16, line 37
that the key is going to be loaded into the device for which the that the key is going to be loaded into the device for which the
key provisioning request was approved. The device is bound to the key provisioning request was approved. The device is bound to the
request using a device identifier, e.g., an International Mobile request using a device identifier, e.g., an International Mobile
Equipment Identity (IMEI) for the phone, or an identifier for a Equipment Identity (IMEI) for the phone, or an identifier for a
class of identifiers, e.g., those for which the keys are protected class of identifiers, e.g., those for which the keys are protected
by a Trusted Platform Module (TPM). by a Trusted Platform Module (TPM).
<StartDate>: and <ExpiryDate>: These two elements indicate the start <StartDate>: and <ExpiryDate>: These two elements indicate the start
and end date of a device (such as the one on a payment card, used and end date of a device (such as the one on a payment card, used
when issue numbers are not printed on cards). The date MUST be when issue numbers are not printed on cards). The date MUST be
expressed in UTC form with no timezone component. Implementations expressed as a dateTime in "canonical representation"
SHOULD NOT rely on time resolution finer than milliseconds and [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely
MUST NOT generate time instants that specify leap seconds. Keys on time resolution finer than milliseconds and MUST NOT generate
that reside on the device SHOULD only be used when the current time instants that specify leap seconds. Keys that reside on the
date is after the <StartDate> and before the <ExpiryDate>. Note device SHOULD only be used when the current date is after the
that usage enforcement of the keys with respective to the dates <StartDate> and before the <ExpiryDate>. Note that usage
MAY only happen on the validation server as some devices such as enforcement of the keys with respective to the dates MAY only
smart cards do not have an internal clock. Systems thus SHOULD happen on the validation server as some devices such as smart
NOT rely upon the device to enforce key usage date restrictions. cards do not have an internal clock. Systems thus SHOULD NOT rely
upon the device to enforce key usage date restrictions.
Depending on the device type certain child elements of the Depending on the device type certain child elements of the
<DeviceInfo> element MUST be included in order to uniquely identify a <DeviceInfo> element MUST be included in order to uniquely identify a
device. This document does not enumerate the different device types device. This document does not enumerate the different device types
and therefore does not list the elements that are mandatory for each and therefore does not list the elements that are mandatory for each
type of device. type of device.
4.3.2. <CryptoModuleInfo> Element: CryptoModule Identification 4.3.2. <CryptoModuleInfo> Element: CryptoModule Identification
The <CryptoModuleInfo> element identifies the cryptographic module to The <CryptoModuleInfo> element identifies the cryptographic module to
skipping to change at page 22, line 37 skipping to change at page 23, line 37
</Key> </Key>
</KeyPackage> </KeyPackage>
</KeyContainer> </KeyContainer>
Figure 5: Non-Encrypted HOTP Secret Key protected by PIN Figure 5: Non-Encrypted HOTP Secret Key protected by PIN
This document defines the following Policy child elements: This document defines the following Policy child elements:
<StartDate> and <ExpiryDate>: These two elements denote the validity <StartDate> and <ExpiryDate>: These two elements denote the validity
period of a key. It MUST be ensured that the key is only used period of a key. It MUST be ensured that the key is only used
between the start and the end date (inclusive). The value MUST be between the start and the end date (inclusive). The date MUST be
expressed in UTC form, with no time zone component. expressed as a dateTime in "canonical representation"
Implementations SHOULD NOT rely on time resolution finer than [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely
milliseconds and MUST NOT generate time instants that specify leap on time resolution finer than milliseconds and MUST NOT generate
seconds. When this element is absent the current time is assumed time instants that specify leap seconds. When this element is
as the start time. absent the current time is assumed as the start time.
<NumberOfTransactions>: The value in this element indicates the <NumberOfTransactions>: The value in this element indicates the
maximum number of times a key carried within the PSKC document can maximum number of times a key carried within the PSKC document can
be used by an application after having received it.. When this be used by an application after having received it.. When this
element is omitted then there is no restriction regarding the element is omitted then there is no restriction regarding the
number of times a key can be used. number of times a key can be used.
<KeyUsage>: The <KeyUsage> element puts constraints on the intended <KeyUsage>: The <KeyUsage> element puts constraints on the intended
usage of the key. The recipient of the PSKC document MUST enforce usage of the key. The recipient of the PSKC document MUST enforce
the key usage. Currently, the following tokens are registered by the key usage. Currently, the following tokens are registered by
skipping to change at page 59, line 21 skipping to change at page 60, line 21
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[SP800-67] [SP800-67]
National Institute of Standards, "NIST Special Publication National Institute of Standards, "NIST Special Publication
800-67 Version 1.1: Recommendation for the Triple Data 800-67 Version 1.1: Recommendation for the Triple Data
Encryption Algorithm (TDEA) Block Cipher", NIST Special Encryption Algorithm (TDEA) Block Cipher", NIST Special
Publication 800-67, May 2008. Publication 800-67, May 2008.
[W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing", [XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
W3C Recommendation, February 2002. W3C Recommendation, February 2002.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
URL: http://www.w3.org/TR/xmlenc-core/, URL: http://www.w3.org/TR/xmlenc-core/,
W3C Recommendation, December 2002. W3C Recommendation, December 2002.
[XMLENC11] [XMLENC11]
Eastlake, D., "XML Encryption Syntax and Processing Eastlake, D., "XML Encryption Syntax and Processing
 End of changes. 14 change blocks. 
62 lines changed or deleted 73 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/