Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6030

Portable Symmetric Key Container (PSKC)

Pages: 58
Proposed Standard
Errata
Part 3 of 3 – Pages 38 to 58
First   Prev   None

Top   ToC   RFC6030 - Page 38   prevText

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>
Top   ToC   RFC6030 - Page 39
     </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>
Top   ToC   RFC6030 - Page 40
               <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>
Top   ToC   RFC6030 - Page 41
     </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"/>
Top   ToC   RFC6030 - Page 42
          </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>
Top   ToC   RFC6030 - Page 43
               <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"/>
Top   ToC   RFC6030 - Page 44
          </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
Top   ToC   RFC6030 - Page 45
   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>
Top   ToC   RFC6030 - Page 46

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.
Top   ToC   RFC6030 - Page 47
   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.
Top   ToC   RFC6030 - Page 48
   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.
Top   ToC   RFC6030 - Page 49

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.
Top   ToC   RFC6030 - Page 50

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.
Top   ToC   RFC6030 - Page 51
   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.
Top   ToC   RFC6030 - Page 52
   [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.
Top   ToC   RFC6030 - Page 53
   [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>.
Top   ToC   RFC6030 - Page 54

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.
Top   ToC   RFC6030 - Page 55

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.
Top   ToC   RFC6030 - Page 56
   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.
Top   ToC   RFC6030 - Page 57
   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.
Top   ToC   RFC6030 - Page 58

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