idnits 2.17.1 draft-ietf-keyprov-dskpp-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 102 pages 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 7, 2010) is 4977 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) == Missing Reference: 'DeviceID' is mentioned on line 1686, but not defined == Missing Reference: 'KeyID' is mentioned on line 1686, but not defined == Missing Reference: 'AD' is mentioned on line 1237, but not defined == Missing Reference: 'K' is mentioned on line 1298, but not defined == Missing Reference: 'MAC' is mentioned on line 1298, but not defined == Missing Reference: 'RFC5226' is mentioned on line 3156, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-SHA' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197-AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3309' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS-5' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS-5-XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'PSKC' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Downref: Normative reference to an Informational RFC: RFC 5649 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLENC' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KEYPROV Working Group A. Doherty 3 Internet-Draft RSA, The Security Division of EMC 4 Intended status: Standards Track M. Pei 5 Expires: March 11, 2011 VeriSign, Inc. 6 S. Machani 7 Diversinet Corp. 8 M. Nystrom 9 Microsoft Corp. 10 September 7, 2010 12 Dynamic Symmetric Key Provisioning Protocol (DSKPP) 13 draft-ietf-keyprov-dskpp-14.txt 15 Abstract 17 DSKPP is a client-server protocol for initialization (and 18 configuration) of symmetric keys to locally and remotely accessible 19 cryptographic modules. The protocol can be run with or without 20 private-key capabilities in the cryptographic modules, and with or 21 without an established public-key infrastructure. 23 Two variations of the protocol support multiple usage scenarios. 24 With the four-pass variant, keys are mutually generated by the 25 provisioning server and cryptographic module; provisioned keys are 26 not transferred over-the-wire or over-the-air. The two-pass variant 27 enables secure and efficient download and installation of pre- 28 generated symmetric keys to a cryptographic module. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 11, 2011. 47 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 Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 76 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1.2. Version Support . . . . . . . . . . . . . . . . . . . . . 6 78 1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 7 79 1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 7 80 1.3.2. Identifiers Defined in Related Specifications . . . . 7 81 1.3.3. Referenced Identifiers . . . . . . . . . . . . . . . 7 82 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 84 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 10 85 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 11 86 3. DSKPP Overview . . . . . . . . . . . . . . . . . . . . . . . 11 87 3.1. Protocol Entities . . . . . . . . . . . . . . . . . . . . 11 88 3.2. Basic DSKPP Exchange . . . . . . . . . . . . . . . . . . 12 89 3.2.1. User Authentication . . . . . . . . . . . . . . . . . 12 90 3.2.2. Protocol Initiated by the DSKPP Client . . . . . . . 13 91 3.2.3. Protocol Triggered by the DSKPP Server . . . . . . . 15 92 3.2.4. Variants . . . . . . . . . . . . . . . . . . . . . . 16 93 3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 17 94 3.4. Basic Constructs . . . . . . . . . . . . . . . . . . . . 18 95 3.4.1. User Authentication Data, AD . . . . . . . . . . . . 19 96 3.4.2. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF . 23 97 3.4.3. The DSKPP Message Hash Algorithm . . . . . . . . . . 23 98 4. Four-Pass Protocol Usage . . . . . . . . . . . . . . . . . . 24 99 4.1. The Key Agreement Mechanism . . . . . . . . . . . . . . . 24 100 4.1.1. Data Flow . . . . . . . . . . . . . . . . . . . . . . 24 101 4.1.2. Computation . . . . . . . . . . . . . . . . . . . . . 26 102 4.2. Message Flow . . . . . . . . . . . . . . . . . . . . . . 27 103 4.2.1. KeyProvTrigger . . . . . . . . . . . . . . . . . . . 27 104 4.2.2. KeyProvClientHello . . . . . . . . . . . . . . . . . 28 105 4.2.3. KeyProvServerHello . . . . . . . . . . . . . . . . . 29 106 4.2.4. KeyProvClientNonce . . . . . . . . . . . . . . . . . 31 107 4.2.5. KeyProvServerFinished . . . . . . . . . . . . . . . . 33 108 5. Two-Pass Protocol Usage . . . . . . . . . . . . . . . . . . . 34 109 5.1. Key Protection Methods . . . . . . . . . . . . . . . . . 35 110 5.1.1. Key Transport . . . . . . . . . . . . . . . . . . . . 35 111 5.1.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 35 112 5.1.3. Passphrase-Based Key Wrap . . . . . . . . . . . . . . 36 113 5.2. Message Flow . . . . . . . . . . . . . . . . . . . . . . 37 114 5.2.1. KeyProvTrigger . . . . . . . . . . . . . . . . . . . 37 115 5.2.2. KeyProvClientHello . . . . . . . . . . . . . . . . . 37 116 5.2.3. KeyProvServerFinished . . . . . . . . . . . . . . . . 42 117 6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 43 118 6.1. The ClientInfoType Extension . . . . . . . . . . . . . . 44 119 6.2. The ServerInfoType Extension . . . . . . . . . . . . . . 44 120 7. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 44 121 7.1. General Requirements . . . . . . . . . . . . . . . . . . 44 122 7.2. HTTP/1.1 Binding for DSKPP . . . . . . . . . . . . . . . 44 123 7.2.1. Identification of DSKPP Messages . . . . . . . . . . 45 124 7.2.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . 45 125 7.2.3. HTTP Operations . . . . . . . . . . . . . . . . . . . 45 126 7.2.4. HTTP Status Codes . . . . . . . . . . . . . . . . . . 46 127 7.2.5. HTTP Authentication . . . . . . . . . . . . . . . . . 46 128 7.2.6. Initialization of DSKPP . . . . . . . . . . . . . . . 46 129 7.2.7. Example Messages . . . . . . . . . . . . . . . . . . 47 130 8. DSKPP XML Schema . . . . . . . . . . . . . . . . . . . . . . 47 131 8.1. General Processing Requirements . . . . . . . . . . . . . 47 132 8.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 48 133 9. Conformance Requirements . . . . . . . . . . . . . . . . . . 56 134 10. Security Considerations . . . . . . . . . . . . . . . . . . . 58 135 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 58 136 10.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 58 137 10.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 58 138 10.2.2. Message Modifications . . . . . . . . . . . . . . . . 58 139 10.2.3. Message Deletion . . . . . . . . . . . . . . . . . . 60 140 10.2.4. Message Insertion . . . . . . . . . . . . . . . . . . 60 141 10.2.5. Message Replay . . . . . . . . . . . . . . . . . . . 60 142 10.2.6. Message Reordering . . . . . . . . . . . . . . . . . 61 143 10.2.7. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 61 144 10.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 61 145 10.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 61 146 10.5. Attacks on the Interaction between DSKPP and User 147 Authentication . . . . . . . . . . . . . . . . . . . . . 62 148 10.6. Miscellaneous Considerations . . . . . . . . . . . . . . 62 149 10.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 63 150 10.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . 63 151 10.6.3. Server Authentication . . . . . . . . . . . . . . . . 63 152 10.6.4. User Authentication . . . . . . . . . . . . . . . . . 63 153 10.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . 64 154 10.6.6. Algorithm Agility . . . . . . . . . . . . . . . . . . 65 155 11. Internationalization Considerations . . . . . . . . . . . . . 65 156 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 157 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 66 158 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 66 159 12.3. MIME Media Type Registration . . . . . . . . . . . . . . 66 160 12.4. Status Code Registration . . . . . . . . . . . . . . . . 67 161 12.5. DSKPP Version Registration . . . . . . . . . . . . . . . 68 162 12.6. PRF Algorithm ID Sub-Registry . . . . . . . . . . . . . . 68 163 12.6.1. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . 69 164 12.6.2. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . 69 165 12.7. Key Container Registration . . . . . . . . . . . . . . . 69 166 13. Intellectual Property Considerations . . . . . . . . . . . . 70 167 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 71 168 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71 169 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 170 16.1. Normative references . . . . . . . . . . . . . . . . . . 72 171 16.2. Informative references . . . . . . . . . . . . . . . . . 74 172 Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . 75 173 A.1. Single Key Request . . . . . . . . . . . . . . . . . . . 75 174 A.2. Multiple Key Requests . . . . . . . . . . . . . . . . . . 76 175 A.3. User Authentication . . . . . . . . . . . . . . . . . . . 76 176 A.4. Provisioning Time-Out Policy . . . . . . . . . . . . . . 76 177 A.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . . . 76 178 A.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . . . 76 179 A.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . . . 77 180 A.8. End-to-End Protection of Key Material . . . . . . . . . . 77 181 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 77 182 B.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 78 183 B.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . 78 184 B.2.1. Without a Preceding Trigger . . 78 185 B.2.2. Assuming a Preceding Trigger . . 79 186 B.2.3. Without a Preceding Trigger . . 81 187 B.2.4. Assuming Key Renewal . . . . . . 82 188 B.2.5. Using Default Encryption . . . . 82 189 B.2.6. Using Default Encryption . . 83 190 B.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 84 191 B.3.1. Example Using the Key Transport Method . . . . . . . 84 192 B.3.2. Example Using the Key Wrap Method . . . . . . . . . . 88 193 B.3.3. Example Using the Passphrase-Based Key Wrap Method . 91 194 Appendix C. Integration with PKCS #11 . . . . . . . . . . . . . 95 195 C.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . 96 196 C.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . 96 197 Appendix D. Example of DSKPP-PRF Realizations . . . . . . . . . 98 198 D.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 98 199 D.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 98 200 D.2.1. Identification . . . . . . . . . . . . . . . . . . . 98 201 D.2.2. Definition . . . . . . . . . . . . . . . . . . . . . 99 202 D.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 100 203 D.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . 100 204 D.3.1. Identification . . . . . . . . . . . . . . . . . . . 100 205 D.3.2. Definition . . . . . . . . . . . . . . . . . . . . . 100 206 D.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 101 207 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102 209 1. Introduction 211 Symmetric key based cryptographic systems (e.g., those providing 212 authentication mechanisms such as one-time passwords and challenge- 213 response) offer performance and operational advantages over public 214 key schemes. Such use requires a mechanism for provisioning of 215 symmetric keys providing equivalent functionality to mechanisms such 216 as CMP [RFC4210] and CMC [RFC5272] in a Public Key Infrastructure. 218 Traditionally, cryptographic modules have been provisioned with keys 219 during device manufacturing, and the keys have been imported to the 220 cryptographic server using, e.g., a CD-ROM disc shipped with the 221 devices. Some vendors also have proprietary provisioning protocols, 222 which often have not been publicly documented (CT-KIP is one 223 exception [RFC4758]). 225 This document describes the Dynamic Symmetric Key Provisioning 226 Protocol (DSKPP), a client-server protocol for provisioning symmetric 227 keys between a cryptographic module (corresponding to DSKPP client) 228 and a key provisioning server (corresponding to DSKPP server). 230 DSKPP provides an open and interoperable mechanism for initializing 231 and configuring symmetric keys to cryptographic modules that are 232 accessible over the Internet. The description is based on the 233 information contained in [RFC4758], and contains specific 234 enhancements, such as User Authentication and support for the [PSKC] 235 format for transmission of keying material. 237 DSKPP has two principal protocol variants. The four-pass protocol 238 variant permits a symmetric key to be established that includes 239 randomness contributed by both the client and the server. The two- 240 pass protocol requires only one round trip instead of two and permits 241 a server specified key to be established. 243 1.1. Key Words 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in [RFC2119]. 249 1.2. Version Support 251 There is a provision made in the syntax for an explicit version 252 number. Only version "1.0" is currently specified. 254 The purpose for versioning the protocol is to provide a mechanism by 255 which changes to required cryptographic algorithms (e.g., SHA-256) 256 and attributes (e.g., key size) can be deployed without disrupting 257 existing implementations; likewise, out-dated implementations can be 258 de-commissioned without disrupting operations involving newer 259 protocol versions. 261 The numbering scheme for DSKPP versions is ".". The 262 major and minor numbers MUST be treated as separate integers and each 263 number MAY be incremented higher than a single digit. Thus, "DSKPP 264 2.4" would be a lower version than "DSKPP 2.13", which in turn would 265 be lower than "DSKPP 12.3". Leading zeros (e.g., "DSKPP 6.01") MUST 266 be ignored by recipients and MUST NOT be sent. 268 The major version number should be incremented only if the data 269 formats or security algorithms have changed so dramatically that an 270 older version implementation would not be able to interoperate with a 271 newer version (e.g., removing support for a previously mandatory-to- 272 implement algorithm now found to be insecure). The minor version 273 number indicates new capabilities (e.g., introducing a new algorithm 274 option) and MUST be ignored by an entity with a smaller minor version 275 number, but used for informational purposes by the entity with the 276 larger minor version number. 278 1.3. Namespace Identifiers 280 This document uses Uniform Resource Identifiers [RFC3986] to identify 281 resources, algorithms, and semantics. 283 1.3.1. Defined Identifiers 285 The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is: 287 "urn:ietf:params:xml:ns:keyprov:dskpp" 289 References to qualified elements in the DSKPP schema defined herein 290 use the prefix "dskpp", but any prefix is allowed. 292 1.3.2. Identifiers Defined in Related Specifications 294 This document relies on qualified elements already defined in the 295 Portable Symmetric Key Container [PSKC] namespace, which is 296 represented by the prefix "pskc" and declared as: 298 xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" 300 1.3.3. Referenced Identifiers 302 Finally, the DSKPP syntax presented in this document relies on 303 algorithm identifiers defined in the XML Signature [XMLDSIG] 304 namespace: 306 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 308 References to algorithm identifiers in the XML Signature namespace 309 are represented by the prefix "ds". 311 2. Terminology 313 2.1. Definitions 315 The definitions provided below are defined as used in this document. 316 The same terms may be defined differently in other documents. 318 Authentication Code (AC): User Authentication Code comprised of a 319 string of hexadecimal characters known to the device and the 320 server and containing at a minimum a client identifier and a 321 password. This ClientID/password combination is used only once 322 and may have a time limit, and then discarded. 324 Authentication Data (AD): User Authentication Data that is derived 325 from the Authentication Code (AC) 327 Client ID: An identifier that the DSKPP Server uses to locate the 328 real user name or account identifier on the server. It can be a 329 short random identifier that is unrelated to any real usernames. 331 Cryptographic Module: A component of an application, which enables 332 symmetric key cryptographic functionality 334 Device: A physical piece of hardware, or a software framework, that 335 hosts symmetric key cryptographic modules 337 Device ID (DeviceID): A unique identifier for the device that houses 338 the cryptographic module, e.g., a mobile phone 340 DSKPP Client: Manages communication between the symmetric key 341 cryptographic module and the DSKPP server 343 DSKPP Server: The symmetric key provisioning server that 344 participates in the DSKPP protocol run 346 DSKPP Server ID (ServerID): The unique identifier of a DSKPP server 348 Key Agreement: A key establishment protocol whereby two or more 349 parties can agree on a key in such a way that both influence the 350 outcome 352 Key Confirmation: The assurance of the rightful participants in a 353 key-establishment protocol that the intended recipient of the 354 shared key actually possesses the shared key 356 Key Issuer: An organization that issues symmetric keys to end-users 358 Key Package (KP): An object that encapsulates a symmetric key and 359 its configuration data 361 Key ID (KeyID): A unique identifier for the symmetric key 363 Key Protection Method (KPM): The key transport method used during 364 two-pass DSKPP 366 Key Protection Method List (KPML): The list of key protection 367 methods supported by a cryptographic module 369 Key Provisioning Server: A lifecycle management system that provides 370 a key issuer with the ability to provision keys to cryptographic 371 modules hosted on end-users' devices 373 Key Transport: A key establishment procedure whereby the DSKPP 374 server selects and encrypts the keying material and then sends 375 the material to the DSKPP client [NIST-SP800-57] 377 Key Transport Key: The private key that resides on the cryptographic 378 module. This key is paired with the DSKPP client's public key, 379 which the DSKPP server uses to encrypt keying material during key 380 transport [NIST-SP800-57] 382 Key Type: The type of symmetric key cryptographic methods for which 383 the key will be used (e.g., OATH HOTP or RSA SecurID 384 authentication, AES encryption, etc.) 386 Key Wrapping: A method of encrypting keys for key transport 387 [NIST-SP800-57] 389 Key Wrapping Key: A symmetric key encrypting key used for key 390 wrapping [NIST-SP800-57] 392 Keying Material: The data necessary (e.g., keys and key 393 configuration data) necessary to establish and maintain 394 cryptographic keying relationships [NIST-SP800-57] 396 Manufacturer's Key A unique master key pre-issued to a hardware 397 device, e.g., a smart card, during the manufacturing process. If 398 present, this key may be used by a cryptographic module to derive 399 secret keys 401 Protocol Run: Complete execution of the DSKPP that involves one 402 exchange (2-pass) or two exchanges (4-pass) 404 Security Attribute List (SAL): A payload that contains the DSKPP 405 version, DSKPP variant (four- or two-pass), key package formats, 406 key types, and cryptographic algorithms that the cryptographic 407 module is capable of supporting 409 2.2. Notation 411 || String concatenation 412 [x] Optional element x 413 A ^ B Exclusive-OR operation on strings A and B (where 414 A and B are of equal length) 415 A typographical convention used in the body of 416 the text 417 DSKPP-PRF(k,s,dsLen) A keyed pseudo-random function 418 E(k,m) Encryption of m with the key k 419 K Key used to encrypt R_C (either K_SERVER or 420 K_SHARED), or in MAC or DSKPP_PRF computations 421 K_AC Secret key that is derived from the 422 Authentication Code and used for user 423 authentication purposes 424 K_MAC Secret key derived during a DSKPP exchange for 425 use with key confirmation 426 K_MAC' A second secret key used for server 427 authentication 428 K_PROV A provisioning master key from which two keys are 429 derived: K_TOKEN and K_MAC 430 K_SERVER Public key of the DSKPP server; used for 431 encrypting R_C in the four-pass protocol variant 432 K_SHARED Secret key that is pre-shared between the DSKPP 433 client and the DSKPP server; used for encrypting 434 R_C in the four-pass protocol variant 435 K_TOKEN Secret key that is established in a cryptographic 436 module using DSKPP 437 R Pseudorandom value chosen by the DSKPP client and 438 used for MAC computations 440 R_C Pseudorandom value chosen by the DSKPP client and 441 used as input to the generation of K_TOKEN 442 R_S Pseudorandom value chosen by the DSKPP server and 443 used as input to the generation of K_TOKEN 444 URL_S DSKPP server address, as a URL 446 2.3. Abbreviations 448 AC Authentication Code 449 AD Authentication Data 450 DSKPP Dynamic Symmetric Key Provisioning Protocol 451 HTTP Hypertext Transfer Protocol 452 KP Key Package 453 KPM Key Protection Method 454 KPML Key Protection Method List 455 MAC Message Authentication Code 456 PC Personal Computer 457 PDU Protocol Data Unit 458 PKCS Public-Key Cryptography Standards 459 PRF Pseudo-Random Function 460 PSKC Portable Symmetric Key Container 461 SAL Security Attribute List (see Section 2.1) 462 TLS Transport Layer Security 463 URL Uniform Resource Locator 464 USB Universal Serial Bus 465 XML eXtensible Markup Language 467 3. DSKPP Overview 469 The following sub-sections provide a high-level view of protocol 470 internals and how they interact with external provisioning 471 applications. Usage scenarios are provided in Appendix A. 473 3.1. Protocol Entities 475 A DSKPP provisioning transaction has three entities: 477 Server: The DSKPP provisioning server. 479 Cryptographic Module: The cryptographic module to which the 480 symmetric keys are to be provisioned, e.g., an authentication 481 token. 483 Client: The DSKPP client which manages communication between the 484 cryptographic module and the key provisioning server. 486 The principal syntax is XML [XML] and it is layered on a transport 487 mechanism such as HTTP [RFC2616] and HTTP Over TLS [RFC2818]. While 488 it is highly desirable for the entire communication between the DSKPP 489 client and server to be protected by means of a transport providing 490 confidentiality and integrity protection such as HTTP over Transport 491 Layer Security (TLS), such protection is not sufficient to protect 492 the exchange of the symmetric key data between the server and the 493 cryptographic module and the DSKPP protocol is designed to permit 494 implementations that satisfy this requirement. 496 The server only communicates to the client. As far as the server is 497 concerned, the client and cryptographic module may be considered to 498 be a single entity. 500 From a client-side security perspective, however, the client and the 501 cryptographic module are separate logical entities and may in some 502 implementations be separate physical entities as well. 504 It is assumed that a device will host an application layered above 505 the cryptographic module, and this application will manage 506 communication between the DSKPP client and cryptographic module. The 507 manner in which the communicating application will transfer DSKPP 508 protocol elements to and from the cryptographic module is transparent 509 to the DSKPP server. One method for this transfer is described in 510 [CT-KIP-P11]. 512 3.2. Basic DSKPP Exchange 514 3.2.1. User Authentication 516 In a DSKPP message flow, the user has obtained a new hardware or 517 software device embedded with a cryptographic module. The goal of 518 DSKPP is to provision the same symmetric key and related information 519 to the cryptographic module and the key management server, and 520 associate the key with the correct user name (or other account 521 identifier) on the server. To do this, the DSKPP Server MUST 522 authenticate the user to be sure he is authorized for the new key. 524 User authentication occurs within the protocol itself after__ the 525 DSKPP client initiates the first message. In this case, the DSKPP 526 client MUST have access to the DSKPP Server URL. 528 Alternatively, a DSKPP web service or other form of web application 529 can authenticate a user before__ the first message is exchanged. In 530 this case, the DSKPP server MUST trigger the DSKPP client to initiate 531 the first message in the protocol transaction. 533 3.2.2. Protocol Initiated by the DSKPP Client 535 In the following example, the DSKPP client first initiates DSKPP, and 536 then the user is authenticated using a Client ID and Authentication 537 Code. 538 Crypto DSKPP DSKPP Key Provisioning 539 Module Client Server Server 540 | | | | 541 | | | +---------------+ 542 | | | |Server creates | 543 | | | |and stores | 544 | | | |Client ID and | 545 | | | |Auth. Code and | 546 | | | |delivers them | 547 | | | |to user out-of-| 548 | | | |band. | 549 | | | +---------------+ 550 | | | | 551 | +----------------------+ | | 552 | |User enters Client ID,| | | 553 | |Auth. Code, and URL | | | 554 | +----------------------+ | | 555 | | | | 556 | |<-- 1. TLS handshake with --->| | 557 | | server auth. | | 558 | | | | 559 | | 2. ---->| User -->| 560 | | | Auth. | 561 | |<-- [3. ] | | 562 | | | | 563 | | [4. ] -->| | 564 | | | | 565 | |<- 5. | | 566 | | | | 567 | | | | 568 |<-- Key | | Key -->| 569 | Package | | Package | 571 Figure 1: Basic DSKPP Exchange 573 Before DSKPP begins: 574 o The Authentication Code is generated by the DSKPP Server, and 575 delivered to the user via an out-of-band trustworthy channel 576 (e.g., a paper slip delivered by IT department staff). 578 o The user typically enters the Client ID and Authentication Code 579 manually, possibly on a device with only numeric keypad. Thus, 580 they are often short numeric values (for example, 8 decimal 581 digits). However, the DSKPP Server is free to generate them in 582 any way it wishes. 583 o The DSKPP client needs the URL [RFC3986] of the DSKPP server 584 (which is not user-specific or secret, and may be pre-configured 585 somehow), and a set of trust anchors for verifying the server 586 certificate. 587 o There must be an account for the user that has an identifier and 588 long-term user name (or other account identifier) to which the 589 token will be associated. The DSKPP server will use the Client ID 590 to find the corresponding Authentication Code for user 591 authentication. 593 In Step 1, the client establishes a TLS connection, and authenticates 594 the server (that is, validates the certificate, and compares the host 595 name in the URL with the certificate) as described in Section 3.1 of 596 [RFC2818]. 598 Next, the DSKPP Client and DSKPP Server exchange DSKPP messages 599 (which are sent over HTTPS). In these messages: 600 o The client and server negotiate which cryptographic algorithms 601 they want to use; which algorithms are supported for protecting 602 DSKPP messages, and other DSKPP protocol details. 603 o The client sends the Client ID to the server, and proves that it 604 knows the corresponding Authentication Code. 605 o The client and server agree on a secret key (token key or 606 K_TOKEN); depending on the negotiated protocol variant, this is 607 either a fresh key derived during the DSKPP protocol run (called 608 "four-pass variant", since it involves four DSKPP messages), or it 609 is generated by (or pre-exists on) the server and transported to 610 the client (called "two-pass variant" in the rest of this 611 document, since it involves two DSKPP messages). 612 o The server sends a "key package" to the client. The package only 613 includes the key itself in the case of the "two-pass variant"; 614 with either variant, the key package contains attributes that 615 influence how the provisioned key will be later used by the 616 cryptographic module and cryptographic server. The exact contents 617 depend on the cryptographic algorithm (e.g., for a one-time 618 password algorithm that supports variable-length OTP values, the 619 length of the OTP value would be one attribute in the key 620 package). 622 After the protocol run has been successfully completed, the 623 cryptographic modules stores the contents of the key package. 624 Likewise, the DSKPP provisioning server stores the contents of the 625 key package with the cryptographic server, and associates these with 626 the correct user name. The user can now use the their device to 627 perform symmetric-key based operations. 629 The exact division of work between the cryptographic module and the 630 DSKPP client -- and key Provisioning server and DSKPP server -- are 631 not specified in this document. The figure above shows one possible 632 case, but this is intended for illustrative purposes only. 634 3.2.3. Protocol Triggered by the DSKPP Server 636 In the first message flow (previous section), the Client ID and 637 Authentication Code were delivered to the client by some out-of-band 638 means (such as paper sent to the user). 640 Web DSKPP DSKPP Web 641 Browser Client Server Server 642 | | | | 643 |<-------- HTTPS browsing + some kind of user auth. --------->| 644 | | | | 645 | some HTTP request ----------------------------------------->| 646 | | | 647 | | |<------------->| 648 | | | | 649 |<----------------------- HTTP response with | 650 | | | | 651 | Trigger ---->| | | 652 | | | | 653 | |<-- 1. TLS handshake with --->| | 654 | | server auth. | | 655 | | | | 656 | | ... continues... | | 658 Figure 2: DSKPP Exchange with Web-Based Authentication 660 In the second message flow, the user first authenticates to a web 661 server (for example, IT department's "self-service" Intranet page), 662 using an ordinary web browser and some existing credentials. 664 The user then requests (by clicking a link or submitting a form) 665 provisioning of a new key to the cryptographic module. The web 666 server will reply with a message that contains the 667 Client ID, Authentication Code, and URL of the DSKPP server. This 668 information is also needed by the DSKPP server; how the web server 669 and DSKPP server interact is beyond the scope of this document. 671 The message is sent in a HTTP response, and it is 672 marked with MIME type "application/dskpp+xml". It is assumed the web 673 browser has been configured to recognize this MIME type; the browser 674 will start the DSKPP client, and provides it with the 675 message. 677 The DSKPP client then contacts the DSKPP server, and uses the Client 678 ID and Authentication Code (from the message) the 679 same way as in the first message flow. 681 3.2.4. Variants 683 As noted in the previous section, once the protocol has started, the 684 client and server MAY engage in either a two-pass or four-pass 685 message exchange. The four-pass and two-pass protocols are 686 appropriate in different deployment scenarios. The biggest 687 differentiator between the two is that the two-pass protocol supports 688 transport of an existing key to a cryptographic module, while the 689 four-pass involves key generation on-the-fly via key agreement. In 690 either case, both protocol variants support algorithm agility through 691 negotiation of encryption mechanisms and key types at the beginning 692 of each protocol run. 694 3.2.4.1. Criteria for Using the Four-Pass Variant 696 The four-pass protocol is needed under one or more of the following 697 conditions: 698 o Policy requires that both parties engaged in the protocol jointly 699 contribute entropy to the key. Enforcing this policy mitigates 700 the risk of exposing a key during the provisioning process as the 701 key is generated through mutual agreement without being 702 transferred over-the-air or over-the-wire. It also mitigates risk 703 of exposure after the key is provisioned, as the key will not be 704 vulnerable to a single point of attack in the system. 705 o A cryptographic module does not have private-key capabilities. 706 o The cryptographic module is hosted by a device that was neither 707 pre-issued with a manufacturer's key or other form of pre-shared 708 key (as might be the case with a smart card or SIM card) nor has a 709 keypad that can be used for entering a passphrase (such as present 710 on a mobile phone). 712 3.2.4.2. Criteria for Using the Two-Pass Variant 714 The two-pass protocol is needed under one or more of the following 715 conditions: 716 o Pre-existing (i.e., legacy) keys must be provisioned via transport 717 to the cryptographic module. 718 o The cryptographic module is hosted on a device that was pre-issued 719 with a manufacturer's key (such as may exist on a smart card), or 720 other form of pre-shared key (such as may exist on a SIM-card), 721 and is capable of performing private-key operations. 723 o The cryptographic module is hosted by a device that has a built-in 724 keypad with which a user may enter a passphrase, useful for 725 deriving a key wrapping key for distribution of keying material. 727 3.3. Status Codes 729 Upon transmission or receipt of a message for which the Status 730 attribute's value is not "Success" or "Continue", the default 731 behavior, unless explicitly stated otherwise below, is that both the 732 DSKPP server and the DSKPP client MUST immediately terminate the 733 DSKPP protocol run. DSKPP servers and DSKPP clients MUST delete any 734 secret values generated as a result of failed runs of the DSKPP 735 protocol. Session identifiers MAY be retained from successful or 736 failed protocol runs for replay detection purposes, but such retained 737 identifiers MUST NOT be reused for subsequent runs of the protocol. 739 When possible, the DSKPP client SHOULD present an appropriate error 740 message to the user. 742 These status codes are valid in all DSKPP Response messages unless 743 explicitly stated otherwise: 745 Continue: The DSKPP server is ready for a subsequent request from 746 the DSKPP client. It cannot be sent in the server's final 747 message 749 Success: Successful completion of the DSKPP session. It can only be 750 sent in the server's final message 752 Abort: The DSKPP server rejected the DSKPP client's request for 753 unspecified reasons 755 AccessDenied: The DSKPP client is not authorized to contact this 756 DSKPP server 758 MalformedRequest: The DSKPP server failed to parse the DSKPP 759 client's request 761 UnknownRequest: The DSKPP client made a request that is unknown to 762 the DSKPP server 764 UnknownCriticalExtension: A DSKPP extension marked as "Critical" 765 could not be interpreted by the receiving party. 767 UnsupportedVersion: The DSKPP client used a DSKPP protocol version 768 not supported by the DSKPP server. This error is only valid in 769 the DSKPP server's first response message 771 NoSupportedKeyTypes: "NoSupportedKeyTypes" indicates that the DSKPP 772 client only suggested key types that are not supported by the 773 DSKPP server. This error is only valid in the DSKPP server's 774 first response message 776 NoSupportedEncryptionAlgorithms: The DSKPP client only suggested 777 encryption algorithms that are not supported by the DSKPP server. 778 This error is only valid in the DSKPP server's first response 779 message 781 NoSupportedMacAlgorithms: The DSKPP client only suggested MAC 782 algorithms that are not supported by the DSKPP server. This 783 error is only valid in the DSKPP server's first response message 785 NoProtocolVariants: The DSKPP client did not suggest a required 786 protocol variant (either 2-pass or 4-pass). This error is only 787 valid in the DSKPP server's first response message. 789 NoSupportedKeyPackages: The DSKPP client only suggested key package 790 formats that are not supported by the DSKPP server. This error 791 is only valid in the DSKPP server's first response message 793 AuthenticationDataMissing: The DSKPP client didn't provide 794 authentication data that the DSKPP server required 796 AuthenticationDataInvalid: The DSKPP client supplied user 797 authentication data that the DSKPP server failed to validate 799 InitializationFailed: The DSKPP server could not generate a valid 800 key given the provided data. When this status code is received, 801 the DSKPP client SHOULD try to restart DSKPP, as it is possible 802 that a new run will succeed 804 ProvisioningPeriodExpired: The provisioning period set by the DSKPP 805 server has expired. When the status code is received, the DSKPP 806 client SHOULD report the reason for key initialization failure to 807 the user and the user MUST register with the DSKPP server to 808 initialize a new key 810 3.4. Basic Constructs 812 The following calculations are used in both DSKPP protocol variants. 814 3.4.1. User Authentication Data, AD 816 User authentication data (AD) is derived from a Client ID and 817 Authentication Code that the user enters before the first DSKPP 818 message is sent. 820 Note: The user will typically enter the Client ID and Authentication 821 Code manually, possibly on a device with only numeric keypad. Thus, 822 they are often short numeric values (for example, 8 decimal digits). 823 However, the DSKPP Server is free to generate them in any way it 824 wishes. 826 3.4.1.1. Authentication Code Format 828 AC is encoded in Type-Length-Value (TLV) format. The format consists 829 of a minimum of two TLVs and a variable number of additional TLVs, 830 depending on implementation. 832 The TLV fields are defined as follows: 834 Type (1 character) A hexadecimal character identifying the 835 type of information contained in the Value 836 field. 838 Length (2 characters) Two hexadecimal characters indicating the 839 length of the Value field to follow. The 840 field value MAY be up to 255 characters. 841 The Length value 00 MAY be used to specify 842 custom tags without any field values. 844 Value (variable length) A variable-length string of hexadecimal 845 characters containing the instance-specific 846 information for this TLV. 848 The following table summarizes the TLVs defined in this document. 849 Optional TLVs are allowed for vendor-specific extensions with the 850 constraint that the high bit MUST be set to indicate a vendor- 851 specific type. Other TLVs are left for later revisions of this 852 protocol. 854 +------+------------+-------------------------------------------+ 855 | Type | TLV Name | Conformance | Example Usage | 856 +------+------------+-------------------------------------------+ 857 | 1 | Client ID | Mandatory | { "AC00000A" } | 858 +------+------------+-------------+-----------------------------+ 859 | 2 | Password | Mandatory | { "3582AF0C3E" } | 860 +------+------------+-------------+-----------------------------+ 861 | 3 | Checksum | Optional | { "4D5" } | 862 +------+------------+-------------+-----------------------------+ 864 The Client ID is a mandatory TLV that represents the requester's 865 identifier of maximum length 255. The value is represented as a 866 string of hexadecimal characters that identifies the key request. 867 For example, suppose Client ID is set to "AC00000A", the Client ID 868 TLV in the AC will be represented as "108AC00000A". 870 The Password is a mandatory TLV the contains a one-time use shared 871 secret known by the user and the Provisioning Server. The password 872 value is unique and SHOULD be a random string to make AC more 873 difficult to guess. The string MUST contain hexadecimal characters 874 only. For example, suppose password is set to "3582AF0C3E", then the 875 Password TLV would be "20A3582AF0C3E". 877 The Checksum is an OPTIONAL TLV, which is generated by the issuing 878 server and sent to the user as part of the AC. If the TLV is 879 provided, the checksum value MUST be computed using the CRC16 880 algorithm [ISO3309]. When the user enters the AC, the typed AC 881 string of characters is verified with the checksum to ensure it is 882 correctly entered by the user. For example, suppose the AC with 883 combined Client ID tag and Password tag is set to 884 "108AC00000A20A3582AF0C3E", then the CRC16 calculation would generate 885 a checksum of 0x356, resulting in a Checksum TLV of "334D5". The 886 complete AC string in this example would be 887 "108AC00000A20A3582AF0C3E3034D5". 889 Although this specification recommends using hexadecimal characters 890 only for the AC at the application's user interface layer and making 891 the TLV triples non-transparent to the user as described in the 892 example above; implementations MAY additionally choose to use other 893 printable Unicode characters [UNICODE] at the application's user 894 interface layer in order to meet specific local, context or usability 895 requirements. When non-hexadecimal characters are desired at the 896 user interface layer such as when other printable US-ASCII characters 897 or international characters are used, SASLprep [RFC4013] MUST be used 898 to normalize user input before converting it to a string of 899 hexadecimal characters. For example, if a given application allows 900 use of any printable US-ASCII characters and extended ASCII 901 characters for Client ID and password fields and the Client ID is set 902 to "myclient!D" and associated password is set to "mYpas&#rD", the 903 user enters through the keyboard or other means a Client ID of 904 "myclient!D" and a password of "mYpas&#rD" in separate form fields or 905 as instructed by the provider. The application's layer processing 906 user input MUST then convert the values entered by the user to the 907 following string for use in the protocol: 908 "1146D79636C69656E7421442126D5970617326237244" (note that in this 909 example the Checksum TLV is not added). 911 The example is explained further below in detail: 913 Assume that the raw Client ID value or the value entered by the use 914 is: myclient!ID 916 The Client ID value as characters names is: 918 U+006D LATIN SMALL LETTER M character 919 U+0079 LATIN SMALL LETTER Y character 920 U+0063 LATIN SMALL LETTER C character 921 U+006C LATIN SMALL LETTER L character 922 U+0069 LATIN SMALL LETTER I character 923 U+0065 LATIN SMALL LETTER E character 924 U+006E LATIN SMALL LETTER N character 925 U+0074 LATIN SMALL LETTER T character 926 U+0021 EXCLAMATION MARK character (!) 927 U+0044 LATIN CAPITAL LETTER D character 929 The UTF-8 conversion of the Client ID value is: 6D 79 63 6C 69 65 6E 930 74 21 44 932 The length of the Client ID value in hexadecimal characters is: 14 934 The TLV presentation of the Client ID field is: 935 1146D79636C69656E742144 937 The raw password value or the value entered by the user is: mYpas&#rD 939 The password value as character names is: 941 U+006D LATIN SMALL LETTER M character 942 U+0059 LATIN LARGE LETTER Y character 943 U+0070 LATIN SMALL LETTER P character 944 U+0061 LATIN SMALL LETTER A character 945 U+0073 LATIN SMALL LETTER S character 946 U+0026 AMPERSAND character (&) 947 U+0023 POUND SIGN character (#) 948 U+0072 LATIN SMALL LETTER R character 949 U+0044 LATIN LARGE LETTER D character 951 The UTF-8 conversion of the password value is: 6D 59 70 61 73 26 23 952 72 44 954 The length of the password value in hexadecimal characters is: 12 956 The TLV presentation of the password field is: 2126D5970617326237244 958 The combined Client ID and password fields value or the AC value is: 959 1146D79636C69656E7421442126D5970617326237244 961 3.4.1.2. User Authentication Data Calculation 963 The Authentication Data consists of a Client ID (extracted from the 964 AC) and a value, which is derived from AC as follows (refer to 965 Section 3.4.2 for a description of DSKPP-PRF in general and 966 Appendix D for a description of DSKPP-PRF-AES): 968 MAC = DSKPP-PRF(K_AC, AC->ClientID||URL_S||R_C||[R_S], 16) 970 In four-pass DSKPP, the cryptographic module uses R_C, R_S, and URL_S 971 to calculate the MAC, where URL_S is the URL the DSKPP client uses 972 when contacting the DSKPP server. In two-pass DSKPP, the 973 cryptographic module does not have access to R_S, therefore only R_C 974 is used in combination with URL_S to produce the MAC. In either 975 case, K_AC MUST be derived from AC->password as follows [PKCS-5]: 977 K_AC = PBKDF2(AC->password, R_C || K, iter_count, 16) 979 One of the following values for K MUST be used: 981 a. In four-pass: 982 * The public key of the DSKPP server (K_SERVER), or (in the pre- 983 shared key variant) the pre-shared key between the client and 984 the server (K_SHARED) 986 b. In two-pass: 987 * The public key of the DSKPP client, or the public key of the 988 device when a device certificate is available 989 * The pre-shared key between the client and the server 990 (K_SHARED) 991 * A passphrase-derived key 993 The iteration count, iter_count, MUST be set to at least 100,000 994 except in the last two two-pass cases (where K is set to K_SHARED or 995 a passphrase-derived key), in which case iter_count MUST be set to 1. 997 3.4.2. The DSKPP One-Way Pseudorandom Function, DSKPP-PRF 999 Regardless of the protocol variant employed, there is a requirement 1000 for a cryptographic primitive that provides a deterministic 1001 transformation of a secret key k and a varying length octet string s 1002 to a bit string of specified length dsLen. 1004 This primitive must meet the same requirements as for a keyed hash 1005 function: It MUST take an arbitrary length input, and generate an 1006 output that is one-way and collision-free (for a definition of these 1007 terms, see, e.g., [FAQ]). Further, its output MUST be unpredictable 1008 even if other outputs for the same key are known. 1010 From the point of view of this specification, DSKPP-PRF is a "black- 1011 box" function that, given the inputs, generates a pseudorandom value 1012 and MAY be realized by any appropriate and competent cryptographic 1013 technique. Appendix D contains two example realizations of DSKPP- 1014 PRF. 1016 DSKPP-PRF(k, s, dsLen) 1018 Input: 1020 k secret key in octet string format 1021 s octet string of varying length consisting of variable data 1022 distinguishing the particular string being derived 1023 dsLen desired length of the output 1025 Output: 1027 DS pseudorandom string, dsLen-octets long 1029 For the purposes of this document, the secret key k MUST be at least 1030 16 octets long. 1032 3.4.3. The DSKPP Message Hash Algorithm 1034 When sending its last message in a protocol run, the DSKPP server 1035 generates a MAC that is used by the client for key confirmation. 1036 Computation of the MAC MUST include a hash of all DSKPP messages sent 1037 by the client and server during the transaction. To compute a 1038 message hash for the MAC given a sequence of DSKPP messages msg_1, 1039 ..., msg_n, the following operations MUST be carried out: 1041 a. The sequence of messages contains all DSKPP Request and Response 1042 messages up to but not including this message. 1043 b. Re-transmitted messages are removed from the sequence of 1044 messages. 1045 Note: The resulting sequence of messages MUST be an alternating 1046 sequence of DSKPP Request and DSKPP Response messages 1047 c. The contents of each message is concatenated together. 1048 d. The resultant string is hashed using SHA-256 in accordance with 1049 [FIPS180-SHA]. 1051 4. Four-Pass Protocol Usage 1053 This section describes the methods and message flow that comprise the 1054 four-pass protocol variant. Four-pass DSKPP depends on a client- 1055 server key agreement mechanism. 1057 4.1. The Key Agreement Mechanism 1059 With 4-pass DSKPP, the symmetric key that is the target of 1060 provisioning, is generated on-the-fly without being transferred 1061 between the DSKPP client and DSKPP server. The data flow and 1062 computation are described below. 1064 4.1.1. Data Flow 1066 A sample data flow showing key generation during the 4-pass protocol 1067 is shown in Figure 3. 1069 +----------------------+ +----------------------+ 1070 | +------------+ | | | 1071 | | Server key | | | | 1072 | +<-| Public |------>------------->-------------+---------+ | 1073 | | | Private | | | | | | 1074 | | +------------+ | | | | | 1075 | | | | | | | | 1076 | V V | | V V | 1077 | | +---------+ | | +---------+ | | 1078 | | | Decrypt |<-------<-------------<-----------| Encrypt | | | 1079 | | +---------+ | | +---------+ | | 1080 | | | +--------+ | | ^ | | 1081 | | | | Server | | | | | | 1082 | | | | Random |--->------------->------+ +----------+ | | 1083 | | | +--------+ | | | | Client | | | 1084 | | | | | | | | Random | | | 1085 | | | | | | | +----------+ | | 1086 | | | | | | | | | | 1087 | | V V | | V V | | 1088 | | +------------+ | | +------------+ | | 1089 | +-->| DSKPP PRF | | | | DSKPP PRF |<----+ | 1090 | +------------+ | | +------------+ | 1091 | | | | | | 1092 | V | | V | 1093 | +-------+ | | +-------+ | 1094 | | Key | | | | Key | | 1095 | +-------+ | | +-------+ | 1096 | +-------+ | | +-------+ | 1097 | |Key Id |-------->------------->------|Key Id | | 1098 | +-------+ | | +-------+ | 1099 +----------------------+ +----------------------+ 1100 DSKPP Server DSKPP Client 1102 Figure 3: Principal data flow for DSKPP key generation - 1103 using public server key 1105 The inclusion of the two random nonces (R_S and R_C) in the key 1106 generation provides assurance to both sides (the cryptographic module 1107 and the DSKPP server) that they have contributed to the key's 1108 randomness and that the key is unique. The inclusion of the 1109 encryption key (K) ensures that no man-in-the-middle may be present, 1110 or else the cryptographic module will end up with a key different 1111 from the one stored by the legitimate DSKPP server. 1113 Conceptually, although R_C is one pseudorandom string, it may be 1114 viewed as consisting of two components, R_C1 and R_C2, where R_C1 is 1115 generated during the protocol run, and R_C2 can be pre-generated and 1116 loaded on the cryptographic module before the device is issued to the 1117 user. In that case, the latter string, R_C2, SHOULD be unique for 1118 each cryptographic module. 1120 A man-in-the-middle (in the form of corrupt client software or a 1121 mistakenly contacted server) may present his own public key to the 1122 cryptographic module. This will enable the attacker to learn the 1123 client's version of K_TOKEN. However, the attacker is not able to 1124 persuade the legitimate server to derive the same value for K_TOKEN, 1125 since K_TOKEN is a function of the public key involved, and the 1126 attacker's public key must be different than the correct server's (or 1127 else the attacker would not be able to decrypt the information 1128 received from the client). Therefore, once the attacker is no longer 1129 "in the middle," the client and server will detect that they are "out 1130 of sync" when they try to use their keys. In the case of encrypting 1131 R_C with K_SERVER, it is therefore important to verify that K_SERVER 1132 really is the legitimate server's key. One way to do this is to 1133 independently validate a newly generated K_TOKEN against some 1134 validation service at the server (e.g., using a connection 1135 independent from the one used for the key generation). 1137 4.1.2. Computation 1139 In 4-pass DSKPP, the client and server both generate K_TOKEN and 1140 K_MAC by deriving them from a provisioning key (K_PROV) using the 1141 DSKPP-PRF function (refer to Section 3.4.2) as follows: 1143 K_PROV = DSKPP-PRF(k,s,dsLen), where 1145 k = R_C (i.e., the secret random value chosen by the DSKPP 1146 client) 1148 s = "Key generation" || K || R_S (where K is the key used to 1149 encrypt R_C and R_S is the random value chosen by the DSKPP 1150 server) 1152 dsLen = (desired length of K_PROV whose first half constitutes 1153 K_MAC and second half constitutes K_TOKEN) 1155 Then K_TOKEN and K_MAC are derived from K_PROV, where 1157 K_PROV = K_MAC || K_TOKEN 1159 When computing K_PROV, the derived keys, K_MAC and K_TOKEN, MAY be 1160 subject to an algorithm-dependent transform before being adopted as a 1161 key of the selected type. One example of this is the need for parity 1162 in DES keys. 1164 Note that this computation pertains to 4-pass DSKPP only. 1166 4.2. Message Flow 1168 The four-pass protocol flow consists of two message exchanges: 1169 1: Pass 1 = , Pass 2 = 1170 2: Pass 3 = , Pass 4 = 1172 The first pair of messages negotiate cryptographic algorithms and 1173 exchange nonces. The second pair of messages establishes a symmetric 1174 key using mutually authenticated key agreement. 1176 The purpose and content of each message are described below. XML 1177 format and examples are in Section 8 and Appendix B. 1179 4.2.1. KeyProvTrigger 1181 DSKPP Client DSKPP Server 1182 ------------ ------------ 1183 [<---] AD, [DeviceID], 1184 [KeyID], [URL_S] 1186 When this message is sent: 1187 The "trigger" message is optional. The DSKPP server sends this 1188 message after the following out-of-band steps are performed: 1189 1. A user directed their browser to a key provisioning web 1190 application and signs in (i.e., authenticates) 1191 2. The user requests a key 1192 3. The web application processes the request and returns an 1193 authentication code to the user, e.g., in response to an 1194 enrollment request via a secure web session 1195 4. The web application retrieves the authentication code from the 1196 user (possibly by asking the user to enter it using a web 1197 form, or alternatively by the user selecting a URL in which 1198 the authentication code is embedded) 1199 5. The web application derives authentication data (AD) from the 1200 authentication code as described in Section 3.4.1 1201 6. The web application passes AD, and possibly a DeviceID 1202 (identifies a particular device to which the key is to be 1203 provisioned) and/or KeyID (identifies a key that will be 1204 replaced) to the DSKPP server 1206 Purpose of this message: 1207 To start a DSKPP session: The DSKPP server uses this message to 1208 trigger a client-side application to send the first DSKPP message. 1210 To provide a way for the key provisioning system to get the DSKPP 1211 server URL to the DSKPP client. 1213 So the key provisioning system can point the DSKPP client to a 1214 particular cryptographic module that was pre-configured in the 1215 DSKPP provisioning server. 1217 In the case of key renewal, to identify the key to be replaced. 1219 What is contained in this message: 1220 AD MUST be provided to allow the DSKPP server to authenticate the 1221 user before completing the protocol run. 1223 A DeviceID MAY be included to allow a key provisioning application 1224 to bind the provisioned key to a specific device. 1226 A KeyID MAY be included to allow the key provisioning application 1227 to identify a key to be replaced, e.g., in the case of key 1228 renewal. 1230 The Server URL MAY be included to allow the key provisioning 1231 application to inform the DSKPP client of which server to contact 1233 4.2.2. KeyProvClientHello 1235 DSKPP Client DSKPP Server 1236 ------------ ------------ 1237 SAL, [AD], 1238 [DeviceID], [KeyID] ---> 1240 When this message is sent: 1241 When a DSKPP client first connects to a DSKPP server, it is 1242 required to send the as its first message. 1243 The client can also send a in response to a 1244 . 1246 What is contained in this message: 1247 The Security Attribute List (SAL) included with 1248 contains the combinations of DSKPP versions, 1249 variants, key package formats, key types, and cryptographic 1250 algorithms that the DSKPP client supports in order of the client's 1251 preference (favorite choice first). 1253 If was preceded by a , then 1254 this message MUST also include the Authentication (AD), DeviceID, 1255 and/or KeyID that was provided with the trigger. 1257 If was not preceded by a , 1258 then this message MAY contain a device ID that was pre-shared with 1259 the DSKPP server, and a key ID associated with a key previously 1260 provisioned by the DSKPP provisioning server. 1262 Application note: 1263 If this message is preceded by trigger message , 1264 then the application will already have AD available (see 1265 Section 4.2.1). However, if this message was not preceded by 1266 , then the application MUST retrieve the user 1267 authentication code, possibly by prompting the user to manually 1268 enter their authentication code, e.g., on a device with only a 1269 numeric keypad. 1271 The application MUST also derive Authentication Data (AD) from the 1272 authentication code, as described in Section 3.4.1, and save it 1273 for use in its next message, . 1275 How the DSKPP server uses this message: 1276 The DSKPP server will look for an acceptable combination of DSKPP 1277 version, variant (in this case, four-pass), key package format, 1278 key type, and cryptographic algorithms. If the DSKPP Client's SAL 1279 does not match the capabilities of the DSKPP Server, or does not 1280 comply with key provisioning policy, then the DSKPP Server will 1281 set the Status attribute to something other than "Continue". 1282 Otherwise, Status will be set to "Continue". 1284 If included in , the DSKPP server will 1285 validate the Authentication Data (AD), DeviceID, and KeyID. The 1286 DSKPP server MUST NOT accept the DeviceID unless the server sent 1287 the DeviceID in a preceding trigger message. Note that it is also 1288 legitimate for a DSKPP client to initiate the DSKPP protocol run 1289 without having received a message from a server, 1290 but in this case any provided DeviceID MUST NOT be accepted by the 1291 DSKPP server unless the server has access to a unique key for the 1292 identified device and that key will be used in the protocol. 1294 4.2.3. KeyProvServerHello 1296 DSKPP Client DSKPP Server 1297 ------------ ------------ 1298 <--- SAL, R_S, [K], [MAC] 1300 When this message is sent: 1301 The DSKPP server will send this message in response to a 1302 message after it looks for an acceptable 1303 combination of DSKPP version, variant (in this case, four-pass), 1304 key package format, key type, and set of cryptographic algorithms. 1305 If it could not find an acceptable combination, then it will still 1306 send the message, but with a failure status. 1308 Purpose of this message: 1310 With this message, the context for the protocol run is set. 1311 Furthermore, the DSKPP server uses this message to transmit a 1312 random nonce, which is required for each side to agree upon the 1313 same symmetric key (K_TOKEN). 1315 What is contained in this message: 1316 A status attribute equivalent to the server's return code to 1317 . If the server found an acceptable set of 1318 attributes from the client's SAL, then it sets status to Continue 1319 and returns an SAL (selected from the SAL that it received in 1320 ). The Server's SAL specifies the DSKPP 1321 version and variant (in this case, four-pass), key type, 1322 cryptographic algorithms, and key package format that the DSKPP 1323 Client MUST use for the remainder of the protocol run. 1325 A random nonce (R_S) for use in generating a symmetric key through 1326 key agreement; the length of R_S may depend on the selected key 1327 type. 1329 A key (K) for the DSKPP Client to use for encrypting the client 1330 nonce included with . K represents the 1331 server's public key (K_SERVER) or a pre-shared secret key 1332 (K_SHARED). 1334 A MAC MUST be present if a key is being renewed so that the DSKPP 1335 client can confirm that the replacement key came from a trusted 1336 server. This MAC MUST be computed using DSKPP-PRF (see 1337 Section 3.4.2), where the input parameter k MUST be set to the 1338 existing MAC key K_MAC' (i.e., the value of the MAC key that 1339 existed before this protocol run; the implementation MAY specify 1340 K_MAC' to be the value of the K_TOKEN that is being replaced), and 1341 input parameter dsLen MUST be set to the length of R_S. 1343 How the DSKPP client uses this message: 1344 When the Status attribute is not set to "Continue", this indicates 1345 failure and the DSKPP client MUST abort the protocol. 1347 If successful execution of the protocol will result in the 1348 replacement of an existing key with a newly generated one, the 1349 DSKPP client MUST verify the MAC provided in . 1350 The DSKPP client MUST terminate the DSKPP session if the MAC does 1351 not verify, and MUST delete any nonces, keys, and/or secrets 1352 associated with the failed run. 1354 If Status is set to "Continue" the cryptographic module generates 1355 a random nonce (R_C) using the cryptographic algorithm specified 1356 in the SAL. The length of the nonce R_C will depend on the 1357 selected key type. 1359 Encrypt R_C using K and the encryption algorithm included in the 1360 SAL. 1362 The method the DSKPP client MUST use to encrypt R_C: 1363 If K is equivalent to K_SERVER (i.e., the public key of the DSKPP 1364 server), then an RSA encryption scheme from PKCS #1 [PKCS-1] MAY 1365 be used. If K is equivalent to K_SERVER, then the cryptographic 1366 module SHOULD verify the server's certificate before using it to 1367 encrypt R_C as described in [RFC2818], Section 3.1, and [RFC5280]. 1369 If K is equivalent to K_SHARED, the DSKPP client MAY use the 1370 DSKPP-PRF function to avoid dependence on other algorithms. In 1371 this case, the client uses K_SHARED as input parameter k (K_SHARED 1372 SHOULD be used solely for this purpose) as follows: 1374 dsLen = len(R_C), where "len" is the length of R_C 1375 DS = DSKPP-PRF(K_SHARED, "Encryption" || R_S, dsLen) 1377 This will produce a pseudorandom string DS of length equal to R_C. 1378 Encryption of R_C MAY then be achieved by XOR-ing DS with R_C: 1380 E(DS, R_C) = DS ^ R_C 1382 The DSKPP server will then perform the reverse operation to 1383 extract R_C from E(DS, R_C). 1385 4.2.4. KeyProvClientNonce 1387 DSKPP Client DSKPP Server 1388 ------------ ------------ 1389 E(K,R_C), AD ---> 1391 When this message is sent: 1392 The DSKPP client will send this message immediately following a 1393 message whose status was set to "Continue". 1395 Purpose of this message: 1396 With this message the DSKPP client transmits user authentication 1397 data (AD) and a random nonce encrypted with the DSKPP server's key 1398 (K). The client's random nonce is required for each side to agree 1399 upon the same symmetric key (K_TOKEN). 1401 What is contained in this message: 1402 Authentication Data (AD) that was derived from an authentication 1403 code entered by the user before was sent 1404 (refer to Section 3.2). 1406 The DSKPP client's random nonce (R_C), which was encrypted as 1407 described in Section 4.2.3. 1409 How the DSKPP server uses this message: 1410 The DSKPP server MUST use AD to authenticate the user. If 1411 authentication fails, then the DSKPP server MUST set the return 1412 code to a failure status. 1414 If user authentication passes, the DSKPP server decrypts R_C using 1415 its key (K). The decryption method is based on whether K that was 1416 transmitted to the client in was equal to the 1417 server's public key (K_SERVER) or a pre-shared key (K_SHARED) 1418 (refer to Section 4.2.3 for a description of how the DSKPP client 1419 encrypts R_C). 1421 After extracting R_C, the DSKPP server computes K_TOKEN using a 1422 combination of the two random nonces R_S and R_C and its 1423 encryption key, K, as described in Section 4.1.2. The particular 1424 realization of DSKPP-PRF (e.g., those defined in Appendix D) 1425 depends on the MAC algorithm contained in the 1426 message. The DSKPP server then generates a key package that 1427 contains key usage attributes such as expiry date and length. The 1428 key package MUST NOT include K_TOKEN since in the four-pass 1429 variant K_TOKEN is never transmitted between the DSKPP server and 1430 client. The server stores K_TOKEN and the key package with the 1431 user's account on the cryptographic server. 1433 Finally, the server generates a key confirmation MAC that the 1434 client will use to avoid a false "Commit" message that would cause 1435 the cryptographic module to end up in state in which the server 1436 does not recognize the stored key. 1438 The MAC used for key confirmation MUST be calculated as follows: 1439 msg_hash = SHA-256(msg_1, ..., msg_n) 1441 dsLen = len(msg_hash) 1443 MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash, dsLen) 1445 where 1447 MAC The DSKPP Pseudo-Random Function defined in Section 3.4.2 is 1448 used to compute the MAC. The particular realization of DSKPP- 1449 PRF (e.g., those defined in Appendix D) depends on the MAC 1450 algorithm contained in the message. The 1451 MAC MUST be computed using the existing MAC key (K_MAC), and a 1452 string that is formed by concatenating the (ASCII) string "MAC 1453 1 computation" and a msg_hash 1455 K_MAC The key derived from K_PROV, as described in Section 4.1.2. 1457 msg_hash The message hash (defined in Section 3.4.3) of messages 1458 msg_1, ..., msg_n. 1460 4.2.5. KeyProvServerFinished 1462 DSKPP Client DSKPP Server 1463 ------------ ------------ 1464 <--- KP, MAC 1466 When this message is sent: 1467 The DSKPP server will send this message after authenticating the 1468 user and, if authentication passed, generating K_TOKEN and a key 1469 package, and associating them with the user's account on the 1470 cryptographic server. 1472 Purpose of this message: 1473 With this message the DSKPP server confirms generation of the key 1474 (K_TOKEN), and transmits the associated identifier and 1475 application-specific attributes, but not the key itself, in a key 1476 package to the client for protocol completion. 1478 What is contained in this message: 1479 A status attribute equivalent to the server's return code to 1480 . If user authentication passed, and the 1481 server successfully computed K_TOKEN, generated a key package, and 1482 associated them with the user's account on the cryptographic 1483 server, then it sets Status to Success. 1485 If status is Success, then this message acts as a "commit" 1486 message, instructing the cryptographic module to store the 1487 generated key (K_TOKEN) and associate the given key identifier 1488 with this key. As such, a key package (KP) MUST be included in 1489 this message, which holds an identifier for the generated key (but 1490 not the key itself) and additional configuration, e.g., the 1491 identity of the DSKPP server, key usage attributes, etc. The 1492 default symmetric key package format MUST be based on the Portable 1493 Symmetric Key Container (PSKC) defined in [PSKC]. Alternative 1494 formats MAY include [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML 1495 [PKCS-5-XML] format. 1497 With KP, the server includes a key confirmation MAC that the 1498 client uses to avoid a false "Commit". The MAC algorithm is the 1499 same DSKPP-PRF that was sent in the message. 1501 How the DSKPP client uses this message: 1503 When the Status attribute is not set to "Success", this indicates 1504 failure and the DSKPP client MUST abort the protocol. 1506 After receiving a message with Status = 1507 "Success", the DSKPP client MUST verify the key confirmation MAC 1508 that was transmitted with this message. The DSKPP client MUST 1509 terminate the DSKPP session if the MAC does not verify, and MUST, 1510 in this case, also delete any nonces, keys, and/or secrets 1511 associated with the failed run of the protocol. 1513 If has Status = "Success" and the MAC was 1514 verified, then the DSKPP client MUST calculate K_TOKEN from the 1515 combination of the two random nonces R_S and R_C and the server's 1516 encryption key, K, as described in Section 4.1.2. The DSKPP-PRF 1517 is the same one used for MAC computation. The DSKPP client 1518 associates the key package contained in 1519 with the generated key, K_TOKEN, and stores this data permanently 1520 on the cryptographic module. 1522 After this operation, it MUST NOT be possible to overwrite the key 1523 unless knowledge of an authorizing key is proven through a MAC on 1524 a later (and ) 1525 message. 1527 5. Two-Pass Protocol Usage 1529 This section describes the methods and message flow that comprise the 1530 two-pass protocol variant. Two-pass DSKPP is essentially a transport 1531 of keying material from the DSKPP server to the DSKPP client. The 1532 DSKPP server transmits keying material in a key package formatted in 1533 accordance with [PSKC], [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 1534 XML [PKCS-5-XML]. 1536 The keying material includes a provisioning master key, K_PROV, from 1537 which the DSKPP client derives two keys: the symmetric key to be 1538 established in the cryptographic module, K_TOKEN, and a key, K_MAC, 1539 used for key confirmation. The keying material also includes key 1540 usage attributes, such as expiry date and length. 1542 The DSKPP server encrypts K_PROV to ensure that it is not exposed to 1543 any other entity than the DSKPP server and the cryptographic module 1544 itself. The DSKPP server uses any of three key protection methods to 1545 encrypt K_PROV: Key Transport, Key Wrap, and Passphrase-Based Key 1546 Wrap Key Protection Methods. 1548 While the DSKPP client and server may negotiate the key protection 1549 method to use, the actual key protection is carried out in the 1550 KeyPackage. The format of a KeyPackage specifies how a key should be 1551 protected using the three key protection methods. The following 1552 KeyPackage formats are defined for DSKPP: 1554 o PSKC Key Container [PSKC] at 1555 urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 1557 o SKPC Key Container [SKPC-ASN.1] at 1558 urn:ietf:params:xml:ns:keyprov:dskpp:skpc-key-container 1560 o PKCS12 Key Container [PKCS-12] at 1561 urn:ietf:params:xml:ns:keyprov:dskpp:pkcs12-key-container 1563 o PKCS5-XML Key Container [PKCS-5-XML] at 1564 urn:ietf:params:xml:ns:keyprov:dskpp:pkcs5-xml-key-container 1566 Each of the key protection methods is described below. 1568 5.1. Key Protection Methods 1570 This section introduces three key protection methods for the two-pass 1571 variant. Additional methods MAY be defined by external entities or 1572 through the IETF process. 1574 5.1.1. Key Transport 1576 Purpose of this method: 1577 This method is intended for PKI-capable devices. The DSKPP server 1578 encrypts keying material and transports it to the DSKPP client. 1579 The server encrypts the keying material using the public key of 1580 the DSKPP client, whose private key part resides in the 1581 cryptographic module. The DSKPP client decrypts the keying 1582 material and uses it to derive the symmetric key, K_TOKEN. 1584 This method is identified with the following URN: 1585 urn:ietf:params:xml:schema:keyprov:dskpp:transport 1587 The DSKPP server and client MUST support the following mechanism: 1588 http://www.w3.org/2001/04/xmlenc#rsa-1_5 encryption mechanism 1589 defined in [XMLENC]. 1591 5.1.2. Key Wrap 1593 Purpose of this method: 1594 This method is ideal for pre-keyed devices, e.g., SIM cards. The 1595 DSKPP server encrypts keying material using a pre-shared key 1596 wrapping key and transports it to the DSKPP client. The DSKPP 1597 client decrypts the keying material, and uses it to derive the 1598 symmetric key, K_TOKEN. 1600 This method is identified with the following URN: 1601 urn:ietf:params:xml:schema:keyprov:dskpp:wrap 1603 The DSKPP server and client MUST support all of the following key 1604 wrapping mechanisms: 1606 AES128 KeyWrap 1607 Refer to id-aes128-wrap in [RFC3394] and 1608 http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] 1610 AES128 KeyWrap with Padding 1611 Refer to id-aes128-wrap-pad in [RFC5649] and 1612 http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] 1614 AES-CBC-128 1615 Refer to [FIPS197-AES] and 1616 http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC] 1618 5.1.3. Passphrase-Based Key Wrap 1620 Purpose of this method: 1621 This method is a variation of the Key Wrap Method that is 1622 applicable to constrained devices with keypads, e.g., mobile 1623 phones. The DSKPP server encrypts keying material using a 1624 wrapping key derived from a user-provided passphrase, and 1625 transports the encrypted material to the DSKPP client. The DSKPP 1626 client decrypts the keying material, and uses it to derive the 1627 symmetric key, K_TOKEN. 1629 To preserve the property of not exposing K_TOKEN to any other 1630 entity than the DSKPP server and the cryptographic module itself, 1631 the method SHOULD be employed only when the device contains 1632 facilities (e.g. a keypad) for direct entry of the passphrase. 1634 This method is identified with the following URN: 1635 urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap 1637 The DSKPP server and client MUST support the following: 1639 * The PBES2 password-based encryption scheme defined in [PKCS-5] 1640 (and identified as 1641 http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in 1642 [PKCS-5-XML]) 1644 * The PBKDF2 passphrase-based key derivation function also 1645 defined in [PKCS-5] (and identified as 1646 http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 1647 in [PKCS-5-XML]) 1649 * All of the following key wrapping mechanisms: 1651 AES128 KeyWrap 1652 Refer to id-aes128-wrap in [RFC3394] and 1653 http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] 1655 AES128 KeyWrap with Padding 1656 Refer to id-aes128-wrap-pad in [RFC5649] and 1657 http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] 1659 AES-CBC-128 1660 Refer to [FIPS197-AES] and 1661 http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC] 1663 5.2. Message Flow 1665 The two-pass protocol flow consists of one exchange: 1666 1: Pass 1 = , Pass 2 = 1668 Although there is no exchange of the message or the 1669 message, the DSKPP client is still able to specify 1670 algorithm preferences and supported key types in the 1671 message. 1673 The purpose and content of each message are described below. XML 1674 format and examples are in Section 8 and Appendix B. 1676 5.2.1. KeyProvTrigger 1678 The trigger message is used in exactly the same way for the two-pass 1679 variant as for the four-pass variant; refer to Section 4.2.1. 1681 5.2.2. KeyProvClientHello 1683 DSKPP Client DSKPP Server 1684 ------------ ------------ 1685 SAL, AD, R_C, 1686 [DeviceID], [KeyID], 1687 KPML ---> 1689 When this message is sent: 1691 When a DSKPP client first connects to a DSKPP server, it is 1692 required to send the as its first message. 1693 The client can also send in response to a 1694 message. 1696 Purpose of this message: 1697 With this message, the DSKPP client specifies its algorithm 1698 preferences and supported key types as well as which DSKPP 1699 versions, protocol variants (in this case "two-pass"), key package 1700 formats, and key protection methods that it supports. 1701 Furthermore, the DSKPP client facilitates user authentication by 1702 transmitting the authentication data (AD) that was provided by the 1703 user before the first DSKPP message was sent. 1705 Application note: 1706 This message MUST send user authentication data (AD) to the DSKPP 1707 server. If this message is preceded by trigger message 1708 , then the application will already have AD 1709 available (see Section 4.2.1). However, if this message was not 1710 preceded by , then the application MUST retrieve 1711 the user authentication code, possibly by prompting the user to 1712 manually enter their authentication code, e.g., on a device with 1713 only a numeric keypad. The application MUST also derive 1714 Authentication Data (AD) from the authentication code, as 1715 described in Section 3.4.1, and save it for use in its next 1716 message, . 1718 What is contained in this message: 1719 The Security Attribute List (SAL) included with 1720 contains the combinations of DSKPP versions, 1721 variants, key package formats, key types, and cryptographic 1722 algorithms that the DSKPP client supports in order of the client's 1723 preference (favorite choice first). 1725 Authentication Data (AD) that was either included with 1726 , or generated as described in the "Application 1727 Note" above 1729 The DSKPP client's random nonce (R_C), which was used by the 1730 client when generating AD. By inserting R_C into the DSKPP 1731 session, the DSKPP client is able to ensure the DSKPP server is 1732 live before committing the key. 1734 If was preceded by a , then 1735 this message MUST also include the DeviceID and/or KeyID that was 1736 provided with the trigger. Otherwise, if a trigger message did 1737 not precede , then this message MAY include a 1738 device ID that was pre-shared with the DSKPP server, and MAY 1739 contain a key ID associated with a key previously provisioned by 1740 the DSKPP provisioning server. 1742 The list of key protection methods (KPML) that the DSKPP client 1743 supports. Each item in the list MAY include an encryption key 1744 "payload" for the DSKPP server to use to protect keying material 1745 that it sends back to the client. The payload MUST be of type 1746 ([XMLDSIG]). For each key protection method, the 1747 allowable choices for are: 1749 * Key Transport 1750 Only those choices of that identify a public 1751 key (i.e., , , , or ). The option of the alternative is RECOMMENDED when the public key 1754 corresponding to the private key on the cryptographic module 1755 has been certified. 1757 * Key Wrap 1758 Only those choices of that identify a 1759 symmetric key (i.e., and ). The alternative is RECOMMENDED. 1762 * Passphrase-Based Key Wrap 1763 The option MUST be used and the key name MUST 1764 identify the passphrase that will be used by the server to 1765 generate the key wrapping key. The identifier and passphrase 1766 components of MUST be set to the Client ID and 1767 authentication code components of AD (same AD as contained in 1768 this message). 1770 How the DSKPP server uses this message: 1771 The DSKPP server will look for an acceptable combination of DSKPP 1772 version, variant (in this case, two-pass), key package format, key 1773 type, and cryptographic algorithms. If the DSKPP Client's SAL 1774 does not match the capabilities of the DSKPP Server, or does not 1775 comply with key provisioning policy, then the DSKPP Server will 1776 set the Status attribute to something other than "Success". 1777 Otherwise, Status will be set to "Success". 1779 The DSKPP server will validate the DeviceID and KeyID if included 1780 in . The DSKPP server MUST NOT accept the 1781 DeviceID unless the server sent the DeviceID in a preceding 1782 trigger message. Note that it is also legitimate for a DSKPP 1783 client to initiate the DSKPP protocol run without having received 1784 a message from a server, but in this case any 1785 provided DeviceID MUST NOT be accepted by the DSKPP server unless 1786 the server has access to a unique key for the identified device 1787 and that key will be used in the protocol. 1789 The DSKPP server MUST use AD to authenticate the user. If 1790 authentication fails, then the DSKPP server MUST set the return 1791 code to a failure status, and MUST, in this case, also delete any 1792 nonces, keys, and/or secrets associated with the failed run of the 1793 protocol. 1795 If user authentication passes, the DSKPP server generates a key 1796 K_PROV. In the two-pass case, wherein the client does not have 1797 access to R_S, K_PROV is randomly generated solely by the DSKPP 1798 server wherein K_PROV MUST consist of two parts of equal length, 1799 i.e., 1801 K_PROV = K_MAC || K_TOKEN 1803 The length of K_TOKEN (and hence also the length of K_MAC) is 1804 determined by the type of K_TOKEN, which MUST be one of the key 1805 types supported by the DSKPP client. In cases where the desired 1806 key length for K_TOKEN is different from the length of K_MAC for 1807 the underlying MAC algorithm, the greater length of the two MUST 1808 be chosen to generate K_PROV. The actual MAC key is truncated 1809 from the resulting K_MAC when it is used in the MAC algorithm when 1810 K_MAC is longer than necessary in order to match the desired 1811 K_TOKEN length. If K_TOKEN is longer than needed in order to 1812 match the K_MAC length, the provisioning server and the receiving 1813 client must determine the actual secret key length from the target 1814 key algorithm and store only the truncated portion of the K_TOKEN. 1815 The truncation MUST take the beginning bytes of the desired length 1816 from K_TOKEN or K_MAC for the actual key. For example, when a 1817 provisioning server provisions an event based HOTP secret key with 1818 length 20 and MAC algorithm DSKPP-PRF-SHA256 (Appendix D), K_PROV 1819 length will be 64. The derived K_TOKEN and K_MAC will each 1820 consist of 32 bytes. The actual HOTP key should be the first 20 1821 bytes of the K_TOKEN. 1823 Once K_PROV is computed, the DSKPP server selects one of the key 1824 protection methods from the DSKPP client's KPML, and uses that 1825 method and corresponding payload to encrypt K_PROV. The DSKPP 1826 server generates a key package to transport the key encryption 1827 method information and the encrypted provisioning key (K_PROV). 1828 The encrypted data format is subject to the choice supported by 1829 the selected key package. The key package MUST specify and use 1830 the selected key protection method and the key information that 1831 was received in .The key package also includes 1832 key usage attributes such as expiry date and length. The server 1833 stores the key package and K_TOKEN with a user account on the 1834 cryptographic server. 1836 The server generates a MAC for key confirmation, which the client 1837 will use to avoid a false "Commit" message that would cause the 1838 cryptographic module to end up in state in which the server does 1839 not recognize the stored key. 1841 In addition, if an existing key is being renewed, the server 1842 generates a second MAC that it will return to the client as server 1843 authentication data, AD, so that the DSKPP client can confirm that 1844 the replacement key came from a trusted server. 1846 The method the DSKPP server MUST use to calculate the key 1847 confirmation MAC: 1848 msg_hash = SHA-256(msg_1, ..., msg_n) 1850 dsLen = len(msg_hash) 1852 MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash || 1853 ServerID, dsLen) 1855 where 1857 MAC The MAC MUST be calculated using the already 1858 established MAC algorithm and MUST be computed on the 1859 (ASCII) string "MAC 1 computation", msg_hash, and 1860 ServerID using the existing MAC key K_MAC. 1862 K_MAC The key that is derived from K_PROV which the DSKPP 1863 server MUST provide to the cryptographic module. 1865 msg_hash The message hash, defined in Section 3.4.3, of 1866 messages msg_1, ..., msg_n. 1868 ServerID The identifier that the DSKPP server MUST include in 1869 the element of . 1871 If DSKPP-PRF (defined in Section 3.4.2) is used as the MAC 1872 algorithm, then the input parameter s MUST consist of the 1873 concatenation of the (ASCII) string "MAC 1 computation", msg_hash, 1874 and ServerID, and the parameter dsLen MUST be set to the length of 1875 msg_hash. 1877 The method the DSKPP server MUST use to calculate the server 1878 authentication MAC: 1879 The MAC MUST be computed on the (ASCII) string "MAC 2 1880 computation", the server identifier ServerID, and R, using a pre- 1881 existing MAC key K_MAC' (the MAC key that existed before this 1882 protocol run). Note that the implementation may specify K_MAC' to 1883 be the value of the K_TOKEN that is being replaced. 1885 If DSKPP-PRF is used as the MAC algorithm, then the input 1886 parameter s MUST consist of the concatenation of the (ASCII) 1887 string "MAC 2 computation" ServerID, and R. The parameter dsLen 1888 MUST be set to at least 16 (i.e. the length of the MAC MUST be at 1889 least 16 octets): 1891 dsLen >= 16 1893 MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R, 1894 dsLen) 1896 The MAC algorithm MUST be the same as the algorithm used by the 1897 DSKPP server to calculate the key confirmation MAC. 1899 5.2.3. KeyProvServerFinished 1901 DSKPP Client DSKPP Server 1902 ------------ ------------ 1903 <--- KP, MAC, AD 1905 When this message is sent: 1906 The DSKPP server will send this message after authenticating the 1907 user and, if authentication passed, generating K_TOKEN and a key 1908 package, and associating them with the user's account on the 1909 cryptographic server. 1911 Purpose of this message: 1912 With this message the DSKPP server transports a key package 1913 containing the encrypted provisioning key (K_PROV) and key usage 1914 attributes. 1916 What is contained in this message: 1917 A status attribute equivalent to the server's return code to 1918 . If the server found an acceptable set of 1919 attributes from the client's SAL, then it sets status to Success. 1921 The confirmation message MUST include the Key Package (KP) that 1922 holds the DSKPP Server's ID, key ID, key type, encrypted 1923 provisioning key (K_PROV), encryption method, and additional 1924 configuration information. The default symmetric key package 1925 format MUST be based on the Portable Symmetric Key Container 1926 (PSKC) defined in [PSKC]. Alternative formats MAY include 1927 [SKPC-ASN.1], PKCS#12 [PKCS-12], or PKCS#5 XML [PKCS-5-XML]. 1929 This message MUST include a MAC that the DSKPP client will use for 1930 key confirmation. This key confirmation MAC is calculated using 1931 the "MAC 1 computation" as described in the previous section. 1933 Finally, if an existing key is being replaced, then this message 1934 MUST also include a server authentication MAC (calculated using 1935 the "MAC 2 computation" as described in the previous section), 1936 which is passed as AD to the DSKPP client. 1938 How the DSKPP client uses this message: 1939 After receiving a message with Status = 1940 "Success", the DSKPP client MUST verify both MACs (MAC and AD). 1941 The DSKPP client MUST terminate the DSKPP protocol run if either 1942 MAC does not verify, and MUST, in this case, also delete any 1943 nonces, keys, and/or secrets associated with the failed run of the 1944 protocol. 1946 If has Status = "Success" and the MACs 1947 were verified, then the DSKPP client MUST extract K_PROV from the 1948 provided key package, and derive K_TOKEN. Finally, the DSKPP 1949 client initializes the cryptographic module with K_TOKEN and the 1950 corresponding key usage attributes. After this operation, it MUST 1951 NOT be possible to overwrite the key unless knowledge of an 1952 authorizing key is proven through a MAC on a later 1953 message. 1955 6. Protocol Extensions 1957 DSKPP has been designed to be extensible. The sub-sections below 1958 define two extensions that are included with the DSKPP schema. Since 1959 it is possible that the use of extensions will harm interoperability, 1960 protocol designers are advised to carefully consider the use of 1961 extensions. For example, if a particular implementation relies on 1962 the presence of a proprietary extension, then it may not be able to 1963 interoperate with independent implementations that have no knowledge 1964 of this extension. 1966 Extensions may be sent with any DSKPP message using the 1967 ExtensionsType. The ExtensionsType type is a list of Extensions 1968 containing type-value pairs that define optional features supported 1969 by a DSKPP client or server. Each extension MAY be marked as 1970 Critical by setting the "Critical" attribute of the Extension to 1971 "true". Unless an extension is marked as Critical, a receiving party 1972 need not be able to interpret it; a receiving party is always free to 1973 disregard any (non-critical) extensions. 1975 6.1. The ClientInfoType Extension 1977 The ClientInfoType extension MAY contain any client-specific data 1978 required of an application. This extension MAY be present in a 1979 or message. When present, 1980 this extension MUST NOT be marked as Critical. 1982 DSKPP servers MUST support this extension. DSKPP servers MUST NOT 1983 attempt to interpret the data it carries and, if received, MUST 1984 include it unmodified in the current protocol run's next server 1985 response. DSKPP servers need not retain the ClientInfoType data. 1987 6.2. The ServerInfoType Extension 1989 The ServerInfoType extension MAY contain any server-specific data 1990 required of an application, e.g., state information. This extension 1991 is only valid in messages for which the Status 1992 attribute is set to "Continue". When present, this extension MUST 1993 NOT be marked as Critical. 1995 DSKPP clients MUST support this extension. DSKPP clients MUST NOT 1996 attempt to interpret the data it carries and, if received, MUST 1997 include it unmodified in the current protocol run's next client 1998 request (i.e., the message). DSKPP clients need 1999 not retain the ServerInfoType data. 2001 7. Protocol Bindings 2003 7.1. General Requirements 2005 DSKPP assumes a reliable transport. 2007 7.2. HTTP/1.1 Binding for DSKPP 2009 This section presents a binding of the previous messages to HTTP/1.1 2010 [RFC2616]. This HTTP binding is mandatory-to-implement, although 2011 newer versions of the specification might define additional bindings 2012 in the future. Note that the HTTP client will normally be different 2013 from the DSKPP client (i.e., the HTTP client will "proxy" DSKPP 2014 messages from the DSKPP client to the DSKPP server). Likewise, on 2015 the HTTP server side, the DSKPP server MAY receive DSKPP message from 2016 a "front-end" HTTP server. The DSKPP server will be identified by a 2017 specific URL, which may be pre-configured, or provided to the client 2018 during initialization. 2020 7.2.1. Identification of DSKPP Messages 2022 The MIME-type for all DSKPP messages MUST be 2024 application/dskpp+xml 2026 7.2.2. HTTP Headers 2028 In order to avoid caching of responses carrying DSKPP messages by 2029 proxies, the following holds: 2031 o When using HTTP/1.1, requesters SHOULD: 2032 * Include a Cache-Control header field set to "no-cache, no- 2033 store". 2034 * Include a Pragma header field set to "no-cache". 2036 o When using HTTP/1.1, responders SHOULD: 2037 * Include a Cache-Control header field set to "no-cache, no-must- 2038 revalidate, private". 2039 * Include a Pragma header field set to "no-cache". 2040 * NOT include a Validator, such as a Last-Modified or ETag 2041 header. 2043 To handle content negotiation, HTTP requests MAY include an HTTP 2044 Accept header field. This header field SHOULD should be identified 2045 using the MIME type specified in Section 7.2.1. The Accept header 2046 MAY include additional content types defined by future versions of 2047 this protocol. 2049 There are no other restrictions on HTTP headers, besides the 2050 requirement to set the Content-Type header value to the MIME type 2051 specified in Section 7.2.1. 2053 7.2.3. HTTP Operations 2055 Persistent connections as defined in HTTP/1.1 are OPTIONAL. DSKPP 2056 requests are mapped to HTTP requests with the POST method. DSKPP 2057 responses are mapped to HTTP responses. 2059 For the 4-pass DSKPP, messages within the protocol run are bound 2060 together. In particular, is bound to the 2061 preceding by being transmitted in the 2062 corresponding HTTP response. MUST have a 2063 SessionID attribute, and the SessionID attribute of the subsequent 2064 message MUST be identical. 2065 is then once again bound to the rest through 2066 HTTP (and possibly through a SessionID). 2068 7.2.4. HTTP Status Codes 2070 A DSKPP HTTP responder that refuses to perform a message exchange 2071 with a DSKPP HTTP requester SHOULD return a 403 (Forbidden) response. 2072 In this case, the content of the HTTP body is not significant. In 2073 the case of an HTTP error while processing a DSKPP request, the HTTP 2074 server MUST return a 500 (Internal Server Error) response. This type 2075 of error SHOULD be returned for HTTP-related errors detected before 2076 control is passed to the DSKPP processor, or when the DSKPP processor 2077 reports an internal error (for example, the DSKPP XML namespace is 2078 incorrect, or the DSKPP schema cannot be located). If a request is 2079 received that is not a DSKPP client message, the DSKPP responder MUST 2080 return a 400 (Bad request) response. 2082 In these cases (i.e., when the HTTP response code is 4xx or 5xx), the 2083 content of the HTTP body is not significant. 2085 Redirection status codes (3xx) apply as usual. 2087 Whenever the HTTP POST is successfully invoked, the DSKPP HTTP 2088 responder MUST use the 200 status code and provide a suitable DSKPP 2089 message (possibly with DSKPP error information included) in the HTTP 2090 body. 2092 7.2.5. HTTP Authentication 2094 No support for HTTP/1.1 authentication is assumed. 2096 7.2.6. Initialization of DSKPP 2098 If a user requests key initialization in a browsing session, and if 2099 that request has an appropriate Accept header (e.g., to a specific 2100 DSKPP server URL), the DSKPP server MAY respond by sending a DSKPP 2101 initialization message in an HTTP response with Content-Type set 2102 according to Section 7.2.1 and response code set to 200 (OK). The 2103 initialization message MAY carry data in its body, such as the URL 2104 for the DSKPP client to use when contacting the DSKPP server. If the 2105 message does carry data, the data MUST be a valid instance of a 2106 element. 2108 Note that if the user's request was directed to some other resource, 2109 the DSKPP server MUST NOT respond by combining the DSKPP content type 2110 with response code 200. In that case, the DSKPP server SHOULD 2111 respond by sending a DSKPP initialization message in an HTTP response 2112 with Content-Type set according to Section 7.2.1 and response code 2113 set to 406 (Not Acceptable). 2115 7.2.7. Example Messages 2117 a. Initialization from DSKPP server: 2118 HTTP/1.1 200 OK 2120 Cache-Control: no-store 2121 Content-Type: application/dskpp+xml 2122 Content-Length: 2124 DSKPP initialization data in XML form... 2126 b. Initial request from DSKPP client: 2127 POST http://example.com/cgi-bin/DSKPP-server HTTP/1.1 2129 Cache-Control: no-cache, no-store 2130 Pragma: no-cache 2131 Host: www.example.com 2132 Content-Type: application/dskpp+xml 2133 Content-Length: 2135 DSKPP data in XML form (supported version, supported 2136 algorithms...) 2138 c. Initial response from DSKPP server: 2139 HTTP/1.1 200 OK 2141 Cache-Control: no-cache, no-must-revalidate, private 2142 Pragma: no-cache 2143 Content-Type: application/dskpp+xml 2144 Content-Length: 2146 DSKPP data in XML form (server random nonce, server public key, 2147 ...) 2149 8. DSKPP XML Schema 2151 8.1. General Processing Requirements 2153 Some DSKPP elements rely on the parties being able to compare 2154 received values with stored values. Unless otherwise noted, all 2155 elements that have the XML Schema "xs:string" type, or a type derived 2156 from it, MUST be compared using an exact binary comparison. In 2157 particular, DSKPP implementations MUST NOT depend on case-insensitive 2158 string comparisons, normalization or trimming of white space, or 2159 conversion of locale-specific formats such as numbers. 2161 Implementations that compare values that are represented using 2162 different character encodings MUST use a comparison method that 2163 returns the same result as converting both values to the Unicode 2164 character encoding [UNICODE] and then performing an exact binary 2165 comparison. 2167 No collation or sorting order for attributes or element values is 2168 defined. Therefore, DSKPP implementations MUST NOT depend on 2169 specific sorting orders for values. 2171 8.2. Schema 2173 2174 2182 2186 2188 2189 2190 Basic types 2191 2192 2194 2196 2197 2198 Basic types 2199 2200 2202 2203 2205 2207 2208 2209 2211 2212 2214 2215 2216 2217 2218 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2242 2243 2244 2245 2246 2247 2249 2250 2251 2252 2253 2254 2255 2257 2258 2260 2262 2264 2265 2266 2267 2268 2270 2271 2272 2273 2274 2276 2277 2278 2280 2281 2282 2283 2285 2286 2288 2289 2290 2291 This element is only valid for two-pass DSKPP. 2292 2293 2294 2295 2297 2299 2300 2302 2303 2304 2305 2306 2308 2310 2311 2312 2314 2315 2317 2318 2319 2321 2322 2323 2324 Authentication data contains a MAC. 2325 2326 2327 2328 2330 2331 2333 2334 2335 2336 2338 2339 2340 2342 2344 2345 2346 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2359 2361 2362 2364 2365 2366 2367 2369 2370 2371 2373 2375 2377 2379 2381 2383 2384 2386 2387 2388 Extension types 2389 2390 2391 2393 2394 2396 2397 2398 2400 2401 2402 2403 2404 2405 2406 2407 2408 2410 2411 2412 2413 2414 2415 2416 2417 2418 2420 2422 2423 DSKPP PDUs 2424 2425 2426 2427 2428 2429 Message used to trigger the device to initiate a 2430 DSKPP protocol run. 2431 2432 2433 2434 2435 2437 2438 2439 2440 2441 2443 2445 2446 KeyProvClientHello PDU 2447 2448 2449 2450 2451 2452 Message sent from DSKPP client to DSKPP server to 2453 initiate a DSKPP session. 2454 2455 2456 2457 2458 2459 2461 2463 2465 2467 2469 2471 2474 2476 2478 2480 2481 2482 2483 2485 2487 2488 KeyProvServerHello PDU 2489 2490 2491 2492 2493 2494 Response message sent from DSKPP server to DSKPP client 2495 in four-pass DSKPP. 2496 2497 2498 2499 2500 2501 2503 2505 2507 2509 2511 2512 2514 2516 2517 2518 2519 2521 2523 2524 KeyProvClientNonce PDU 2525 2526 2527 2528 2529 2530 Response message sent from DSKPP client to 2531 DSKPP server in a four-pass DSKPP session. 2532 2533 2534 2535 2536 2537 2539 2541 2543 2544 2546 2548 2549 2551 2553 2554 2555 KeyProvServerFinished PDU 2556 2557 2558 2559 2560 2561 2562 Final message sent from DSKPP server to DSKPP client in 2563 a DSKPP session. A MAC value serves for key 2564 confirmation, and optional AuthenticationData serves for 2565 server authentication. 2566 2567 2568 2569 2570 2571 2573 2575 2576 2578 2579 2580 2581 2582 2584 9. Conformance Requirements 2586 In order to assure that all implementations of DSKPP can 2587 interoperate, the DSKPP server: 2589 a. MUST implement the four-pass variation of the protocol 2590 (Section 4) 2592 b. MUST implement the two-pass variation of the protocol (Section 5) 2594 c. MUST support user authentication (Section 3.2.1) 2596 d. MUST support the following key derivation functions: 2597 * DSKPP-PRF-AES DSKPP-PRF realization (Appendix D) 2598 * DSKPP-PRF-SHA256 DSKPP-PRF realization (Appendix D) 2600 e. MUST support the following encryption mechanisms for protection 2601 of the client nonce in the four-pass protocol: 2602 * Mechanism described in Section 4.2.4 2604 f. MUST support one of the following encryption algorithms for 2605 symmetric key operations, e.g., key wrap: 2606 * KW-AES128 without padding; refer to 2607 http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] 2608 * KW-AES128 with padding; refer to 2609 http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] and 2610 [RFC5649] 2611 * AES-CBC-128; refer to [FIPS197-AES] 2613 g. MUST support the following encryption algorithms for asymmetric 2614 key operations, e.g., key transport: 2615 * RSA Encryption Scheme [PKCS-1] 2617 h. MUST support the following integrity/KDF MAC functions: 2618 * DSKPP-PRF-AES (Appendix D) 2619 * DSKPP-PRF-SHA256 (Appendix D) 2621 i. MUST support the PSKC key package [PSKC]; all three PSKC key 2622 protection methods (Key Transport, Key Wrap, and Passphrase-Based 2623 Key Wrap) MUST be implemented 2625 j. MAY support the ASN.1 key package as defined in [SKPC-ASN.1] 2627 DSKPP clients MUST support either the two-pass or the four-pass 2628 variant of the protocol. DSKPP clients MUST fulfill all requirements 2629 listed in item (c) - (j). 2631 Finally, implementations of DSKPP MUST bind DSKPP messages to 2632 HTTP/1.1 as described in Section 7.2. 2634 Of course, DSKPP is a security protocol, and one of its major 2635 functions is to allow only authorized parties to successfully 2636 initialize a cryptographic module with a new symmetric key. 2637 Therefore, a particular implementation may be configured with any of 2638 a number of restrictions concerning algorithms and trusted 2639 authorities that will prevent universal interoperability. 2641 10. Security Considerations 2643 10.1. General 2645 DSKPP is designed to protect generated keying material from exposure. 2646 No other entities than the DSKPP server and the cryptographic module 2647 will have access to a generated K_TOKEN if the cryptographic 2648 algorithms used are of sufficient strength and, on the DSKPP client 2649 side, generation and encryption of R_C and generation of K_TOKEN take 2650 place as specified in the cryptographic module. This applies even if 2651 malicious software is present in the DSKPP client. However, as 2652 discussed in the following sub-sections, DSKPP does not protect 2653 against certain other threats resulting from man-in-the-middle 2654 attacks and other forms of attacks. DSKPP MUST, therefore, be run 2655 over a transport providing confidentiality and integrity, such as 2656 HTTP over Transport Layer Security (TLS) with a suitable ciphersuite 2657 [RFC2818], when such threats are a concern. Note that TLS 2658 ciphersuites with anonymous key exchanges are not suitable in those 2659 situations [RFC5246]. 2661 10.2. Active Attacks 2663 10.2.1. Introduction 2665 An active attacker MAY attempt to modify, delete, insert, replay, or 2666 reorder messages for a variety of purposes including service denial 2667 and compromise of generated keying material. 2669 10.2.2. Message Modifications 2671 Modifications to a message will either cause denial- 2672 of-service (modifications of any of the identifiers or the 2673 authentication code) or will cause the DSKPP client to contact the 2674 wrong DSKPP server. The latter is in effect a man-in-the-middle 2675 attack and is discussed further in Section 10.2.7. 2677 An attacker may modify a message. This means 2678 that the attacker could indicate a different key or device than the 2679 one intended by the DSKPP client, and could also suggest other 2680 cryptographic algorithms than the ones preferred by the DSKPP client, 2681 e.g., cryptographically weaker ones. The attacker could also suggest 2682 earlier versions of the DSKPP protocol, in case these versions have 2683 been shown to have vulnerabilities. These modifications could lead 2684 to an attacker succeeding in initializing or modifying another 2685 cryptographic module than the one intended (i.e., the server 2686 assigning the generated key to the wrong module), or gaining access 2687 to a generated key through the use of weak cryptographic algorithms 2688 or protocol versions. DSKPP implementations MAY protect against the 2689 latter by having strict policies about what versions and algorithms 2690 they support and accept. The former threat (assignment of a 2691 generated key to the wrong module) is not possible when the shared- 2692 key variant of DSKPP is employed (assuming existing shared keys are 2693 unique per cryptographic module), but is possible in the public-key 2694 variation. Therefore, DSKPP servers MUST NOT accept unilaterally 2695 provided device identifiers in the public-key variation. This is 2696 also indicated in the protocol description. In the shared-key 2697 variation, however, an attacker may be able to provide the wrong 2698 identifier (possibly also leading to the incorrect user being 2699 associated with the generated key) if the attacker has real-time 2700 access to the cryptographic module with the identified key. The 2701 result of this attack could be that the generated key is associated 2702 with the correct cryptographic module but the module is associated 2703 with the incorrect user. See further Section 10.5 for a discussion 2704 of this threat and possible countermeasures. 2706 An attacker may also modify a message. This 2707 means that the attacker could indicate different key types, 2708 algorithms, or protocol versions than the legitimate server would, 2709 e.g., cryptographically weaker ones. The attacker may also provide a 2710 different nonce than the one sent by the legitimate server. Clients 2711 MAY protect against the former through strict adherence to policies 2712 regarding permissible algorithms and protocol versions. The latter 2713 (wrong nonce) will not constitute a security problem, as a generated 2714 key will not match the key generated on the legitimate server. Also, 2715 whenever the DSKPP run would result in the replacement of an existing 2716 key, the element protects against modifications of R_S. 2718 Modifications of messages are also possible. If 2719 an attacker modifies the SessionID attribute, then, in effect, a 2720 switch to another session will occur at the server, assuming the new 2721 SessionID is valid at that time on the server. It still will not 2722 allow the attacker to learn a generated K_TOKEN since R_C has been 2723 wrapped for the legitimate server. Modifications of the 2724 element, e.g., replacing it with a value for which 2725 the attacker knows an underlying R'C, will not result in the client 2726 changing its pre-DSKPP state, since the server will be unable to 2727 provide a valid MAC in its final message to the client. The server 2728 MAY, however, end up storing K'TOKEN rather than K_TOKEN. If the 2729 cryptographic module has been associated with a particular user, then 2730 this could constitute a security problem. For a further discussion 2731 about this threat, and a possible countermeasure, see Section 10.5 2732 below. Note that use of TLS does not protect against this attack if 2733 the attacker has access to the DSKPP client (e.g., through malicious 2734 software, "Trojans") [RFC5246]. 2736 Finally, attackers may also modify the 2737 message. Replacing the element will only result in denial-of- 2738 service. Replacement of any other element may cause the DSKPP client 2739 to associate, e.g., the wrong service with the generated key. DSKPP 2740 SHOULD be run over a transport providing confidentiality and 2741 integrity when this is a concern. 2743 10.2.3. Message Deletion 2745 Message deletion will not cause any other harm than denial-of- 2746 service, since a cryptographic module MUST NOT change its state 2747 (i.e., "commit" to a generated key) until it receives the final 2748 message from the DSKPP server and successfully has processed that 2749 message, including validation of its MAC. A deleted 2750 message will not cause the server to end up 2751 in an inconsistent state vis-a-vis the cryptographic module if the 2752 server implements the suggestions in Section 10.5. 2754 10.2.4. Message Insertion 2756 An active attacker may initiate a DSKPP run at any time, and suggest 2757 any device identifier. DSKPP server implementations MAY receive some 2758 protection against inadvertently initializing a key or inadvertently 2759 replacing an existing key or assigning a key to a cryptographic 2760 module by initializing the DSKPP run by use of the . 2761 The element allows the server to associate a 2762 DSKPP protocol run with, e.g., an earlier user-authenticated session. 2763 The security of this method, therefore, depends on the ability to 2764 protect the element in the DSKPP initialization 2765 message. If an eavesdropper is able to capture this message, he may 2766 race the legitimate user for a key initialization. DSKPP over a 2767 transport providing confidentiality and integrity, coupled with the 2768 recommendations in Section 10.5, is RECOMMENDED when this is a 2769 concern. 2771 Insertion of other messages into an existing protocol run is seen as 2772 equivalent to modification of legitimately sent messages. 2774 10.2.5. Message Replay 2776 During 4-pass DSKPP, attempts to replay a previously recorded DSKPP 2777 message will be detected, as the use of nonces ensures that both 2778 parties are live. For example, a DSKPP client knows that a server it 2779 is communicating with is "live" since the server MUST create a MAC on 2780 information sent by the client. 2782 The same is true for 2-pass DSKPP thanks to the requirement that the 2783 client sends R in the message and that the 2784 server includes R in the MAC computation. 2786 10.2.6. Message Reordering 2788 An attacker may attempt to re-order 4-pass DSKPP messages but this 2789 will be detected, as each message is of a unique type. Note: Message 2790 re-ordering attacks cannot occur in 2-pass DSKPP since each party 2791 sends at most one message each. 2793 10.2.7. Man-in-the-Middle 2795 In addition to other active attacks, an attacker posing as a man-in- 2796 the-middle may be able to provide his own public key to the DSKPP 2797 client. This threat and countermeasures to it are discussed in 2798 Section 4.1.1. An attacker posing as a man-in-the-middle may also be 2799 acting as a proxy and, hence, may not interfere with DSKPP runs but 2800 still learn valuable information; see Section 10.3. 2802 10.3. Passive Attacks 2804 Passive attackers may eavesdrop on DSKPP runs to learn information 2805 that later on may be used to impersonate users, mount active attacks, 2806 etc. 2808 If DSKPP is not run over a transport providing confidentiality, a 2809 passive attacker may learn: 2810 o What cryptographic modules a particular user is in possession of 2811 o The identifiers of keys on those cryptographic modules and other 2812 attributes pertaining to those keys, e.g., the lifetime of the 2813 keys 2814 o DSKPP versions and cryptographic algorithms supported by a 2815 particular DSKPP client or server 2816 o Any value present in an that is part of 2817 2819 Whenever the above is a concern, DSKPP MUST be run over a transport 2820 providing confidentiality. If man-in-the-middle attacks for the 2821 purposes described above are a concern, the transport MUST also offer 2822 server-side authentication. 2824 10.4. Cryptographic Attacks 2826 An attacker with unlimited access to an initialized cryptographic 2827 module may use the module as an "oracle" to pre-compute values that 2828 later on may be used to impersonate the DSKPP server. Section 4.1.1 2829 contains a discussion of this threat and steps RECOMMENDED to protect 2830 against it. 2832 Implementers are advised that cryptographic algorithms become weaker 2833 with time. As new cryptographic techniques are developed and 2834 computing performance improves, the work factor to break a particular 2835 cryptographic algorithm will reduce. Therefore, cryptographic 2836 algorithm implementations SHOULD be modular allowing new algorithms 2837 to be readily inserted. That is, implementers SHOULD be prepared to 2838 regularly update the algorithms in their implementations. 2840 10.5. Attacks on the Interaction between DSKPP and User Authentication 2842 If keys generated in DSKPP will be associated with a particular user 2843 at the DSKPP server (or a server trusted by, and communicating with 2844 the DSKPP server), then in order to protect against threats where an 2845 attacker replaces a client-provided encrypted R_C with his own R'C 2846 (regardless of whether the public-key variation or the shared-secret 2847 variation of DSKPP is employed to encrypt the client nonce), the 2848 server SHOULD NOT commit to associate a generated K_TOKEN with the 2849 given cryptographic module until the user simultaneously has proven 2850 both possession of the device that hosts the cryptographic module 2851 containing K_TOKEN and some out-of-band provided authenticating 2852 information (e.g., an authentication code). For example, if the 2853 cryptographic module is a one-time password token, the user could be 2854 required to authenticate with both a one-time password generated by 2855 the cryptographic module and an out-of-band provided authentication 2856 code in order to have the server "commit" to the generated OTP value 2857 for the given user. Preferably, the user SHOULD perform this 2858 operation from another host than the one used to initialize keys on 2859 the cryptographic module, in order to minimize the risk of malicious 2860 software on the client interfering with the process. 2862 Note: This scenario, wherein the attacker replaces a client-provided 2863 R_C with his own R'C, does not apply to 2-pass DSKPP as the client 2864 does not provide any entropy to K_TOKEN. The attack as such (and its 2865 countermeasures) still applies to 2-pass DSKPP, however, as it 2866 essentially is a man-in-the-middle attack. 2868 Another threat arises when an attacker is able to trick a user to 2869 authenticate to the attacker rather than to the legitimate service 2870 before the DSKPP protocol run. If successful, the attacker will then 2871 be able to impersonate the user towards the legitimate service, and 2872 subsequently receive a valid DSKPP trigger. If the public-key 2873 variant of DSKPP is used, this may result in the attacker being able 2874 to (after a successful DSKPP protocol run) impersonate the user. 2875 Ordinary precautions MUST, therefore, be in place to ensure that 2876 users authenticate only to legitimate services. 2878 10.6. Miscellaneous Considerations 2879 10.6.1. Client Contributions to K_TOKEN Entropy 2881 In 4-pass DSKPP, both the client and the server provide randomizing 2882 material to K_TOKEN, in a manner that allows both parties to verify 2883 that they did contribute to the resulting key. In the 2-pass DSKPP 2884 version defined herein, only the server contributes to the entropy of 2885 K_TOKEN. This means that a broken or compromised (pseudo-)random 2886 number generator in the server may cause more damage than it would in 2887 the 4-pass variant. Server implementations SHOULD therefore take 2888 extreme care to ensure that this situation does not occur. 2890 10.6.2. Key Confirmation 2892 4-pass DSKPP servers provide key confirmation through the MAC on R_C 2893 in the message. In the 2-pass DSKPP variant 2894 described herein, key confirmation is provided by the MAC including 2895 R, using K_MAC. 2897 10.6.3. Server Authentication 2899 DSKPP servers MUST authenticate themselves whenever a successful 2900 DSKPP 2-pass protocol run would result in an existing K_TOKEN being 2901 replaced by a K_TOKEN', or else a denial-of-service attack where an 2902 unauthorized DSKPP server replaces a K_TOKEN with another key would 2903 be possible. In 2-pass DSKPP, servers authenticate by including the 2904 AuthenticationDataType extension containing a MAC as described in 2905 Section 5 for two-pass DSKPP. 2907 Whenever a successful DSKPP 2-pass protocol run would result in an 2908 existing K_TOKEN being replaced by a K_TOKEN', the DSKPP client and 2909 server MUST do the following to prevent a denial-of-service attack 2910 where an unauthorized DSKPP server replaces a K_TOKEN with another 2911 key: 2912 o The DSKPP server MUST use the AuthenticationDataType extension to 2913 transmit a second MAC, calculated as described in Section 5.2.2. 2914 o The DSKPP client MUST authenticate the server using the MAC 2915 contained in the AuthenticationDataType extension received from 2916 the DSKPP server to which it is connected. 2918 10.6.4. User Authentication 2920 A DSKPP server MUST authenticate a client to ensure that K_TOKEN is 2921 delivered to the intended device. The following measures SHOULD be 2922 considered: 2924 o When an Authentication Code is used for client authentication, a 2925 password dictionary attack on the authentication data is possible. 2927 o The length of the Authentication Code when used over a non-secure 2928 channel SHOULD be longer than what is used over a secure channel. 2929 When a device, e.g., some mobile phones with small screens, cannot 2930 handle a long Authentication Code in a user-friendly manner, DSKPP 2931 SHOULD rely on a secure channel for communication. 2932 o In the case that a non-secure channel has to be used, the 2933 Authentication Code SHOULD be sent to the server MAC'd as 2934 specified in Section 3.4.1. The Authentication Code and nonce 2935 value MUST be strong enough to prevent offline brute-force 2936 recovery of the Authentication Code from the HMAC data. Given 2937 that the nonce value is sent in plaintext format over a non-secure 2938 transport, the cryptographic strength of the Authentication Data 2939 depends more on the quality of the Authentication Code. 2940 o When the Authentication Code is sent from the DSKPP server to the 2941 device in a DSKPP initialization trigger message, an eavesdropper 2942 may be able to capture this message and race the legitimate user 2943 for a key initialization. To prevent this, the transport layer 2944 used to send the DSKPP trigger MUST provide confidentiality and 2945 integrity, e.g. a secure browser session. 2947 10.6.5. Key Protection in Two-Pass DSKPP 2949 Three key protection methods are defined for the different usages of 2950 2-pass DSKPP, which MUST be supported by a key package format, such 2951 as [PSKC] and [SKPC-ASN.1]. Therefore, key protection in the two- 2952 pass DSKPP is dependent upon the security of the key package format 2953 selected for a protocol run. Some considerations for the Passphrase- 2954 Based Key Wrap method follow. 2956 The passphrase-based key wrap method SHOULD depend upon the PBKDF2 2957 function from [PKCS-5] to generate an encryption key from a 2958 passphrase and salt string. It is important to note that passphrase- 2959 based encryption is generally limited in the security that it 2960 provides despite the use of salt and iteration count in PBKDF2 to 2961 increase the complexity of attack. Implementations SHOULD therefore 2962 take additional measures to strengthen the security of the 2963 passphrase-based key wrap method. The following measures SHOULD be 2964 considered where applicable: 2966 o The passphrase is the same as the one-time password component of 2967 the authentication code (see Section 3.4.1) for a description of 2968 the AC format). The passphrase SHOULD be selected well, and usage 2969 guidelines such as the ones in [NIST-PWD] SHOULD be taken into 2970 account. 2971 o A different passphrase SHOULD be used for every key initialization 2972 wherever possible (the use of a global passphrase for a batch of 2973 cryptographic modules SHOULD be avoided, for example). One way to 2974 achieve this is to use randomly-generated passphrases. 2976 o The passphrase SHOULD be protected well if stored on the server 2977 and/or on the cryptographic module and SHOULD be delivered to the 2978 device's user using secure methods. 2979 o User pre-authentication SHOULD be implemented to ensure that 2980 K_TOKEN is not delivered to a rogue recipient. 2981 o The iteration count in PBKDF2 SHOULD be high to impose more work 2982 for an attacker using brute-force methods (see [PKCS-5] for 2983 recommendations). However, it MUST be noted that the higher the 2984 count, the more work is required on the legitimate cryptographic 2985 module to decrypt the newly delivered K_TOKEN. Servers MAY use 2986 relatively low iteration counts to accommodate devices with 2987 limited processing power such as some PDA and cell phones when 2988 other security measures are implemented and the security of the 2989 passphrase-based key wrap method is not weakened. 2990 o Transport level security [RFC5246] SHOULD be used where possible 2991 to protect a two-pass protocol run. Transport level security 2992 provides a second layer of protection for the newly generated 2993 K_TOKEN. 2995 10.6.6. Algorithm Agility 2997 Many protocols need to be algorithm agile. One reason for this is 2998 that in the past many protocols had fixed sized fields for 2999 information such as hash outputs, keys, etc. This is not the case 3000 for DSKPP, except for the key size in the computation of DSKPP-PRF. 3001 Another reason was that protocols did not support algorithm 3002 negotiation. This is also not the case for DSKPP, except for the use 3003 of SHA-256 in the MAC confirmation message. Updating the key size 3004 for DSKPP-PRF or the MAC confirmation message algorithm will require 3005 a new version of the protocol, which is supported with the Version 3006 attribute. 3008 11. Internationalization Considerations 3010 The DSKPP protocol is meant for machine-to-machine communications; as 3011 such, its elements are tokens not meant for direct human consumption. 3012 DSKPP exchanges information using XML. All XML processors are 3013 required to understand UTF-8 [RFC3629] encoding, and therefore all 3014 DSKPP clients and servers MUST understand UTF-8 encoded XML. 3015 Additionally, DSKPP servers and clients MUST NOT encode XML with 3016 encodings other than UTF-8. 3018 12. IANA Considerations 3020 This document requires several IANA registrations, detailed below. 3022 12.1. URN Sub-Namespace Registration 3024 This section registers a new XML namespace, 3025 "urn:ietf:params:xml:ns:keyprov:dskpp" per the guidelines in 3026 [RFC3688]: 3028 URI: urn:ietf:params:xml:ns:keyprov:dskpp 3029 Registrant Contact: 3030 IETF, KEYPROV Working Group (keyprov@ietf.org), Andrea Doherty 3031 (andrea.doherty@rsa.com) 3032 XML: 3033 BEGIN 3034 3035 3037 3038 3039 DSKPP Messsages 3040 3041 3042

