idnits 2.17.00 (12 Aug 2021) /tmp/idnits23795/draft-ietf-keyprov-pskc-05.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 (January 5, 2010) is 4518 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 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 6 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: July 9, 2010 VeriSign 6 S. Machani 7 Diversinet 8 January 5, 2010 10 Portable Symmetric Key Container (PSKC) 11 draft-ietf-keyprov-pskc-05 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 July 9, 2010. 36 Copyright Notice 38 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 6. Key Protection Methods . . . . . . . . . . . . . . . . . . . . 23 80 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 23 81 6.1.1. MAC Method . . . . . . . . . . . . . . . . . . . . . . 25 82 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 26 83 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 29 84 6.4. Padding of Encrypted Values for Non-Padded Encryption 85 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 30 86 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 31 87 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 33 88 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36 89 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 37 90 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 91 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 37 92 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 94 12.1. Content-type registration for 'application/pskc+xml' . . . 46 95 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 47 96 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 47 97 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 48 98 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 49 99 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 49 100 13. Security Considerations . . . . . . . . . . . . . . . . . . . 51 101 13.1. Payload Confidentiality . . . . . . . . . . . . . . . . . 51 102 13.2. Payload Integrity . . . . . . . . . . . . . . . . . . . . 52 103 13.3. Payload Authenticity . . . . . . . . . . . . . . . . . . . 52 104 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 105 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 106 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 107 16.1. Normative References . . . . . . . . . . . . . . . . . . . 55 108 16.2. Informative References . . . . . . . . . . . . . . . . . . 55 109 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 57 110 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 57 111 A.1.1. Transport of keys from Server to Cryptographic 112 Module . . . . . . . . . . . . . . . . . . . . . . . . 57 113 A.1.2. Transport of keys from Cryptographic Module to 114 Cryptographic Module . . . . . . . . . . . . . . . . . 57 115 A.1.3. Transport of keys from Cryptographic Module to 116 Server . . . . . . . . . . . . . . . . . . . . . . . . 58 117 A.1.4. Server to server Bulk import/export of keys . . . . . 58 118 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 58 119 A.2.1. Server to server Bulk import/export of keys . . . . . 58 120 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 60 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 123 1. Introduction 125 With increasing use of symmetric key based systems, such as 126 encryption of data at rest, or systems used for strong 127 authentication, such as those based on one-time-password (OTP) and 128 challenge response (CR) mechanisms, there is a need for vendor 129 interoperability and a standard format for importing and exporting 130 (provisioning) symmetric keys. For instance, traditionally, vendors 131 of authentication servers and service providers have used proprietary 132 formats for importing and exporting these keys into their systems, 133 thus making it hard to use tokens from two different vendors. 135 This document defines a standardized XML-based key container, called 136 Portable Symmetric Key Container (PSKC), for transporting symmetric 137 keys and key related meta data. The document also specifies the 138 information elements that are required when the symmetric key is 139 utilized for specific purposes, such as the initial counter in the 140 MAC-Based One Time Password (HOTP) [HOTP] algorithm. It also 141 requests the creation of an IANA registry for algorithm profiles 142 where algorithms, their meta-data and PSKC transmission profile can 143 be recorded for centralised standardised reference. 145 1.1. Key Words 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 1.2. Versions 153 There is a provision made in the syntax for an explicit version 154 number. Only version "1.0" is currently specified. 156 1.3. Namespace Identifiers 158 This document uses Uniform Resource Identifiers [RFC3986] to identify 159 resources, algorithms, and semantics. 161 1.3.1. Defined Identifiers 163 The XML namespace [XMLNS] URI for Version 1.0 of PSKC is: 165 xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" 167 References to qualified elements in the PSKC schema defined herein 168 use the prefix "pskc". 170 1.3.2. Referenced Identifiers 172 The PSKC syntax presented in this document relies on algorithm 173 identifiers and elements defined in the XML Signature [XMLDSIG] 174 namespace: 176 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 178 References to the XML Signature namespace are represented by the 179 prefix "ds". 181 PSKC also relies on algorithm identifiers and elements defined in the 182 XML Encryption [XMLENC] namespace: 184 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 186 References to the XML Encryption namespace are represented by the 187 prefix "xenc". 189 When protecting keys in transport with passphrase-based keys, PSKC 190 also relies on the derived key element defined in the XML Encryption 191 Version 1.1 [XMLENC11] namespace: 193 xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"" 195 References to the XML Encryption Version 1.1 namespace are 196 represented by the prefix "xenc11". 198 When protecting keys in transport with passphrase-based keys, PSKC 199 also relies on algorithm identifiers and elements defined in the 200 PKCS#5 [PKCS5] namespace: 202 xmlns:pkcs5= 203 "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#" 205 References to the PKCS#5 namespace are represented by the prefix 206 "pkcs5". 208 2. Terminology 210 NOTE: In subsequent sections of the document we highlight 211 **mandatory** XML elements and attributes. Optional elements and 212 attributes are not explicitly indicated, i.e., if it does not say 213 mandatory it is optional. 215 3. Portable Key Container Entities Overview and Relationships 217 The portable key container is based on an XML schema definition and 218 contains the following main conceptual entities: 220 1. KeyContainer entity - representing the container that carries a 221 number of KeyPackages 223 2. KeyPackage entity - representing the package of at most one key 224 and its related provisioning endpoint or current usage endpoint, 225 such as a physical or virtual device and a specific CryptoModule 227 3. DeviceInfo entity - representing the information about the device 228 and criteria to uniquely identify the device 230 4. CryptoModuleInfo entity - representing the information about the 231 CryptoModule where the keys reside or are provisioned to 233 5. Key entity - representing the key transported or provisioned 235 6. Data entity - representing a list of meta-data related to the 236 key, where the element name is the name of the meta-data and its 237 associated value is either in encrypted form (for example for 238 Data element ) or plaintext (for example the Data element 239 ) 241 Figure 1 shows the high-level structure of the PSKC data elements. 243 ----------------- 244 | KeyContainer | 245 |---------------| 246 | EncryptionKey | 247 | Signature | 248 | ... | 249 ----------------- 250 | 251 | 252 /|\ 1..n 253 ---------------- ---------------- 254 | KeyPackage | 0..1| DeviceInfo | 255 |--------------|--------|--------------| 256 | |-- | SerialNumber | 257 ---------------- | | Manufacturer | 258 | | | .... | 259 | | ---------------- 260 /|\ 0..1 | 261 ---------------- | -------------------- 262 | Key | | 0..1| CryptoModuleInfo | 263 |--------------| -----|------------------| 264 | Id | | Id | 265 | Algorithm | |.... | 266 | UserId | -------------------- 267 | Policy | 268 | .... | 269 ---------------- 270 | 271 | 272 /|\ 0..n 273 --------------------------------------- - - 274 | | | 275 ------------------ ---------------- -------- - - 276 | Data:Secret | | Data:Counter | | Data:other 277 |----------------| |--------------| |-- - - 278 | EncryptedValue | | PlainValue | 279 | ValueMAC | ---------------- 280 ------------------ 282 Figure 1: PSKC data elements relationship diagram 284 The following sections describe in detail all the entities and 285 related XML schema elements and attributes. 287 4. Element: The Basics 289 In its most basic form, a PSKC document uses the top-level element 290 and a single element to carry key 291 information. 293 The following example shows such a simple PSKC document. We will use 294 it to describe the structure of the element and its 295 child elements. 297 298 301 302 304 Issuer-A 305 306 307 MTIzNA== 308 309 310 311 312 313 315 Figure 2: Basic PSKC Key Container Example 317 The attributes of the element have the following 318 semantics: 320 'Version:' The 'Version' attribute is used to identify the version 321 of the PSKC schema version. This specification defines the 322 initial version ("1.0") of the PSKC schema. This attribute MUST 323 be included. 325 'Id:' The 'Id' attribute carries a unique identifier for the 326 container. As such, it helps to identify a specific key container 327 in cases when multiple containers are embedded in larger xml 328 documents. 330 4.1. : Embedding Keying Material and Key Related Information 332 The following attributes of the element MUST be included at a 333 minimum: 335 'Id': This attribute carries a globally unique identifier for the 336 symmetric key. The identifier is defined as a string of 337 alphanumeric characters. 339 'Algorithm': This attribute contains a unique identifier for the 340 PSKC algorithm profile. This profile associates specific 341 semantics to the elements and attributes contained in the 342 element. This document describes profiles for open standards 343 algorithms in Section 10. Additional profiles are defined in the 344 following information draft [PSKC-ALGORITHM-PROFILES]. 346 The element has a number of optional child elements. An 347 initial set is described below: 349 : This element represents the name of the party that issued 350 the key. For example, a bank "Foobar Bank Inc." issuing hardware 351 tokens to their retail banking users may set this element to 352 "Foobar Bank Inc.". 354 : A human readable name for the secret key for easier 355 reference. This element serves informational purposes only. 357 : This element carries parameters that 358 influence the result of the algorithmic computation, for example 359 response truncation and format in OTP and CR algorithms. A more 360 detailed discussion of the element can be found in Section 4.2.4. 362 : This element carries data about and related to the key. The 363 following child elements are defined for the element: 365 : This element carries the value of the key itself in a 366 binary representation. 368 : This element contains the event counter for event 369 based OTP algorithms. 371