idnits 2.17.1 draft-ietf-keyprov-pskc-07.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. == 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 (June 28, 2010) is 5049 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' ** Downref: Normative reference to an Informational RFC: RFC 4226 (ref. 'HOTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAPENREG' -- 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) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-67' -- 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) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 12 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: December 30, 2010 VeriSign 6 S. Machani 7 Diversinet 8 June 28, 2010 10 Portable Symmetric Key Container (PSKC) 11 draft-ietf-keyprov-pskc-07 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 December 30, 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. Version Support . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 5 67 1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 5 68 1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Portable Key Container Entities Overview and Relationships . . 8 71 4. Element: The Basics . . . . . . . . . . . . . . 10 72 4.1. : Embedding Keying Material and Key Related 73 Information . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.2. Key Value Encoding . . . . . . . . . . . . . . . . . . . . 12 75 4.2.1. AES Key Value Encoding . . . . . . . . . . . . . . . . 13 76 4.2.2. Triple DES Key Value Encoding . . . . . . . . . . . . 13 77 4.3. Transmission of supplementary Information . . . . . . . . 14 78 4.3.1. Element: Unique Device Identification . . 15 79 4.3.2. Element: CryptoModule 80 Identification . . . . . . . . . . . . . . . . . . . . 16 81 4.3.3. Element: User Identification . . . . . . . . 17 82 4.3.4. Element: Supplementary 83 Information for OTP and CR Algorithms . . . . . . . . 17 84 4.4. Transmission of Key Derivation Values . . . . . . . . . . 19 85 5. Key Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 5.1. PIN Algorithm definition . . . . . . . . . . . . . . . . . 25 87 6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 26 88 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 26 89 6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 28 90 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 29 91 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 32 92 6.4. Padding of Encrypted Values for Non-Padded Encryption 93 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 33 94 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 34 95 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 36 96 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 39 97 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 40 98 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 99 10.2. PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 100 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 42 101 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 102 12.1. Content-type registration for 'application/pskc+xml' . . . 49 103 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 50 104 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 50 105 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 51 106 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 52 107 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 52 108 13. Security Considerations . . . . . . . . . . . . . . . . . . . 54 109 13.1. PSKC Confidentiality . . . . . . . . . . . . . . . . . . . 54 110 13.2. PSKC Integrity . . . . . . . . . . . . . . . . . . . . . . 55 111 13.3. PSKC Authenticity . . . . . . . . . . . . . . . . . . . . 55 112 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 56 113 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 114 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 115 16.1. Normative References . . . . . . . . . . . . . . . . . . . 58 116 16.2. Informative References . . . . . . . . . . . . . . . . . . 59 117 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 61 118 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 61 119 A.1.1. Transport of keys from Server to Cryptographic 120 Module . . . . . . . . . . . . . . . . . . . . . . . . 61 121 A.1.2. Transport of keys from Cryptographic Module to 122 Cryptographic Module . . . . . . . . . . . . . . . . . 61 123 A.1.3. Transport of keys from Cryptographic Module to 124 Server . . . . . . . . . . . . . . . . . . . . . . . . 62 125 A.1.4. Server to server Bulk import/export of keys . . . . . 62 126 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 62 127 A.2.1. Server to server Bulk import/export of keys . . . . . 62 128 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 64 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 131 1. Introduction 133 With increasing use of symmetric key based systems, such as 134 encryption of data at rest, or systems used for strong 135 authentication, such as those based on one-time-password (OTP) and 136 challenge response (CR) mechanisms, there is a need for vendor 137 interoperability and a standard format for importing and exporting 138 (provisioning) symmetric keys. For instance, traditionally, vendors 139 of authentication servers and service providers have used proprietary 140 formats for importing and exporting these keys into their systems, 141 thus making it hard to use tokens from two different vendors. 143 This document defines a standardized XML-based key container, called 144 Portable Symmetric Key Container (PSKC), for transporting symmetric 145 keys and key related meta data. The document also specifies the 146 information elements that are required when the symmetric key is 147 utilized for specific purposes, such as the initial counter in the 148 HMAC-Based One Time Password (HOTP) [HOTP] algorithm. It also 149 requests the creation of an IANA registry for algorithm profiles 150 where algorithms, their meta-data and PSKC transmission profile can 151 be recorded for centralised standardised reference. 153 1.1. Key Words 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 1.2. Version Support 161 There is a provision made in the syntax for an explicit version 162 number. Only version "1.0" is currently specified. 164 The numbering scheme for PSKC versions is ".". The 165 major and minor numbers MUST be treated as separate integers and each 166 number MAY be incremented higher than a single digit. Thus, "PSKC 167 2.4" would be a lower version than "PSKC 2.13", which in turn would 168 be lower than "PSKC 12.3". Leading zeros (e.g., "PSKC 6.01") MUST be 169 ignored by recipients and MUST NOT be sent. 171 The major version number should be incremented only if the message 172 format (E.g. Element structure) has changed so dramatically that an 173 older version implementation would not be able to interoperate with a 174 newer version. The minor version number indicates new capabilities, 175 and MUST be ignored by an entity with a smaller minor version number, 176 but used for informational purposes by the entity with the larger 177 minor version number. 179 1.3. Namespace Identifiers 181 This document uses Uniform Resource Identifiers [RFC3986] to identify 182 resources, algorithms, and semantics. 184 1.3.1. Defined Identifiers 186 The XML namespace [XMLNS] URI for Version 1.0 of PSKC is: 188 "urn:ietf:params:xml:ns:keyprov:pskc" 190 References to qualified elements in the PSKC schema defined in this 191 specification and used in the example use the prefix "pskc" (defined 192 as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc") . It is 193 RECOMMENDED to use this namespace in implementations. 195 1.3.2. Referenced Identifiers 197 The PSKC syntax presented in this document relies on algorithm 198 identifiers and elements defined in the XML Signature [XMLDSIG] 199 namespace: 201 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 203 References to the XML Signature namespace are represented by the 204 prefix "ds". 206 PSKC also relies on algorithm identifiers and elements defined in the 207 XML Encryption [XMLENC] namespace: 209 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 211 References to the XML Encryption namespace are represented by the 212 prefix "xenc". 214 When protecting keys in transport with passphrase-based keys, PSKC 215 also relies on the derived key element defined in the XML Encryption 216 Version 1.1 [XMLENC11] namespace: 218 xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"" 220 References to the XML Encryption Version 1.1 namespace are 221 represented by the prefix "xenc11". 223 When protecting keys in transport with passphrase-based keys, PSKC 224 also relies on algorithm identifiers and elements defined in the 225 PKCS#5 [PKCS5] namespace: 227 xmlns:pkcs5= 228 "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" 230 References to the PKCS#5 namespace are represented by the prefix 231 "pkcs5". 233 2. Terminology 235 NOTE: In subsequent sections of the document we highlight 236 **mandatory** XML elements and attributes. Optional elements and 237 attributes are not explicitly indicated, i.e., if it does not say 238 mandatory it is optional. 240 3. Portable Key Container Entities Overview and Relationships 242 The portable key container is based on an XML schema definition and 243 contains the following main conceptual entities: 245 1. KeyContainer entity - representing the container that carries a 246 number of KeyPackages. A valid container MUST carry at least 1 247 KeyPackage. 249 2. KeyPackage entity - representing the package of at most one key 250 and its related provisioning endpoint or current usage endpoint, 251 such as a physical or virtual device and a specific CryptoModule 253 3. DeviceInfo entity - representing the information about the device 254 and criteria to uniquely identify the device 256 4. CryptoModuleInfo entity - representing the information about the 257 CryptoModule where the keys reside or are provisioned to 259 5. Key entity - representing the key transported or provisioned 261 6. Data entity - representing a list of meta-data related to the 262 key, where the element name is the name of the meta-data and its 263 associated value is either in encrypted form (for example for 264 Data element ) or plaintext (for example the Data element 265 ) 267 Figure 1 shows the high-level structure of the PSKC data elements. 269 ----------------- 270 | KeyContainer | 271 |---------------| 272 | EncryptionKey | 273 | Signature | 274 | ... | 275 ----------------- 276 | 277 | 278 /|\ 1..n 279 ---------------- ---------------- 280 | KeyPackage | 0..1| DeviceInfo | 281 |--------------|--------|--------------| 282 | |-- | SerialNumber | 283 ---------------- | | Manufacturer | 284 | | | .... | 285 | | ---------------- 286 /|\ 0..1 | 287 ---------------- | -------------------- 288 | Key | | 0..1| CryptoModuleInfo | 289 |--------------| -----|------------------| 290 | Id | | Id | 291 | Algorithm | |.... | 292 | UserId | -------------------- 293 | Policy | 294 | .... | 295 ---------------- 296 | 297 | 298 /|\ 0..n 299 --------------------------------------- - - 300 | | | 301 ------------------ ---------------- -------- - - 302 | Data:Secret | | Data:Counter | | Data:other 303 |----------------| |--------------| |-- - - 304 | EncryptedValue | | PlainValue | 305 | ValueMAC | ---------------- 306 ------------------ 308 Figure 1: PSKC data elements relationship diagram 310 The following sections describe in detail all the entities and 311 related XML schema elements and attributes. 313 4. Element: The Basics 315 In its most basic form, a PSKC document uses the top-level element 316 and a single element to carry key 317 information. 319 The following example shows such a simple PSKC document. We will use 320 it to describe the structure of the element and its 321 child elements. 323 324 327 328 330 Issuer-A 331 332 333 MTIzNA== 334 335 336 337 338 339 341 Figure 2: Basic PSKC Key Container Example 343 The attributes of the element have the following 344 semantics: 346 'Version:' The 'Version' attribute is used to identify the version 347 of the PSKC schema version. This specification defines the 348 initial version ("1.0") of the PSKC schema. This attribute MUST 349 be included. 351 'Id:' The 'Id' attribute carries a unique identifier for the 352 container. As such, it helps to identify a specific key container 353 in cases when multiple containers are embedded in larger xml 354 documents. 356 4.1. : Embedding Keying Material and Key Related Information 358 The following attributes of the element MUST be included at a 359 minimum: 361 'Id': This attribute carries a unique identifier for the symmetric 362 key in the context of key provisioning exchanges between two 363 parties. This means that if PSKC is used in multiple interactions 364 between a sending and receiving party, using different containers 365 referencing the same keys, the KeyId MUST use the same KeyId 366 values (e.g. after initial provisioning, if a system wants to 367 update key meta data values in the other system the KeyId value of 368 the key where the meta data is to be updates MUST be the same of 369 the original KeyId value provisioned). The identifier is defined 370 as a string of alphanumeric characters. 372 'Algorithm': This attribute contains a unique identifier for the 373 PSKC algorithm profile. This profile associates specific 374 semantics to the elements and attributes contained in the 375 element. This document describes profiles for open standards 376 algorithms in Section 10. Additional profiles are defined in the 377 following information draft [PSKC-ALGORITHM-PROFILES]. 379 The element has a number of optional child elements. An 380 initial set is described below: 382 : This element represents the name of the party that issued 383 the key. For example, a bank "Foobar Bank Inc." issuing hardware 384 tokens to their retail banking users may set this element to 385 "Foobar Bank Inc.". 387 : A human readable name for the secret key for easier 388 reference. This element serves informational purposes only. This 389 element is a language dependent string hence it SHOULD have an 390 attribute xml:lang="xx" where xx is the language identifier as 391 specified in [RFC4646]. If no xml:lang attribute is present 392 implementations MUST assume the language to be English as defined 393 by setting the attribute value to "en" (e.g. xml:lang="en"). 395 : This element carries parameters that 396 influence the result of the algorithmic computation, for example 397 response truncation and format in OTP and CR algorithms. A more 398 detailed discussion of the element can be found in Section 4.3.4. 400 : This element carries data about and related to the key. The 401 following child elements are defined for the element: 403 : This element carries the value of the key itself in a 404 binary representation, please see Section 4.2 for more details 405 on Key Value Encoding. 407 : This element contains the event counter for event 408 based OTP algorithms. 410