idnits 2.17.1 draft-ietf-keyprov-pskc-01.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 -- The document date (January 20, 2009) is 5572 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' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 24, 2009 VeriSign 6 S. Machani 7 Diversinet 8 January 20, 2009 10 Portable Symmetric Key Container (PSKC) 11 draft-ietf-keyprov-pskc-01.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 24, 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 . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6. Protection of Keys and Related Data . . . . . . . . . . . . . 18 71 6.1. Encryption based on Pre-Shared Keys . . . . . . . . . . . 18 72 6.2. Encryption based on Passphrase-based Keys . . . . . . . . 20 73 6.3. Encryption based on Asymmetric Keys . . . . . . . . . . . 23 74 6.4. Transmission of Key Derivation Values . . . . . . . . . . 25 75 7. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 27 76 8. Bulk Provisioning . . . . . . . . . . . . . . . . . . . . . . 29 77 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 32 78 10. PSKC Algorithm Profile . . . . . . . . . . . . . . . . . . . . 33 79 10.1. HOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 80 10.2. KEYPROV-PIN . . . . . . . . . . . . . . . . . . . . . . . 33 81 11. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 35 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 83 12.1. Content-type registration for 'application/pskc+xml' . . . 42 84 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 43 85 12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 43 86 12.4. PSKC Algorithm Profile Registry . . . . . . . . . . . . . 44 87 12.5. PSKC Version Registry . . . . . . . . . . . . . . . . . . 45 88 12.6. Key Usage Registry . . . . . . . . . . . . . . . . . . . . 45 89 13. Security Considerations . . . . . . . . . . . . . . . . . . . 46 90 13.1. Payload confidentiality . . . . . . . . . . . . . . . . . 46 91 13.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 47 92 13.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 47 93 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 94 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 96 16.1. Normative References . . . . . . . . . . . . . . . . . . . 50 97 16.2. Informative References . . . . . . . . . . . . . . . . . . 50 98 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 52 99 A.1. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 52 100 A.1.1. Transport of keys from Server to Cryptographic 101 Module . . . . . . . . . . . . . . . . . . . . . . . . 52 102 A.1.2. Transport of keys from Cryptographic Module to 103 Cryptographic Module . . . . . . . . . . . . . . . . . 52 104 A.1.3. Transport of keys from Cryptographic Module to 105 Server . . . . . . . . . . . . . . . . . . . . . . . . 53 106 A.1.4. Server to server Bulk import/export of keys . . . . . 53 107 A.2. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 53 108 A.2.1. Server to server Bulk import/export of keys . . . . . 53 109 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 55 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 112 1. Introduction 114 With increasing use of symmetric key based authentication systems, 115 such as those based one time password (OTP) and challenge response 116 mechanisms, there is a need for vendor interoperability and a 117 standard format for importing and exporting (provisioning) symmetric 118 keys. Traditionally, vendors of authentication servers and service 119 providers have used proprietary formats for importing and exporting 120 these keys into their systems making it hard to use tokens from 121 vendor "Foo" with a server from vendor "Bar". 123 This document proposes a standardized XML-based key container, called 124 Portable Symmetric Key Container (PSKC), for transporting symmetric 125 keys and meta data. This document also specifies the information 126 elements that are required for computing the initial event counter 127 used by the MAC-Based One Time Password Algorithm (HOTP) algorithm 128 [HOTP] and these elements are also applicable for other time-based 129 algorithms. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 NOTE: In subsequent sections of the document we highlight 138 **mandatory** XML elements and attributes. Optional elements and 139 attributes are not explicitly indicated, i.e., if it does not say 140 mandatory it is optional. 142 3. Portable Key Container Entities Overview and Relationships 144 The portable key container is based on an XML schema definition and 145 contains the following main conceptual entities: 147 1. KeyContainer entity - representing the container that carries the 148 keys 150 2. Device entity - representing a physical or virtual device where 151 the keys reside optionally bound to a specific user 153 3. DeviceInfo entity - representing the information about the device 154 and criteria to uniquely identify the device 156 4. Key entity - representing the key transmitted 158 5. KeyData entity - representing data related to the key including 159 value either in plain or encrypted 161 Figure 1 shows the high-level structure of the PSKC data elements. 163 ----------------- 164 | KeyContainer | 165 |---------------| 166 | EncryptionKey | 167 | Signature | 168 | ... | 169 ----------------- 170 | 171 | 172 /|\ 1..n 173 ---------------- ---------------- 174 | Device | 1| DeviceInfo | 175 |--------------|-----|--------------| 176 | User | | SerialNumber | 177 ---------------- | Manufacturer | 178 | | .... | 179 | ---------------- 180 /|\ 1..n 181 ---------------- 182 | Key | 183 |--------------| 184 | ID | 185 | Algorithm | 186 | User | 187 | .... | 188 ---------------- 189 | 190 | 191 /|\ 1..n -------------- 192 ---------------- | Plainvalue | 193 | KeyData | -------------- 194 |--------------| | 195 | name | either| 196 | value |----------| 197 | ..... | ------------------ 198 ---------------- | EncryptedValue | 199 ------------------ 201 Figure 1 203 The following sections describe in detail all the entities and 204 related XML schema elements and attributes. 206 4. Element: The Basics 208 In it's most basic form a PSKC document uses the top-level element 209 and a single element to carry key 210 information. 212 The following example shows such a simple PSKC document. We will use 213 it to describe the structure of the element and it's 214 child elements. 216 217 219 220 221 Manufacturer 222 987654321 223 224 226 Issuer 227 228 229 230 231 232 MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= 233 234 235 236 0 237 238 239 240 241 243 Figure 2: Basic PSKC Key Container Example 245 The attributes of the element have the following 246 semantic: 248 'Version:' The 'Version' attribute is used to identify the version 249 of the PSKC schema version. This specification defines the 250 initial version ("1") of the PSKC schema. This attribute is 251 mandatory. 253 'ID:' The 'ID' attribute carries a unique identifier for the 254 container. As such, it helps to identify a specific key 255 container. 257 A element MUST contain at least one element. 258 Multiple elements can be used when for bulk provisioning, 259 see Section 8. A MUST contain at least one element. 260 A MAY be bound to a user. A key SHOULD be bound to only one 261 element. 263 4.1. Element: Unique Device Identification 265 The element uniquely identifies the device the 266 element refers to. Since devices can come in different form factors, 267 such as hardware tokens, smart-cards, soft tokens in a mobile phone 268 or as a PC, this element allows different criteria to be used. 269 Combined though the criteria MUST uniquely identify the device. For 270 example, for hardware tokens the combination of and 271 elements uniquely identifies a device but the 272 element alone is insufficient since two different token 273 manufacturers might issue devices with the same serial number 274 (similar to the Issuer Distinguished Name and serial number of a 275 certificate). 277 The element has the following child elements: 279 : This element indicates the manufacturer of the 280 device. 282 : This element contains the serial number of the device. 284 : This element describes the model of the device (e.g., one- 285 button-HOTP-token-V1). 287 : This element contains the issue number in case devices 288 with the same serial number that are distinguished by different 289 issue numbers. 291 : This element carries the identifier that can be 292 used to bind keys to the device or to a class of devices. When 293 loading keys into a device, this identifier can be checked against 294 information obtained from the device to ensure that the correct 295 device or class of device is being used. 297 : and : These two elements indicates the 298 start and end date of a device (such as the one on a payment card, 299 used when issue numbers are not printed on cards). The date MUST 300 be expressed in UTC form with no timezone component. 302 Implementations SHOULD NOT rely on time resolution finer than 303 milliseconds and MUST NOT generate time instants that specify leap 304 seconds. 306 Depending on the device type certain child elements of the 307 element are necessary to include in order to uniquely 308 identify a device. This document does not enumerate the different 309 device types and therefore does not list the elements that are 310 mandatory for each type of device. 312 4.2. : Embedding Keying Material 314 The following attributes of the element MUST be included at a 315 minimum: 317 'KeyId': This attribute carries a globally unique identifier for the 318 symmetric key. The identifier is defined as a string of 319 alphanumeric characters. 321 'KeyAlgorithm': This attribute contains a unique identifier for the 322 PSKC algorithm profile. This profile associates a specific 323 semantic to the elements and attributes contained in the 324 element. More information about the PSKC algorithm profile 325 defined in this document can be found in Section 10. 327 The element has a number of optional child elements. An 328 initial set is described below: 330 : This element represents the name of the party that issued 331 the key. For example, a bank "Foobar Bank Inc." issuing hardware 332 tokens to their retail banking users may set this element to 333 "Foobar Bank Inc.". 335 : A human readable name for the secret key for easier 336 reference. This element serves informational purposes only. 338 : This element provides supplementary information for usage 339 with OTP and CR algorithms. A more detailed discussion of the 340 element can be found in Section 4.4. 342 : This element carries data about and related to the key. The 343 follow child elements are defined for the element: 345 : This element carries the value of the key itself in a 346 binary representation. 348 : This element contains the event counter for event 349 based OTP algorithms. 351