Namespace for DSKPP Messages

3043

urn:ietf:params:xml:ns:keyprov:dskpp

3044 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX below 3045 with the RFC number for this specification.] 3046

See RFCXXXX

3047 3048 3049 END 3051 12.2. XML Schema Registration 3053 This section registers an XML schema as per the guidelines in 3054 [RFC3688]. 3056 URI: urn:ietf:params:xml:ns:keyprov:dskpp 3057 Registrant Contact: 3058 IETF, KEYPROV Working Group (keyprov@ietf.org), Andrea Doherty 3059 (andrea.doherty@rsa.com) 3060 Schema: 3061 The XML for this schema can be found as the entirety of Section 8 3062 of this document. 3064 12.3. MIME Media Type Registration 3066 This section registers the "application/dskpp+xml" MIME type: 3068 To: ietf-types@iana.org 3069 Subject: Registration of MIME media type application/dskpp+xml 3070 MIME media type name: application 3071 MIME subtype name: dskpp+xml 3072 Required parameters: (none) 3073 Optional parameters: charset 3074 Indicates the character encoding of enclosed XML. 3075 Encoding considerations: Uses XML, which can employ 8-bit 3076 characters, depending on the character encoding used. See 3077 [RFC3203], Section 3.2. Implementations need to support UTF-8 3078 [RFC3629]. 3079 Security considerations: This content type is designed to carry 3080 protocol data related to key management. Security mechanisms are 3081 built into the protocol to ensure that various threats are dealt 3082 with. Refer to Section 10 of the Published Specification for more 3083 details 3084 Interoperability considerations: None 3085 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please 3086 replace XXXX with the RFC number for this specification.] 3087 Applications which use this media type: Protocol for key exchange. 3088 Additional information: 3089 Magic Number(s): (none) 3090 File extension(s): .xmls 3091 Macintosh File Type Code(s): (none) 3092 Person & email address to contact for further information: 3093 Andrea Doherty (andrea.doherty@rsa.com) 3094 Intended usage: LIMITED USE 3095 Author/Change controller: The IETF 3096 Other information: This media type is a specialization of 3097 application/xml [RFC3203], and many of the considerations 3098 described there also apply to application/dskpp+xml. 3100 12.4. Status Code Registration 3102 This section registers status codes included in each DSKPP response 3103 message. The status codes are defined in the schema in the 3104 type definition contained in the XML schema in 3105 Section 8. The following summarizes the registry: 3107 Related Registry: 3108 KEYPROV DSKPP Registries, Status codes for DSKPP 3110 Defining RFC: 3111 RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the 3112 RFC number for this specification.] 3114 Registration/Assignment Procedures: 3115 Following the policies outlined in [RFC3575], the IANA policy for 3116 assigning new values for the status codes for DSKPP MUST be 3117 "Specification Required" and their meanings MUST be documented in 3118 an RFC or in some other permanent and readily available reference, 3119 in sufficient detail that interoperability between independent 3120 implementations is possible. No mechanism to mark entries as 3121 "deprecated" is envisioned. It is possible to update entries from 3122 the registry. 3124 Registrant Contact: 3125 IETF, KEYPROV working group (keyprov@ietf.org), 3126 Andrea Doherty (andrea.doherty@rsa.com) 3128 12.5. DSKPP Version Registration 3130 This section registers DSKPP version numbers. The registry has the 3131 following structure: 3132 +-------------------------------------------+ 3133 | DSKPP Version | Specification | 3134 +-------------------------------------------+ 3135 | 1.0 | [This document] | 3136 +-------------------------------------------+ 3138 Standards action is required to define new versions of DSKPP. It is 3139 not envisioned to deprecate, delete, or modify existing DSKPP 3140 versions. 3142 12.6. PRF Algorithm ID Sub-Registry 3144 This specification relies on a cryptographic primitive, called 3145 "DSKPP-PRF" that provides a deterministic transformation of a secret 3146 key k and a varying length octet string s to a bit string of 3147 specified length dsLen. From the point of view of this 3148 specification, DSKPP-PRF is a "black-box" function that, given the 3149 inputs, generates a pseudorandom value that can be realized by any 3150 appropriate and competent cryptographic technique. . Section 3.4.2 3151 provides two realizations of DSKPP-PRF, DSKPP-PRF-AES and DSKPP-PRF- 3152 SHA256. 3154 This section registers the identifiers associated with these 3155 realizations. PRF Algorithm ID Sub-registries are to be subject to 3156 Specification Required as per RFC 5226 [RFC5226]. Updates MUST be 3157 documented in an RFC or in some other permanent and readily available 3158 reference, in sufficient detail that interoperability between 3159 independent implementations is possible. 3161 Expert approval is required to deprecate a sub-registry. Once 3162 deprecated, the PRF Algorithm ID SHOULD NOT be used in any new 3163 implementations. 3165 12.6.1. DSKPP-PRF-AES 3167 Common Name: 3168 DSKPP-PRF-AES 3170 URI: 3171 urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128 3173 Identifier Definition: 3174 The DSKPP-PRF-AES algorithm realization is defined in 3175 Appendix D.2.2 of this document. 3177 Registrant Contact: 3178 IETF, KEYPROV working group (keyprov@ietf.org), 3179 Andrea Doherty (andrea.doherty@rsa.com) 3181 12.6.2. DSKPP-PRF-SHA256 3183 Common Name: 3184 DSKPP-PRF-SHA256 3186 URI: 3187 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 3189 Identifier Definition: 3190 The DSKPP-PRF-SHA256 algorithm realization is defined in 3191 Appendix D.3.2 of this document. 3193 Registrant Contact: 3194 IETF, KEYPROV working group (keyprov@ietf.org), 3195 Andrea Doherty (andrea.doherty@rsa.com) 3197 12.7. Key Container Registration 3199 This section registers the Key Container type. 3201 Key Container: 3202 The registration name for the Key Container. 3204 Specification: 3205 Key Container defines a key package format that specifies how a 3206 key should be protected using the three key protection methods 3207 provided in Section 5.1. 3209 Registration Procedure: 3210 Following the policies outlined in [RFC3575], the IANA policy for 3211 assigning new values for the status codes for DSKPP MUST be 3212 "Specification Required" and their meanings MUST be documented in 3213 an RFC or in some other permanent and readily available reference, 3214 in sufficient detail that interoperability between independent 3215 implementations is possible. 3217 Deprecated: 3218 TRUE if based on expert approval this entry has been deprecated 3219 and SHOULD NOT be used in any new implementations. Otherwise 3220 FALSE. 3222 Identifiers: 3223 The initial URIs for the Key Container defined for this version of 3224 the document are listed here: 3226 Name: PSKC Key Container 3227 URI: urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 3228 Specification: [PSKC] 3229 Deprecated: FALSE 3231 Name: SKPC Key Container 3232 URI: urn:ietf:params:xml:ns:keyprov:dskpp:skpc-key-container 3233 Specification: [SKPC-ASN.1] 3234 Deprecated: FALSE 3236 Name: PKCS12 Key Container 3237 URI: urn:ietf:params:xml:ns:keyprov:dskpp:pkcs12-key-container 3238 Specification: [PKCS-12] 3239 Deprecated: FALSE 3241 Name: PKCS5-XML Key Container 3242 URI: urn:ietf:params:xml:ns:keyprov:dskpp:pkcs5-xml-key-container 3243 Specification: [PKCS-5-XML] 3244 Deprecated: FALSE 3246 Registrant Contact: 3247 IETF, KEYPROV working group (keyprov@ietf.org), 3248 Andrea Doherty (andrea.doherty@rsa.com) 3250 13. Intellectual Property Considerations 3252 RSA and RSA Security are registered trademarks or trademarks of RSA 3253 Security Inc. in the United States and/or other countries. The names 3254 of other products and services mentioned may be the trademarks of 3255 their respective owners. 3257 14. Contributors 3259 This work is based on information contained in [RFC4758], authored by 3260 Magnus Nystrom, with enhancements borrowed from an individual 3261 Internet-Draft co-authored by Mingliang Pei and Salah Machani (e.g., 3262 User Authentication, and support for multiple key package formats). 3264 We would like to thank Philip Hoyer for his work in aligning DSKPP 3265 and PSKC schemas. 3267 We would also like to thank Hannes Tschofenig and Phillip Hallam- 3268 Baker for their draft reviews, feedback, and text contributions. 3270 15. Acknowledgements 3272 We would like to thank the following for review of previous DSKPP 3273 document versions: 3275 o Dr. Ulrike Meyer (Review June 2007) 3276 o Niklas Neumann (Review June 2007) 3277 o Shuh Chang (Review June 2007) 3278 o Hannes Tschofenig (Review June 2007 and again in August 2007) 3279 o Sean Turner (Reviews August 2007 and again in July 2008) 3280 o John Linn (Review August 2007) 3281 o Philip Hoyer (Review September 2007) 3282 o Thomas Roessler (Review November 2007) 3283 o Lakshminath Dondeti (Comments December 2007) 3284 o Pasi Eronen (Comments December 2007) 3285 o Phillip Hallam-Baker (Review and Edits November 2008 and again in 3286 January 2009) 3287 o Alexey Melnikov (Review May 2010) 3288 o Peter Saint-Andre (Review May 2010) 3290 We would also like to thank the following for their input to selected 3291 design aspects of the DSKPP protocol: 3293 o Anders Rundgren (Key Package Format and Client Authentication 3294 Data) 3295 o Thomas Roessler (HTTP Binding) 3296 o Hannes Tschofenig (HTTP Binding) 3297 o Phillip Hallam-Baker (Registry for Algorithms) 3298 o N. Asokan (original observation of weakness in Authentication 3299 Data) 3301 Finally, we would like to thank Robert Griffin for opening 3302 communication channels for us with the IEEE P1619.3 Key Management 3303 Group, and facilitating our groups in staying informed of potential 3304 areas (esp. key provisioning and global key identifiers of 3305 collaboration) of collaboration. 3307 16. References 3309 16.1. Normative references 3311 [FIPS180-SHA] 3312 National Institute of Standards and Technology, "Secure 3313 Hash Standard", FIPS 180-2, February 2004, . 3317 [FIPS197-AES] 3318 National Institute of Standards and Technology, 3319 "Specification for the Advanced Encryption Standard 3320 (AES)", FIPS 197, November 2001, . 3323 [ISO3309] "ISO Information Processing Systems - Data Communication - 3324 High-Level Data Link Control Procedure - Frame Structure", 3325 IS 3309, 3rd Edition, October 1984. 3327 [PKCS-1] RSA Laboratories, "RSA Cryptography Standard", PKCS #1 3328 Version 2.1, June 2002, 3329 . 3331 [PKCS-5] RSA Laboratories, "Password-Based Cryptography Standard", 3332 PKCS #5 Version 2.0, March 1999, 3333 . 3335 [PKCS-5-XML] 3336 RSA Laboratories, "XML Schema for PKCS #5 Version 2.0", 3337 PKCS #5 Version 2.0 Amd.1 (FINAL DRAFT), October 2006, 3338 . 3340 [PSKC] "Portable Symmetric Key Container", 2010, 3341 . 3343 [RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 3344 Hashing for Message Authentication", RFC 2104, 3345 February 1997, . 3347 [RFC2119] "Key words for use in RFCs to Indicate Requirement 3348 Levels", BCP 14, RFC 2119, March 1997, 3349 . 3351 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3352 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3353 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999, 3354 . 3356 [RFC3394] Schaad , J. and R. Housley, "Advanced Encryption Standard 3357 (AES) Key Wrap Algorithm", RFC 3394, September 2002, 3358 . 3360 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646", 3361 STD 63, RFC 3629, November 2003, 3362 . 3364 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 3365 and Passwords", RFC 4013, February 2005, 3366 . 3368 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3369 "Internet X.509 Public Key Infrastructure Certificate 3370 Management Protocol (CMP)", RFC 4210, September 2005, 3371 . 3373 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 3374 (CMC)", RFC 5272, June 2008, 3375 . 3377 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3378 Housley, R., and W. Polk, "Internet X.509 Public Key 3379 Infrastructure Certificate and Certificate Revocation List 3380 (CRL) Profile", RFC 5280, May 2008, 3381 . 3383 [RFC5649] Housley, R. and M. Dworkin , "Advanced Encryption Standard 3384 (AES) Key Wrap with Padding Algorithm", RFC 5649, 3385 August 2009, . 3387 [UNICODE] Davis, M. and M. Duerst, "Unicode Normalization Forms", 3388 March 2001, 3389 . 3392 [XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth 3393 Edition)", W3C Recommendation, November 2008, 3394 . 3396 [XMLDSIG] W3C, "XML Signature Syntax and Processing", 3397 W3C Recommendation, February 2002, 3398 . 3400 [XMLENC] W3C, "XML Encryption Syntax and Processing", 3401 W3C Recommendation, December 2002, 3402 . 3404 16.2. Informative references 3406 [CT-KIP-P11] 3407 RSA Laboratories, "PKCS #11 Mechanisms for the 3408 Cryptographic Token Key Initialization Protocol", PKCS #11 3409 Version 2.20 Amd.2, December 2005, 3410 . 3412 [FAQ] RSA Laboratories, "Frequently Asked Questions About 3413 Today's Cryptography", Version 4.1, 2000. 3415 [NIST-PWD] 3416 National Institute of Standards and Technology, "Password 3417 Usage", FIPS 112, May 1985, 3418 . 3420 [NIST-SP800-38B] 3421 International Organization for Standardization, 3422 "Recommendations for Block Cipher Modes of Operation: The 3423 CMAC Mode for Authentication", NIST SP800-38B, May 2005, < 3424 http://csrc.nist.gov/publications/nistpubs/800-38B/ 3425 SP_800-38B.pdf>. 3427 [NIST-SP800-57] 3428 National Institute of Standards and Technology, 3429 "Recommendation for Key Management - Part I: General 3430 (Revised)", NIST 800-57, March 2007, . 3434 [PKCS-11] RSA Laboratories, "Cryptographic Token Interface 3435 Standard", PKCS #11 Version 2.20, June 2004, 3436 . 3438 [PKCS-12] "Personal Information Exchange Syntax Standard", PKCS #12 3439 Version 1.0, 2005, 3440 . 3443 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, 3444 . 3446 [RFC3203] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 3447 Types", RFC 3203, January 2001, 3448 . 3450 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, 3451 July 2003, . 3453 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, 3454 January 2004, . 3456 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3457 Resource Identifier (URI): Generic Syntax", RFC 3986, 3458 STD 66, January 2005, 3459 . 3461 [RFC4758] RSA, The Security Division of EMC, "Cryptographic Token 3462 Key Initialization Protocol (CT-KIP)", RFC 4758, 3463 November 2006, . 3465 [RFC5246] Dierks, T. and E. Rescorla , "The Transport Layer Security 3466 (TLS) Protocol, Version 1.2", RFC 5246, August 2008, 3467 . 3469 [SKPC-ASN.1] 3470 "Symmetric Key Package Content Type", 2007, . 3474 [XMLNS] W3C, "Namespaces in XML", W3C Recommendation, 3475 January 1999, 3476 . 3478 Appendix A. Usage Scenarios 3480 DSKPP is expected to be used to provision symmetric keys to 3481 cryptographic modules in a number of different scenarios, each with 3482 its own special requirements, as described below. This appendix 3483 forms an informative part of the document. 3485 A.1. Single Key Request 3487 The usual scenario is that a cryptographic module makes a request for 3488 a symmetric key from a provisioning server that is located on the 3489 local network or somewhere on the Internet. Depending upon the 3490 deployment scenario, the provisioning server may generate a new key 3491 on-the-fly or use a pre-generated key, e.g., one provided by a legacy 3492 back-end issuance server. The provisioning server assigns a unique 3493 key ID to the symmetric key and provisions it to the cryptographic 3494 module. 3496 A.2. Multiple Key Requests 3498 A cryptographic module makes multiple requests for symmetric keys 3499 from the same provisioning server. The symmetric keys need not be of 3500 the same type, i.e., the keys may be used with different symmetric 3501 key cryptographic algorithms, including one-time password 3502 authentication algorithms, and the AES encryption algorithm. 3504 A.3. User Authentication 3506 In some deployment scenarios, a key issuer may rely on a third party 3507 provisioning service. In this case, the issuer directs provisioning 3508 requests from the cryptographic module to the provisioning service. 3509 As such, it is the responsibility of the issuer to authenticate the 3510 user through some out-of-band means before granting him rights to 3511 acquire keys. Once the issuer has granted those rights, the issuer 3512 provides an authentication code to the user and makes it available to 3513 the provisioning service, so that the user can prove that he is 3514 authorized to acquire keys. 3516 A.4. Provisioning Time-Out Policy 3518 An issuer may provide a time-limited authentication code to a user 3519 during registration, which the user will input into the cryptographic 3520 module to authenticate themselves with the provisioning server. The 3521 server will allow a key to be provisioned to the cryptographic module 3522 hosted by the user's device when user authentication is required only 3523 if the user inputs a valid authentication code within the fixed time 3524 period established by the issuer. 3526 A.5. Key Renewal 3528 A cryptographic module requests renewal of the symmetric key material 3529 attached to a key ID, as opposed to keeping the key value constant 3530 and refreshing the metadata. Such a need may occur in the case when 3531 a user wants to upgrade her device that houses the cryptographic 3532 module or when a key has expired. When a user uses the same 3533 cryptographic module to, for example, perform strong authentication 3534 at multiple Web login sites, keeping the same key ID removes the need 3535 for the user to register a new key ID at each site. 3537 A.6. Pre-Loaded Key Replacement 3539 This scenario represents a special case of symmetric key renewal in 3540 which a local administrator can authenticate the user procedurally 3541 before initiating the provisioning process. It also allows for a 3542 device issuer to pre-load a key onto a cryptographic module with a 3543 restriction that the key is replaced with a new key prior to use of 3544 the cryptographic module. Another variation of this scenario is the 3545 organization who recycles devices. In this case, a key issuer would 3546 provision a new symmetric key to a cryptographic module hosted on a 3547 device that was previously owned by another user. 3549 Note that this usage scenario is essentially the same as the previous 3550 scenario wherein the same key ID is used for renewal. 3552 A.7. Pre-Shared Manufacturing Key 3554 A cryptographic module is loaded onto a smart card after the card is 3555 issued to a user. The symmetric key for the cryptographic module 3556 will then be provisioned using a secure channel mechanism present in 3557 many smart card platforms. This allows a direct secure channel to be 3558 established between the smart card chip and the provisioning server. 3559 For example, the card commands (i.e., Application Protocol Data 3560 Units, or APDUs) are encrypted with a pre-issued card manufacturer's 3561 key and sent directly to the smart card chip, allowing secure post- 3562 issuance in-the-field provisioning. This secure flow can pass 3563 Transport Layer Security (TLS) [RFC5246] and other transport security 3564 boundaries. 3566 Note that two pre-conditions for this usage scenario are for the 3567 protocol to be tunneled and the provisioning server to know the 3568 correct pre-established manufacturer's key. 3570 A.8. End-to-End Protection of Key Material 3572 In this scenario, transport layer security does not provide end-to- 3573 end protection of keying material transported from the provisioning 3574 server to the cryptographic module. For example, TLS may terminate 3575 at an application hosted on a PC rather than at the cryptographic 3576 module (i.e., the endpoint) located on a data storage device 3577 [RFC5246]. Mutually authenticated key agreement provides end-to-end 3578 protection, which TLS cannot provide. 3580 Appendix B. Examples 3582 This appendix contains example messages that illustrate parameters, 3583 encoding, and semantics in four-and two- pass DSKPP exchanges. The 3584 examples are written using XML, and are syntactically correct. MAC 3585 and cipher values are fictitious however. This appendix forms an 3586 informative part of the document. 3588 B.1. Trigger Message 3590 3591 3594 3595 3596 3597 TokenVendorAcme 3598 987654321 3599 2009-09-01T00:00:00Z 3600 2014-09-01T00:00:00Z 3601 3602 3603 SE9UUDAwMDAwMDAx 3604 3606 3607 31300257 3608 3609 512 3610 4bRJf9xXd3KchKoTenHJiw== 3611 3612 3613 https://www.somekeyprovservice.com/ 3614 3615 3616 3618 B.2. Four-Pass Protocol 3620 B.2.1. Without a Preceding Trigger 3621 3622 3628 3629 3630 TokenVendorAcme 3631 987654321 3632 2009-09-01T00:00:00Z 3633 2014-09-01T00:00:00Z 3634 3635 3636 3637 3638 urn:ietf:params:xml:ns:keyprov:pskc:hotp 3639 3640 3641 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES 3642 3643 3644 3645 3646 http://www.w3.org/2001/04/xmlenc#aes128-cbc 3647 3648 3649 3650 3651 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 3652 3653 3654 3655 3656 3657 3658 3659 urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 3660 3661 3662 3664 B.2.2. Assuming a Preceding Trigger 3665 3666 3672 3673 3674 TokenVendorAcme 3675 987654321 3676 2009-09-01T00:00:00Z 3677 2014-09-01T00:00:00Z 3678 3679 3680 SE9UUDAwMDAwMDAx 3681 3682 3683 urn:ietf:params:xml:ns:keyprov:pskc:hotp 3684 3685 3686 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES 3687 3688 3689 3690 3691 http://www.w3.org/2001/04/xmlenc#aes128-cbc 3692 3693 3694 3695 3696 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 3697 3698 3699 3700 3701 3702 3703 3704 urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 3705 3706 3707 3709 B.2.3. Without a Preceding Trigger 3711 3712 3720 3721 urn:ietf:params:xml:ns:keyprov:pskc:hotp 3722 3723 3724 http://www.w3.org/2001/04/xmlenc#aes128-cbc 3725 3726 3727 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 3728 3729 3730 Example-Key1 3731 3732 3733 urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 3734 3735 3736 EjRWeJASNFZ4kBI0VniQEg== 3737 3738 3740 B.2.4. Assuming Key Renewal 3742 3743 3751 3752 urn:ietf:params:xml:schema:keyprov:otpalg#SecurID-AES 3753 3754 3755 http://www.w3.org/2001/04/xmlenc#aes128-cbc 3756 3757 3758 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 3759 3760 3761 Example-Key1 3762 3763 3764 urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 3765 3766 3767 qw2ewasde312asder394jw== 3768 3769 3771 cXcycmFuZG9tMzEyYXNkZXIzOTRqdw== 3772 3773 3775 B.2.5. Using Default Encryption 3777 This message contains the nonce chosen by the cryptographic module, 3778 R_C, encrypted by the specified encryption key and encryption 3779 algorithm. 3781 3782 3789 3790 oTvo+S22nsmS2Z/RtcoF8CTwadRa1PVsRXkZnCihHkU1rPueggrd0NpEWVZR 3791 16Rg16+FHuTg33GK1wH3wffDZQ== 3792 3793 3795 B.2.6. Using Default Encryption 3797 3798 3806 3807 3808 3809 3810 3811 TokenVendorAcme 3812 3813 3814 987654321 3815 3816 3817 2009-09-01T00:00:00Z 3818 3819 3820 2014-09-01T00:00:00Z 3821 3822 3823 3824 CM_ID_001 3825 3826 3830 Example-Issuer 3831 3832 3834 3835 3836 3837 0 3838 3839 3840 3841 OTP 3842 3843 3844 3845 3846 3847 3850 151yAR2NqU5dJzETK+SGYqN6sq6DEH5AgHohra3Jpp4= 3851 3852 3854 B.3. Two-Pass Protocol 3856 B.3.1. Example Using the Key Transport Method 3858 The client indicates support for all the Key Transport, Key Wrap, and 3859 Passphrase-Based Key Wrap key protection methods: 3861 3862 3868 3869 3870 TokenVendorAcme 3871 987654321 3872 2009-09-01T00:00:00Z 3873 2014-09-01T00:00:00Z 3874 3875 3876 3877 3878 urn:ietf:params:xml:ns:keyprov:pskc:hotp 3879 3880 3881 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES 3882 3883 3884 3885 3886 http://www.w3.org/2001/04/xmlenc#rsa_1_5 3887 3888 3889 3890 3891 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 3892 3893 3894 3895 3896 3897 urn:ietf:params:xml:schema:keyprov:dskpp:transport 3898 3899 3900 3901 3902 3903 MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGM 3904 RMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MD 3905 kxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXl 3906 Qcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ 3907 AoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA 3908 3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCx 3909 vdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYE 3910 Ae875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqfrnRuXJRMeZXaaEGmzY1k 3911 LonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w4rnqdkmwZX/NgXg06aln 3912 c2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo= 3913 3914 3915 3916 3917 3918 3919 3920 3921 urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 3922 3923 3924 3925 AC00000A 3926 3927 3928 ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI= 3929 3930 100000 3931 3934 3eRz51ILqiG+dJW2iLcjuA== 3935 3936 3937 3938 3940 In this example, the server responds to the previous request by 3941 returning a key package in which the provisioning key was encrypted 3942 using the Key Transport key protection method. 3944 3945 3956 3957 3958 3959 3960 3961 MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGM 3962 RMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MD 3963 kxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXl 3964 Qcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ 3965 AoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA 3966 3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCx 3967 vdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYE 3968 Ae875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqfrnRuXJRMeZXaaEGmzY1k 3969 LonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w4rnqdkmwZX/NgXg06aln 3970 c2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo= 3971 3972 3974 3975 3976 3977 3978 TokenVendorAcme 3979 3980 3981 987654321 3982 3983 3984 2009-09-01T00:00:00Z 3985 3986 3987 2014-09-01T00:00:00Z 3988 3989 3990 3994 Example-Issuer 3995 3996 3998 3999 4000 4001 4002 4005 4006 4007 eyjr23WMy9S2UdKgGnQEbs44T1jmX1TNWEBq48xfS20PK2VWF4ZK1iSctHj/u3uk+7+y8 4008 uKrAzHEm5mujKPAU4DCbb5mSibXMnAbbIoAi2cJW60/l8FlzwaU4EZsZ1LyQ1GcBQKACE 4009 eylG5vK8NTo47vZTatL5UxmbmOX2HvaVQ= 4010 4011 4012 4013 4014 4015 0 4016 4017 4018 4019 OTP 4020 4021 4023 4024 4025 4026 4029 GHZ0H6Y+KpxdlVZ7zgcJDiDdqc8Gcmlcf+HQi4EUxYU= 4030 4031 4033 B.3.2. Example Using the Key Wrap Method 4035 The client sends a request that specifies a shared key to protect the 4036 K_TOKEN, and the server responds using the Key Wrap key protection 4037 method. Authentication data in this example is based on an 4038 authentication code rather than a device certificate. 4040 4041 4047 4048 4049 TokenVendorAcme 4050 987654321 4051 2009-09-01T00:00:00Z 4052 2014-09-01T00:00:00Z 4053 4054 4055 4056 4057 urn:ietf:params:xml:ns:keyprov:pskc:hotp 4058 4059 4060 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES 4061 4062 4063 4064 4065 http://www.w3.org/2001/04/xmlenc#aes128-cbc 4066 4067 4068 4069 4070 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 4072 4073 4074 4075 4076 4077 urn:ietf:params:xml:schema:keyprov:dskpp:wrap 4078 4079 4080 4081 Pre-shared-key-1 4082 4083 4084 4085 4086 4087 4088 urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 4089 4090 4091 4092 AC00000A 4093 4094 4095 ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI= 4096 4097 1 4098 4101 3eRz51ILqiG+dJW2iLcjuA== 4102 4103 4104 4105 4107 In this example, the server responds to the previous request by 4108 returning a key package in which the provisioning key was encrypted 4109 using the Key Wrap key protection method. 4111 4112 4124 4125 4126 4127 Pre-shared-key-1 4128 4129 4132 4133 4136 4137 4138 2GTTnLwM3I4e5IO5FkufoMUBJBuAf25hARFv0Z7MFk9Ecdb04PWY/qaeCbrgz7Es 4139 4140 4141 4142 4143 4144 4145 4146 TokenVendorAcme 4147 4148 4149 987654321 4150 4151 4152 2009-09-01T00:00:00Z 4153 4154 4155 2014-09-01T00:00:00Z 4156 4157 4158 4159 CM_ID_001 4160 4161 4165 Example-Issuer 4166 4167 4170 4171 4172 4173 4174 4177 4178 4179 oTvo+S22nsmS2Z/RtcoF8AabC6vr 4180 09sh0QIU+E224S96sZjpV+6nFYgn 4181 6525OoepbPnL/fGuuey64WCYXoqh 4182 Tg== 4183 4184 4185 4186 4187 o+e9xgMVUbYuZH9UHe0W9dIo88A= 4188 4189 4190 4191 0 4192 4193 4194 4195 OTP 4196 4197 4198 4199 4200 4201 4204 l53BmSO6qUzoIgbQegimsKk2es+WRpEl0YFqaOp5PGE= 4205 4206 4208 B.3.3. Example Using the Passphrase-Based Key Wrap Method 4210 The client sends a request similar to that in Appendix B.3.1 with 4211 authentication data based on an authentication code, and the server 4212 responds using the Passphrase-Based Key Wrap method to encrypt the 4213 provisioning key (note that the encryption is derived from the 4214 password component of the authentication code). The authentication 4215 data is set in clear text when it is sent over a secure transport 4216 channel such as TLS [RFC5246]. 4218 4219 4225 4226 4227 TokenVendorAcme 4228 987654321 4229 2009-09-01T00:00:00Z 4230 2014-09-01T00:00:00Z 4231 4232 4233 4234 4235 urn:ietf:params:xml:ns:keyprov:pskc:hotp 4236 4237 4238 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES 4239 4240 4241 4242 4243 http://www.w3.org/2001/04/xmlenc#rsa_1_5 4244 4245 4246 4247 4248 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 4249 4250 4251 4252 4253 4254 urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap 4255 4256 4257 4258 Passphrase-1 4259 4260 4261 4262 4263 4264 4265 urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container 4267 4268 4269 4270 AC00000A 4271 4272 4273 ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI= 4274 4275 1 4276 4279 K4YvLMN6Q1DZvtShoCxQag== 4280 4281 4282 4283 4285 In this example, the server responds to the previous request by 4286 returning a key package in which the provisioning key was encrypted 4287 using the Passphrase-Based Key Wrap key protection method. 4289 4290 4301 4302 4303 4304 4305 4309 4310 4311 Ej7/PEpyEpw= 4312 4313 1000 4314 16 4316 4317 4318 4319 4320 4321 4322 Passphrase1 4323 4324 4325 4326 4329 4330 4333 4334 4335 2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx 4336 4337 4338 4339 4340 4341 4342 4343 TokenVendorAcme 4344 4345 4346 987654321 4347 4348 4349 2009-09-01T00:00:00Z 4350 4351 4352 2014-09-01T00:00:00Z 4353 4354 4355 4356 CM_ID_001 4357 4358 4362 Example-Issuer 4363 4364 4366 4367 4368 4369 4370 4374 4375 4376 oTvo+S22nsmS2Z/RtcoF8HX385uMWgJ 4377 myIFMESBmcvtHQXp/6T1TgCS9CsgKtm 4378 cOrF8VoK254tZKnrAjiD5cdw== 4379 4380 4381 4382 4383 pbgEbVYxoYs0x41wdeC7eDRbUEk= 4384 4385 4386 4387 0 4388 4389 4390 4391 OTP 4392 4393 4394 4395 4396 4397 4399 Jc4VsNODYXgfbDmTn9qQZgcL3cKoa//j/NRT7sTpKOM= 4400 4401 4403 Appendix C. Integration with PKCS #11 4405 A DSKPP client that needs to communicate with a connected 4406 cryptographic module to perform a DSKPP exchange MAY use PKCS #11 4407 [PKCS-11] as a programming interface as described herein. This 4408 appendix forms an informative part of the document. 4410 C.1. The 4-pass Variant 4412 When performing 4-pass DSKPP with a cryptographic module using the 4413 PKCS #11 programming interface, the procedure described in 4414 [CT-KIP-P11], Appendix B, is RECOMMENDED. 4416 C.2. The 2-pass Variant 4418 A suggested procedure to perform 2-pass DSKPP with a cryptographic 4419 module through the PKCS #11 interface using the mechanisms defined in 4420 [CT-KIP-P11] is as follows: 4422 a. On the client side, 4423 1. The client selects a suitable slot and token (e.g., through 4424 use of the or the element 4425 of the DSKPP trigger message). 4426 2. A nonce R is generated, e.g. by calling C_SeedRandom and 4427 C_GenerateRandom. 4428 3. The client sends its first message to the server, including 4429 the nonce R. 4430 b. On the server side, 4431 1. A generic key K_PROV = K_TOKEN | K_MAC (where '|' denotes 4432 concatenation) is generated, e.g. by calling C_GenerateKey 4433 (using key type CKK_GENERIC_SECRET). The template for K_PROV 4434 MUST allow it to be exported (but only in wrapped form, i.e. 4435 CKA_SENSITIVE MUST be set to CK_TRUE and CKA_EXTRACTABLE MUST 4436 also be set to CK_TRUE), and also to be used for further key 4437 derivation. From K, a token key K_TOKEN of suitable type is 4438 derived by calling C_DeriveKey using the PKCS #11 mechanism 4439 CKM_EXTRACT_KEY_FROM_KEY and setting the CK_EXTRACT_PARAMS to 4440 the first bit of the generic secret key (i.e. set to 0). 4441 Likewise, a MAC key K_MAC is derived from K_PROV by calling 4442 C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY mechanism, 4443 this time setting CK_EXTRACT_PARAMS to the length of K_PROV 4444 (in bits) divided by two. 4445 2. The server wraps K_PROV with either the public key of the 4446 DSKPP client or device, the pre-shared secret key, or the 4447 derived shared secret key by using C_WrapKey. If use of the 4448 DSKPP key wrap algorithm has been negotiated then the 4449 CKM_KIP_WRAP mechanism MUST be used to wrap K. When calling 4450 C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure 4451 MUST be set to NULL_PTR. The pSeed parameter in the 4452 CK_KIP_PARAMS structure MUST point to the nonce R provided by 4453 the DSKPP client, and the ulSeedLen parameter MUST indicate 4454 the length of R. The hWrappingKey parameter in the call to 4455 C_WrapKey MUST be set to refer to the key wrapping key. 4457 3. Next, the server needs to calculate a MAC using K_MAC. If 4458 use of the DSKPP MAC algorithm has been negotiated, then the 4459 MAC is calculated by calling C_SignInit with the CKM_KIP_MAC 4460 mechanism followed by a call to C_Sign. In the call to 4461 C_SignInit, K_MAC MUST be the signature key, the hKey 4462 parameter in the CK_KIP_PARAMS structure MUST be set to 4463 NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure 4464 MUST be set to NULL_PTR, and the ulSeedLen parameter MUST be 4465 set to zero. In the call to C_Sign, the pData parameter MUST 4466 be set to the concatenation of the string ServerID and the 4467 nonce R, and the ulDataLen parameter MUST be set to the 4468 length of the concatenated string. The desired length of the 4469 MAC MUST be specified through the pulSignatureLen parameter 4470 and MUST be set to the length of R. 4471 4. If the server also needs to authenticate its message (due to 4472 an existing K_TOKEN being replaced), the server MUST 4473 calculate a second MAC. Again, if use of the DSKPP MAC 4474 algorithm has been negotiated, then the MAC is calculated by 4475 calling C_SignInit with the CKM_KIP_MAC mechanism followed by 4476 a call to C_Sign. In this call to C_SignInit, the K_MAC' 4477 existing before this DSKPP protocol run MUST be the signature 4478 key (the implementation may specify K_MAC' to be the value of 4479 the K_TOKEN that is being replaced, or a version of K_MAC 4480 from the previous protocol run), the hKey parameter in the 4481 CK_KIP_PARAMS structure MUST be set to NULL, the pSeed 4482 parameter of the CT_KIP_PARAMS structure MUST be set to 4483 NULL_PTR, and the ulSeedLen parameter MUST be set to zero. 4484 In the call to C_Sign, the pData parameter MUST be set to the 4485 concatenation of the string ServerID and the nonce R, and the 4486 ulDataLen parameter MUST be set to the length of concatenated 4487 string. The desired length of the MAC MUST be specified 4488 through the pulSignatureLen parameter and MUST be set to the 4489 length of R. 4490 5. The server sends its message to the client, including the 4491 wrapped key K_TOKEN, the MAC and possibly also the 4492 authenticating MAC. 4493 c. On the client side, 4494 1. The client calls C_UnwrapKey to receive a handle to K. After 4495 this, the client calls C_DeriveKey twice: Once to derive 4496 K_TOKEN and once to derive K_MAC. The client MUST use the 4497 same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same 4498 mechanism parameters as used by the server above. When 4499 calling C_UnwrapKey and C_DeriveKey, the pTemplate parameter 4500 MUST be used to set additional key attributes in accordance 4501 with local policy and as negotiated and expressed in the 4502 protocol. In particular, the value of the element in 4503 the server's response message MAY be used as CKA_ID for 4504 K_TOKEN. The key K_PROV MUST be destroyed after deriving 4505 K_TOKEN and K_MAC. 4506 2. The MAC is verified in a reciprocal fashion as it was 4507 generated by the server. If use of the CKM_KIP_MAC mechanism 4508 has been negotiated, then in the call to C_VerifyInit, the 4509 hKey parameter in the CK_KIP_PARAMS structure MUST be set to 4510 NULL_PTR, the pSeed parameter MUST be set to NULL_PTR, and 4511 ulSeedLen MUST be set to 0. The hKey parameter of 4512 C_VerifyInit MUST refer to K_MAC. In the call to C_Verify, 4513 pData MUST be set to the concatenation of the string ServerID 4514 and the nonce R, and the ulDataLen parameter MUST be set to 4515 the length of the concatenated string, pSignature to the MAC 4516 value received from the server, and ulSignatureLen to the 4517 length of the MAC. If the MAC does not verify the protocol 4518 session ends with a failure. The token MUST be constructed 4519 to not "commit" to the new K_TOKEN or the new K_MAC unless 4520 the MAC verifies. 4521 3. If an authenticating MAC was received (REQUIRED if the new 4522 K_TOKEN will replace an existing key on the token), then it 4523 is verified in a similar vein but using the K_MAC' associated 4524 with this server and existing before the protocol run (the 4525 implementation may specify K_MAC' to be the value of the 4526 K_TOKEN that is being replaced, or a version of K_MAC from 4527 the previous protocol run). Again, if the MAC does not 4528 verify the protocol session ends with a failure, and the 4529 token MUST be constructed no to "commit" to the new K_TOKEN 4530 or the new K_MAC unless the MAC verifies. 4532 Appendix D. Example of DSKPP-PRF Realizations 4534 D.1. Introduction 4536 This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES] 4537 and HMAC [RFC2104]. This appendix forms a normative part of the 4538 document. 4540 D.2. DSKPP-PRF-AES 4542 D.2.1. Identification 4544 For cryptographic modules supporting this realization of DSKPP-PRF, 4545 the following URN MUST be used to identify this algorithm in DSKPP: 4547 urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128 4549 When this URN is used to identify the encryption algorithm, the 4550 method for encryption of R_C values described in Section 4.2.4 MUST 4551 be used. 4553 D.2.2. Definition 4555 DSKPP-PRF-AES (k, s, dsLen) 4557 Input: 4559 k Encryption key to use 4560 s Octet string consisting of randomizing material. The 4561 length of the string s is sLen. 4562 dsLen Desired length of the output 4564 Output: 4566 DS A pseudorandom string, dsLen-octets long 4568 Steps: 4570 1. Let bLen be the output block size of AES in octets: 4572 bLen = (AES output block length in octets) 4573 (normally, bLen = 16) 4575 2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and 4576 stop 4578 3. Let n be the number of bLen-octet blocks in the output data, 4579 rounding up, and let j be the number of octets in the last block: 4581 n = CEILING( dsLen / bLen) 4582 j = dsLen - (n - 1) * bLen 4584 4. For each block of the pseudorandom string DS, apply the function 4585 F defined below to the key k, the string s and the block index to 4586 compute the block: 4588 B1 = F (k, s, 1) , 4589 B2 = F (k, s, 2) , 4590 ... 4591 Bn = F (k, s, n) 4593 The function F is defined in terms of the CMAC construction from 4594 [NIST-SP800-38B], using AES as the block cipher: 4596 F (k, s, i) = CMAC-AES (k, INT (i) || s) 4598 where INT (i) is a four-octet encoding of the integer i, most 4599 significant octet first, and the output length of CMAC is set to 4600 bLen. 4602 Concatenate the blocks and extract the first dsLen octets to product 4603 the desired data string DS: 4605 DS = B1 || B2 || ... || Bn<0..j-1> 4607 Output the derived data DS. 4609 D.2.3. Example 4611 If we assume that dsLen = 16, then: 4613 n = 16 / 16 = 1 4615 j = 16 - (1 - 1) * 16 = 16 4617 DS = B1 = F (k, s, 1) = CMAC-AES (k, INT (1) || s) 4619 D.3. DSKPP-PRF-SHA256 4621 D.3.1. Identification 4623 For cryptographic modules supporting this realization of DSKPP-PRF, 4624 the following URN MUST be used to identify this algorithm in DSKPP: 4626 urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256 4628 When this URN is used to identify the encryption algorithm to use, 4629 the method for encryption of R_C values described in Section 4.2.4 4630 MUST be used. 4632 D.3.2. Definition 4634 DSKPP-PRF-SHA256 (k, s, dsLen) 4636 Input: 4638 k Encryption key to use 4639 s Octet string consisting of randomizing material. The 4640 length of the string s is sLen. 4641 dsLen Desired length of the output 4643 Output: 4645 DS A pseudorandom string, dsLen-octets long 4647 Steps: 4649 1. Let bLen be the output size of SHA-256 in octets of [FIPS180-SHA] 4650 (no truncation is done on the HMAC output): 4652 bLen = 32 4653 (normally, bLen = 16) 4655 2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and 4656 stop 4658 3. Let n be the number of bLen-octet blocks in the output data, 4659 rounding up, and let j be the number of octets in the last block: 4661 n = CEILING( dsLen / bLen) 4662 j = dsLen - (n - 1) * bLen 4664 4. For each block of the pseudorandom string DS, apply the function 4665 F defined below to the key k, the string s and the block index to 4666 compute the block: 4668 B1 = F (k, s, 1), 4669 B2 = F (k, s, 2), 4670 ... 4671 Bn = F (k, s, n) 4673 The function F is defined in terms of the HMAC construction from 4674 [RFC2104], using SHA-256 as the digest algorithm: 4676 F (k, s, i) = HMAC-SHA256 (k, INT (i) || s) 4678 where INT (i) is a four-octet encoding of the integer i, most 4679 significant octet first, and the output length of HMAC is set to 4680 bLen. 4682 Concatenate the blocks and extract the first dsLen octets to product 4683 the desired data string DS: 4685 DS = B1 || B2 || ... || Bn<0..j-1> 4687 Output the derived data DS. 4689 D.3.3. Example 4691 If we assume that sLen = 256 (two 128-octet long values) and dsLen = 4692 16, then: 4694 n = CEILING( 16 / 32 ) = 1 4696 j = 16 - (1 - 1) * 32 = 16 4697 B1 = F (k, s, 1) = HMAC-SHA256 (k, INT (1) || s) 4699 DS = B1<0 ... 15> 4701 That is, the result will be the first 16 octets of the HMAC output. 4703 Authors' Addresses 4705 Andrea Doherty 4706 RSA, The Security Division of EMC 4707 174 Middlesex Turnpike 4708 Bedford, MA 01730 4709 USA 4711 Email: andrea.doherty@rsa.com 4713 Mingliang Pei 4714 VeriSign, Inc. 4715 487 E. Middlefield Road 4716 Mountain View, CA 94043 4717 USA 4719 Email: mpei@verisign.com 4721 Salah Machani 4722 Diversinet Corp. 4723 2225 Sheppard Avenue East, Suite 1801 4724 Toronto, Ontario M2J 5C2 4725 Canada 4727 Email: smachani@diversinet.com 4729 Magnus Nystrom 4730 Microsoft Corp. 4731 One Microsoft Way 4732 Redmond, WA 98052 4733 USA 4735 Email: mnystrom@microsoft.com