keyprov P. Hoyer Internet-Draft ActivIdentity Intended status: Standards Track M. Pei Expires: August 26, 2009 VeriSign S. Machani Diversinet February 22, 2009 Portable Symmetric Key Container (PSKC) draft-ietf-keyprov-pskc-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 26, 2009. Copyright Notice Copyright (c) 2009 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. Hoyer, et al. Expires August 26, 2009 [Page 1] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 Abstract This document specifies a symmetric key format for transport and provisioning of symmetric keys (for example One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of crypto modules, such as a strong authentication device. The standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Portable Key Container Entities Overview and Relationships . . 6 4. Element: The Basics . . . . . . . . . . . . . . 8 4.1. Element: Unique Device Identification . . . . 9 4.2. : Embedding Keying Material . . . . . . . . . . . . . 10 4.3. Element: User Identification . . . . . . . . . . . 11 4.4. Element: Supplementary Information for OTP and CR Algorithms . . . . . . . . . . . . . . . . . . . . . . 12 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Protection of Keys and Related Data . . . . . . . . . . . . . 19 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 19 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 22 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 24 6.4. Transmission of Key Derivation Values . . . . . . . . . . 26 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 28 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 30 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 34 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 34 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12.1. Content-type registration for 'application/pskc+xml' . . . 43 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 44 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 44 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 45 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 46 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 46 13. Security Considerations . . . . . . . . . . . . . . . . . . . 48 13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 48 13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 49 13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 49 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 Hoyer, et al. Expires August 26, 2009 [Page 2] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 16.1. Normative References . . . . . . . . . . . . . . . . . . . 52 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 . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 Hoyer, et al. Expires August 26, 2009 [Page 3] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 1. Introduction With increasing use of symmetric key based authentication systems, such as those based one time password (OTP) and challenge response mechanisms, there is a need for vendor interoperability and a standard format for importing and exporting (provisioning) symmetric keys. Traditionally, vendors of authentication servers and service providers have used proprietary formats for importing and exporting these keys into their systems making it hard to use tokens from vendor "Foo" with a server from vendor "Bar". This document proposes a standardized XML-based key container, called Portable Symmetric Key Container (PSKC), for transporting symmetric keys and meta data. This document also specifies the information elements that are required for computing the initial event counter used by the MAC-Based One Time Password Algorithm (HOTP) algorithm [HOTP] and these elements are also applicable for other time-based algorithms. Hoyer, et al. Expires August 26, 2009 [Page 4] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 2. Terminology 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]. 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. Hoyer, et al. Expires August 26, 2009 [Page 5] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 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 the keys 2. Device entity - representing a physical or virtual device where the keys reside optionally bound to a specific user 3. DeviceInfo entity - representing the information about the device and criteria to uniquely identify the device 4. Key entity - representing the key transmitted 5. KeyData entity - representing data related to the key including value either in plain or encrypted Figure 1 shows the high-level structure of the PSKC data elements. Hoyer, et al. Expires August 26, 2009 [Page 6] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 +---------------+ | KeyContainer | +---------------+ | EncryptionKey | | Signature | | ... | +---------------+ | | /|\ 1..n +--------------+ +--------------+ | Device | 1| DeviceInfo | +--------------+-----+--------------+ | User | | SerialNumber | +--------------+ | Manufacturer | | | .... | | +--------------+ /|\ 1..n +--------------+ | Key | +--------------+ | ID | | Algorithm | | User | | .... | +--------------+ | | /|\ 1..n +------------+ +--------------+ | Plainvalue | | KeyData | +----+-------+ +--------------+ | | name | either| | value +----------+ | ..... | +------+---------+ +--------------+ | EncryptedValue | +----------------+ Figure 1 The following sections describe in detail all the entities and related XML schema elements and attributes. Hoyer, et al. Expires August 26, 2009 [Page 7] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 4. Element: The Basics In it's most basic form a PSKC document uses the top-level element and a single element to carry key information. The following example shows such a simple PSKC document. We will use it to describe the structure of the element and it's child elements. Manufacturer 987654321 Issuer MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= 0 Figure 2: Basic PSKC Key Container Example The attributes of the element have the following semantic: '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 is mandatory. Hoyer, et al. Expires August 26, 2009 [Page 8] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 'ID:' The 'ID' attribute carries a unique identifier for the container. As such, it helps to identify a specific key container. A element MUST contain at least one element. Multiple elements can be used when for bulk provisioning, see Section 8. A MUST contain at least one element. A MAY be bound to a user. A key SHOULD be bound to only one element. 4.1. Element: Unique Device Identification The element uniquely identifies the device the element refers to. 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 criteria to be used. Combined though the criteria MUST uniquely identify the device. For example, for hardware tokens the combination of and elements uniquely identifies a device but the 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). The element has the following child elements: : This element indicates the manufacturer of the device. : This element contains the serial number of the device. : This element describes the model of the device (e.g., one- button-HOTP-token-V1). : This element contains the issue number in case devices with the same serial number that are distinguished by different issue numbers. : In a number of cases access to lower layer device identifiers, such as a serial number, from a PSKC implementation is difficult or not possible. For this purpose an opaque identifier, carried in the element, is introduced that allows to bind keys to the device or to a class of devices. When loading keys into a device, the value of the element MUST be checked against information provided to the user via out-of-band mechanisms. The implementation then ensures that the correct device or class of device is being used with respect to the provisioned key. Hoyer, et al. Expires August 26, 2009 [Page 9] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 : and : These two elements indicates 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 in UTC form with no timezone component. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. Depending on the device type certain child elements of the element are necessary to include 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. 4.2. : Embedding Keying Material The following attributes of the element MUST be included at a minimum: 'KeyId': This attribute carries a globally unique identifier for the symmetric key. The identifier is defined as a string of alphanumeric characters. 'KeyAlgorithm': This attribute contains a unique identifier for the PSKC algorithm profile. This profile associates a specific semantic to the elements and attributes contained in the element. More information about the PSKC algorithm profile defined in this document can be found in Section 10. The element has a number of optional child elements. An initial set is described below: : 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.". : A human readable name for the secret key for easier reference. This element serves informational purposes only. : This element provides supplementary information for usage with OTP and CR algorithms. A more detailed discussion of the element can be found in Section 4.4. : This element carries data about and related to the key. The follow child elements are defined for the element: Hoyer, et al. Expires August 26, 2009 [Page 10] Internet-Draft Portable Symmetric Key Container (PSKC) February 2009 : This element carries the value of the key itself in a binary representation. : This element contains the event counter for event based OTP algorithms.