idnits 2.17.1 draft-ietf-keyprov-pskc-00.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 'MUST not' in this paragraph: 'MaxFailedAttempts': This attribute indicates the maximum number of times the PIN can be entered wrongly before it MUST not be possible to use the key anymore. If the 'PinUsageMode'="Local" then the device MUST enforce this value, otherwise it MUST be enforced by the validation server. -- The document date (January 13, 2009) is 5582 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) == Unused Reference: 'PKCS1' is defined on line 1910, but no explicit reference was found in the text == Unused Reference: 'RFC3553' is defined on line 1923, but no explicit reference was found in the text == Unused Reference: 'AlgorithmURIs' is defined on line 1951, but no explicit reference was found in the text == Unused Reference: 'NIST-SP800-57' is defined on line 1968, but no explicit reference was found in the text == Unused Reference: 'OATH' is defined on line 1975, but no explicit reference was found in the text == Unused Reference: 'OCRA' is defined on line 1978, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'LUHN' ** Obsolete normative reference: RFC 2437 (ref. 'PKCS1') (Obsoleted by RFC 3447) -- 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 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC' -- Obsolete informational reference (is this intentional?): RFC 4051 (ref. 'AlgorithmURIs') (Obsoleted by RFC 6931) == Outdated reference: A later version (-14) exists of draft-mraihi-mutual-oath-hotp-variants-06 Summary: 5 errors (**), 0 flaws (~~), 9 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: July 17, 2009 VeriSign 6 S. Machani 7 Diversinet 8 January 13, 2009 10 Portable Symmetric Key Container (PSKC) 11 draft-ietf-keyprov-pskc-00.txt 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 17, 2009. 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 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This document specifies a symmetric key format for transport and 51 provisioning of symmetric keys (for example One Time Password (OTP) 52 shared secrets or symmetric cryptographic keys) to different types of 53 crypto modules, such as a strong authentication device. The standard 54 key transport format enables enterprises to deploy best-of-breed 55 solutions combining components from different vendors into the same 56 infrastructure. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Portable Key Container Entities Overview and Relationships . . 6 63 4. Element: The Basics . . . . . . . . . . . . . . 8 64 4.1. Element: Unique Device Identification . . . . 9 65 4.2. : Embedding Keying Material . . . . . . . . . . . . . 10 66 4.3. Element: User Identification . . . . . . . . . . . 11 67 4.4. Element: Supplementary Information for OTP and 68 CR Algorithms . . . . . . . . . . . . . . . . . . . . . . 12 69 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6. Protection of Keys and Related Data . . . . . . . . . . . . . 19 71 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 19 72 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 21 73 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 24 74 6.4. Transmission of Key Derivation Values . . . . . . . . . . 26 75 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 28 76 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 30 77 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33 78 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 34 79 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 80 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 34 81 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 36 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 83 12.1. Content-type registration for 'application/pskc+xml' . . . 43 84 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 44 85 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 44 86 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 45 87 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 46 88 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 46 89 13. Security Considerations . . . . . . . . . . . . . . . . . . . 47 90 13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 47 91 13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 48 92 13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 48 93 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49 94 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 96 16.1. Normative References . . . . . . . . . . . . . . . . . . . 51 97 16.2. Informative References . . . . . . . . . . . . . . . . . . 52 98 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 53 99 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 53 100 A.1.1. Transport of keys from Server to Cryptographic 101 Module . . . . . . . . . . . . . . . . . . . . . . . . 53 102 A.1.2. Transport of keys from Cryptographic Module to 103 Cryptographic Module . . . . . . . . . . . . . . . . . 53 104 A.1.3. Transport of keys from Cryptographic Module to 105 Server . . . . . . . . . . . . . . . . . . . . . . . . 54 106 A.1.4. Server to server Bulk import/export of keys . . . . . 54 107 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 54 108 A.2.1. Server to server Bulk import/export of keys . . . . . 54 109 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 56 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 112 1. Introduction 114 With increasing use of symmetric key based authentication systems 115 such as systems based one time password (OTP) and challenge response 116 mechanisms, there is a need for vendor interoperability and a 117 standard format for importing, exporting or provisioning symmetric 118 keys from one system to another. Traditionally authentication server 119 vendors and service providers have used proprietary formats for 120 importing, exporting and provisioning these keys into their systems 121 making it hard to use tokens from vendor A with a server from vendor 122 B. 124 This document describes a standard format for serializing symmetric 125 keys such as OTP shared secrets for system import, export or network/ 126 protocol transport. The goal is that the format will facilitate 127 dynamic provisioning and transfer of symmetric keys such as OTP 128 shared secrets or encryption keys of different types. In the case of 129 OTP shared secrets, the format will facilitate dynamic provisioning 130 using an online provisioning protocol to different flavors of 131 embedded tokens or allow customers to import new or existing tokens 132 in batch or single instances into a compliant system. 134 This draft also specifies the key attributes required for computation 135 such as the initial event counter used in the HOTP algorithm [HOTP]. 136 It is also applicable for other time-based or proprietary algorithms. 138 To provide an analogy, in public key environments the PKCS#12 format 139 [PKCS12] is commonly used for importing and exporting private keys 140 and certificates between systems. In the environments outlined in 141 this document where OTP keys may be transported directly down to 142 smartcards or devices with limited computing capabilities and 143 explicit shared secret, configuration attribute information is 144 desirable. With PKCS#12, one would have to use opaque data to carry 145 shared secret attributes used for OTP calculations, whereas a more 146 explicit attribute schema definition is better for interoperability 147 and efficiency. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 In subsequent sections of the document we highlight mandatory 156 elements and attributes. Optional elements and attributes are not 157 explicitly indicated. 159 3. Portable Key Container Entities Overview and Relationships 161 The portable key container is based on an XML schema definition and 162 contains the following main conceptual entities: 164 1. KeyContainer entity - representing the container that carries the 165 keys 167 2. Device entity - representing a physical or virtual device where 168 the keys reside optionally bound to a specific user 170 3. DeviceInfo entity - representing the information about the device 171 and criteria to uniquely identify the device 173 4. Key entity - representing the key transmitted 175 5. KeyData entity - representing data related to the key including 176 value either in plain or encrypted 178 The figure below represents the entity relationship diagram (brackets 179 () denote optional elements). 181 ----------------- 182 | KeyContainer | 183 |---------------| 184 | EncryptionKey | 185 | Signature | 186 | ... | 187 ----------------- 188 | 189 | 190 /|\ 1..n 191 ---------------- ---------------- 192 | Device | 1| DeviceInfo | 193 |--------------|-----|--------------| 194 | (User) | | SerialNumber | 195 ---------------- | Manufacturer | 196 | | .... | 197 | ---------------- 198 /|\ 1..n 199 ---------------- 200 | Key | 201 |--------------| 202 | ID | 203 | Algorithm | 204 | (User) | 205 | .... | 206 ---------------- 207 | 208 | 209 /|\ 1..n -------------- 210 ---------------- | Plainvalue | 211 | KeyData | -------------- 212 |--------------| | 213 | name | either| 214 | value |----------| 215 | ..... | ------------------ 216 ---------------- | EncryptedValue | 217 ------------------ 219 The following sections describe in detail all the entities and 220 related XML schema elements and attributes. 222 4. Element: The Basics 224 In it's most basic form a PSKC document uses the top-level element 225 and a single element to carry key 226 information. 228 The following example shows such a simple PSKC document. We will use 229 it to describe the structure of the element and it's 230 child elements. 232 233 235 236 237 Manufacturer 238 987654321 239 240 242 Issuer 243 244 245 246 247 248 MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= 249 250 251 252 0 253 254 255 256 257 259 Figure 1: Basic PSKC Key Container Example 261 The attributes of the element have the following 262 semantic: 264 'Version:' The 'Version' attribute is used to identify the version 265 of the PSKC schema version. This specification defines the 266 initial version ("1") of the PSKC schema. This attribute is 267 mandatory. 269 'ID:' The 'ID' attribute carries a unique identifier for the 270 container. This is useful when needing to refer to an individual 271 key container when more than one container is embedded into a 272 larger XML document. 274 A element MUST contain at least one elements. 275 Multiple elements may be used when for bulk provisioning, 276 see Section 8. A MUST contain at least one element. 277 A MAY be bound to a user. A key SHOULD be bound to only one 278 element. 280 4.1. Element: Unique Device Identification 282 The element allows to uniquely identify the device the 283 element refers to. Since devices can come in different form 284 factors, such as hardware tokens, smart-cards, soft tokens in a 285 mobile phone or as a PC, this element allows different criteria to be 286 used. Combined though the criteria MUST uniquely identify the 287 device. For example, for hardware tokens the combination of SerialNo 288 and Manufacturer will uniquely identify a device but not SerialNo 289 alone since two different token manufacturers might issue devices 290 with the same serial number (similar to the IssuerDN and serial 291 number of a certificate). Symmetric keys used in the payment 292 industry are usually stored on Integrated Circuit Smart Cards. 294 The element has the following child elements: 296 : This element indicates the manufacturer of the 297 device. 299 : This element contains the serial number of the device 301 : This element describes the model of the device (e.g., one- 302 button-HOTP-token-V1) 304 : This element contains the issue number in case devices 305 with the same serial number that are distinguished by different 306 issue numbers 308 : This element carries the identifier that can be 309 used to bind keys to the device or class of device. When loading 310 keys into a device, this identifier can be checked against 311 information obtained from the device to ensure that the correct 312 device or class of device is being used. 314 : This element indicates the start date of a device (such 315 as the one on a payment card, used when issue numbers are not 316 printed on cards). The date MUST be expressed in UTC form with no 317 timezone component. Implementations SHOULD NOT rely on time 318 resolution finer than milliseconds and MUST NOT generate time 319 instants that specify leap seconds. 321 : This field contains the expiry date of a device (such 322 as the one on a payment card, used when issue numbers are not 323 printed on cards). It MUST be expressed in UTC form with no 324 timezone component. Implementations SHOULD NOT rely on time 325 resolution finer than milliseconds and MUST NOT generate time 326 instants that specify leap seconds. 328 4.2. : Embedding Keying Material 330 The following attributes of the element MUST be included at a 331 minimum: 333 'KeyId': This attribute carries a globally unique identifier for the 334 symmetric key. The identifier is defined as a string of 335 alphanumeric characters. 337 'KeyAlgorithm': This attribute contains a unique identifier for the 338 PSKC algorithm profile. This profile associates a specific 339 semantic to the elements and attributes contained in the 340 element. More information about the PSKC algorithm profile 341 defined in this document can be found in Section 10. 343 The element has a number of optional child elements. An 344 initial set is described below: 346 : The key issuer name, this is normally the name of the 347 organization that issues the key to the end user of the key. For 348 example MyBank issuing hardware tokens to their retail banking 349 users 'MyBank' would be the issuer. 351 : A human readable name for the secret key for easier 352 reference. This element serves informational purposes only. 354 : This element defines the intended usage of the key and 355 related metadata as defined in Section 4.4 There are cases where 356 the specific context in which the key is used can be inferred but 357 typically the context is provided explicitly. 359 : This element carries data about and related to the key. 360 Further description about the element can be found 361 subsequent to this list. 363 This document defines a few child element for the element, 364 namely 366 : This element carries the value of the key itself in a 367 binary representation. 369 : This element contains the event counter for event based 370 OTP algorithms. 372