diff options
Diffstat (limited to 'doc/rfc/rfc6030.txt')
| -rw-r--r-- | doc/rfc/rfc6030.txt | 3251 |
1 files changed, 3251 insertions, 0 deletions
diff --git a/doc/rfc/rfc6030.txt b/doc/rfc/rfc6030.txt new file mode 100644 index 0000000..96e85e5 --- /dev/null +++ b/doc/rfc/rfc6030.txt @@ -0,0 +1,3251 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Hoyer +Request for Comments: 6030 ActivIdentity +Category: Standards Track M. Pei +ISSN: 2070-1721 VeriSign + S. Machani + Diversinet + October 2010 + + + Portable Symmetric Key Container (PSKC) + +Abstract + + This document specifies a symmetric key format for the transport and + provisioning of symmetric keys to different types of crypto modules. + For example, One-Time Password (OTP) shared secrets or symmetric + cryptographic keys to strong authentication devices. A standard key + transport format enables enterprises to deploy best-of-breed + solutions combining components from different vendors into the same + infrastructure. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6030. + + + + + + + + + + + + + + + + + +Hoyer, et al. Standards Track [Page 1] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Key Words ..................................................4 + 1.2. Version Support ............................................4 + 1.3. Namespace Identifiers ......................................5 + 1.3.1. Defined Identifiers .................................5 + 1.3.2. Referenced Identifiers ..............................5 + 2. Terminology .....................................................6 + 3. Portable Key Container Entities Overview and Relationships ......6 + 4. <KeyContainer> Element: The Basics ..............................8 + 4.1. <Key>: Embedding Keying Material and Key-Related + Information ................................................8 + 4.2. Key Value Encoding ........................................10 + 4.2.1. AES Key Value Encoding .............................11 + 4.2.2. Triple-DES Key Value Encoding ......................11 + 4.3. Transmission of Supplementary Information .................12 + 4.3.1. <DeviceInfo> Element: Unique Device + Identification .....................................13 + 4.3.2. <CryptoModuleInfo> Element: CryptoModule + Identification .....................................15 + 4.3.3. <UserId> Element: User Identification ..............15 + 4.3.4. <AlgorithmParameters> Element: + Supplementary Information for OTP and CR Algorithms 15 + 4.4. Transmission of Key Derivation Values .....................17 + 5. Key Policy .....................................................19 + 5.1. PIN Algorithm Definition ..................................23 + 6. Key Protection Methods .........................................23 + 6.1. Encryption Based on Pre-Shared Keys .......................24 + 6.1.1. MAC Method .........................................26 + 6.2. Encryption Based on Passphrase-Based Keys .................27 + 6.3. Encryption Based on Asymmetric Keys .......................29 + + + + +Hoyer, et al. Standards Track [Page 2] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + 6.4. Padding of Encrypted Values for Non-Padded + Encryption Algorithms .....................................31 + 7. Digital Signature ..............................................31 + 8. Bulk Provisioning ..............................................33 + 9. Extensibility ..................................................35 + 10. PSKC Algorithm Profile ........................................36 + 10.1. HOTP .....................................................36 + 10.2. PIN ......................................................37 + 11. XML Schema ....................................................38 + 12. IANA Considerations ...........................................44 + 12.1. Content-Type Registration for 'application/pskc+xml' .....44 + 12.2. XML Schema Registration ..................................45 + 12.3. URN Sub-Namespace Registration ...........................46 + 12.4. PSKC Algorithm Profile Registry ..........................46 + 12.5. PSKC Version Registry ....................................47 + 12.6. Key Usage Registry .......................................47 + 13. Security Considerations .......................................48 + 13.1. PSKC Confidentiality .....................................49 + 13.2. PSKC Integrity ...........................................50 + 13.3. PSKC Authenticity ........................................50 + 14. Contributors ..................................................50 + 15. Acknowledgements ..............................................50 + 16. References ....................................................51 + 16.1. Normative References .....................................51 + 16.2. Informative References ...................................52 + Appendix A. Use Cases ............................................54 + A.1. Online Use Cases ..........................................54 + A.1.1. Transport of Keys from Server to Cryptographic + Module ................................................54 + A.1.2. Transport of Keys from Cryptographic Module to + Cryptographic Module ..................................54 + A.1.3. Transport of Keys from Cryptographic Module to + Server ................................................55 + A.1.4. Server-to-Server Bulk Import/Export of Keys ...........55 + A.2. Offline Use Cases .........................................55 + A.2.1. Server-to-Server Bulk Import/Export of Keys ...........55 + Appendix B. Requirements .........................................56 + + + + + + + + + + + + + + +Hoyer, et al. Standards Track [Page 3] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +1. Introduction + + With the increasing use of symmetric-key-based systems, such as + encryption of data at rest or systems used for strong authentication, + such as those based on One-Time Password (OTP) and Challenge/Response + (CR) mechanisms, there is a need for vendor interoperability and a + standard format for importing and exporting (provisioning) symmetric + keys. For instance, traditionally, vendors of authentication servers + and service providers have used proprietary formats for importing and + exporting these keys into their systems, thus making it hard to use + tokens from two different vendors. + + This document defines a standardized XML-based key container, called + Portable Symmetric Key Container (PSKC), for transporting symmetric + keys and key-related metadata. The document also specifies the + information elements that are required when the symmetric key is + utilized for specific purposes, such as the initial counter in the + HMAC-Based One-Time Password (HOTP) [HOTP] algorithm. It also + creates an IANA registry for algorithm profiles where algorithms, + their metadata and PSKC transmission profile can be recorded for a + centralized, standardized reference. + +1.1. Key Words + + 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]. + +1.2. Version Support + + There is a provision made in the syntax for an explicit version + number. Only version "1.0" is currently specified. + + The numbering scheme for PSKC versions is "<major>.<minor>". The + major and minor numbers MUST be treated as separate integers and each + number MAY be incremented higher than a single digit. Thus, "PSKC + 2.4" would be a lower version than "PSKC 2.13", which in turn would + be lower than "PSKC 12.3". Leading zeros (e.g., "PSKC 6.01") MUST be + ignored by recipients and MUST NOT be sent. + + The major version number should be incremented only if the message + format (e.g., element structure) has changed so dramatically that an + older version implementation would not be able to interoperate with a + newer version. The minor version number indicates new capabilities, + and it MUST be ignored by an entity with a smaller minor version + number but used for informational purposes by the entity with the + larger minor version number. + + + + +Hoyer, et al. Standards Track [Page 4] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +1.3. Namespace Identifiers + + This document uses Uniform Resource Identifiers (URIs) [RFC3986] to + identify resources, algorithms, and semantics. + +1.3.1. Defined Identifiers + + The XML namespace [XMLNS] URI for Version 1.0 of PSKC is: + + "urn:ietf:params:xml:ns:keyprov:pskc" + + References to qualified elements in the PSKC schema defined in this + specification and used in the example use the prefix "pskc" (defined + as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"). It is + RECOMMENDED to use this namespace in implementations. + +1.3.2. Referenced Identifiers + + The PSKC syntax presented in this document relies on algorithm + identifiers and elements defined in the XML Signature [XMLDSIG] + namespace: + + xmlns:ds="http://www.w3.org/2000/09/xmldsig#" + + References to the XML Signature namespace are represented by the + prefix "ds". + + PSKC also relies on algorithm identifiers and elements defined in the + XML Encryption [XMLENC] namespace: + + xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" + + References to the XML Encryption namespace are represented by the + prefix "xenc". + + When protecting keys in transport with passphrase-based keys, PSKC + also relies on the derived key element defined in the XML Encryption + Version 1.1 [XMLENC11] namespace: + + xmlns:xenc11="http://www.w3.org/2009/xmlenc11#" + + References to the XML Encryption Version 1.1 namespace are + represented by the prefix "xenc11". + + When protecting keys in transport with passphrase-based keys, PSKC + also relies on algorithm identifiers and elements defined in the PKCS + #5 [PKCS5] namespace: + + + + +Hoyer, et al. Standards Track [Page 5] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + xmlns:pkcs5= + "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" + + References to the PKCS #5 namespace are represented by the prefix + "pkcs5". + +2. Terminology + + NOTE: In subsequent sections of the document, we highlight + **mandatory** XML elements and attributes. Optional elements and + attributes are not explicitly indicated, i.e., if it does not say + mandatory, it is optional. + +3. Portable Key Container Entities Overview and Relationships + + The portable key container is based on an XML schema definition and + contains the following main conceptual entities: + + 1. KeyContainer entity - representing the container that carries a + number of KeyPackage entities. A valid container MUST carry at + least one KeyPackage entity. + + 2. KeyPackage entity - representing the package of at most one key + and its related provisioning endpoint or current usage endpoint, + such as a physical or virtual device and a specific CryptoModule. + + 3. DeviceInfo entity - representing the information about the device + and criteria to identify uniquely the device. + + 4. CryptoModuleInfo entity - representing the information about the + CryptoModule where the keys reside or to which they are + provisioned. + + 5. Key entity - representing the key transported or provisioned. + + 6. Data entity - representing a list of metadata related to the key, + where the element name is the name of the metadata and its + associated value is either in encrypted (for example, for <Data> + element <Secret>) or plaintext (for example, the <Data> element + <Counter>) form. + + Figure 1 shows the high-level structure of the PSKC data elements. + + + + + + + + + +Hoyer, et al. Standards Track [Page 6] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + ----------------- + | KeyContainer | + |---------------| + | EncryptionKey | + | Signature | + | ... | + ----------------- + | + | + /|\ 1..n + ---------------- ---------------- + | KeyPackage | 0..1| DeviceInfo | + |--------------|--------|--------------| + | |-- | SerialNumber | + ---------------- | | Manufacturer | + | | | .... | + | | ---------------- + /|\ 0..1 | + ---------------- | -------------------- + | Key | | 0..1| CryptoModuleInfo | + |--------------| -----|------------------| + | Id | | Id | + | Algorithm | |.... | + | UserId | -------------------- + | Policy | + | .... | + ---------------- + | + | + /|\ 0..n + --------------------------------------- - - + | | | + ------------------ ---------------- -------- - - + | Data:Secret | | Data:Counter | | Data:other + |----------------| |--------------| |-- - - + | EncryptedValue | | PlainValue | + | ValueMAC | ---------------- + ------------------ + + Figure 1: PSKC Data Elements Relationship Diagram + + The following sections describe in detail all the entities and + related XML schema elements and attributes. + + + + + + + + +Hoyer, et al. Standards Track [Page 7] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +4. <KeyContainer> Element: The Basics + + In its most basic form, a PSKC document uses the top-level element + <KeyContainer> and a single <KeyPackage> element to carry key + information. + + The following example shows a simple PSKC document. We will use it + to describe the structure of the <KeyContainer> element and its child + elements. + + <?xml version="1.0" encoding="UTF-8"?> + <KeyContainer Version="1.0" + Id="exampleID1" + xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> + <KeyPackage> + <Key Id="12345678" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer-A</Issuer> + <Data> + <Secret> + <PlainValue>MTIzNA== + </PlainValue> + </Secret> + </Data> + </Key> + </KeyPackage> + </KeyContainer> + + Figure 2: Basic PSKC Key Container Example + + The attributes of the <KeyContainer> element have the following + semantics: + + 'Version': The 'Version' attribute is used to identify the version + of the PSKC schema version. This specification defines the + initial version ("1.0") of the PSKC schema. This attribute MUST + be included. + + 'Id': The 'Id' attribute carries a unique identifier for the + container. As such, it helps to identify a specific key container + in cases in which multiple containers are embedded in larger XML + documents. + +4.1. <Key>: Embedding Keying Material and Key-Related Information + + The following attributes of the <Key> element MUST be included at a + minimum: + + + + +Hoyer, et al. Standards Track [Page 8] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + 'Id': This attribute carries a unique identifier for the symmetric + key in the context of key provisioning exchanges between two + parties. This means that if PSKC is used in multiple interactions + between a sending and receiving party, using different containers + referencing the same keys, the 'Id' attribute of <Key> MUST use + the same value (e.g., after initial provisioning, if a system + wants to update key metadata values in the other system, the value + of the 'Id' attribute of the <Key> where the metadata is to be + updated MUST be the same of the original 'Id' attribute value + provisioned). The identifier is defined as a string of + alphanumeric characters. + + 'Algorithm': This attribute contains a unique identifier for the + PSKC algorithm profile. This profile associates specific + semantics to the elements and attributes contained in the <Key> + element. This document describes profiles for open standards + algorithms in Section 10. Additional profiles are defined in the + following informative document: [PSKC-ALGORITHM-PROFILES]. + + The <Key> element has a number of optional child elements. An + initial set is described below: + + <Issuer>: This element represents the name of the party that issued + the key. For example, a bank "Foobar Bank, Inc." issuing hardware + tokens to their retail banking users may set this element to + 'Foobar Bank, Inc.'. + + <FriendlyName>: A human-readable name for the secret key for easier + reference. This element serves informational purposes only. This + element is a language-dependent string; hence, it SHOULD have an + attribute xml:lang="xx" where xx is the language identifier as + specified in [RFC5646]. If no xml:lang attribute is present, + implementations MUST assume the language to be English as defined + by setting the attribute value to 'en' (e.g., xml:lang="en"). + + <AlgorithmParameters>: This element carries parameters that + influence the result of the algorithmic computation, for example, + response truncation and format in OTP and CR algorithms. A more + detailed discussion of the element can be found in Section 4.3.4. + + <Data>: This element carries data about and related to the key. The + following child elements are defined for the <Data> element: + + <Secret>: This element carries the value of the key itself in a + binary representation. Please see Section 4.2 for more details + on Key Value Encoding. + + + + + +Hoyer, et al. Standards Track [Page 9] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <Counter>: This element contains the event counter for event- + based OTP algorithms. + + <Time>: This element contains the time for time-based OTP + algorithms. (If time intervals are used, this element carries + the number of time intervals passed from a specific start + point, normally it is algorithm dependent). + + <TimeInterval>: This element carries the time interval value for + time-based OTP algorithms in seconds (a typical value for this + would be 30, indicating a time interval of 30 seconds). + + <TimeDrift>: This element contains the device clock drift value + for time-based OTP algorithms. The integer value (positive or + negative drift) that indicates the number of time intervals + that a validation server has established the device clock + drifted after the last successful authentication. So, for + example, if the last successful authentication established a + device time value of 8 intervals from a specific start date but + the validation server determines the time value at 9 intervals, + the server SHOULD record the drift as -1. + + All the elements listed above (and those defined in the future) + obey a simple structure in that they MUST support child elements + to convey the data value in either plaintext or encrypted format: + + Plaintext: The <PlainValue> element carries a plaintext value + that is typed, for example, to xs:integer. + + Encrypted: The <EncryptedValue> element carries an encrypted + value. + + ValueMAC: The <ValueMAC> element is populated with a Message + Authentication Code (MAC) generated from the encrypted value in + case the encryption algorithm does not support integrity + checks. The example shown in Figure 2 illustrates the usage of + the <Data> element with two child elements, namely <Secret> and + <Counter>. Both elements carry a plaintext value within the + <PlainValue> child element. + +4.2. Key Value Encoding + + Two parties receiving the same key value OCTET STRING, resulting in + decoding the xs:base64Binary, inside the <PlainValue> or + <EncryptedValue> elements, must make use of the key in exactly the + same way in order to interoperate. To ensure that, it is necessary + to define a correspondence between the OCTET STRING and the notation + in the standard algorithm description that defines how the key is + + + +Hoyer, et al. Standards Track [Page 10] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + used. The next sections establish that correspondence for the AES + algorithm [FIPS197] and the Triple Data Encryption Algorithm (TDEA or + Triple DES) [SP800-67]. Unless otherwise specified for a specific + algorithm, the OCTET STRING encoding MUST follow the AES Key Value + Encoding. + +4.2.1. AES Key Value Encoding + + [FIPS197], Section 5.2, titled "Key Expansion", uses the input key as + an array of bytes indexed starting at 0. The first octet of the + OCTET STRING SHALL become the key byte in the AES, labeled index 0 in + [FIPS197]; the succeeding octets of the OCTET STRING SHALL become key + bytes in AES, in increasing index order. + + Proper parsing and key load of the contents of the OCTET STRING for + AES SHALL be determined by using the following value for the + <PlainValue> element (binaryBase64-encoded) to generate and match the + key expansion test vectors in [FIPS197], Appendix A, for AES + + Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c + + ... + <PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue> + ... + +4.2.2. Triple-DES Key Value Encoding + + A Triple-DES key consists of three keys for the cryptographic engine + (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8 + parity bits); the three keys are also collectively referred to as a + key bundle [SP800-67]. A key bundle may employ either two or three + independent keys. When only two independent keys are employed + (called two-key Triple DES), the same value is used for Key1 and + Key3. + + Each key in a Triple-DES key bundle is expanded into a key schedule + according to a procedure defined in [SP800-67], Appendix A. That + procedure numbers the bits in the key from 1 to 64, with number 1 + being the leftmost, or most significant bit (MSB). The first octet + of the OCTET STRING SHALL be bits 1 through 8 of Key1 with bit 1 + being the MSB. The second octet of the OCTET STRING SHALL be bits 9 + through 16 of Key1, and so forth, so that the trailing octet of the + OCTET STRING SHALL be bits 57 through 64 of Key3 (or Key2 for two-key + Triple DES). + + + + + + + +Hoyer, et al. Standards Track [Page 11] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + Proper parsing and key load of the contents of the OCTET STRING for + Triple DES SHALL be determined by using the following <PlainValue> + element (binaryBase64-encoded) to generate and match the key + expansion test vectors in [SP800-67], Appendix B, for the key bundle: + + Key1 = 0123456789ABCDEF + + Key2 = 23456789ABCDEF01 + + Key3 = 456789ABCDEF0123 + + ... + <PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue> + ... + +4.3. Transmission of Supplementary Information + + A PSKC document can contain a number of additional information + regarding device identification, cryptographic module identification, + user identification, and parameters for usage with OTP and CR + algorithms. The following example, see Figure 3, is used as a + reference for the subsequent sub-sections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hoyer, et al. Standards Track [Page 12] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <?xml version="1.0" encoding="UTF-8"?> + <KeyContainer Version="1.0" + Id="exampleID1" + xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> + <KeyPackage> + <DeviceInfo> + <Manufacturer>Manufacturer</Manufacturer> + <SerialNo>987654321</SerialNo> + <UserId>DC=example-bank,DC=net</UserId> + </DeviceInfo> + <CryptoModuleInfo> + <Id>CM_ID_001</Id> + </CryptoModuleInfo> + <Key Id="12345678" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="8" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= + </PlainValue> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + <UserId>UID=jsmith,DC=example-bank,DC=net</UserId> + </Key> + </KeyPackage> + </KeyContainer> + + Figure 3: PSKC Key Container Example with Supplementary Data + +4.3.1. <DeviceInfo> Element: Unique Device Identification + + The <DeviceInfo> element uniquely identifies the device to which the + <KeyPackage> is provisioned. Since devices can come in different + form factors, such as hardware tokens, smart-cards, soft tokens in a + mobile phone, or as a PC, this element allows different child element + combinations to be used. When combined, the values of the child + elements MUST uniquely identify the device. For example, for + hardware tokens, the combination of <SerialNo> and <Manufacturer> + elements uniquely identifies a device, but the <SerialNo> element + alone is insufficient since two different token manufacturers might + issue devices with the same serial number (similar to the Issuer + Distinguished Name and serial number of a certificate). + + + +Hoyer, et al. Standards Track [Page 13] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + The <DeviceInfo> element has the following child elements: + + <Manufacturer>: This element indicates the manufacturer of the + device. Values for the <Manufacturer> element MUST be taken from + either [OATHMAN] prefixes (i.e., the left column) or from the IANA + Private Enterprise Number Registry [IANAPENREG], using the + Organization 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.<Organization + value from [IANAPENREG]>"). + + <SerialNo>: This element contains the serial number of the device. + + <Model>: This element describes the model of the device (e.g., one- + button-HOTP-token-V1). + + <IssueNo>: This element contains the issue number in case there are + devices with the same serial number so that they can be + distinguished by different issue numbers. + + <DeviceBinding>: This element allows a provisioning server to ensure + 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 + request using a device identifier, e.g., an International Mobile + Equipment Identity (IMEI) for the phone, or an identifier for a + class of identifiers, e.g., those for which the keys are protected + by a Trusted Platform Module (TPM). + + <StartDate> and <ExpiryDate>: These two elements indicate the start + 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 + expressed as a dateTime value in "canonical representation" + [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely + on time resolution finer than milliseconds and MUST NOT generate + time instants that specify leap seconds. Keys that reside on the + device SHOULD only be used when the current date is after the + <StartDate> and before the <ExpiryDate>. Note that usage + enforcement of the keys with respect to the dates MAY only happen + on the validation server, as some devices such as smart 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 + <DeviceInfo> element MUST be included in order to uniquely identify a + device. This document does not enumerate the different device types + and therefore does not list the elements that are mandatory for each + type of device. + + + +Hoyer, et al. Standards Track [Page 14] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +4.3.2. <CryptoModuleInfo> Element: CryptoModule Identification + + The <CryptoModuleInfo> element identifies the cryptographic module to + which the symmetric keys are or have been provisioned. This allows + the identification of the specific cases where a device MAY contain + more than one crypto module (e.g., a PC hosting a TPM and a connected + token). + + The <CryptoModuleInfo> element has a single child element that MUST + be included: + + <Id>: This element carries a unique identifier for the CryptoModule + and is implementation specific. As such, it helps to identify a + specific CryptoModule to which the key is being or was + provisioned. + +4.3.3. <UserId> Element: User Identification + + The <UserId> element identifies the user of a distinguished name, as + defined in [RFC4514], for example, UID=jsmith,DC=example,DC=net. + + Although the syntax of the user identifier is defined, there are no + semantics associated with this element, i.e., there are no checks + enforcing that only a specific user can use this key. As such, this + element is for informational purposes only. + + This element may appear in two places, namely as a child element of + the <Key> element, where it indicates the user with whom the key is + associated, and as a child element of the <DeviceInfo> element, where + it indicates the user with whom the device is associated. + +4.3.4. <AlgorithmParameters> Element: Supplementary Information for OTP + and CR Algorithms + + The <AlgorithmParameters> element is a child element of the <Key> + element, and this document defines three child elements: <Suite>, + <ChallengeFormat>, and <ResponseFormat>. + + <Suite>: + + The optional <Suite> element defines additional characteristics of + the algorithm used, which are algorithm specific. For example, in + an HMAC-based (Hashed MAC) OTP algorithm, it could designate the + strength of the hash algorithm used (SHA1, SHA256, etc.). Please + refer to the algorithm profile section, Section 10, for the exact + semantics of the value for each algorithm profile. + + + + + +Hoyer, et al. Standards Track [Page 15] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <ChallengeFormat>: + + The <ChallengeFormat> element defines the characteristics of the + challenge in a CR usage scenario whereby the following attributes + are defined: + + 'Encoding': This attribute, which MUST be included, defines the + encoding of the challenge accepted by the device and MUST be + one of the following values: + + DECIMAL: Only numerical digits + + HEXADECIMAL: Hexadecimal response + + ALPHANUMERIC: All letters and numbers (case sensitive) + + BASE64: Base-64 encoded, as defined in Section 4 of [RFC4648] + + BINARY: Binary data + + 'CheckDigit': This attribute indicates whether a device needs to + check the appended Luhn check digit, as defined in + [ISOIEC7812], contained in a challenge. This is only valid if + the 'Encoding' attribute is set to 'DECIMAL'. A value of TRUE + indicates that the device will check the appended Luhn check + digit in a provided challenge. A value of FALSE indicates that + the device will not check the appended Luhn check digit in the + challenge. + + 'Min': This attribute defines the minimum size of the challenge + accepted by the device for CR mode and MUST be included. If + the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or + 'ALPHANUMERIC', this value indicates the minimum number of + digits/characters. If the 'Encoding' attribute is set to + 'BASE64' or 'BINARY', this value indicates the minimum number + of bytes of the unencoded value. + + 'Max': This attribute defines the maximum size of the challenge + accepted by the device for CR mode and MUST be included. If + the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or + 'ALPHANUMERIC', this value indicates the maximum number of + digits/characters. If the 'Encoding' attribute is set to + 'BASE64' or 'BINARY', this value indicates the maximum number + of bytes of the unencoded value. + + + + + + + +Hoyer, et al. Standards Track [Page 16] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <ResponseFormat>: + + The <ResponseFormat> element defines the characteristics of the + result of a computation and defines the format of the OTP or the + response to a challenge. For cases in which the key is a PIN + value, this element contains the format of the PIN itself (e.g., + DECIMAL, length 4 for a 4-digit PIN). The following attributes + are defined: + + 'Encoding': This attribute defines the encoding of the response + generated by the device, it MUST be included and MUST be one of + the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, + BASE64, or BINARY. + + 'CheckDigit': This attribute indicates whether the device needs + to append a Luhn check digit, as defined in [ISOIEC7812], to + the response. This is only valid if the 'Encoding' attribute + is set to 'DECIMAL'. If the value is TRUE, then the device + will append a Luhn check digit to the response. If the value + is FALSE, then the device will not append a Luhn check digit to + the response. + + 'Length': This attribute defines the length of the response + generated by the device and MUST be included. If the + 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or + ALPHANUMERIC, this value indicates the number of digits/ + characters. If the 'Encoding' attribute is set to 'BASE64' or + 'BINARY', this value indicates the number of bytes of the + unencoded value. + +4.4. Transmission of Key Derivation Values + + <KeyProfileId> element, which is a child element of the <Key> + element, carries a unique identifier used between the sending and + receiving parties to establish a set of key attribute values that are + not transmitted within the container but are agreed upon between the + two parties out of band. This element will then represent the unique + reference to a set of key attribute values. (For example, a smart + card application personalization profile id related to specific + attribute values present on a smart card application that have + influence when computing a response). + + For example, in the case of MasterCard's Chip Authentication Program + [CAP], the sending and the receiving party would agree that + KeyProfileId='1' represents a certain set of values (e.g., Internet + Authentication Flag (IAF) set to a specific value). During + transmission of the <KeyContainer>, these values would not be + transmitted as key attributes but would only be referred to via the + + + +Hoyer, et al. Standards Track [Page 17] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <KeyProfileId> element set to the specific agreed-upon profile (in + this case '1'). The receiving party can then associate all relevant + key attributes contained in the profile that was agreed upon out of + band with the imported keys. Often, this methodology is used between + a manufacturing service, run by company A, and the validation + service, run by company B, to avoid repeated transmission of the same + set of key attribute values. + + The <KeyReference> element contains a reference to an external key to + be used with a key derivation scheme. In this case, the parent <Key> + element will not contain the <Secret> subelement of <Data>, in which + the key value (secret) is transported; only the reference to the + external master key is transported (e.g., a PKCS #11 key label). + + <?xml version="1.0" encoding="UTF-8"?> + <KeyContainer Version="1.0" Id="exampleID1" + xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> + <KeyPackage> + <DeviceInfo> + <Manufacturer>Manufacturer</Manufacturer> + <SerialNo>987654321</SerialNo> + </DeviceInfo> + <CryptoModuleInfo> + <Id>CM_ID_001</Id> + </CryptoModuleInfo> + <Key Id="12345678" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="8" Encoding="DECIMAL"/> + </AlgorithmParameters> + <KeyProfileId>keyProfile1</KeyProfileId> + <KeyReference>MasterKeyLabel + </KeyReference> + <Data> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + <Policy> + <KeyUsage>OTP</KeyUsage> + </Policy> + </Key> + </KeyPackage> + </KeyContainer> + + Figure 4: Example of a PSKC Document Transmitting an HOTP Key via Key + Derivation Values + + + +Hoyer, et al. Standards Track [Page 18] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + The key value will be derived using the value of the <SerialNo> + element, values agreed upon between the sending and the receiving + parties and identified by the <KeyProfile> 'keyProfile1', and an + externally agreed-upon key referenced by the label 'MasterKeyLabel'. + +5. Key Policy + + This section illustrates the functionality of the <Policy> element + within PSKC, which allows a key usage and key PIN protection policy + to be attached to a specific key and its related metadata. This + element is a child element of the <Key> element. + + If the <Policy> element contains child elements or values within + elements/attributes that are not understood by the recipient of the + PSKC document, then the recipient MUST assume that key usage is not + permitted. This statement ensures that the lack of understanding of + certain extensions does not lead to unintended key usage. + + We will start our description with an example that expands the + example shown in Figure 3. + + <?xml version="1.0" encoding="UTF-8"?> + <KeyContainer + Version="1.0" Id="exampleID1" + xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> + <KeyPackage> + <DeviceInfo> + <Manufacturer>Manufacturer</Manufacturer> + <SerialNo>987654321</SerialNo> + </DeviceInfo> + <CryptoModuleInfo> + <Id>CM_ID_001</Id> + </CryptoModuleInfo> + <Key Id="12345678" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="8" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= + </PlainValue> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + + + + + +Hoyer, et al. Standards Track [Page 19] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + </Counter> + </Data> + <Policy> + <PINPolicy MinLength="4" MaxLength="4" + PINKeyId="123456781" PINEncoding="DECIMAL" + PINUsageMode="Local"/> + <KeyUsage>OTP</KeyUsage> + </Policy> + </Key> + </KeyPackage> + <KeyPackage> + <DeviceInfo> + <Manufacturer>Manufacturer</Manufacturer> + <SerialNo>987654321</SerialNo> + </DeviceInfo> + <CryptoModuleInfo> + <Id>CM_ID_001</Id> + </CryptoModuleInfo> + <Key Id="123456781" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:pin"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="4" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <PlainValue>MTIzNA==</PlainValue> + </Secret> + </Data> + </Key> + </KeyPackage> + </KeyContainer> + + Figure 5: Non-Encrypted HOTP Secret Key Protected by PIN + + This document defines the following <Policy> child elements: + + <StartDate> and <ExpiryDate>: These two elements denote the validity + period of a key. It MUST be ensured that the key is only used + between the start and the end date (inclusive). The date MUST be + expressed as a dateTime value in "canonical representation" + [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely + on time resolution finer than milliseconds and MUST NOT generate + time instants that specify leap seconds. When this element is + absent, the current time is assumed as the start time. + + + + + + +Hoyer, et al. Standards Track [Page 20] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <NumberOfTransactions>: The value in this element indicates the + maximum number of times a key carried within the PSKC document can + be used by an application after having received it. When this + element is omitted, there is no restriction regarding the number + of times a key can be used. + + <KeyUsage>: The <KeyUsage> element puts constraints on the intended + usage of the key. The recipient of the PSKC document MUST enforce + the key usage. Currently, the following tokens are registered by + this document: + + OTP: The key MUST only be used for OTP generation. + + CR: The key MUST only be used for Challenge/Response purposes. + + Encrypt: The key MUST only be used for data encryption purposes. + + Integrity: The key MUST only be used to generate a keyed message + digest for data integrity or authentication purposes. + + Verify: The key MUST only be used to verify a keyed message + digest for data integrity or authentication purposes (this is + the opposite key usage of 'Integrity'). + + Unlock: The key MUST only be used for an inverse Challenge/ + Response in the case where a user has locked the device by + entering a wrong PIN too many times (for devices with PIN-input + capability). + + Decrypt: The key MUST only be used for data decryption purposes. + + KeyWrap: The key MUST only be used for key wrap purposes. + + Unwrap: The key MUST only be used for key unwrap purposes. + + Derive: The key MUST only be used with a key derivation function + to derive a new key (see also Section 8.2.4 of [NIST800-57]). + + Generate: The key MUST only be used to generate a new key based + on a random number and the previous value of the key (see also + Section 8.1.5.2.1 of [NIST800-57]). + + The element MAY also be repeated to allow several key usages to be + expressed. When this element is absent, no key usage constraint + is assumed, i.e., the key MAY be utilized for every usage. + + + + + + +Hoyer, et al. Standards Track [Page 21] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <PINPolicy>: The <PINPolicy> element allows policy about the PIN + usage to be associated with the key. The following attributes are + specified: + + 'PINKeyId': This attribute carries the unique 'Id' attribute vale + of the <Key> element held within this <KeyContainer> that + contains the value of the PIN that protects the key. + + 'PINUsageMode': This mandatory attribute indicates the way the + PIN is used during the usage of the key. The following values + are defined: + + Local: This value indicates that the PIN is checked locally on + the device before allowing the key to be used in executing + the algorithm. + + Prepend: This value indicates that the PIN is prepended to the + algorithm response; hence, it MUST be checked by the party + validating the response. + + Append: This value indicates that the PIN is appended to the + algorithm response; hence, it MUST be checked by the party + validating the response. + + Algorithmic: This value indicates that the PIN is used as part + of the algorithm computation. + + 'MaxFailedAttempts': This attribute indicates the maximum number + of times the PIN may be entered wrongly before it MUST NOT be + possible to use the key anymore (typical reasonable values are + in the positive integer range of at least 2 and no more than + 10). + + 'MinLength': This attribute indicates the minimum length of a PIN + that can be set to protect the associated key. It MUST NOT be + possible to set a PIN shorter than this value. If the + 'PINFormat' attribute is set to 'DECIMAL', 'HEXADECIMAL', or + 'ALPHANUMERIC', this value indicates the number of digits/ + characters. If the 'PINFormat' attribute is set to 'BASE64' or + 'BINARY', this value indicates the number of bytes of the + unencoded value. + + 'MaxLength': This attribute indicates the maximum length of a PIN + that can be set to protect this key. It MUST NOT be possible + to set a PIN longer than this value. If the 'PINFormat' + attribute is set to 'DECIMAL', 'HEXADECIMAL', or + 'ALPHANUMERIC', this value indicates the number of digits/ + + + + +Hoyer, et al. Standards Track [Page 22] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + characters. If the 'PINFormat' attribute is set to 'BASE64' or + 'BINARY', this value indicates the number of bytes of the + unencoded value. + + 'PINEncoding': This attribute indicates the encoding of the PIN + and MUST be one of the values: DECIMAL, HEXADECIMAL, + ALPHANUMERIC, BASE64, or BINARY. + + If the 'PinUsageMode' attribute is set to 'Local', then the device + MUST enforce the restriction indicated in the 'MaxFailedAttempts', + 'MinLength', 'MaxLength', and 'PINEncoding' attributes; otherwise, + it MUST be enforced on the server side. + +5.1. PIN Algorithm Definition + + The PIN algorithm is defined as: + + boolean = comparePIN(K,P) + + Where: + + 'K' is the stored symmetric credential (PIN) in binary format. + + 'P' is the proposed PIN to be compared in binary format. + + The function comparePIN is a straight octet comparison of K and P. + Such a comparison MUST yield a value of TRUE (credentials matched) + when the octet length of K is the same as the octet length of P and + all octets comprising K are the same as the octets comprising P. + +6. Key Protection Methods + + With the functionality described in the previous sections, + information related to keys had to be transmitted in cleartext. With + the help of the <EncryptionKey> element, which is a child element of + the <KeyContainer> element, it is possible to encrypt keys and + associated information. The level of encryption is applied to the + value of individual elements and the applied encryption algorithm + MUST be the same for all encrypted elements. Keys are protected + using the following methods: pre-shared keys, passphrase-based keys, + and asymmetric keys. When encryption algorithms are used that make + use of Initialization Vectors (IVs), for example, AES-128-CBC, a + random IV value MUST be generated for each value to be encrypted and + it MUST be prepended to the resulting encrypted value as specified in + [XMLENC]. + + + + + + +Hoyer, et al. Standards Track [Page 23] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +6.1. Encryption Based on Pre-Shared Keys + + Figure 6 shows an example that illustrates the encryption of the + content of the <Secret> element using AES-128-CBC and PKCS #5 + Padding. The plaintext value of <Secret> is + '3132333435363738393031323334353637383930'. The name of the pre- + shared secret is "Pre-shared-key", as set in the <KeyName> element + (which is a child element of the <EncryptionKey> element). The value + of the encryption key used is '12345678901234567890123456789012'. + + The IV for the MAC key is '11223344556677889900112233445566', and the + IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'. + + As AES-128-CBC does not provide integrity checks, a keyed MAC is + applied to the encrypted value using a MAC key and a MAC algorithm as + declared in the <MACMethod> element (in our example, + "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the + algorithm and the value of the MAC key is randomly generated, in our + case '1122334455667788990011223344556677889900', and encrypted with + the above encryption key). The result of the keyed-MAC computation + is placed in the <ValueMAC> child element of <Secret>. + + <?xml version="1.0" encoding="UTF-8"?> + <KeyContainer Version="1.0" + xmlns="urn:ietf:params:xml:ns:keyprov:pskc" + xmlns:ds="http://www.w3.org/2000/09/xmldsig#" + xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> + <EncryptionKey> + <ds:KeyName>Pre-shared-key</ds:KeyName> + </EncryptionKey> + <MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"> + <MACKey> + <xenc:EncryptionMethod + Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> + <xenc:CipherData> + <xenc:CipherValue> + ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX + </xenc:CipherValue> + </xenc:CipherData> + </MACKey> + </MACMethod> + <KeyPackage> + <DeviceInfo> + <Manufacturer>Manufacturer</Manufacturer> + <SerialNo>987654321</SerialNo> + </DeviceInfo> + <CryptoModuleInfo> + + + + +Hoyer, et al. Standards Track [Page 24] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <Id>CM_ID_001</Id> + </CryptoModuleInfo> + <Key Id="12345678" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="8" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <EncryptedValue> + <xenc:EncryptionMethod + Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> + <xenc:CipherData> + <xenc:CipherValue> + AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv + </xenc:CipherValue> + </xenc:CipherData> + </EncryptedValue> + <ValueMAC>Su+NvtQfmvfJzF6bmQiJqoLRExc= + </ValueMAC> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + </Key> + </KeyPackage> + </KeyContainer> + + Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key with HMAC-SHA1 + + When protecting the payload with pre-shared keys, implementations + MUST set the name of the specific pre-shared key in the <KeyName> + element inside the <EncryptionKey> element. When the encryption + method uses a CBC mode that requires an explicit initialization + vector (IV), the IV MUST be passed by prepending it to the encrypted + value. + + For systems implementing PSKC, it is RECOMMENDED to support + AES-128-CBC (with the URI of + http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with the + URI of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that + KW-AES128 requires that the key to be protected must be a multiple of + 8 bytes in length. Hence, if keys of a different length have to be + protected, then the usage of the key-wrap algorithm with padding, as + described in [RFC5649] is RECOMMENDED. Some of the encryption + algorithms that can optionally be implemented are: + + + +Hoyer, et al. Standards Track [Page 25] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + Algorithm | Uniform Resource Locator (URL) + ---------------+------------------------------------------------------- + AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc + AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc + TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc + Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128 + Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192 + Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256 + KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128 + KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192 + KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256 + KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes + KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128 + KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192 + KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256 + +6.1.1. MAC Method + + When algorithms without integrity checks are used, such as AES-128- + CBC, a keyed-MAC value MUST be placed in the <ValueMAC> element of + the <Data> element. In this case, the MAC algorithm type MUST be set + in the <MACMethod> element of the <KeyContainer> element. The MAC + key MUST be a randomly generated key by the sender, be pre-agreed + upon between the receiver and the sender, or be set by the + application protocol that carries the PSKC document. It is + RECOMMENDED that the sender generate a random MAC key. When the + sender generates such a random MAC key, the MAC key material MUST be + encrypted with the same encryption key specified in <EncryptionKey> + element of the key container. The encryption method and encrypted + value MUST be set in the <EncryptionMethod> element and the + <CipherData> element, respectively, of the <MACKey> element in the + <MACMethod> element. The <MACKeyReference> element of the + <MACMethod> element MAY be used to indicate a pre-shared MAC key or a + provisioning protocol derived MAC key. For systems implementing + PSKC, it is RECOMMENDED to implement the HMAC-SHA1 (with the URI of + 'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC + algorithms that can optionally be implemented are: + + Algorithm | Uniform Resource Locator (URL) + ---------------+----------------------------------------------------- + HMAC-SHA224 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224 + HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 + HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 + HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 + + + + + + + +Hoyer, et al. Standards Track [Page 26] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +6.2. Encryption Based on Passphrase-Based Keys + + Figure 7 shows an example that illustrates the encryption of the + content of the <Secret> element using passphrase-based key derivation + (PBKDF2) to derive the encryption key as defined in [PKCS5]. When + using passphrase-based key derivation, the <DerivedKey> element + defined in XML Encryption Version 1.1 [XMLENC11] MUST be used to + specify the passphrased-based key. A <DerivedKey> element is set as + the child element of <EncryptionKey> element of the key container. + + The <DerivedKey> element is used to specify the key derivation + function and related parameters. The encryption algorithm, in this + example, AES-128-CBC (URI + 'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the + 'Algorithm' attribute of <EncryptionMethod> element used inside the + encrypted data elements. + + When PBKDF2 is used, the 'Algorithm' attribute of the <xenc11: + KeyDerivationMethod> element MUST be set to the URI + 'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The + <xenc11:KeyDerivationMethod> element MUST include the <PBKDF2-params> + child element to indicate the PBKDF2 parameters, such as salt and + iteration count. + + When the encryption method uses a CBC mode that uses an explicit + initialization vector (IV) other than a derived one, the IV MUST be + passed by prepending it to the encrypted value. + + In the example below, the following data is used. + + Password: qwerty + + Salt: 0x123eff3c4a72129c + + Iteration Count: 1000 + + MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581 + + OTP Secret: 12345678901234567890 + + The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41". + The initialization vector (IV) is + "0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to + encrypt the randomly chosen MAC key. A different IV can be used, say + "0xd864d39cbc0cdc8e1ee483b9164b9fa0", in the example. The encryption + with algorithm "AES-128-CBC" follows the specification defined in + [XMLENC]. + + + + +Hoyer, et al. Standards Track [Page 27] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <?xml version="1.0" encoding="UTF-8"?> + <pskc:KeyContainer + xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" + xmlns:xenc11="http://www.w3.org/2009/xmlenc11#" + xmlns:pkcs5= + "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" + xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0"> + <pskc:EncryptionKey> + <xenc11:DerivedKey> + <xenc11:KeyDerivationMethod + Algorithm= + "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2"> + <pkcs5:PBKDF2-params> + <Salt> + <Specified>Ej7/PEpyEpw=</Specified> + </Salt> + <IterationCount>1000</IterationCount> + <KeyLength>16</KeyLength> + <PRF/> + </pkcs5:PBKDF2-params> + </xenc11:KeyDerivationMethod> + <xenc:ReferenceList> + <xenc:DataReference URI="#ED"/> + </xenc:ReferenceList> + <xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName> + </xenc11:DerivedKey> + </pskc:EncryptionKey> + <pskc:MACMethod + Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"> + <pskc:MACKey> + <xenc:EncryptionMethod + Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> + <xenc:CipherData> + <xenc:CipherValue> + 2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx + </xenc:CipherValue> + </xenc:CipherData> + </pskc:MACKey> + </pskc:MACMethod> + <pskc:KeyPackage> + <pskc:DeviceInfo> + <pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer> + <pskc:SerialNo>987654321</pskc:SerialNo> + </pskc:DeviceInfo> + <pskc:CryptoModuleInfo> + <pskc:Id>CM_ID_001</pskc:Id> + </pskc:CryptoModuleInfo> + <pskc:Key Algorithm= + + + +Hoyer, et al. Standards Track [Page 28] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + "urn:ietf:params:xml:ns:keyprov:pskc:hotp" Id="123456"> + <pskc:Issuer>Example-Issuer</pskc:Issuer> + <pskc:AlgorithmParameters> + <pskc:ResponseFormat Length="8" Encoding="DECIMAL"/> + </pskc:AlgorithmParameters> + <pskc:Data> + <pskc:Secret> + <pskc:EncryptedValue Id="ED"> + <xenc:EncryptionMethod + Algorithm= + "http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> + <xenc:CipherData> + <xenc:CipherValue> + oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f + </xenc:CipherValue> + </xenc:CipherData> + </pskc:EncryptedValue> + <pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w= + </pskc:ValueMAC> + </pskc:Secret> + </pskc:Data> + </pskc:Key> + </pskc:KeyPackage> + </pskc:KeyContainer> + + Figure 7: Example of a PSKC Document Using Encryption Based on + Passphrase-Based Keys + +6.3. Encryption Based on Asymmetric Keys + + When using asymmetric keys to encrypt child elements of the <Data> + element, information about the certificate being used MUST be stated + in the <X509Data> element, which is a child element of the + <EncryptionKey> element. The encryption algorithm MUST be indicated + in the 'Algorithm' attribute of the <EncryptionMethod> element. In + the example shown in Figure 8, the algorithm is set to + 'http://www.w3.org/2001/04/xmlenc#rsa_1_5'. + + <?xml version="1.0" encoding="UTF-8" ?> + <KeyContainer + xmlns:ds="http://www.w3.org/2000/09/xmldsig#" + xmlns="urn:ietf:params:xml:ns:keyprov:pskc" + xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" + id="KC0001" + Version="1.0"> + <EncryptionKey> + <ds:X509Data> + + + + +Hoyer, et al. Standards Track [Page 29] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <ds:X509Certificate>MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4M + Q0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIF + Rlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVR + GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI + hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e + DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ + xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY + JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf + rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w + 4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo= + </ds:X509Certificate> + </ds:X509Data> + </EncryptionKey> + <KeyPackage> + <DeviceInfo> + <Manufacturer>TokenVendorAcme</Manufacturer> + <SerialNo>987654321</SerialNo> + </DeviceInfo> + <Key + Id="MBK000000001" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Example-Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="6" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <EncryptedValue> + <xenc:EncryptionMethod + Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/> + <xenc:CipherData> + <xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4 + xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6 + Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4= + </xenc:CipherValue> + </xenc:CipherData> + </EncryptedValue> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + </Key> + </KeyPackage> + </KeyContainer> + + Figure 8: Example of a PSKC Document Using Encryption Based on + Asymmetric Keys + + + +Hoyer, et al. Standards Track [Page 30] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + For systems implementing PSKC, it is RECOMMENDED to implement the + RSA-1.5 algorithm, identified by the URI + 'http://www.w3.org/2001/04/xmlenc#rsa-1_5'. + + Some of the asymmetric encryption algorithms that can optionally be + implemented are: + + Algorithm | Uniform Resource Locator (URL) + ------------------+------------------------------------------------- + RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p + +6.4. Padding of Encrypted Values for Non-Padded Encryption Algorithms + + Padding of encrypted values (for example, the key secret value) is + required when key protection algorithms are used that do not support + embedded padding and the value to be encrypted is not a multiple of + the encryption algorithm cipher block length. + + For example, when transmitting an HOTP key (20 bytes long) protected + with the AES algorithm in CBC mode (8-byte block cipher), padding is + required since its length is not a multiple of the 8-byte block + length. + + In these cases, for systems implementing PSKC, it is RECOMMENDED to + pad the value before encryption using PKCS #5 padding as described in + [PKCS5]. + +7. Digital Signature + + PSKC allows a digital signature to be added to the XML document, as a + child element of the <KeyContainer> element. The description of the + XML digital signature can be found in [XMLDSIG]. + + <?xml version="1.0" encoding="UTF-8"?> + <KeyContainer + xmlns="urn:ietf:params:xml:ns:keyprov:pskc" + xmlns:ds="http://www.w3.org/2000/09/xmldsig#" + xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" + Version="1.0"> + <KeyPackage> + <DeviceInfo> + <Manufacturer>TokenVendorAcme</Manufacturer> + <SerialNo>0755225266</SerialNo> + </DeviceInfo> + <Key Id="123" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Example-Issuer</Issuer> + <AlgorithmParameters> + + + +Hoyer, et al. Standards Track [Page 31] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <ResponseFormat Length="6" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <PlainValue> + MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= + </PlainValue> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + </Key> + </KeyPackage> + <Signature> + <ds:SignedInfo> + <ds:CanonicalizationMethod + Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> + <ds:SignatureMethod + Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> + <ds:Reference URI="#Device"> + <ds:DigestMethod + Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> + <ds:DigestValue> + j6lwx3rvEPO0vKtMup4NbeVu8nk= + </ds:DigestValue> + </ds:Reference> + </ds:SignedInfo> + <ds:SignatureValue> + j6lwx3rvEPO0vKtMup4NbeVu8nk= + </ds:SignatureValue> + <ds:KeyInfo> + <ds:X509Data> + <ds:X509IssuerSerial> + <ds:X509IssuerName> + CN=Example.com,C=US + </ds:X509IssuerName> + <ds:X509SerialNumber> + 12345678 + </ds:X509SerialNumber> + </ds:X509IssuerSerial> + </ds:X509Data> + </ds:KeyInfo> + </Signature> + </KeyContainer> + + Figure 9: Digital Signature Example + + + + +Hoyer, et al. Standards Track [Page 32] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +8. Bulk Provisioning + + The functionality of bulk provisioning can be accomplished by + repeating the <KeyPackage> element multiple times within the + <KeyContainer> element, indicating that multiple keys are provided to + different devices or cryptographic modules. The <EncryptionKey> + element then applies to all <KeyPackage> elements. When provisioning + multiple keys to the same device, the <KeyPackage> element is + repeated, but the enclosed <DeviceInfo> element will contain the same + sub-elements that uniquely identify the single device (for example, + the keys for the device identified by SerialNo='9999999' in the + example below). + + Figure 10 shows an example utilizing these capabilities. + + <?xml version="1.0" encoding="UTF-8"?> + <KeyContainer Version="1.0" + xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> + <KeyPackage> + <DeviceInfo> + <Manufacturer>TokenVendorAcme</Manufacturer> + <SerialNo>654321</SerialNo> + </DeviceInfo> + <Key Id="1" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="8" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <PlainValue> + MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= + </PlainValue> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + <Policy> + <StartDate>2006-05-01T00:00:00Z</StartDate> + <ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate> + </Policy> + </Key> + </KeyPackage> + + + + + + +Hoyer, et al. Standards Track [Page 33] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <KeyPackage> + <DeviceInfo> + <Manufacturer>TokenVendorAcme</Manufacturer> + <SerialNo>123456</SerialNo> + </DeviceInfo> + <Key Id="2" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="8" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <PlainValue> + MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= + </PlainValue> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + <Policy> + <StartDate>2006-05-01T00:00:00Z</StartDate> + <ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate> + </Policy> + </Key> + </KeyPackage> + <KeyPackage> + <DeviceInfo> + <Manufacturer>TokenVendorAcme</Manufacturer> + <SerialNo>9999999</SerialNo> + </DeviceInfo> + <Key Id="3" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="8" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <PlainValue> + MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= + </PlainValue> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + + + +Hoyer, et al. Standards Track [Page 34] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <Policy> + <StartDate>2006-03-01T00:00:00Z</StartDate> + <ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate> + </Policy> + </Key> + </KeyPackage> + <KeyPackage> + <DeviceInfo> + <Manufacturer>TokenVendorAcme</Manufacturer> + <SerialNo>9999999</SerialNo> + </DeviceInfo> + <Key Id="4" + Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> + <Issuer>Issuer</Issuer> + <AlgorithmParameters> + <ResponseFormat Length="8" Encoding="DECIMAL"/> + </AlgorithmParameters> + <Data> + <Secret> + <PlainValue> + MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= + </PlainValue> + </Secret> + <Counter> + <PlainValue>0</PlainValue> + </Counter> + </Data> + <Policy> + <StartDate>2006-04-01T00:00:00Z</StartDate> + <ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate> + </Policy> + </Key> + </KeyPackage> + </KeyContainer> + + Figure 10: Bulk Provisioning Example + +9. Extensibility + + This section lists a few common extension points provided by PSKC: + + New PSKC Version: Whenever it is necessary to define a new version + of this document, a new version number has to be allocated to + refer to the new specification. The version number is carried + inside the 'Version' attribute, as described in Section 4, the + numbering scheme MUST follow Section 1.2, and rules for + extensibility are defined in Section 12. + + + + +Hoyer, et al. Standards Track [Page 35] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + New XML Elements: The usage of the XML schema and the available + extension points allows new XML elements to be added. Depending + on the type of XML element, different ways for extensibility are + offered. In some places, the <Extensions> element can be used and + elsewhere the "<xs:any namespace="##other" processContents="lax" + minOccurs="0" maxOccurs="unbounded"/>" XML extension point is + utilized. + + New XML Attributes: The XML schema allows new XML attributes to be + added where XML extension points have been defined (see "<xs: + anyAttribute namespace="##other"/>" in Section 11). + + New PSKC Algorithm Profiles: This document defines two PSKC + algorithm profiles, see Section 10. The following informational + document describes additional profiles [PSKC-ALGORITHM-PROFILES]. + Further PSKC algorithm profiles can be registered as described in + Section 12.4. + + Algorithm URIs: Section 6 defines how keys and related data can be + protected. A number of algorithms can be used. New algorithms + can be used by pointing to a new algorithm URI. + + Policy: Section 5 defines policies that can be attached to a key and + keying-related data. The <Policy> element is one such item that + allows implementers to restrict the use of the key to certain + functions, such as "OTP usage only". Further values may be + registered as described in Section 12. + +10. PSKC Algorithm Profile + +10.1. HOTP + + Common Name: HOTP + + Class: OTP + + URI: urn:ietf:params:xml:ns:keyprov:pskc:hotp + + Algorithm Definition: [HOTP] + + Identifier Definition: (this RFC) + + Registrant Contact: IESG + + Deprecated: FALSE + + + + + + +Hoyer, et al. Standards Track [Page 36] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + Profiling: + + The <KeyPackage> element MUST be present and the + <ResponseFormat> element, which is a child element of the + <AlgorithmParameters> element, MUST be used to indicate the OTP + length and the value format. + + The <Counter> element (see Section 4.1) MUST be provided as + metadata for the key. + + The following additional constraints apply: + + + The value of the <Secret> element MUST contain key material + with a length of at least 16 octets (128 bits), if it is + present. + + + The <ResponseFormat> element MUST have the 'Format' + attribute set to "DECIMAL", and the 'Length' attribute MUST + indicate a length value between 6 and 9 (inclusive). + + + The <PINPolicy> element MAY be present, but the + 'PINUsageMode' attribute cannot be set to "Algorithmic". + + An example can be found in Figure 3. + +10.2. PIN + + Common Name: PIN + + Class: Symmetric static credential comparison + + URI: urn:ietf:params:xml:ns:keyprov:pskc:pin + + Algorithm Definition: (this RFC) Section 5.1 + + Identifier Definition (this RFC) + + Registrant Contact: IESG + + Deprecated: FALSE + + Profiling: + + The <Usage> element MAY be present, but no attribute of the + <Usage> element is required. The <ResponseFormat> element MAY + be used to indicate the PIN value format. + + + + + +Hoyer, et al. Standards Track [Page 37] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + The <Secret> element (see Section 4.1) MUST be provided. + + See the example in Figure 5 + +11. XML Schema + + This section defines the XML schema for PSKC. + +<?xml version="1.0" encoding="UTF-8"?> +<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" + xmlns:ds="http://www.w3.org/2000/09/xmldsig#" + xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" + targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" + schemaLocation= +"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ + xmldsig-core-schema.xsd"/> + <xs:import namespace="http://www.w3.org/2001/04/xmlenc#" + schemaLocation= +"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/> + <xs:import namespace="http://www.w3.org/XML/1998/namespace"/> + <xs:complexType name="KeyContainerType"> + <xs:sequence> + <xs:element name="EncryptionKey" + type="ds:KeyInfoType" minOccurs="0"/> + <xs:element name="MACMethod" + type="pskc:MACMethodType" minOccurs="0"/> + <xs:element name="KeyPackage" + type="pskc:KeyPackageType" maxOccurs="unbounded"/> + <xs:element name="Signature" + type="ds:SignatureType" minOccurs="0"/> + <xs:element name="Extensions" + type="pskc:ExtensionsType" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + <xs:attribute name="Version" + type="pskc:VersionType" use="required"/> + <xs:attribute name="Id" + type="xs:ID" use="optional"/> + </xs:complexType> + <xs:simpleType name="VersionType" final="restriction"> + <xs:restriction base="xs:string"> + <xs:pattern value="\d{1,2}\.\d{1,3}"/> + </xs:restriction> + + + + +Hoyer, et al. Standards Track [Page 38] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + </xs:simpleType> + <xs:complexType name="KeyType"> + <xs:sequence> + <xs:element name="Issuer" + type="xs:string" minOccurs="0"/> + <xs:element name="AlgorithmParameters" + type="pskc:AlgorithmParametersType" + minOccurs="0"/> + <xs:element name="KeyProfileId" + type="xs:string" minOccurs="0"/> + <xs:element name="KeyReference" + type="xs:string" minOccurs="0"/> + <xs:element name="FriendlyName" + type="xs:string" minOccurs="0"/> + <xs:element name="Data" + type="pskc:KeyDataType" minOccurs="0"/> + <xs:element name="UserId" + type="xs:string" minOccurs="0"/> + <xs:element name="Policy" + type="pskc:PolicyType" minOccurs="0"/> + <xs:element name="Extensions" + type="pskc:ExtensionsType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + <xs:attribute name="Id" + type="xs:string" use="required"/> + <xs:attribute name="Algorithm" + type="pskc:KeyAlgorithmType" use="optional"/> + </xs:complexType> + <xs:complexType name="PolicyType"> + <xs:sequence> + <xs:element name="StartDate" + type="xs:dateTime" minOccurs="0"/> + <xs:element name="ExpiryDate" + type="xs:dateTime" minOccurs="0"/> + <xs:element name="PINPolicy" + type="pskc:PINPolicyType" minOccurs="0"/> + <xs:element name="KeyUsage" + type="pskc:KeyUsageType" + minOccurs="0" maxOccurs="unbounded"/> + <xs:element name="NumberOfTransactions" + type="xs:nonNegativeInteger" minOccurs="0"/> + <xs:any namespace="##other" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + <xs:complexType name="KeyDataType"> + <xs:sequence> + + + +Hoyer, et al. Standards Track [Page 39] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <xs:element name="Secret" + type="pskc:binaryDataType" minOccurs="0"/> + <xs:element name="Counter" + type="pskc:longDataType" minOccurs="0"/> + <xs:element name="Time" + type="pskc:intDataType" minOccurs="0"/> + <xs:element name="TimeInterval" + type="pskc:intDataType" minOccurs="0"/> + <xs:element name="TimeDrift" + type="pskc:intDataType" minOccurs="0"/> + <xs:any namespace="##other" + processContents="lax" + minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + <xs:complexType name="binaryDataType"> + <xs:sequence> + <xs:choice> + <xs:element name="PlainValue" + type="xs:base64Binary"/> + <xs:element name="EncryptedValue" + type="xenc:EncryptedDataType"/> + </xs:choice> + <xs:element name="ValueMAC" + type="xs:base64Binary" minOccurs="0"/> + </xs:sequence> + </xs:complexType> + <xs:complexType name="intDataType"> + <xs:sequence> + <xs:choice> + <xs:element name="PlainValue" type="xs:int"/> + <xs:element name="EncryptedValue" + type="xenc:EncryptedDataType"/> + </xs:choice> + <xs:element name="ValueMAC" + type="xs:base64Binary" minOccurs="0"/> + </xs:sequence> + </xs:complexType> + <xs:complexType name="stringDataType"> + <xs:sequence> + <xs:choice> + <xs:element name="PlainValue" type="xs:string"/> + <xs:element name="EncryptedValue" + type="xenc:EncryptedDataType"/> + </xs:choice> + <xs:element name="ValueMAC" + type="xs:base64Binary" minOccurs="0"/> + </xs:sequence> + + + +Hoyer, et al. Standards Track [Page 40] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + </xs:complexType> + <xs:complexType name="longDataType"> + <xs:sequence> + <xs:choice> + <xs:element name="PlainValue" type="xs:long"/> + <xs:element name="EncryptedValue" + type="xenc:EncryptedDataType"/> + </xs:choice> + <xs:element name="ValueMAC" + type="xs:base64Binary" minOccurs="0"/> + </xs:sequence> + </xs:complexType> + <xs:complexType name="PINPolicyType"> + <xs:attribute name="PINKeyId" + type="xs:string" use="optional"/> + <xs:attribute name="PINUsageMode" + type="pskc:PINUsageModeType"/> + <xs:attribute name="MaxFailedAttempts" + type="xs:unsignedInt" use="optional"/> + <xs:attribute name="MinLength" + type="xs:unsignedInt" use="optional"/> + <xs:attribute name="MaxLength" + type="xs:unsignedInt" use="optional"/> + <xs:attribute name="PINEncoding" + type="pskc:ValueFormatType" use="optional"/> + <xs:anyAttribute namespace="##other"/> + </xs:complexType> + <xs:simpleType name="PINUsageModeType"> + <xs:restriction base="xs:string"> + <xs:enumeration value="Local"/> + <xs:enumeration value="Prepend"/> + <xs:enumeration value="Append"/> + <xs:enumeration value="Algorithmic"/> + </xs:restriction> + </xs:simpleType> + <xs:simpleType name="KeyUsageType"> + <xs:restriction base="xs:string"> + <xs:enumeration value="OTP"/> + <xs:enumeration value="CR"/> + <xs:enumeration value="Encrypt"/> + <xs:enumeration value="Integrity"/> + <xs:enumeration value="Verify"/> + <xs:enumeration value="Unlock"/> + <xs:enumeration value="Decrypt"/> + <xs:enumeration value="KeyWrap"/> + <xs:enumeration value="Unwrap"/> + <xs:enumeration value="Derive"/> + <xs:enumeration value="Generate"/> + + + +Hoyer, et al. Standards Track [Page 41] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + </xs:restriction> + </xs:simpleType> + <xs:complexType name="DeviceInfoType"> + <xs:sequence> + <xs:element name="Manufacturer" + type="xs:string" minOccurs="0"/> + <xs:element name="SerialNo" + type="xs:string" minOccurs="0"/> + <xs:element name="Model" + type="xs:string" minOccurs="0"/> + <xs:element name="IssueNo" + type="xs:string" minOccurs="0"/> + <xs:element name="DeviceBinding" + type="xs:string" minOccurs="0"/> + <xs:element name="StartDate" + type="xs:dateTime" minOccurs="0"/> + <xs:element name="ExpiryDate" + type="xs:dateTime" minOccurs="0"/> + <xs:element name="UserId" + type="xs:string" minOccurs="0"/> + <xs:element name="Extensions" + type="pskc:ExtensionsType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + <xs:complexType name="CryptoModuleInfoType"> + <xs:sequence> + <xs:element name="Id" type="xs:string"/> + <xs:element name="Extensions" + type="pskc:ExtensionsType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + <xs:complexType name="KeyPackageType"> + <xs:sequence> + <xs:element name="DeviceInfo" + type="pskc:DeviceInfoType" minOccurs="0"/> + <xs:element name="CryptoModuleInfo" + type="pskc:CryptoModuleInfoType" minOccurs="0"/> + <xs:element name="Key" + type="pskc:KeyType" minOccurs="0"/> + <xs:element name="Extensions" + type="pskc:ExtensionsType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + <xs:complexType name="AlgorithmParametersType"> + <xs:choice> + + + +Hoyer, et al. Standards Track [Page 42] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + <xs:element name="Suite" type="xs:string" minOccurs="0"/> + <xs:element name="ChallengeFormat" minOccurs="0"> + <xs:complexType> + <xs:attribute name="Encoding" + type="pskc:ValueFormatType" + use="required"/> + <xs:attribute name="Min" + type="xs:unsignedInt" use="required"/> + <xs:attribute name="Max" + type="xs:unsignedInt" use="required"/> + <xs:attribute name="CheckDigits" + type="xs:boolean" default="false"/> + </xs:complexType> + </xs:element> + <xs:element name="ResponseFormat" minOccurs="0"> + <xs:complexType> + <xs:attribute name="Encoding" + type="pskc:ValueFormatType" + use="required"/> + <xs:attribute name="Length" + type="xs:unsignedInt" use="required"/> + <xs:attribute name="CheckDigits" + type="xs:boolean" default="false"/> + </xs:complexType> + </xs:element> + <xs:element name="Extensions" + type="pskc:ExtensionsType" minOccurs="0" + maxOccurs="unbounded"/> + </xs:choice> + </xs:complexType> + <xs:complexType name="ExtensionsType"> + <xs:sequence> + <xs:any namespace="##other" + processContents="lax" maxOccurs="unbounded"/> + </xs:sequence> + <xs:attribute name="definition" + type="xs:anyURI" use="optional"/> + </xs:complexType> + <xs:simpleType name="KeyAlgorithmType"> + <xs:restriction base="xs:anyURI"/> + </xs:simpleType> + <xs:simpleType name="ValueFormatType"> + <xs:restriction base="xs:string"> + <xs:enumeration value="DECIMAL"/> + <xs:enumeration value="HEXADECIMAL"/> + <xs:enumeration value="ALPHANUMERIC"/> + <xs:enumeration value="BASE64"/> + <xs:enumeration value="BINARY"/> + + + +Hoyer, et al. Standards Track [Page 43] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + </xs:restriction> + </xs:simpleType> + <xs:complexType name="MACMethodType"> + <xs:sequence> + <xs:choice> + <xs:element name="MACKey" + type="xenc:EncryptedDataType" minOccurs="0"/> + <xs:element name="MACKeyReference" + type="xs:string" minOccurs="0"/> + </xs:choice> + <xs:any namespace="##other" + processContents="lax" minOccurs="0" maxOccurs="unbounded"/> + </xs:sequence> + <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> + </xs:complexType> + <xs:element name="KeyContainer" + type="pskc:KeyContainerType"/> +</xs:schema> + +12. IANA Considerations + +12.1. Content-Type Registration for 'application/pskc+xml' + + This specification contains the registration of a new media type + according to the procedures of RFC 4288 [RFC4288] and guidelines in + RFC 3023 [RFC3023]. + + MIME media type name: application + + MIME subtype name: pskc+xml + + Required parameters: There is no required parameter. + + Optional parameters: charset + + Indicates the character encoding of enclosed XML. + + Encoding considerations: Uses XML, which can employ 8-bit + characters, depending on the character encoding used. See RFC + 3023 [RFC3023], Section 3.2. + + Security considerations: Please refer to Section 13 of RFC 6030. + + Interoperability considerations: None + + + + + + + +Hoyer, et al. Standards Track [Page 44] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + Published specification: RFC 6030. + + Applications which use this media type: This media type is being + used as a symmetric key container format for transport and + provisioning of symmetric keys (One-Time Password (OTP) shared + secrets or symmetric cryptographic keys) to different types of + strong authentication devices. As such, it is used for key + provisioning systems. + + Additional information: + + Magic Number: None + + File Extension: .pskcxml + + Macintosh file type code: 'TEXT' + + Personal and email address to contact for further information: + Philip Hoyer, Philip.Hoyer@actividentity.com + + Intended usage: LIMITED USE + + Restrictions on usage: None + + Author: This specification is a work item of the IETF KEYPROV + working group, with mailing list address <keyprov@ietf.org>. + + Change controller: The IESG <iesg@ietf.org> + +12.2. XML Schema Registration + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:keyprov:pskc + + Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer + (Philip.Hoyer@actividentity.com). + + XML Schema: The XML schema to be registered is contained in + Section 11. Its first line is + + <?xml version="1.0" encoding="UTF-8"?> + + and its last line is + + </xs:schema> + + + + +Hoyer, et al. Standards Track [Page 45] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +12.3. URN Sub-Namespace Registration + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:keyprov:pskc + + Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer + (Philip.Hoyer@actividentity.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>PSKC Namespace</title> + </head> + <body> + <h1>Namespace for PSKC</h1> + <h2>urn:ietf:params:xml:ns:keyprov:pskc</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc6030.txt"> + RFC 6030</a>.</p> + </body> + </html> + END + +12.4. PSKC Algorithm Profile Registry + + IANA has created a registry for PSKC algorithm profiles in accordance + with the principles set out in RFC 5226 [RFC5226]. + + As part of this registry, IANA maintains the following information: + + Common Name: The name by which the PSKC algorithm profile is + generally referred. + + Class: The type of PSKC algorithm profile registry entry being + created, such as encryption, Message Authentication Code (MAC), + One-Time Password (OTP), Digest. + + + + + + +Hoyer, et al. Standards Track [Page 46] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + URI: The URI to be used to identify the profile. + + Identifier Definition: IANA will add a pointer to the specification + containing information about the PSKC algorithm profile + registration. + + Algorithm Definition: A reference to the stable document in which + the algorithm being used with the PSKC is defined. + + Registrant Contact: Contact information about the party submitting + the registration request. + + Deprecated: TRUE if this entry has been deprecated based on expert + approval and SHOULD not be used in any new implementations. + Otherwise, FALSE. + + PSKC Profiling: Information about PSKC XML elements and attributes + being used (or not) with this specific profile of PSKC. + + PSKC algorithm profile identifier registrations are to be subject to + Specification Required as per RFC 5226 [RFC5226]. Updates can be + provided based on expert approval only. Based on expert approval, it + is possible to mark entries as "deprecated". A designated expert + will be appointed by the IESG. + + IANA has added two initial values to the registry based on the + algorithm profiles described in Section 10. + +12.5. PSKC Version Registry + + IANA has created a registry for PSKC version numbers. The registry + has the following structure: + + PSKC Version | Specification + +---------------------------+---------------- + | 1.0 | RFC 6030 + + Standards action is required to define new versions of PSKC. It is + not envisioned to deprecate, delete, or modify existing PSKC + versions. + +12.6. Key Usage Registry + + IANA has created a registry for key usage. A description of the + <KeyUsage> element can be found in Section 5. + + + + + + +Hoyer, et al. Standards Track [Page 47] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + As part of this registry IANA will maintain the following + information: + + Key Usage: The identifier of the Key Usage. + + Specification: IANA will add a pointer to the specification + containing information about the semantics of a new Key Usage + registration. + + Deprecated: TRUE if this entry has been deprecated based on expert + approval and SHOULD not be used in any new implementations. + Otherwise, FALSE. + + IANA has added these initial values to the registry: + + Key Usage | Specification | Deprecated + +---------------+------------------------------+----------- + | OTP | [Section 5 of this document] | FALSE + | CR | [Section 5 of this document] | FALSE + | Encrypt | [Section 5 of this document] | FALSE + | Integrity | [Section 5 of this document] | FALSE + | Verify | [Section 5 of this document] | FALSE + | Unlock | [Section 5 of this document] | FALSE + | Decrypt | [Section 5 of this document] | FALSE + | KeyWrap | [Section 5 of this document] | FALSE + | Unwrap | [Section 5 of this document] | FALSE + | Derive | [Section 5 of this document] | FALSE + | Generate | [Section 5 of this document] | FALSE + +---------------+------------------------------+----------- + + Key Usage Registry registrations are to be subject to Specification + Required as per RFC 5226 [RFC5226]. Expert Review is required to + define new Key Usage values. Updates can be provided based on expert + approval only. Based on expert approval, it is possible to mark + entries as "deprecated". A designated expert will be appointed by + the IESG. + +13. Security Considerations + + The portable symmetric key container (PSKC) carries sensitive + information (e.g., cryptographic keys) and may be transported across + the boundaries of one secure perimeter to another. For example, a + container residing within the secure perimeter of a back-end + provisioning server in a secure room may be transported across the + Internet to an end-user device attached to a personal computer. This + means that special care MUST be taken to ensure the confidentiality, + integrity, and authenticity of the information contained within. + + + + +Hoyer, et al. Standards Track [Page 48] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +13.1. PSKC Confidentiality + + By design, the container allows two main approaches to guaranteeing + the confidentiality of the information it contains while transported. + + First, the container key data payload may be encrypted. + + In this case, no transport layer security is required. However, + standard security best practices apply when selecting the strength of + the cryptographic algorithm for key data payload encryption. A + symmetric cryptographic cipher SHOULD be used -- the longer the + cryptographic key, the stronger the protection. Please see + Section 6.1 for recommendations of key data payload protection using + symmetric cryptographic ciphers. In cases where the exchange of key + encryption keys between the sender and the receiver is not possible, + asymmetric encryption of the key data payload may be employed, see + Section 6.3. Similar to symmetric key cryptography, the stronger the + asymmetric key, the more secure the protection. + + If the key data payload is encrypted with a method that uses one of + the password-based encryption methods (PBE methods) detailed in + Section 6.2, the key data payload may be subjected to password + dictionary attacks to break the encryption password and recover the + information. Standard security best practices for selection of + strong encryption passwords apply. + + Additionally, it is strongly RECOMMENDED that practical + implementations use PBESalt and PBEIterationCount when PBE encryption + is used. A different PBESalt value per PSKC SHOULD be used for best + protection. + + The second approach to protecting the confidentiality of the key data + is based on using lower-layer security mechanisms (e.g., [TLS], + [IPsec]). The secure connection established between the source + secure perimeter (the provisioning server from the example above) and + the target perimeter (the device attached to the end-user computer) + utilizes encryption to protect the messages that travel across that + connection. No key data payload encryption is required in this mode. + Secure connections that encrypt and digest each message provide an + extra measure of security. + + Because of the fact that the plaintext PSKC is protected only by the + transport layer security, practical implementation MUST ensure + protection against man-in-the-middle attacks. Authenticating the + secure channel endpoints is critically important for eliminating + intruders that may compromise the confidentiality of the PSKC. + + + + + +Hoyer, et al. Standards Track [Page 49] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +13.2. PSKC Integrity + + The PSKC provides means to guarantee the integrity of the information + it contains through the use of digital signatures. It is RECOMMENDED + that for best security practices, the digital signature of the + container encompasses the entire PSKC. This provides assurances for + the integrity of all attributes. It also allows verification of the + integrity of a given PSKC even after the container is delivered + through the communication channel to the target perimeter and channel + message integrity check is no longer possible. + +13.3. PSKC Authenticity + + The digital signature of the PSKC is the primary way of showing its + authenticity. The recipient of the container SHOULD use the public + key associated with the signature to assert the authenticity of the + sender by tracing it back to a pre-loaded public key or certificate. + Note that the digital signature of the PSKC can be checked even after + the container has been delivered through the secure channel of + communication. + + Authenticity guarantee may be provided by [TLS] or [IPsec]. However, + no authenticity verification is possible once the container is + delivered at the recipient end. Since the TLS endpoints could differ + from the key provisioning endpoints, this solution is weaker than the + previous solution that relies on a digital signature of the PSKC. + +14. Contributors + + We would like Hannes Tschofenig for his text contributions to this + document. + +15. Acknowledgements + + The authors of this document would like to thank the following people + for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson, + Siddhart Bajaj, Stu Vaeth, Kevin Lewis, Philip Hallam-Baker, Andrea + Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner, and + especially Robert Philpott. + + We would like to thank Sean Turner for his review in January 2009. + We would also like to thank Anders Rundgren for triggering the + discussion regarding to the selection of encryption algorithms + (KW-AES-128 vs. AES-128-CBC) and his input on the keyed message + digest computation. + + + + + + +Hoyer, et al. Standards Track [Page 50] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + This work is based on earlier work by the members of OATH (Initiative + for Open AuTHentication), see [OATH], to specify a format that can be + freely distributed to the technical community. + +16. References + +16.1. Normative References + + [FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced + Encryption Standard (AES)", November 2001. + + [HOTP] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and + O. Ranen, "HOTP: An HMAC-Based One-Time Password + Algorithm", RFC 4226, December 2005. + + [IANAPENREG] + IANA, "Private Enterprise Numbers", <http://www.iana.org>. + + [ISOIEC7812] + ISO, "ISO/IEC 7812-1:2006 Identification cards -- + Identification of issuers -- Part 1: Numbering system", + October 2006, <http://www.iso.org/iso/iso_catalogue/ + catalogue_tc/catalogue_detail.htm?csnumber=39698>. + + [OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", + April 2009, + <http://www.openauthentication.org/oath-id/prefixes/>. + + [PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography + Standard", Version 2.0, March 1999, + <http://www.rsasecurity.com/rsalabs/pkcs/>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media + Types", RFC 3023, January 2001. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and + Registration Procedures", BCP 13, RFC 4288, December 2005. + + [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): String Representation of Distinguished Names", + RFC 4514, June 2006. + + + + +Hoyer, et al. Standards Track [Page 51] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + + [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying + Languages", BCP 47, RFC 5646, September 2009. + + [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard + (AES) Key Wrap with Padding Algorithm", RFC 5649, + September 2009. + + [SP800-67] + National Institute of Standards, "NIST Special Publication + 800-67 Version 1.1: Recommendation for the Triple Data + Encryption Algorithm (TDEA) Block Cipher", NIST Special + 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] Solo, D., Reagle, J., and D. Eastlake, "XML-Signature + Syntax and Processing", World Wide Web Consortium + FirstEdition REC-xmldsig-core-20020212, February 2002, + <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>. + + [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", + W3C Recommendation, December 2002, + <http://www.w3.org/TR/xmlenc-core/>. + + [XMLENC11] + Reagle, J. and D. Eastlake, "XML Encryption Syntax and + Processing Version 1.1", World Wide Web Consortium WD WD- + xmlenc-core1-20090730, July 2009, + <http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730>. + +16.2. Informative References + + [CAP] MasterCard International, "Chip Authentication Program + Functional Architecture", September 2004. + + [IPsec] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + + + + + + +Hoyer, et al. Standards Track [Page 52] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + [NIST800-57] + Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, + "NIST Special Publication 800-57, Recommendation for Key + Management Part 1: General (Revised)", NIST Special + Publication 800-57, March 2007. + + [OATH] "Initiative for Open AuTHentication", + <http://www.openauthentication.org>. + + [PSKC-ALGORITHM-PROFILES] + Hoyer, P., Pei, M., Machani, S., and A. Doherty, + "Additional Portable Symmetric Key Container (PSKC) + Algorithm Profiles", Work in Progress, May 2010. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in + XML", World Wide Web Consortium FirstEdition REC-xml- + names-19990114, January 1999, + <http://www.w3.org/TR/1999/REC-xml-names-19990114>. + + + + + + + + + + + + + + + + + + + + + + +Hoyer, et al. Standards Track [Page 53] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +Appendix A. 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. + +A.1. Online Use Cases + + This section describes the use cases related to provisioning the keys + using an online provisioning protocol. + +A.1.1. Transport of Keys from Server to Cryptographic Module + + For example, a mobile device user wants to obtain a symmetric key for + use with a cryptographic module on the device. The cryptographic + module from vendor A initiates the provisioning process against a + provisioning system from vendor B using a standards-based + provisioning protocol. The provisioning entity delivers one or more + keys in a standard format that can be processed by the mobile device. + + For example, in a variation of the above, instead of the user's + mobile phone, a key is provisioned in the user's soft token + application on a laptop using a network-based online protocol. As + before, the provisioning system delivers a key in a standard format + that can be processed by the soft token on the PC. + + For example, the end user or the key issuer wants to update or + configure an existing key in the cryptographic module and requests a + replacement key container. The container may or may not include a + new key and may include new or updated key attributes such as a new + counter value in HOTP key case, a modified response format or length, + a new friendly name, etc. + +A.1.2. Transport of Keys from Cryptographic Module to Cryptographic + Module + + For example, a user wants to transport a key from one cryptographic + module to another. There may be two cryptographic modules, one on a + computer and one on a mobile phone, and the user wants to transport a + key from the computer to the mobile phone. The user can export the + key and related data in a standard format for input into the other + cryptographic module. + + + + + +Hoyer, et al. Standards Track [Page 54] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +A.1.3. Transport of Keys from Cryptographic Module to Server + + For example, a user wants to activate and use a new key and related + data against a validation system that is not aware of this key. This + key may be embedded in the cryptographic module (e.g., a Secure + Digital (SD) card, USB drive) that the user has purchased at the + local electronics retailer. Along with the cryptographic module, the + user may get the key on a CD or a floppy in a standard format. The + user can now upload via a secure online channel or import this key + and related data into the new validation system and start using the + key. + +A.1.4. Server-to-Server Bulk Import/Export of Keys + + From time to time, a key management system may be required to import + or export keys in bulk from one entity to another. + + For example, instead of importing keys from a manufacturer using a + file, a validation server may download the keys using an online + protocol. The keys can be downloaded in a standard format that can + be processed by a validation system. + + For example, in a variation of the above, an Over-The-Air (OTA) key + provisioning gateway that provisions keys to mobile phones may obtain + key material from a key issuer using an online protocol. The keys + are delivered in a standard format that can be processed by the key + provisioning gateway and subsequently sent to the mobile phone of the + end user. + +A.2. Offline Use Cases + + This section describes the use cases relating to offline transport of + keys from one system to another, using some form of export and import + model. + +A.2.1. Server-to-Server Bulk Import/Export of Keys + + For example, cryptographic modules, such as OTP authentication + tokens, may have their symmetric keys initialized during the + manufacturing process in bulk, requiring copies of the keys and + algorithm data to be loaded into the authentication system through a + file on portable media. The manufacturer provides the keys and + related data 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. Some + crypto modules will allow local PIN management (the device will have + a PIN pad); hence, random initial PINs set at manufacturing should be + transmitted together with the respective keys they protect. + + + +Hoyer, et al. Standards Track [Page 55] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + For example, an enterprise wants to port keys and related data 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 keys and related data (e.g., for + OTP authentication tokens) in a standard format. Since the OTP + tokens are in the standard format, the enterprise can 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. + +Appendix B. 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 the transport of multiple types of + symmetric keys and related attributes for algorithms 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 + + * Key friendly name + + * Event counter value (moving factor for OTP algorithms) + + * Time 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 keys. + + + + + +Hoyer, et al. Standards Track [Page 56] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + + R5: The format SHOULD allow bulk representation of PINs related to + specific keys. + + R6: The format SHOULD be portable to various platforms. + Furthermore, it SHOULD be computationally efficient to process. + + R7: The format MUST provide an appropriate level of security in + terms of data encryption and data integrity. + + R8: For online scenarios, the format SHOULD NOT rely on transport + layer security (e.g., Secure Socket Layer/Transport Layer + Security (SSL/TLS)) for core security requirements. + + R9: The format SHOULD be extensible. It SHOULD enable extension + points allowing vendors to specify additional attributes in the + future. + + R10: 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. + + R11: The format SHOULD allow for additional life cycle 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. + + R12: The format MUST support the use of pre-shared symmetric keys to + ensure confidentiality of sensitive data elements. + + R13: 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. + + R14: 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 + key encryption key is difficult to use. + + + + + + + + + +Hoyer, et al. Standards Track [Page 57] + +RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 + + +Authors' Addresses + + Philip Hoyer + ActivIdentity, Inc. + 117 Waterloo Road + London, SE1 8UL + UK + + Phone: +44 (0) 20 7960 0220 + EMail: phoyer@actividentity.com + + + 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 + + + + + + + + + + + + + + + + + + + + +Hoyer, et al. Standards Track [Page 58] + |