idnits 2.17.1 draft-ietf-keyprov-pskc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Deprecated: TRUE if based on expert approval this entry has been deprecated and SHOULD not be used in any new implementations. Otherwise FALSE. -- The document date (May 14, 2010) is 5095 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-housley-aes-key-wrap-with-pad-02 ** Downref: Normative reference to an Informational draft: draft-housley-aes-key-wrap-with-pad (ref. 'AESKWPAD') ** Downref: Normative reference to an Informational RFC: RFC 4226 (ref. 'HOTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISOIEC7812' -- Possible downref: Non-RFC (?) normative reference: ref. 'OATHMAN' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS5' ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC11' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 keyprov P. Hoyer 3 Internet-Draft ActivIdentity 4 Intended status: Standards Track M. Pei 5 Expires: November 15, 2010 VeriSign 6 S. Machani 7 Diversinet 8 May 14, 2010 10 Portable Symmetric Key Container (PSKC) 11 draft-ietf-keyprov-pskc-06 13 Abstract 15 This document specifies a symmetric key format for transport and 16 provisioning of symmetric keys to different types of crypto modules. 17 For example, One Time Password (OTP) shared secrets or symmetric 18 cryptographic keys to strong authentication devices. A standard key 19 transport format enables enterprises to deploy best-of-breed 20 solutions combining components from different vendors into the same 21 infrastructure. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on November 15, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 4 67 1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 4 68 1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Portable Key Container Entities Overview and Relationships . . 7 71 4. Element: The Basics . . . . . . . . . . . . . . 9 72 4.1. : Embedding Keying Material and Key Related 73 Information . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.2. Transmission of supplementary Information . . . . . . . . 11 75 4.2.1. Element: Unique Device Identification . . 12 76 4.2.2. Element: CryptoModule 77 Identification . . . . . . . . . . . . . . . . . . . . 13 78 4.2.3. Element: User Identification . . . . . . . . 14 79 4.2.4. Element: Supplementary 80 Information for OTP and CR Algorithms . . . . . . . . 14 81 4.3. Transmission of Key Derivation Values . . . . . . . . . . 16 82 5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 23 84 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23 85 6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25 86 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26 87 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29 88 6.4. Padding of Encrypted Values for Non-Padded Encryption 89 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30 90 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31 91 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33 92 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36 93 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37 94 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 95 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37 97 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 99 12.1. Content-type registration for 'application/pskc+xml' . . . 46 100 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47 101 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47 102 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48 103 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49 104 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49 105 13. Security Considerations . . . . . . . . . . . . . . . . . . . 51 106 13.1. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 51 107 13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 52 108 13.3. PSKC Authenticity . . . . . . . . . . . . . . . . . . . . 52 109 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 110 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 111 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 112 16.1. Normative References . . . . . . . . . . . . . . . . . . . 55 113 16.2. Informative References . . . . . . . . . . . . . . . . . . 56 114 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 58 115 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 58 116 A.1.1. Transport of keys from Server to Cryptographic 117 Module . . . . . . . . . . . . . . . . . . . . . . . . 58 118 A.1.2. Transport of keys from Cryptographic Module to 119 Cryptographic Module . . . . . . . . . . . . . . . . . 58 120 A.1.3. Transport of keys from Cryptographic Module to 121 Server . . . . . . . . . . . . . . . . . . . . . . . . 59 122 A.1.4. Server to server Bulk import/export of keys . . . . . 59 123 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 59 124 A.2.1. Server to server Bulk import/export of keys . . . . . 59 125 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 61 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 128 1. Introduction 130 With increasing use of symmetric key based systems, such as 131 encryption of data at rest, or systems used for strong 132 authentication, such as those based on one-time-password (OTP) and 133 challenge response (CR) mechanisms, there is a need for vendor 134 interoperability and a standard format for importing and exporting 135 (provisioning) symmetric keys. For instance, traditionally, vendors 136 of authentication servers and service providers have used proprietary 137 formats for importing and exporting these keys into their systems, 138 thus making it hard to use tokens from two different vendors. 140 This document defines a standardized XML-based key container, called 141 Portable Symmetric Key Container (PSKC), for transporting symmetric 142 keys and key related meta data. The document also specifies the 143 information elements that are required when the symmetric key is 144 utilized for specific purposes, such as the initial counter in the 145 HMAC-Based One Time Password (HOTP) [HOTP] algorithm. It also 146 requests the creation of an IANA registry for algorithm profiles 147 where algorithms, their meta-data and PSKC transmission profile can 148 be recorded for centralised standardised reference. 150 1.1. Key Words 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 1.2. Versions 158 There is a provision made in the syntax for an explicit version 159 number. Only version "1.0" is currently specified. 161 1.3. Namespace Identifiers 163 This document uses Uniform Resource Identifiers [RFC3986] to identify 164 resources, algorithms, and semantics. 166 1.3.1. Defined Identifiers 168 The XML namespace [XMLNS] URI for Version 1.0 of PSKC is: 170 "urn:ietf:params:xml:ns:keyprov:pskc" 172 References to qualified elements in the PSKC schema defined in this 173 specification and used in the example use the prefix "pskc" (defined 174 as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc") . It is 175 RECOMMENDED to use this namespace in implementations. 177 1.3.2. Referenced Identifiers 179 The PSKC syntax presented in this document relies on algorithm 180 identifiers and elements defined in the XML Signature [XMLDSIG] 181 namespace: 183 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 185 References to the XML Signature namespace are represented by the 186 prefix "ds". 188 PSKC also relies on algorithm identifiers and elements defined in the 189 XML Encryption [XMLENC] namespace: 191 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 193 References to the XML Encryption namespace are represented by the 194 prefix "xenc". 196 When protecting keys in transport with passphrase-based keys, PSKC 197 also relies on the derived key element defined in the XML Encryption 198 Version 1.1 [XMLENC11] namespace: 200 xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"" 202 References to the XML Encryption Version 1.1 namespace are 203 represented by the prefix "xenc11". 205 When protecting keys in transport with passphrase-based keys, PSKC 206 also relies on algorithm identifiers and elements defined in the 207 PKCS#5 [PKCS5] namespace: 209 xmlns:pkcs5= 210 "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" 212 References to the PKCS#5 namespace are represented by the prefix 213 "pkcs5". 215 2. Terminology 217 NOTE: In subsequent sections of the document we highlight 218 **mandatory** XML elements and attributes. Optional elements and 219 attributes are not explicitly indicated, i.e., if it does not say 220 mandatory it is optional. 222 3. Portable Key Container Entities Overview and Relationships 224 The portable key container is based on an XML schema definition and 225 contains the following main conceptual entities: 227 1. KeyContainer entity - representing the container that carries a 228 number of KeyPackages. A valid container MUST carry at least 1 229 KeyPackage. 231 2. KeyPackage entity - representing the package of at most one key 232 and its related provisioning endpoint or current usage endpoint, 233 such as a physical or virtual device and a specific CryptoModule 235 3. DeviceInfo entity - representing the information about the device 236 and criteria to uniquely identify the device 238 4. CryptoModuleInfo entity - representing the information about the 239 CryptoModule where the keys reside or are provisioned to 241 5. Key entity - representing the key transported or provisioned 243 6. Data entity - representing a list of meta-data related to the 244 key, where the element name is the name of the meta-data and its 245 associated value is either in encrypted form (for example for 246 Data element ) or plaintext (for example the Data element 247 ) 249 Figure 1 shows the high-level structure of the PSKC data elements. 251 ----------------- 252 | KeyContainer | 253 |---------------| 254 | EncryptionKey | 255 | Signature | 256 | ... | 257 ----------------- 258 | 259 | 260 /|\ 1..n 261 ---------------- ---------------- 262 | KeyPackage | 0..1| DeviceInfo | 263 |--------------|--------|--------------| 264 | |-- | SerialNumber | 265 ---------------- | | Manufacturer | 266 | | | .... | 267 | | ---------------- 268 /|\ 0..1 | 269 ---------------- | -------------------- 270 | Key | | 0..1| CryptoModuleInfo | 271 |--------------| -----|------------------| 272 | Id | | Id | 273 | Algorithm | |.... | 274 | UserId | -------------------- 275 | Policy | 276 | .... | 277 ---------------- 278 | 279 | 280 /|\ 0..n 281 --------------------------------------- - - 282 | | | 283 ------------------ ---------------- -------- - - 284 | Data:Secret | | Data:Counter | | Data:other 285 |----------------| |--------------| |-- - - 286 | EncryptedValue | | PlainValue | 287 | ValueMAC | ---------------- 288 ------------------ 290 Figure 1: PSKC data elements relationship diagram 292 The following sections describe in detail all the entities and 293 related XML schema elements and attributes. 295 4. Element: The Basics 297 In its most basic form, a PSKC document uses the top-level element 298 and a single element to carry key 299 information. 301 The following example shows such a simple PSKC document. We will use 302 it to describe the structure of the element and its 303 child elements. 305 306 309 310 312 Issuer-A 313 314 315 MTIzNA== 316 317 318 319 320 321 323 Figure 2: Basic PSKC Key Container Example 325 The attributes of the element have the following 326 semantics: 328 'Version:' The 'Version' attribute is used to identify the version 329 of the PSKC schema version. This specification defines the 330 initial version ("1.0") of the PSKC schema. This attribute MUST 331 be included. 333 'Id:' The 'Id' attribute carries a unique identifier for the 334 container. As such, it helps to identify a specific key container 335 in cases when multiple containers are embedded in larger xml 336 documents. 338 4.1. : Embedding Keying Material and Key Related Information 340 The following attributes of the element MUST be included at a 341 minimum: 343 'Id': This attribute carries a globally unique identifier for the 344 symmetric key. The identifier is defined as a string of 345 alphanumeric characters. 347 'Algorithm': This attribute contains a unique identifier for the 348 PSKC algorithm profile. This profile associates specific 349 semantics to the elements and attributes contained in the 350 element. This document describes profiles for open standards 351 algorithms in Section 10. Additional profiles are defined in the 352 following information draft [PSKC-ALGORITHM-PROFILES]. 354 The element has a number of optional child elements. An 355 initial set is described below: 357 : This element represents the name of the party that issued 358 the key. For example, a bank "Foobar Bank Inc." issuing hardware 359 tokens to their retail banking users may set this element to 360 "Foobar Bank Inc.". 362 : A human readable name for the secret key for easier 363 reference. This element serves informational purposes only. 365 : This element carries parameters that 366 influence the result of the algorithmic computation, for example 367 response truncation and format in OTP and CR algorithms. A more 368 detailed discussion of the element can be found in Section 4.2.4. 370 : This element carries data about and related to the key. The 371 following child elements are defined for the element: 373 : This element carries the value of the key itself in a 374 binary representation. 376 : This element contains the event counter for event 377 based OTP algorithms. 379