idnits 2.17.00 (12 Aug 2021) /tmp/idnits25969/draft-ietf-keyprov-pskc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 -- The document date (October 23, 2009) is 4592 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) -- 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' == Outdated reference: draft-housley-aes-key-wrap-with-pad has been published as RFC 5649 == Outdated reference: A later version (-01) exists of draft-hoyer-keyprov-pskc-algorithm-profiles-00 -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: April 26, 2010 VeriSign 6 S. Machani 7 Diversinet 8 October 23, 2009 10 Portable Symmetric Key Container (PSKC) 11 draft-ietf-keyprov-pskc-04 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 26, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document specifies a symmetric key format for transport and 50 provisioning of symmetric keys to different types of crypto modules. 51 For example, One Time Password (OTP) shared secrets or symmetric 52 cryptographic keys to strong authentication devices. A standard key 53 transport format enables enterprises to deploy best-of-breed 54 solutions combining components from different vendors into the same 55 infrastructure. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 4 63 1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 4 64 1.3.2. Referenced Identifiers . . . . . . . . . . . . . . . . 5 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Portable Key Container Entities Overview and Relationships . . 7 67 4. Element: The Basics . . . . . . . . . . . . . . 9 68 4.1. : Embedding Keying Material and Key Related 69 Information . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. Transmission of supplementary Information . . . . . . . . 11 71 4.2.1. Element: Unique Device Identification . . 12 72 4.2.2. Element: CryptoModule 73 Identification . . . . . . . . . . . . . . . . . . . . 13 74 4.2.3. Element: User Identification . . . . . . . . 14 75 4.2.4. Element: Supplementary 76 Information for OTP and CR Algorithms . . . . . . . . 14 77 4.3. Transmission of Key Derivation Values . . . . . . . . . . 16 78 5. Key policy - transmission of key usage policies and key 79 PIN protection policy . . . . . . . . . . . . . . . . . . . . 18 80 6. Key protection methods . . . . . . . . . . . . . . . . . . . . 23 81 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23 82 6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25 83 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26 84 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29 85 6.4. Padding of encrypted values for non-padded encryption 86 algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30 87 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31 88 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33 89 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36 90 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37 91 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37 93 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 95 12.1. Content-type registration for 'application/pskc+xml' . . . 46 96 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47 97 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47 98 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48 99 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49 100 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49 101 13. Security Considerations . . . . . . . . . . . . . . . . . . . 51 102 13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 51 103 13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 52 104 13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 52 105 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 106 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 107 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 108 16.1. Normative References . . . . . . . . . . . . . . . . . . . 55 109 16.2. Informative References . . . . . . . . . . . . . . . . . . 55 110 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57 111 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57 112 A.1.1. Transport of keys from Server to Cryptographic 113 Module . . . . . . . . . . . . . . . . . . . . . . . . 57 114 A.1.2. Transport of keys from Cryptographic Module to 115 Cryptographic Module . . . . . . . . . . . . . . . . . 57 116 A.1.3. Transport of keys from Cryptographic Module to 117 Server . . . . . . . . . . . . . . . . . . . . . . . . 58 118 A.1.4. Server to server Bulk import/export of keys . . . . . 58 119 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58 120 A.2.1. Server to server Bulk import/export of keys . . . . . 58 121 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 124 1. Introduction 126 With increasing use of symmetric key based systems, such as 127 encryption of data at rest or systems used for strong authentication 128 such as those based on one-time-password (OTP) and challenge response 129 (CR) mechanisms, there is a need for vendor interoperability and a 130 standard format for importing and exporting (provisioning) symmetric 131 keys. Traditionally, for example, vendors of authentication servers 132 and service providers have used proprietary formats for importing and 133 exporting these keys into their systems, thus making it hard to use 134 tokens from vendor "Foo" with a server from vendor "Bar". 136 This document defines a standardized XML-based key container, called 137 Portable Symmetric Key Container (PSKC), for transporting symmetric 138 keys and key related meta data. The document also specifies the 139 information elements that may be required when the symmetric key is 140 utilized for specific purposes, such as the initial counter in the 141 MAC-Based One Time Password (HOTP) [HOTP] algorithm. It also 142 requests the creation of an IANA registry for algorithm profiles 143 where algorithms, their related meta-data and PSKC transmission 144 profile can be recorded for centralised standardised reference. 146 1.1. Key Words 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 1.2. Versions 154 There is a provision made in the syntax for an explicit version 155 number. Only version "1.0" is currently specified. 157 1.3. Namespace Identifiers 159 This document uses Uniform Resource Identifiers [RFC2396] to identify 160 resources, algorithms, and semantics. 162 1.3.1. Defined Identifiers 164 The XML namespace [XMLNS] URI for Version 1.0 of PSKC is: 166 xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" 168 References to qualified elements in the PSKC schema defined herein 169 use the prefix "pskc". 171 1.3.2. Referenced Identifiers 173 The PSKC syntax presented in this document relies on algorithm 174 identifiers and elements defined in the XML Signature [XMLDSIG] 175 namespace: 177 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 179 References to the XML Signature namespace are represented by the 180 prefix "ds". 182 PSKC also relies on algorithm identifiers and elements defined in the 183 XML Encryption [XMLENC] namespace: 185 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 187 References to the XML Encryption namespace are represented by the 188 prefix "xenc". 190 When protecting keys in transport with passphrase-based keys, PSKC 191 also relies on the derived key element defined in the XML Encryption 192 Version 1.1 [XMLENC11] namespace: 194 xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"" 196 References to the XML Encryption Version 1.1 namespace are 197 represented by the prefix "xenc11". 199 When protecting keys in transport with passphrase-based keys, PSKC 200 also relies on algorithm identifiers and elements defined in the 201 PKCS#5 [PKCS5] namespace: 203 xmlns:pkcs5= 204 "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" 206 References to the PKCS#5 namespace are represented by the prefix 207 "pkcs5". 209 2. Terminology 211 NOTE: In subsequent sections of the document we highlight 212 **mandatory** XML elements and attributes. Optional elements and 213 attributes are not explicitly indicated, i.e., if it does not say 214 mandatory it is optional. 216 3. Portable Key Container Entities Overview and Relationships 218 The portable key container is based on an XML schema definition and 219 contains the following main conceptual entities: 221 1. KeyContainer entity - representing the container that carries a 222 number of KeyPackages 224 2. KeyPackage entity - representing the package of at most one key 225 and its related provisioning endpoint or current usage endpoint, 226 such as a physical or virtual device and a specific CryptoModule 228 3. DeviceInfo entity - representing the information about the device 229 and criteria to uniquely identify the device 231 4. CryptoModuleInfo entity - representing the information about the 232 CryptoModule where the keys reside or are provisioned to 234 5. Key entity - representing the key transported or provisioned 236 6. Data entity - representing a list of meta-data related to the 237 key, where the element name is the name of the meta-data and its 238 associated value is either in encrypted form (for example for 239 Data element 'SECRET') or plaintext (for example for the Data 240 element 'COUNTER') 242 Figure 1 shows the high-level structure of the PSKC data elements. 244 ----------------- 245 | KeyContainer | 246 |---------------| 247 | EncryptionKey | 248 | Signature | 249 | ... | 250 ----------------- 251 | 252 | 253 /|\ 1..n 254 ---------------- ---------------- 255 | KeyPackage | 0..1| DeviceInfo | 256 |--------------|--------|--------------| 257 | |-- | SerialNumber | 258 ---------------- | | Manufacturer | 259 | | | .... | 260 | | ---------------- 261 /|\ 0..1 | 262 ---------------- | -------------------- 263 | Key | | 0..1| CryptoModuleInfo | 264 |--------------| -----|------------------| 265 | Id | | Id | 266 | Algorithm | |.... | 267 | UserId | -------------------- 268 | Policy | 269 | .... | 270 ---------------- 271 | 272 | 273 /|\ 0..n 274 --------------------------------------- - - 275 | | | 276 ------------------ ---------------- -------- - - 277 | Data:Secret | | Data:Counter | | Data:other 278 |----------------| |--------------| |-- - - 279 | EncryptedValue | | PlainValue | 280 | ValueMAC | ---------------- 281 ------------------ 283 Figure 1 285 The following sections describe in detail all the entities and 286 related XML schema elements and attributes. 288 4. Element: The Basics 290 In its most basic form, a PSKC document uses the top-level element 291 and a single element to carry key 292 information. 294 The following example shows such a simple PSKC document. We will use 295 it to describe the structure of the element and its 296 child elements. 298 299 302 303 305 Issuer-A 306 307 308 MTIzNA== 309 310 311 312 313 314 316 Figure 2: Basic PSKC Key Container Example 318 The attributes of the element have the following 319 semantics: 321 'Version:' The 'Version' attribute is used to identify the version 322 of the PSKC schema version. This specification defines the 323 initial version ("1.0") of the PSKC schema. This attribute MUST 324 be included. 326 'Id:' The 'Id' attribute carries a unique identifier for the 327 container. As such, it helps to identify a specific key container 328 in cases when multiple containers are embedded in larger xml 329 documents. 331 4.1. : Embedding Keying Material and Key Related Information 333 The following attributes of the element MUST be included at a 334 minimum: 336 'Id': This attribute carries a globally unique identifier for the 337 symmetric key. The identifier is defined as a string of 338 alphanumeric characters. 340 'Algorithm': This attribute contains a unique identifier for the 341 PSKC algorithm profile. This profile associates specific 342 semantics to the elements and attributes contained in the 343 element. This document describes profiles for open standards 344 algorithms in Section 10. Additional profiles are defined in the 345 following information draft [PSKC-ALGORITHM-PROFILES]. 347 The element has a number of optional child elements. An 348 initial set is described below: 350 : This element represents the name of the party that issued 351 the key. For example, a bank "Foobar Bank Inc." issuing hardware 352 tokens to their retail banking users may set this element to 353 "Foobar Bank Inc.". 355 : A human readable name for the secret key for easier 356 reference. This element serves informational purposes only. 358 : This element carries parameters that 359 influence the result of the algorithmic computation, for example 360 response truncation and format in OTP and CR algorithms. A more 361 detailed discussion of the element can be found in Section 4.2.4. 363 : This element carries data about and related to the key. The 364 following child elements are defined for the element: 366 : This element carries the value of the key itself in a 367 binary representation. 369 : This element contains the event counter for event 370 based OTP algorithms. 372