idnits 2.17.1 draft-nystrom-ct-kip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2434. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1, 2006) is 6440 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 1731, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '7') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nystroem 3 Internet-Draft RSA Security 4 Expires: March 5, 2007 September 1, 2006 6 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 7 Revision 1 8 draft-nystrom-ct-kip-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This document may not be modified, and derivative works of it may not 17 be created, except to publish it as an RFC and to translate it into 18 languages other than English. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 5, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document constitutes Revision 1 of CT-KIP Version 1.0 from RSA 45 Laboratories' One-Time Password Specifications (OTPS) series. The 46 body of this document, except for the intellectual property 47 considerations section and the IANA considerations section, is taken 48 from the CT-KIP Version 1.0 document, but comments received during 49 the IETF review are reflected; hence the status of a revised version. 50 As no "bits-on-the-wire" have changed, the protocol specified herein 51 is compatible with CT-KIP Version 1.0. 53 CT-KIP is a client-server protocol for initialization (and 54 configuration) of cryptographic tokens. The protocol requires 55 neither private-key capabilities in the cryptographic tokens, nor an 56 established public-key infrastructure. Provisioned (or generated) 57 secrets will only be available to the server and the cryptographic 58 token itself. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1.3. Document organization . . . . . . . . . . . . . . . . . . 5 66 2. Acronyms and notation . . . . . . . . . . . . . . . . . . . . 7 67 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. CT-KIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.2. Entities . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.3. Principles of operation . . . . . . . . . . . . . . . . . 9 73 3.4. The CT-KIP one-way pseudorandom function, CT-KIP-PRF . . . 12 74 3.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 12 75 3.4.2. Declaration . . . . . . . . . . . . . . . . . . . . . 13 76 3.5. Generation of cryptographic keys for tokens . . . . . . . 13 77 3.6. Encryption of pseudorandom nonces sent from the CT-KIP 78 client . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 3.7. CT-KIP schema basics . . . . . . . . . . . . . . . . . . . 14 80 3.7.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 81 3.7.2. General XML Schema Requirements . . . . . . . . . . . 15 82 3.7.3. The AbstractRequestType type . . . . . . . . . . . . . 15 83 3.7.4. The AbstractResponseType type . . . . . . . . . . . . 16 84 3.7.5. The StatusCode type . . . . . . . . . . . . . . . . . 16 85 3.7.6. The IdentifierType type . . . . . . . . . . . . . . . 18 86 3.7.7. The NonceType type . . . . . . . . . . . . . . . . . . 18 87 3.7.8. The ExtensionsType and the AbstractExtensionType 88 types . . . . . . . . . . . . . . . . . . . . . . . . 18 89 3.8. CT-KIP messages . . . . . . . . . . . . . . . . . . . . . 19 90 3.8.1. Introduction . . . . . . . . . . . . . . . . . . . . . 19 91 3.8.2. CT-KIP initialization . . . . . . . . . . . . . . . . 19 92 3.8.3. The CT-KIP client's initial PDU . . . . . . . . . . . 20 93 3.8.4. The CT-KIP server's initial PDU . . . . . . . . . . . 22 94 3.8.5. The CT-KIP client's second PDU . . . . . . . . . . . . 25 95 3.8.6. The CT-KIP server's final PDU . . . . . . . . . . . . 26 97 3.9. Protocol extensions . . . . . . . . . . . . . . . . . . . 30 98 3.9.1. The ClientInfoType type . . . . . . . . . . . . . . . 30 99 3.9.2. The ServerInfoType type . . . . . . . . . . . . . . . 30 100 3.9.3. The OTPKeyConfigurationDataType type . . . . . . . . . 31 101 4. Protocol bindings . . . . . . . . . . . . . . . . . . . . . . 32 102 4.1. General requirement . . . . . . . . . . . . . . . . . . . 32 103 4.2. HTTP/1.1 binding for CT-KIP . . . . . . . . . . . . . . . 32 104 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 32 105 4.2.2. Identification of CT-KIP messages . . . . . . . . . . 32 106 4.2.3. HTTP headers . . . . . . . . . . . . . . . . . . . . . 32 107 4.2.4. HTTP operations . . . . . . . . . . . . . . . . . . . 33 108 4.2.5. HTTP status codes . . . . . . . . . . . . . . . . . . 33 109 4.2.6. HTTP authentication . . . . . . . . . . . . . . . . . 33 110 4.2.7. Initialization of CT-KIP . . . . . . . . . . . . . . . 33 111 4.2.8. Example messages . . . . . . . . . . . . . . . . . . . 33 112 5. Security considerations . . . . . . . . . . . . . . . . . . . 35 113 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 35 114 5.2. Active attacks . . . . . . . . . . . . . . . . . . . . . . 35 115 5.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 35 116 5.2.2. Message modifications . . . . . . . . . . . . . . . . 35 117 5.2.3. Message deletion . . . . . . . . . . . . . . . . . . . 37 118 5.2.4. Message insertion . . . . . . . . . . . . . . . . . . 37 119 5.2.5. Message replay . . . . . . . . . . . . . . . . . . . . 37 120 5.2.6. Message reordering . . . . . . . . . . . . . . . . . . 37 121 5.2.7. Man in the middle . . . . . . . . . . . . . . . . . . 37 122 5.3. Passive attacks . . . . . . . . . . . . . . . . . . . . . 38 123 5.4. Cryptographic attacks . . . . . . . . . . . . . . . . . . 38 124 5.5. Attacks on the interaction between CT-KIP and user 125 authentication . . . . . . . . . . . . . . . . . . . . . . 38 126 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 40 127 7. Intellectual property considerations . . . . . . . . . . . . . 41 128 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 129 8.1. Normative references . . . . . . . . . . . . . . . . . . . 42 130 8.2. Informative references . . . . . . . . . . . . . . . . . . 42 131 Appendix A. CT-KIP schema . . . . . . . . . . . . . . . . . . . . 44 132 Appendix B. Examples of CT-KIP messages . . . . . . . . . . . . . 52 133 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 52 134 B.2. Example of a CT-KIP initialization (trigger) message . . . 52 135 B.3. Example of a message . . . . . . . . . . . . 52 136 B.4. Example of a message . . . . . . . . . . . . 53 137 B.5. Example of a message . . . . . . . . . . . . 53 138 B.6. Example of a message . . . . . . . . . . 54 139 Appendix C. Integration with PKCS #11 . . . . . . . . . . . . . . 55 140 Appendix D. Example CT-KIP-PRF realizations . . . . . . . . . . . 56 141 D.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 56 142 D.2. CT-KIP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 56 143 D.2.1. Identification . . . . . . . . . . . . . . . . . . . . 56 144 D.2.2. Definition . . . . . . . . . . . . . . . . . . . . . . 56 145 D.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 57 146 D.3. CT-KIP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . 58 147 D.3.1. Identification . . . . . . . . . . . . . . . . . . . . 58 148 D.3.2. Definition . . . . . . . . . . . . . . . . . . . . . . 58 149 D.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 59 150 Appendix E. About OTPS . . . . . . . . . . . . . . . . . . . . . 60 151 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 61 152 Intellectual Property and Copyright Statements . . . . . . . . . . 62 154 1. Introduction 156 1.1. Scope 158 This document describes a client-server protocol for initialization 159 (and configuration) of cryptographic tokens. The protocol requires 160 neither private-key capabilities in the cryptographic tokens, nor an 161 established public-key infrastructure. 163 The objectives of this protocol are: 165 o To provide a secure method of initializing cryptographic tokens 166 with secret keys without exposing generated, secret, material to 167 any other entities than the server and the cryptographic token 168 itself, 170 o To avoid, as much as possible, any impact on existing 171 cryptographic token manufacturing processes, 173 o To provide a solution that is easy to administer and scales well. 175 The mechanism is intended for general use within computer and 176 communications systems employing connected cryptographic tokens (or 177 software emulations thereof). 179 1.2. Background 181 A cryptographic token may be a handheld hardware device, a hardware 182 device connected to a personal computer through an electronic 183 interface such as USB, or a software module resident on a personal 184 computer, which offers cryptographic functionality that may be used 185 e.g., to authenticate a user towards some service. Increasingly, 186 these tokens work in a connected fashion, enabling their programmatic 187 initialization as well as programmatic retrieval of their output 188 values. This document intends to meet the need for an open and 189 interoperable mechanism to programmatically initialize and configure 190 connected cryptographic tokens. A companion document entitled "A 191 PKCS #11 Mechanism for the Cryptographic Token Key Initialization 192 Protocol" [2] describes an application-programming interface suitable 193 for use with this mechanism. 195 1.3. Document organization 197 The organization of this document is as follows: 199 o Section 1 is an introduction. 201 o Section 2 defines some notation used in this document. 203 o Section 3 defines the protocol mechanism in detail. 205 o Section 4 defines a binding of the protocol to transports. 207 o Section 5 provides security considerations. 209 o Appendix A defines the XML schema for the protocol mechanism, 210 Appendix B gives example messages, and Appendix C discusses 211 integration with PKCS #11 [3]. 213 o Appendix D provides example realizations of an abstract 214 pseudorandom function defined in Section 3. 216 o Appendix E provide general information about the One-Time Password 217 Specifications. 219 2. Acronyms and notation 221 2.1. Acronyms 223 MAC Message Authentication Code 225 PDU Protocol Data Unit 227 PRF Pseudo-Random Function 229 CT-KIP Cryptographic Token Key Initialization Protocol (the 230 protocol mechanism described herein) 232 2.2. Notation 234 || String concatenation 236 [x] Optional element x 238 A ^ B Exclusive-or operation on strings A and B (A and B of equal 239 length) 241 K_AUTH Secret key used for authentication purposes 243 K_TOKEN Secret key used for token computations, generated in CT-KIP 245 K_SERVER Public key of CT-KIP server 247 K_SHARED Secret key shared between the cryptographic token and the 248 CT-KIP server 250 K Key used to encrypt R_C (either K_SERVER or K_SHARED) 252 R Pseudorandom value chosen by the cryptographic token and 253 used for MAC computations 255 R_C Pseudorandom value chosen by the cryptographic token 257 R_S Pseudorandom value chosen by the CT-KIP server 259 The following typographical convention is used in the body of the 260 text: . 262 3. CT-KIP 264 3.1. Overview 266 The CT-KIP is a client-server protocol for the secure initialization 267 of cryptographic tokens. The protocol is meant to provide high 268 assurance for both the server and the client (cryptographic token) 269 that generated keys have been correctly and randomly generated and 270 not exposed to other entities. The protocol does not require the 271 existence of a public-key infrastructure. 273 +---------------+ +---------------+ 274 | | | | 275 | CT-KIP client | | CT-KIP server | 276 | | | | 277 +---------------+ +---------------+ 278 | | 279 | [ <---- CT-KIP trigger ---- ] | 280 | | 281 | ------- Client Hello -------> | 282 | | 283 | <------ Server Hello -------- | 284 | | 285 | ------- Client Nonce -------> | 286 | | 287 | <----- Server Finished ------ | 289 Figure 1: The 4-pass CT-KIP protocol (with optional preceding 290 trigger) 292 3.2. Entities 294 In principle, the protocol involves a CT-KIP client and a CT-KIP 295 server. 297 It is assumed that a desktop/laptop or a wireless device (e.g. a 298 mobile phone or a PDA) will host an application communicating with 299 the CT-KIP server as well as the cryptographic token, and 300 collectively, the cryptographic token and the communicating 301 application form the CT-KIP client. When there is a need to point 302 out if an action is to be performed by the communicating application 303 or by the token the text will make this explicit. 305 The manner in which the communicating application will transfer CT- 306 KIP protocol elements to and from the cryptographic token is 307 transparent to the CT-KIP server. One method for this transfer is 308 described in [2]. 310 3.3. Principles of operation 312 To initiate a CT-KIP session, a user may use a browser to connect to 313 a web server running on some host. The user may then identify (and 314 authenticate) herself (through some means that essentially are out of 315 scope for this document) and possibly indicate how the CT-KIP client 316 shall contact the CT-KIP server. There are also other alternatives 317 for CT-KIP session initiation, such as the CT-KIP client being pre- 318 configured to contact a certain CT-KIP server, or the user being 319 informed out-of-band about the location of the CT-KIP server. In any 320 event, once the location of the CT-KIP server is known, the CT-KIP 321 client and the CT-KIP server engage in a 4-pass protocol in which: 323 a. The CT-KIP client provides information to the CT-KIP server about 324 the cryptographic token's identity, supported CT-KIP versions, 325 cryptographic algorithms supported by the token and for which keys 326 may be generated using this protocol, and encryption and MAC 327 algorithms supported by the cryptographic token for the purposes 328 of this protocol. 330 b. Based on this information, the CT-KIP server provides a random 331 nonce, R_S, to the CT-KIP client, along with information about the 332 type of key to generate, the encryption algorithm chosen to 333 protect sensitive data sent in the protocol, and, either 334 information about a shared secret key to use for encrypting the 335 cryptographic token's random nonce (see below), or its own public 336 key. The length of the nonce R_S may depend on the selected key 337 type. 339 c. The cryptographic token generates a random nonce R_C and encrypts 340 it using the selected encryption algorithm and with a key K that 341 is either the CT-KIP server's public key K_SERVER, or a shared 342 secret key K_SHARED as indicated by the CT-KIP server. The length 343 of the nonce R_C may depend on the selected key type. The CT-KIP 344 client then sends the encrypted random nonce to the CT-KIP server. 345 The token also calculates a cryptographic key K_TOKEN of the 346 selected type from the combination of the two random nonces R_S 347 and R_C, the encryption key K, and possibly some other data, using 348 the CT-KIP-PRF function defined herein. 350 d. The CT-KIP server decrypts R_C, calculates K_TOKEN from the 351 combination of the two random nonces R_S and R_C and the 352 encryption key K, and possibly some other data, using the CT-KIP- 353 PRF function defined herein. The server then associates K_TOKEN 354 with the cryptographic token in a server-side data store. The 355 intent is that the data store later on will be used by some 356 service that needs to verify or decrypt data produced by the 357 cryptographic token and the key. 359 e. Once the association has been made, the CT-KIP server sends a 360 confirmation message to the CT-KIP client. The confirmation 361 message includes an identifier for the generated key and may also 362 contain additional configuration information, e.g. the identity of 363 the CT-KIP server. 365 f. Upon receipt of the CT-KIP server's confirmation message, the 366 cryptographic token associates the provided key identifier with 367 the generated key K_TOKEN, and stores the provided configuration 368 data, if any. 370 Note: Conceptually, although R_C is one pseudorandom string, it may 371 be viewed as consisting of two components, R_C1 and R_C2 where R_C1 372 is generated during the protocol run and R_C2 can be generated at the 373 cryptographic token manufacturing time and stored in the 374 cryptographic token. This latter string R_C2 should in that case be 375 unique for each cryptographic token for a given manufacturer. 377 +----------------------+ +-------+ +----------------------+ 378 | +------------+ | | | | | 379 | | Server key | | | | | | 380 | +<-| Public |------>------------->-------------+---------+ | 381 | | | Private | | | | | | | | 382 | | +------------+ | | | | | | | 383 | | | | | | | | | | 384 | V V | | | | V V | 385 | | +---------+ | | | | +---------+ | | 386 | | | Decrypt |<-------<-------------<-----------| Encrypt | | | 387 | | +---------+ | | | | +---------+ | | 388 | | | +--------+ | | | | ^ | | 389 | | | | Server | | | | | | | | 390 | | | | Random |--->------------->------+ +----------+ | | 391 | | | +--------+ | | | | | | Client | | | 392 | | | | | | | | | | Random | | | 393 | | | | | | | | | +----------+ | | 394 | | | | | | | | | | | | 395 | | V V | | | | V V | | 396 | | +------------+ | | | | +------------+ | | 397 | +-->| CT-KIP PRF | | | | | | CT-KIP PRF |<----+ | 398 | +------------+ | | | | +------------+ | 399 | | | | | | | | 400 | V | | | | V | 401 | +-------+ | | | | +-------+ | 402 | | Key | | | | | | Key | | 403 | +-------+ | | | | +-------+ | 404 | +-------+ | | | | +-------+ | 405 | |Key Id |-------->------------->------|Key Id | | 406 | +-------+ | | | | +-------+ | 407 +----------------------+ +-------+ +----------------------+ 408 CT-KIP Server CT-KIP Client CT-KIP Client (Token) 409 (PC Host) 411 Figure 2: Principal data flow for CT-KIP key generation - using 412 public server key 414 The inclusion of the two random nonces R_S and R_C in the key 415 generation provides assurance to both sides (the token and the CT-KIP 416 server) that they have contributed to the key's randomness and that 417 the key is unique. The inclusion of the encryption key K ensures 418 that no man-in-the-middle may be present, or else the cryptographic 419 token will end up with a key different from the one stored by the 420 legitimate CT-KIP server. 422 Note: A man-in-the middle (in the form of corrupt client software or 423 a mistakenly contacted server) may present his own public key to the 424 token. This will enable the attacker to learn the client's version 425 of K_TOKEN. However, the attacker is not able to persuade the 426 legitimate server to derive the same value for K_TOKEN, since K_TOKEN 427 is a function of the public key involved, and the attacker's public 428 key must be different than the correct server's (or else the attacker 429 would not be able to decrypt the information received from the 430 client). Therefore, once the attacker is no longer "in the middle," 431 the client and server will detect that they are "out of synch" when 432 they try to use their keys. In the case of encrypting R_C with 433 K_SERVER, it is therefore important to verify that K_SERVER really is 434 the legitimate server's key. One way to do this is to independently 435 validate a newly generated K_TOKEN against some validation service at 436 the server (e.g. by using a connection independent from the one used 437 for the key generation). 439 The CT-KIP server may couple an initial user authentication to the 440 CT-KIP execution in several ways, to ensure that a generated K_TOKEN 441 ends up associated with the correct token and user. One way is to 442 provide a one-time value to the user or CT-KIP client after 443 successful user authentication and require this value to be used when 444 contacting the CT-KIP service (in effect coupling the user 445 authentication with the subsequent CT-KIP protocol run). This value 446 could, for example, be placed in a element of the CT- 447 KIP initialization trigger (if triggers are used, see further 448 Section 4.2.7). Another way is for the user to provide a token 449 identifier which will later be used in the CT-KIP protocol to the 450 server during the authentication phase. The server may then include 451 this token identifier in the CT-KIP initialization trigger. It is 452 also legitimate for a CT-KIP client to initiate a CT-KIP protocol run 453 without having received an initialization message from a server, but 454 in this case any provided token identifier shall not be accepted by 455 the server unless the server has access to a unique token key for the 456 identified token and that key will be used in the protocol. Whatever 457 the method, the CT-KIP server must ensure that a generated key is 458 associated with the correct token, and if applicable, the correct 459 user. For a further discussion of this, and threats related to man- 460 in-the-middle attacks in this context, see Section 5.5. 462 3.4. The CT-KIP one-way pseudorandom function, CT-KIP-PRF 464 3.4.1. Introduction 466 The general requirements on CT-KIP-PRF are the same as on keyed hash 467 functions: It shall take an arbitrary length input, be one-way and 468 collision-free (for a definition of these terms, see e.g. [4]). 469 Further, the CT-KIP-PRF function shall be capable of generating a 470 variable-length output, and its output shall be unpredictable even if 471 other outputs for the same key are known. 473 It is assumed that any realization of CT-KIP-PRF takes three input 474 parameters: A secret key k, some combination of variable data, and 475 the desired length of the output. Examples of the variable data 476 include, but are not limited to, a current token counter value, the 477 current token time, and a challenge. The combination of variable 478 data can, without loss of generalization, be considered as a salt 479 value (see PKCS #5 Version 2.0 [5]), Section 4, and this 480 characterization of CT-KIP-PRF should fit all actual PRF algorithms 481 implemented by tokens. From the point of view of this specification, 482 CT-KIP-PRF is a "black-box" function that given the inputs generates 483 a pseudorandom value. 485 Separate specifications may define the implementation of CT-KIP-PRF 486 for various types of cryptographic tokens. Appendix D contains two 487 example realizations of CT-KIP-PRF. 489 3.4.2. Declaration 491 CT-KIP-PRF (k, s, dsLen) 493 Input: 495 k secret key in octet string format 497 s octet string of varying length consisting of variable data 498 distinguishing the particular string being derived 500 dsLen desired length of the output 502 Output: 504 DS pseudorandom string, dsLen-octets long 506 For the purposes of this document, the secret key k shall be 16 507 octets long. 509 3.5. Generation of cryptographic keys for tokens 511 In CT-KIP, keys are generated using the CT-KIP-PRF function, a secret 512 random value R_C chosen by the CT-KIP client, a random value R_S 513 chosen by the CT-KIP server, and the key k used to encrypt R_C. The 514 input parameter s of CT-KIP-PRF is set to the concatenation of the 515 (ASCII) string "Key generation", k, and R_S, and the input parameter 516 dsLen is set to the desired length of the key, K_TOKEN (the length of 517 K_TOKEN is given by the key's type): 519 dsLen = (desired length of K_TOKEN) 520 K_TOKEN = CT-KIP-PRF (R_C, "Key generation" || k || R_S, dsLen) 522 When computing K_TOKEN above, the output of CT-KIP-PRF may be subject 523 to an algorithm-dependent transform before being adopted as a key of 524 the selected type. One example of this is the need for parity in DES 525 keys. 527 3.6. Encryption of pseudorandom nonces sent from the CT-KIP client 529 CT-KIP client random nonce(s) are either encrypted with the public 530 key provided by the CT-KIP server or by a shared secret key. For 531 example, in the case of a public RSA key, an RSA encryption scheme 532 from PKCS #1 [6] may be used. 534 In the case of a shared secret key, to avoid dependence on other 535 algorithms, the CT-KIP client may use the CT-KIP-PRF function 536 described herein with the shared secret key K_SHARED as input 537 parameter k (in this case, K_SHARED should be used solely for this 538 purpose), the concatenation of the (ASCII) string "Encryption" and 539 the server's nonce R_S as input parameter s, and dsLen set to the 540 length of R_C: 542 dsLen = len(R_C) 544 DS = CT-KIP-PRF(K_SHARED, "Encryption" || R_S, dsLen) 546 This will produce a pseudorandom string DS of length equal to R_C. 547 Encryption of R_C may then be achieved by XOR-ing DS with R_C: 549 Enc-R_C = DS ^ R_C 551 The CT-KIP server will then perform the reverse operation to extract 552 R_C from Enc-R_C. 554 Note: It may appear that an attacker, who learns a previous value of 555 R_C, may be able to replay the corresponding R_S and hence learn a 556 new R_C as well. This attack is however mitigated by the requirement 557 for a server to show knowledge of K_AUTH (see below) in order to 558 successfully complete a key re-generation. 560 3.7. CT-KIP schema basics 562 3.7.1. Introduction 564 Core parts of the XML schema for CT-KIP, found in Appendix A, are 565 explained in this section. Specific protocol message elements are 566 defined in Section 3.8. Examples can be found in Appendix B. 568 The XML format for CT-KIP messages have been designed to be 569 extensible. However, it is possible that the use of extensions will 570 harm interoperability and therefore any use of extensions should be 571 carefully considered. For examle, if a particular implementation 572 relies on the presence of a proprietary extension then it may not be 573 able to interoperate with independent implementations that have no 574 knowledge of this extension. 576 XML types defined in this sub-section are not CT-KIP messages; rather 577 they provide building blocks that are used by CT-KIP messages. 579 3.7.2. General XML Schema Requirements 581 Some CT-KIP elements rely on the parties being able to compare 582 received values with stored values. Unless otherwise noted, all 583 elements in this document that have the XML Schema "xs:string" type, 584 or a type derived from it, must be compared using an exact binary 585 comparison. In particular, CT-KIP implementations must not depend on 586 case-insensitive string comparisons, normalization or trimming of 587 white space, or conversion of locale-specific formats such as 588 numbers. 590 Implementations that compare values that are represented using 591 different character encodings must use a comparison method that 592 returns the same result as converting both values to the Unicode 593 character encoding, Normalization Form C [1], and then performing an 594 exact binary comparison. 596 No collation or sorting order for attributes or element values is 597 defined. CT-KIP implementations must therefore not depend on 598 specific sorting orders for values. 600 3.7.3. The AbstractRequestType type 602 All CT-KIP requests are defined as extensions to the abstract 603 AbstractRequestType type. The elements of the AbstractRequestType 604 therefore apply to all CT-KIP requests. All CT-KIP requests must 605 contain a Version attribute. For this version of this specification, 606 Version shall be set to "1.0". 608 609 611 613 3.7.4. The AbstractResponseType type 615 All CT-KIP responses are defined as extensions to the abstract 616 AbstractResponseType type. The elements of the AbstractResponseType 617 therefore apply to all CT-KIP responses. All CT-KIP responses 618 contain a Version attribute indicating the version that was used. A 619 Status attribute, which indicates whether the preceding request was 620 successful or not must also be present. Finally, all responses may 621 contain a SessionID attribute identifying the particular CT-KIP 622 session. The SessionID attribute needs only be present if more than 623 one roundtrip is required for a successful protocol run (this is the 624 case with the protocol version described herein). 626 627 628 629 630 632 3.7.5. The StatusCode type 634 The StatusCode type enumerates all possible return codes: 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 653 Upon transmission or receipt of a message for which the Status 654 attribute's value is not "Success" or "Continue", the default 655 behavior, unless explicitly stated otherwise below, is that both the 656 CT-KIP server and the CT-KIP client shall immediately terminate the 657 CT-KIP session. CT-KIP servers and CT-KIP clients must delete any 658 secret values generated as a result of failed runs of the CT-KIP 659 protocol. Session identifiers may be retained from successful or 660 failed protocol runs for replay detection purposes, but such retained 661 identifiers shall not be reused for subsequent runs of the protocol. 663 When possible, the CT-KIP client should present an appropriate error 664 message to the user. 666 These status codes are valid in all CT-KIP-Response messages unless 667 explicitly stated otherwise. 669 o "Continue" indicates that the CT-KIP server is ready for a 670 subsequent request from the CT-KIP client. It cannot be sent in 671 the server's final message. 673 o "Success" indicates successful completion of the CT-KIP session. 674 It can only be sent in the server's final message. 676 o "Abort" indicates that the CT-KIP server rejected the CT-KIP 677 client's request for unspecified reasons. 679 o "AccessDenied" indicates that the CT-KIP client is not authorized 680 to contact this CT-KIP server. 682 o "MalformedRequest" indicates that the CT-KIP server failed to 683 parse the CT-KIP client's request. 685 o "UnknownRequest" indicates that the CT-KIP client made a request 686 that is unknown to the CT-KIP server. 688 o "UnknownCriticalExtension" indicates that a critical CT-KIP 689 extension (see below) used by the CT-KIP client was not supported 690 or recognized by the CT-KIP server. 692 o "UnsupportedVersion" indicates that the CT-KIP client used a CT- 693 KIP protocol version not supported by the CT-KIP server. This 694 error is only valid in the CT-KIP server's first response message. 696 o "NoSupportedKeyTypes" indicates that the CT-KIP client only 697 suggested key types that are not supported by the CT-KIP server. 698 This error is only valid in the CT-KIP server's first response 699 message. Note that the error will only occur if the CT-KIP server 700 does not support any of the CT-KIP client's suggested key types. 702 o "NoSupportedEncryptionAlgorithms" indicates that the CT-KIP client 703 only suggested encryption algorithms that are not supported by the 704 CT-KIP server. This error is only valid in the CT-KIP server's 705 first response message. Note that the error will only occur if 706 the CT-KIP server does not support any of the CT-KIP client's 707 suggested encryption algorithms. 709 o "NoSupportedMACAlgorithms" indicates that the CT-KIP client only 710 suggested MAC algorithms that are not supported by the CT-KIP 711 server. This error is only valid in the CT-KIP server's first 712 response message. Note that the error will only occur if the CT- 713 KIP server does not support any of the CT-KIP client's suggested 714 MAC algorithms. 716 o "InitializationFailed" indicates that the CT-KIP server could not 717 generate a valid key given the provided data. When this status 718 code is received, the CT-KIP client should try to restart CT-KIP, 719 as it is possible that a new run will succeed. 721 3.7.6. The IdentifierType type 723 The IdentifierType type is used to identify various CT-KIP elements, 724 such as sessions, users, and services. Identifiers must not be 725 longer than 128 octets. 727 728 729 730 731 733 3.7.7. The NonceType type 735 The NonceType type is used to carry pseudorandom values in CT-KIP 736 messages. A nonce, as the name implies, must be used only once. For 737 each CT-KIP message that requires a nonce element to be sent, a fresh 738 nonce shall be generated each time. Nonce values must be at least 16 739 octets long. 741 742 743 744 745 747 3.7.8. The ExtensionsType and the AbstractExtensionType types 749 The ExtensionsType type is a list of type-value pairs that define 750 optional CT-KIP features supported by a CT-KIP client or server. 751 Extensions may be sent with any CT-KIP message. Please see the 752 description of individual CT-KIP messages in Section 3.8 of this 753 document for applicable extensions. Unless an extension is marked as 754 Critical, a receiving party need not be able to interpret it. A 755 receiving party is always free to disregard any (non-critical) 756 extensions. 758 759 760 761 762 764 765 766 768 3.8. CT-KIP messages 770 3.8.1. Introduction 772 In this section, CT-KIP messages, including their parameters, 773 encodings and semantics are defined. 775 3.8.2. CT-KIP initialization 777 The CT-KIP server may initialize the CT-KIP protocol by sending a 778 message. This message may e.g. be sent in response 779 to a user requesting token initialization in a browsing session. 781 782 783 784 785 788 789 791 792 793 795 796 797 798 799 Message used to trigger the device to initiate a 800 CT-KIP run. 801 802 803 804 805 807 808 809 810 811 813 The element is intended for the CT-KIP client and may 814 inform the CT-KIP client about the identifier for the token that is 815 to be initialized, and, optionally, of the identifier for the key on 816 that token. The latter would apply when re-seeding. The trigger 817 always contains a nonce to allow the server to couple the trigger 818 with a later CT-KIP request. Finally, the trigger may 819 contain a URL to use when contacting the CT-KIP server. The 820 elements are for future extensibility. Any provided or 821 values shall be used by the CT-KIP client in the subsequent 822 request. The optional element 823 informs the CT-KIP client about the characteristics of the intended 824 token platform, and applies in the public-key variant of CT-KIP in 825 situations when the client potentially need to decide which one of 826 several tokens to initialize. 828 The Version attribute shall be set to "1.0" for this version of CT- 829 KIP. 831 3.8.3. The CT-KIP client's initial PDU 833 This message is the initial message sent from the CT-KIP client to 834 the CT-KIP server. 836 838 839 840 841 Message sent from CT-KIP client to CT-KIP server to 842 initiate a CT-KIP session. 843 844 845 846 847 848 850 852 854 856 858 860 862 864 865 866 867 869 The components of this message have the following meaning: 871 o Version: (attribute inherited from the AbstractRequestType type) 872 The highest version of this protocol the client supports. Only 873 version one ("1.0") is currently specified. 875 o : An identifier for the cryptographic token (allows the 876 server to find, e.g., a correct shared secret for MACing 877 purposes). The identifier shall only be present if such shared 878 secrets exist or if the identifier was provided by the server in a 879 element (see Section 4.2.7 below). In the latter 880 case it must have the same value as the identifier provided in 881 that element. 883 o : An identifier for the key which will be overwritten if 884 the protocol run is successful. The identifier shall only be 885 present if the key exists or was provided by the server in a element (see Section 4.2.7 below). In the latter case 887 it must have the same value as the identifier provided in that 888 element. 890 o : This is the nonce R, which, when present, shall be 891 used by the server when calculating MAC values (see below). It is 892 recommended that clients include this element whenever the 893 element is present. 895 o : This optional element shall be present if and only 896 if the CT-KIP run was initialized with a message 897 (see Section 4.2.7 below), and shall in that case have the same 898 value as the child of that message. A server using 899 nonces in this way must verify that the nonce is valid and that 900 any token or key identifier values provided in the 901 message match the corresponding identifier values in the 902 message. 904 o : A sequence of URIs indicating the key types 905 for which the token is willing to generate keys through CT-KIP. 907 o : A sequence of URIs indicating the 908 encryption algorithms supported by the cryptographic token for the 909 purposes of CT-KIP. The CT-KIP client may indicate the same 910 algorithm both as a supported key type and as an encryption 911 algorithm. 913 o : A sequence of URIs indicating the MAC 914 algorithms supported by the cryptographic token for the purposes 915 of CT-KIP. The CT-KIP client may indicate the same algorithm both 916 as an encryption algorithm and as a MAC algorithm (e.g. http:// 917 www.rsasecurity.com/rsalabs/otps/schemas/2005/086/ 918 ct-kip#ct-kip-prf-aes defined in Appendix D) 920 o : A sequence of extensions. One extension is defined 921 for this message in this version of CT-KIP, the ClientInfoType, 922 see Section 3.9.1. 924 3.8.4. The CT-KIP server's initial PDU 926 This message is the first message sent from the CT-KIP server to the 927 CT-KIP client (assuming a trigger message has not been sent to 928 initiate the protocol, in which case this message is the second 929 message sent frmo the CT-KIP server to the CT-KIP client). It is 930 sent upon reception of a message. 932 934 935 936 937 Message sent from CT-KIP server to CT-KIP 938 client in response to a received ClientHello 939 PDU. 940 941 942 943 944 945 947 949 951 953 957 959 960 961 962 964 965 966 967 Currently only the nonce is defined. In future versions, 968 other payloads may be defined, e.g. for one roundtrip 969 initialization protocols. 970 971 972 973 974 975 976 977 978 979 980 981 982 983 985 The components of this message have the following meaning: 987 o Version: (attribute inherited from the AbstractResponseType type) 988 The version selected by the CT-KIP server. May be lower than the 989 version indicated by the CT-KIP client, in which case local policy 990 at the client will determine whether to continue the session or 991 not. 993 o SessionID: (attribute inherited from the AbstractResponseType 994 type) An identifier for this session. 996 o Status: (attribute inherited from the abstract 997 AbstractResponseType type) Return code for the . If 998 Status is not "Continue", only the Status and Version attributes 999 will be present, otherwise all the other elements must be present 1000 as well. 1002 o : The type of the key to be generated. 1004 o : The encryption algorithm to use when 1005 protecting R_C. 1007 o : The MAC algorithm to be used by the CT-KIP server. 1009 o : Information about the key to use when encrypting 1010 R_C. It will either be the server's public key (the 1011 alternative of ds:KeyInfoType) or an identifier for a shared 1012 secret key (the alternative of ds:KeyInfoType). 1014 o : The actual payload. For this version of the protocol 1015 only one payload is defined, the pseudorandom string R_S. 1017 o : A list of server extensions. Two extensions are 1018 defined for this message in this version of CT-KIP, the 1019 ClientInfoType and the ServerInfoType, see Section 3.9. 1021 o : The MAC must be present if the CT-KIP run will result in 1022 the replacement of an existing token key with a new one (i.e. if 1023 the element was present in the message). In 1024 this case, the CT-KIP server must prove to the cryptographic token 1025 that it is authorized to replace it. The MAC value shall be 1026 computed on the (ASCII) string "MAC 1 computation", the client's 1027 nonce R (if sent) and the server's nonce R_S using an 1028 authentication key K_AUTH that should be a special authentication 1029 key used only for this purpose but may be the current K_TOKEN . 1031 The MAC value may be computed by using the CT-KIP-PRF function of 1032 Section 3.4, in which case the input parameter s shall be set to 1033 the concatenation of the (ASCII) string "MAC 1 computation", R (if 1034 sent by the client), and R_S, and k shall be set to K_AUTH. The 1035 input parameter dsLen shall be set to the length of R_S: 1037 dsLen = len(R_S) 1039 MAC = CT-KIP-PRF (K_AUTH, "MAC 1 computation" || [R ||] R_S, 1040 dsLen) 1042 The CT-KIP client must verify the MAC if the successful execution 1043 of the protocol will result in the replacement of an existing 1044 token key with a newly generated one. The CT-KIP client must 1045 terminate the CT-KIP session if the MAC does not verify, and must 1046 delete any nonces, keys, and/or secrets associated with the failed 1047 run of the CT-KIP protocol. 1049 The MacType's MacAlgorithm attribute shall, when present, identify 1050 the negotiated MAC algorithm. 1052 3.8.5. The CT-KIP client's second PDU 1054 This message contains the nonce chosen by the cryptographic token, 1055 R_C, encrypted by the specified encryption key and encryption 1056 algorithm. 1058 1060 1061 1062 1063 Second message sent from CT-KIP client to 1064 CT-KIP server in a CT-KIP session. 1065 1066 1067 1068 1069 1070 1072 1074 1075 1077 1078 1079 1081 The components of this message have the following meaning: 1083 o Version: (inherited from the AbstractRequestType type) Shall be 1084 the same version as in the message. 1086 o SessionID: Shall have the same value as the SessionID attribute in 1087 the received message. 1089 o : The nonce generated and encrypted by the token. 1090 The encryption shall be made using the selected encryption 1091 algorithm and identified key, and as specified in Section 3.4. 1093 o : A list of extensions. Two extensions are defined 1094 for this message in this version of CT-KIP, the ClientInfoType and 1095 the ServerInfoType, see Section 3.9. 1097 3.8.6. The CT-KIP server's final PDU 1099 This message is the last message of a two roundtrip CT-KIP exchange. 1100 The CT-KIP server sends this message to the CT-KIP client in response 1101 to the message. 1103 1105 1106 1107 1108 Final message sent from CT-KIP server to 1109 CT-KIP client in a CT-KIP session. 1110 1111 1112 1113 1114 1115 1117 1119 1121 1123 1125 1127 1129 1131 1132 1133 1134 1136 The components of this message have the following meaning: 1138 o Version: (inherited from the AbstractResponseType type) The CT-KIP 1139 version used in this session. 1141 o SessionID: (inherited from the AbstractResponseType type) The 1142 previously established identifier for this session. 1144 o Status: (inherited from the AbstractResponseType type) Return code 1145 for the message. If Status is not "Success", 1146 only the Status, SessionID, and Version attributes will be present 1147 (the presence of the SessionID attribute is dependent on the type 1148 of reported error), otherwise all the other elements must be 1149 present as well. In this latter case, the 1150 message can be seen as a "Commit" message, instructing the 1151 cryptographic token to store the generated key and associate the 1152 given key identifier with this key. 1154 o : An identifier for the token carrying the generated key. 1155 Must have the same value as the element of the 1156 message, if one was provided. When assigned by the 1157 CT-KIP server, the element shall be unique within the 1158 domain of the CT-KIP server. 1160 o : An identifier for the newly generated key. The 1161 identifier shall be globally unique. Must have the same value as 1162 any key identifier provided by the CT-KIP client in the 1163 message. 1165 The reason for requiring globally unique key identifiers is that 1166 it avoids potential conflicts when associating key holders with 1167 key identifiers. One way of achieving global uniqueness with 1168 reasonable certainty is to hash the combination of the issuer's 1169 fully qualified domain name with an (issuer-specific) serial 1170 number, assuming that each issuer makes sure their serial numbers 1171 never repeat. 1173 CT-KIP clients must support key identifiers at least 64 octets 1174 long. CT-KIP servers should not generate key identifiers longer 1175 than 64 octets. 1177 o : This optional element provides the date and time 1178 after which the generated key should be treated as expired and 1179 invalid. 1181 o : An optional identifier for the service that has 1182 stored the generated key. The cryptographic token may store this 1183 identifier associated with the key in order to simplify later 1184 lookups. The identifier shall be a printable string. 1186 o : This optional element provides a graphical logo 1187 image for the service that can be displayed in user interfaces, 1188 e.g. to help a user select a certain key. The logo should contain 1189 an image within the size range of 60 pixels wide by 45 pixels 1190 high, and 200 pixels wide by 150 pixels high. The required 1191 MimeType attribute of this type provides information about the 1192 MIME type of the image. This specification supports both the JPEG 1193 and GIF image formats (with MIME types of "image/jpeg" and "image/ 1194 gif"). 1196 o : An optional identifier for the user associated with the 1197 generated key in the authentication service. The cryptographic 1198 token may store this identifier associated with the generated key 1199 in order to enhance later user experiences. The identifier shall 1200 be a printable string. 1202 o : A list of extensions chosen by the CT-KIP server. 1203 For this message, this version of CT-KIP defines two extensions, 1204 the OTPKeyConfigurationDataType and the ClientInfoType (see 1205 Section 3.9). 1207 o : To avoid a false "Commit" message causing the token to end 1208 up in an initialized state for which the server does not know the 1209 stored key, messages must always be authenticated 1210 with a MAC. The MAC shall be made using the already established 1211 MAC algorithm. The MAC value shall be computed on the (ASCII) 1212 string "MAC 2 computation" and R_C using an authentication key 1213 K_AUTH. Again, this should be a special authentication key used 1214 only for this purpose, but may also be an existing K_TOKEN (In 1215 this case, implementations must protect against attacks where 1216 K_TOKEN is used to pre-compute MAC values.). If no authentication 1217 key is present in the token, and no K_TOKEN existed before the CT- 1218 KIP run, K_AUTH shall be the newly generated K_TOKEN. 1220 If CT-KIP-PRF is used as the MAC algorithm, then the input 1221 parameter s shall consist of the concatenation of the (ASCII) 1222 string "MAC 2 computation" and R_C, and the parameter dsLen shall 1223 be set to the length of R_C: 1225 dsLen = len(R_C) 1227 MAC = CT-KIP-PRF (K_AUTH, "MAC 2 computation" || R_C, dsLen) 1229 When receiving a message with Status = "Success" 1230 for which the MAC verifies, the CT-KIP client shall associate the 1231 generated key K_TOKEN with the provided key identifier and store 1232 this data permanently. After this operation, it shall not be 1233 possible to overwrite the key unless knowledge of an authorizing 1234 key is proven through a MAC on a later (and 1235 ) message. 1237 The CT-KIP client must verify the MAC. The CT-KIP client must 1238 terminate the CT-KIP session if the MAC does not verify, and must 1239 in this case also delete any nonces, keys, and/or secrets 1240 associated with the failed run of the CT-KIP protocol. 1242 The MacType's MacAlgorithm attribute shall, when present, identify 1243 the negotiated MAC algorithm. 1245 3.9. Protocol extensions 1247 3.9.1. The ClientInfoType type 1249 When present in a or a message, the 1250 optional ClientInfoType extension contains CT-KIP client-specific 1251 information. CT-KIP servers must support this extension. CT-KIP 1252 servers must not attempt to interpret the data it carries and if 1253 received, must include it unmodified in the current protocol run's 1254 next server response. Servers need not retain the ClientInfoType's 1255 data after that response has been generated. 1257 1258 1259 1260 1261 1263 1264 1265 1266 1268 3.9.2. The ServerInfoType type 1270 When present, the optional ServerInfoType extension contains CT-KIP 1271 server-specific information. This extension is only valid in 1272 messages for which Status = "Continue". CT-KIP clients 1273 must support this extension. CT-KIP clients must not attempt to 1274 interpret the data it carries and if received, must include it 1275 unmodified in the current protocol run's next client request (i.e., 1276 the message). CT-KIP clients need not retain the 1277 ServerInfoType's data after that request has been generated. This 1278 extension may be used, e.g., for state management in the CT-KIP 1279 server. 1281 1282 1283 1284 1285 1287 1288 1289 1290 1292 3.9.3. The OTPKeyConfigurationDataType type 1294 The optional OTPKeyConfigurationDataType extension contains 1295 additional key configuration data for OTP keys: 1297 1298 1299 1300 This extension is only valid in ServerFinished 1301 PDUs. It carries additional configuration data 1302 that an OTP token should use (subject to local 1303 policy) when generating OTP values with a newly 1304 generated OTP key. 1305 1306 1307 1308 1309 1310 1312 1314 1316 1317 1318 1319 1321 This extension is only valid in messages. It 1322 carries additional configuration data that the cryptographic token 1323 should use (subject to local policy) when generating OTP values from 1324 the newly generated OTP key. The components of this extension have 1325 the following meaning: 1327 o OTPFormat: The default format of OTPs produced with this key. 1329 o OTPLength: The default length of OTPs produced with this key. 1331 o OTPMode: The default mode of operation when producing OTPs with 1332 this key. 1334 4. Protocol bindings 1336 4.1. General requirement 1338 CT-KIP assumes a reliable transport. 1340 4.2. HTTP/1.1 binding for CT-KIP 1342 4.2.1. Introduction 1344 This section presents a binding of the previous messages to HTTP/1.1 1345 [7]. Note that the HTTP client normally will be different from the 1346 CT-KIP client, i.e. the HTTP client will only exist to "proxy" CT-KIP 1347 messages from the CT-KIP client to the CT-KIP server. Likewise, on 1348 the HTTP server side, the CT-KIP server may receive CT-KIP PDUs from 1349 a "front-end" HTTP server. 1351 4.2.2. Identification of CT-KIP messages 1353 The MIME-type for all CT-KIP messages shall be 1355 application/vnd.otps.ct-kip+xml 1357 4.2.3. HTTP headers 1359 HTTP proxies must not cache responses carrying CT-KIP messages. For 1360 this reason, the following holds: 1362 o When using HTTP/1.1, requesters should: 1364 * Include a Cache-Control header field set to "no-cache, no- 1365 store". 1367 * Include a Pragma header field set to "no-cache". 1369 o When using HTTP/1.1, responders should: 1371 * Include a Cache-Control header field set to "no-cache, no- 1372 must-revalidate, private". 1374 * Include a Pragma header field set to "no-cache". 1376 * NOT include a Validator, such as a Last-Modified or ETag 1377 header. 1379 There are no other restrictions on HTTP headers, besides the 1380 requirement to set the Content-Type header value to application/ 1381 vnd.otps.ct-kip+xml. 1383 4.2.4. HTTP operations 1385 Persistent connections as defined in HTTP/1.1 are assumed but not 1386 required. CT-KIP requests are mapped to HTTP POST operations. CT- 1387 KIP responses are mapped to HTTP responses. 1389 4.2.5. HTTP status codes 1391 A CT-KIP HTTP responder that refuses to perform a message exchange 1392 with a CT-KIP HTTP requester should return a 403 (Forbidden) 1393 response. In this case, the content of the HTTP body is not 1394 significant. In the case of an HTTP error while processing a CT-KIP 1395 request, the HTTP server must return a 500 (Internal Server Error) 1396 response. This type of error should be returned for HTTP-related 1397 errors detected before control is passed to the CT-KIP processor, or 1398 when the CT-KIP processor reports an internal error (for example, the 1399 CT-KIP XML namespace is incorrect, or the CT-KIP schema cannot be 1400 located). If the type of a CT-KIP request cannot be determined, the 1401 CT-KIP responder must return a 400 (Bad request) response. 1403 In these cases (i.e. when the HTTP response code is 4xx or 5xx), the 1404 content of the HTTP body is not significant. 1406 Redirection status codes (3xx) apply as usual. 1408 Whenever the HTTP POST is successfully invoked, the CT-KIP HTTP 1409 responder must use the 200 status code and provide a suitable CT-KIP 1410 message (possibly with CT-KIP error information included) in the HTTP 1411 body. 1413 4.2.6. HTTP authentication 1415 No support for HTTP/1.1 authentication is assumed. 1417 4.2.7. Initialization of CT-KIP 1419 The CT-KIP server may initialize the CT-KIP protocol by sending an 1420 HTTP response with Content-Type set to application/ 1421 vnd.otps.ct-kip+xml and response code set to 200 (OK). This message 1422 may e.g. be sent in response to a user requesting token 1423 initialization in a browsing session. The initialization message may 1424 carry data in its body. If this is the case, the data shall be a 1425 valid instance of a element. 1427 4.2.8. Example messages 1428 a. Initialization from CT-KIP server: 1430 HTTP/1.1 200 OK 1431 Cache-Control: no-store 1432 Content-Type: application/vnd.otps.ct-kip+xml 1433 Content-Length: 1435 CT-KIP initialization data in XML form... 1437 b. Initial request from CT-KIP client: 1439 POST http://example.com/cgi-bin/CT-KIP-server HTTP/1.1 1440 Cache-Control: no-store 1441 Pragma: no-cache 1442 Host: example.com 1443 Content-Type: application/vnd.otps.ct-kip+xml 1444 Content-Length: 1446 CT-KIP data in XML form (supported version, supported algorithms...) 1448 c. Initial response from CT-KIP server: 1450 HTTP/1.1 200 OK 1451 Cache-Control: no-store 1452 Content-Type: application/vnd.otps.ct-kip+xml 1453 Content-Length: 1455 CT-KIP data in XML form (server random nonce, server public key, ...) 1457 5. Security considerations 1459 5.1. General 1461 CT-KIP is designed to protect generated key material from exposure. 1462 No other entities than the CT-KIP server and the cryptographic token 1463 will have access to a generated K_TOKEN if the cryptographic 1464 algorithms used are of sufficient strength and, on the CT-KIP client 1465 side, generation and encryption of R_C and generation of K_TOKEN 1466 takes place as specified and in the token. This applies even if 1467 malicious software is present in the CT-KIP client. As discussed in 1468 the following, CT-KIP does however not protect against certain other 1469 threats resulting from man-in-the-middle attacks and other forms of 1470 attacks. CT-KIP should therefore be run over a transport providing 1471 privacy and integrity, such as HTTP over TLS with a suitable 1472 ciphersuite, when such threats are a concern. Note that TLS 1473 ciphersuites with anonymous key exchanges are not suitable in those 1474 situations. 1476 5.2. Active attacks 1478 5.2.1. Introduction 1480 An active attacker may attempt to modify, delete, insert, replay or 1481 reorder messages for a variety of purposes including service denial 1482 and compromise of generated key material. Sections 5.2.2 through 1483 5.2.7 analyze these attack scenarios. 1485 5.2.2. Message modifications 1487 Modifications to a message will either cause denial- 1488 of-service (modifications of any of the identifiers or the nonce) or 1489 the CT-KIP client to contact the wrong CT-KIP server. The latter is 1490 in effect a man-in-the-middle attack and is discussed further in 1491 Section 5.2.7. 1493 An attacker may modify a message. This means that the 1494 attacker could indicate a different key or token than the one 1495 intended by the CT-KIP client, and could also suggest other 1496 cryptographic algorithms than the ones preferred by the CT-KIP 1497 client, e.g. cryptographically weaker ones. The attacker could also 1498 suggest earlier versions of the CT-KIP protocol, in case these 1499 versions have been shown to have vulnerabilities. These 1500 modifications could lead to an attacker succeeding in initializing or 1501 modifying another token than the one intended (i.e. the server 1502 assigning the generated key to the wrong token), or gaining access to 1503 a generated key through the use of weak cryptographic algorithms or 1504 protocol versions. CT-KIP implementations may protect against the 1505 latter by having strict policies about what versions and algorithms 1506 they support and accept. The former threat (assignment of a 1507 generated key to the wrong token) is not possible when the shared-key 1508 variant of CT-KIP is employed (assuming existing shared keys are 1509 unique per token) but is possible in the public-key variant. CT-KIP 1510 servers must therefore not accept unilaterally provided token 1511 identifiers in the public-key variant. This is also indicated in the 1512 protocol description. In the shared-key variant however, an attacker 1513 may be able to provide the wrong identifier (possibly also leading to 1514 the incorrect user being associated with the generated key) if the 1515 attacker has real-time access to the token with the identified key. 1516 In other words, the generated key is associated with the correct 1517 token but the token is associated with the incorrect user. See 1518 further Section 5.5 for a discussion of this threat and possible 1519 countermeasures. 1521 An attacker may also modify a message. This means that 1522 the attacker could indicate different key types, algorithms, or 1523 protocol versions than the legitimate server would, e.g. 1524 cryptographically weaker ones. The attacker could also provide a 1525 different nonce than the one sent by the legitimate server. Clients 1526 will protect against the former through strict adherence to policies 1527 regarding permissible algorithms and protocol versions. The latter 1528 (wrong nonce) will not constitute a security problem as a generated 1529 key won't match the key generated on the legitimate server. Also, 1530 whenever the CT-KIP run would result in the replacement of an 1531 existing key, the element protects against modifications of 1532 R_S. 1534 Modifications of messages are also possible. If an 1535 attacker modifies the SessionID attribute then in effect a switch to 1536 another session will occur at the server, assuming the new SessionID 1537 is valid at that time on the server. It still will not allow the 1538 attacker to learn a generated K_TOKEN since R_C has been wrapped for 1539 the legitimate server. Modifications of the 1540 element, e.g. replacing it with a value for which the attacker knows 1541 an underlying R'C, will not result in the client changing its pre-CT- 1542 KIP state, since the server will be unable to provide a valid MAC in 1543 its final message to the client. The server may however end up 1544 storing K'TOKEN rather than K_TOKEN. If the token has been 1545 associated with a particular user, then this could constitute a 1546 seurity problem. For a further discussion about this threat, and a 1547 possible countermeasure, see Section 5.5 below. Note that use of SSL 1548 or TLS does not protect against this attack if the attacker has 1549 access to the CT-KIP client (e.g. through malicious software, 1550 "trojans"). 1552 Finally, attackers may also modify the message. 1554 Replacing the element will only result in denial-of-service. 1555 Replacement of any other element may cause the CT-KIP client to 1556 associate, e.g., the wrong service with the generated key. CT-KIP 1557 should be run over a transport providing privacy and integrity when 1558 this is a concern. 1560 5.2.3. Message deletion 1562 Message deletion will not cause any other harm than denial-of- 1563 service, since a token shall not change its state (i.e. "commit" to a 1564 generated key) until it receives the final message from the CT-KIP 1565 server and successfully has processed that message, including 1566 validation of its MAC. A deleted message will not 1567 cause the server to end up in an inconsistent state vis-a-vis the 1568 token if the server implements the suggestions in Section 5.5. 1570 5.2.4. Message insertion 1572 An active attacker may initiate a CT-KIP run at any time, and suggest 1573 any token identifier. CT-KIP server implementations may receive some 1574 protection against inadvertently initializing a token or 1575 inadvertently replacing an existing key or assigning a key to a token 1576 by initializing the CT-KIP run by use of the . The 1577 element allows the server to associate a CT-KIP 1578 protocol run with, e.g., an earlier user-authenticated session. The 1579 security of this method therefore depends on the ability to protect 1580 the element in the CT-KIP initialization message. If 1581 an eavesdropper is able to capture this message he may race the 1582 legitimate user for a key initialization. CT-KIP over a transport 1583 providing privacy and integrity, coupled with the recommendations in 1584 Section 5.5 is recommended when this is a concern. 1586 Insertion of other messages into an existing protocol run is seen as 1587 equivalent to modification of legitimately sent messages. 1589 5.2.5. Message replay 1591 Attempts to replay a previously recorded CT-KIP message will be 1592 detected as the use of nonces ensures that both parties are live. 1594 5.2.6. Message reordering 1596 An attacker may attempt to re-order messages but this will be 1597 detected as each message is of a unique type. 1599 5.2.7. Man in the middle 1601 In addition to other active attacks, an attacker posing as a man in 1602 the middle may be able to provide his own public key to the CT-KIP 1603 client. This threat and countermeasures to it are discussed in 1604 Section 3.3. An attacker posing as a man-in-the-middle may also be 1605 acting as a proxy and hence not interfere with CT-KIP runs but still 1606 learn valuable information, see Section 5.3. 1608 5.3. Passive attacks 1610 Passive attackers may eavesdrop on CT-KIP runs to learn information 1611 that later on may be used to impersonate users, mount active attacks, 1612 etc. 1614 If CT-KIP is not run over a transport providing privacy, a passive 1615 attacker may learn: 1617 o What tokens a particular user is in possession of; 1619 o The identifiers of keys on those tokens and other attributes 1620 pertaining to those keys, e.g. the lifetime of the keys; and 1622 o CT-KIP versions and cryptographic algorithms supported by a 1623 particular CT-KIP client or server. 1625 Whenever the above is a concern, CT-KIP should be run over a 1626 transport providing privacy. If man-in-the-middle attacks for the 1627 purposes described above are a concern, the transport should also 1628 offer server-side authentication. 1630 5.4. Cryptographic attacks 1632 An attacker with unlimited access to an initialized token may use the 1633 token as an "oracle" to pre-compute values that later on may be used 1634 to impersonate the CT-KIP server. Sections 3.6 and 3.8 contain 1635 discussions of this threat and steps recommended to protect against 1636 it. 1638 5.5. Attacks on the interaction between CT-KIP and user authentication 1640 If keys generated in CT-KIP will be associated with a particular user 1641 at the CT-KIP server (or a server trusted by, and communicating with 1642 the CT-KIP server), then in order to protect against threats where an 1643 attacker replaces a client-provided encrypted R_C with his own R'C 1644 (regardless of whether the public-key variant or the shared-secret 1645 variant of CT-KIP is employed to encrypt the client nonce) the server 1646 should not commit to associate a generated K_TOKEN with the given 1647 token (user) until the user simultaneously has proven both possession 1648 of a token containing K_TOKEN and some out-of-band provided 1649 authenticating information (e.g. a temporary password). For example, 1650 if the token is a one-time password token, the user could be required 1651 to authenticate with both a one-time password generated by the token 1652 and an out-of-band provided temporary PIN in order to have the server 1653 "commit" to the generated token value for the given user. 1654 Preferably, the user should perform this operation from another host 1655 than the one used to initialize the token, in order to minimize the 1656 risk of malicious software on the client interfering with the 1657 process. 1659 Another threat arises when an attacker is able to trick a user to 1660 authenticate to the attacker rather than to the legitimate service 1661 before the CT-KIP protocol run. If successful, the attacker will 1662 then be able to impersonate the user towards the legitimate service, 1663 and subsequently receive a valid CT-KIP trigger. If the public-key 1664 variant of CT-KIP is used, this may result in the attacker being able 1665 to (after a successful CT-KIP protocol run) impersonate the user. 1666 Ordinary precautions must therefore be in place to ensure that users 1667 authenticate only to legitimate services. 1669 6. IANA considerations 1671 IANA has no action with respect to this document. 1673 7. Intellectual property considerations 1675 RSA and SecurID are registered trademarks or trademarks of RSA 1676 Security Inc. in the United States and/or other countries. The names 1677 of other products and services mentioned may be the trademarks of 1678 their respective owners. 1680 8. References 1682 8.1. Normative references 1684 [1] Davis, M. and M. Duerst, "Unicode Normalization Forms", 1685 March 2001, 1686 . 1688 8.2. Informative references 1690 [2] RSA Laboratories, "PKCS #11 Mechanisms for the Cryptographic 1691 Token Key Initialization Protocol", PKCS #11 Version 2.20 1692 Amendment 2, December 2005, . 1695 [3] RSA Laboratories, "Cryptographic Token Interface Standard", 1696 PKCS #11 Version 2.20, June 2004, . 1699 [4] RSA Laboratories, "Frequently Asked Questions About Today's 1700 Cryptography. Version 4.1", 2000, . 1703 [5] RSA Laboratories, "Password-Based Cryptography Standard", 1704 PKCS #5 Version 2.0, March 1999, 1705 . 1707 [6] RSA Laboratories, "RSA Cryptography Standard", PKCS #1 Version 1708 2.1, June 2002, . 1710 [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1711 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1712 HTTP/1.1", RFC 2616, June 1999. 1714 [8] National Institute of Standards and Technology, "Specification 1715 for the Advanced Encryption Standard (AES)", FIPS 197, 1716 November 2001, 1717 . 1719 [9] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1720 for Message Authentication", RFC 2104, February 1997. 1722 [10] Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC. In Fast 1723 Software Encryption, FSE 2003, pages 129 - 153. Springer- 1724 Verlag", 2003, 1725 . 1727 [11] National Institute of Standards and Technology, "Secure Hash 1728 Standard", FIPS 197, February 2004, . 1731 [12] RSA Laboratories, "Cryptographic Token Key Initialization 1732 Protocol", OTPS Version 1.0, December 2005, 1733 . 1735 Appendix A. CT-KIP schema 1737 1745 1750 1752 1753 1754 1756 1757 1758 1759 1760 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1779 1780 1781 1782 1784 1786 1787 1788 1789 1790 1792 1793 1794 1795 1796 1798 1799 1800 1801 1803 1804 1805 1807 1808 1809 1810 1811 1812 1814 1815 1816 1817 1818 1819 1821 1822 1823 1825 1826 1827 1828 1830 1831 1833 1835 1836 1837 1838 1839 1840 1842 1843 1844 1846 1847 1848 1849 1850 1851 1852 1853 1854 1856 1857 1858 1859 1860 1861 1862 1863 1864 1866 1867 1868 1869 This extension is only valid in ServerFinished PDUs. It carries 1870 additional configuration data that an OTP token should use 1871 (subject to local policy) when generating OTP values from a 1872 newly generated OTP key. 1873 1874 1875 1876 1877 1878 1879 1880 1882 1883 1884 1885 1887 1888 1889 1890 1891 1892 1893 1894 1896 1897 1898 1899 1900 1901 1902 1903 1905 1906 1907 1908 1909 1910 1911 1913 1914 1915 1916 1917 1918 1919 1920 1921 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 Carries token platform information helping the client to select 1934 a suitable token. 1935 1936 1937 1938 1939 1941 1942 1943 1944 1945 1947 1948 1949 1951 1952 1954 1956 1957 1959 1960 1961 1962 Message used to trigger the device to initiate a CT-KIP run. 1963 1964 1965 1966 1967 1969 1970 1971 1972 1973 1975 1976 1977 1978 1979 1980 Message sent from CT-KIP client to CT-KIP server to initiate an 1981 CT-KIP session. 1982 1983 1984 1985 1986 1987 1989 1991 1993 1995 1996 1998 2000 2002 2003 2004 2005 2007 2008 2010 2011 2012 2013 Message sent from CT-KIP server to CT-KIP client in response to 2014 a received ClientHello PDU. 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2027 2028 2029 2030 2031 2033 2034 2036 2037 2038 2039 Second message sent from CT-KIP client to CT-KIP server to 2040 convey the client's chosen secret. 2041 2042 2043 2044 2045 2046 2047 2049 2050 2052 2053 2054 2056 2057 2058 2059 2060 2061 Final message sent from CT-KIP server to CT-KIP client in an 2062 CT-KIP session. 2063 2064 2065 2066 2067 2068 2069 2070 2072 2074 2076 2078 2080 2081 2082 2083 2084 2086 2088 Appendix B. Examples of CT-KIP messages 2090 B.1. Introduction 2092 All examples are syntactically correct. MAC and cipher values are 2093 fictitious however. The examples illustrate a complete CT-KIP 2094 exchange, starting with an initialization (trigger) message from the 2095 server. 2097 B.2. Example of a CT-KIP initialization (trigger) message 2099 2104 2105 12345678 2106 112dsdfwf312asder394jw== 2107 2108 2110 B.3. Example of a message 2112 2113 2118 12345678 2119 112dsdfwf312asder394jw== 2120 2121 http://www.rsasecurity.com/rsalabs/otps/schemas 2122 /2005/09/otps-wst#SecurID-AES 2123 2124 2125 http://www.w3.org/2001/04/xmlenc#rsa-1_5 2126 http://www.rsasecurity.com/rsalabs/otps/schemas/ 2127 2005/12/ct-kip#ct-kip-prf-aes 2128 2129 2130 http://www.rsasecurity.com/rsalabs/otps/schemas/ 2131 2005/12/ct-kip#ct-kip-prf-aes 2132 2133 2135 B.4. Example of a message 2137 2138 2144 http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/ 2145 otps-wst#SecurID-AES 2146 http://www.rsasecurity.com/rsalabs/otps/ 2147 schemas/2005/12/ct-kip#ct-kip-prf-aes 2148 http://www.rsasecurity.com/rsalabs/otps/schemas/ 2149 2005/12/ct-kip#ct-kip-prf-aes 2150 2151 KEY-1 2152 2153 2154 qw2ewasde312asder394jw== 2155 2156 2158 B.5. Example of a message 2160 2161 2166 vXENc+Um/9/NvmYKiHDLaErK0gk= 2167 2169 B.6. Example of a message 2171 2172 2177 12345678 2178 2009-09-16T03:02:00Z 2179 43212093 2180 Example Enterprise Name 2181 exampleLoginName 2182 2183 2184 Decimal 2185 6 2186 2187 2188 2189 miidfasde312asder394jw== 2190 2192 Appendix C. Integration with PKCS #11 2194 A CT-KIP client that needs to communicate with a connected 2195 cryptographic token to perform a CT-KIP exchange may use PKCS #11 [3] 2196 as a programming interface. When performing CT-KIP with a 2197 cryptographic token using the PKCS #11 programming interface, the 2198 procedure described in [2], Appendix B, is recommended. 2200 Appendix D. Example CT-KIP-PRF realizations 2202 D.1. Introduction 2204 This example appendix defines CT-KIP-PRF in terms of AES [8] and HMAC 2205 [9]. 2207 D.2. CT-KIP-PRF-AES 2209 D.2.1. Identification 2211 For tokens supporting this realization of CT-KIP-PRF, the following 2212 URI may be used to identify this algorithm in CT-KIP: 2214 http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ 2215 ct-kip#ct-kip-prf-aes 2217 When this URI is used to identify the encryption algorithm to use, 2218 the method for encryption of R_C values described in Section 3.6 2219 shall be used. 2221 D.2.2. Definition 2223 CT-KIP-PRF-AES (k, s, dsLen) 2225 Input: 2227 k encryption key to use 2229 s octet string consisting of randomizing material. The length of 2230 the string s is sLen. 2232 dsLen desired length of the output 2234 Output: 2236 DS a pseudorandom string, dsLen-octets long 2238 Steps: 2240 1. Let bLen be the output block size of AES in octets: 2242 bLen = (AES output block length in octets) 2244 (normally, bLen = 16) 2246 2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and 2247 stop 2249 3. Let n be the number of bLen-octet blocks in the output data, 2250 rounding up, and let j be the number of octets in the last block: 2252 n = ROUND( dsLen / bLen ) 2254 j = dsLen - (n - 1) * bLen 2256 4. For each block of the pseudorandom string DS, apply the function F 2257 defined below to the key k, the string s and the block index to 2258 compute the block: 2260 B1 = F (k, s, 1) , 2262 B2 = F (k, s, 2) , 2264 ... 2266 Bn = F (k, s, n) 2268 The function F is defined in terms of the OMAC1 construction from 2269 [10], using AES as the block cipher: 2271 F (k, s, i) = OMAC1-AES (k, INT (i) || s) 2273 where INT (i) is a four-octet encoding of the integer i, most 2274 significant octet first, and the output length of OMAC1 is set to 2275 bLen. 2277 Concatenate the blocks and extract the first dsLen octets to produce 2278 the desired data string DS: 2280 DS = B1 || B2 || ... || Bn<0..j-1> 2282 Output the derived data DS. 2284 D.2.3. Example 2286 If we assume that dsLen = 16, then: 2288 n = 16 / 16 = 1 2290 j = 16 - (1 - 1) * 16 = 16 2292 DS = B1 = F (k, s, 1) = OMAC1-AES (k, INT (1) || S) 2294 D.3. CT-KIP-PRF-SHA256 2296 D.3.1. Identification 2298 For tokens supporting this realization of CT-KIP-PRF, the following 2299 URI may be used to identify this algorithm in CT-KIP: 2301 http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ 2302 ct-kip#ct-kip-prf-sha256 2304 When this URI is used to identify the encryption algorithm to use, 2305 the method for encryption of R_C values described in Section 3.6 2306 shall be used. 2308 D.3.2. Definition 2310 CT-KIP-PRF-SHA256 (k, s, dsLen) 2312 Input: 2314 k encryption key to use 2316 s octet string consisting of randomizing material. The length of 2317 the string s is sLen 2319 dsLen desired length of the output 2321 Output: 2323 DS a pseudorandom string, dsLen-octets long 2325 Steps: 2327 1. Let bLen be the output size in octets of SHA-256 [11] (no 2328 truncation is done on the HMAC output): 2330 bLen = 32 2332 2. If dsLen > (2**32 - 1) bLen, output "derived data too long" and 2333 stop 2335 3. Let n be the number of bLen-octet blocks in the output data, 2336 rounding up, and let j be the number of octets in the last block: 2338 n = ROUND ( dsLen / bLen ) 2340 j = dsLen - (n - 1) * bLen 2342 4. For each block of the pseudorandom string DS, apply the function F 2343 defined below to the key k, the string s and the block index to 2344 compute the block: 2346 B1 = F (k, s, 1) , 2348 B2 = F (k, s, 2) , 2350 ... 2352 Bn = F (k, s, n) 2354 The function F is defined in terms of the HMAC construction from [9], 2355 using SHA-256 as the digest algorithm: 2357 F (k, s, i) = HMAC-SHA256 (k, INT (i) || s) 2359 where INT (i) is a four-octet encoding of the integer i, most 2360 significant octet first, and the output length of HMAC is set to 2361 bLen. 2363 Concatenate the blocks and extract the first dsLen octets to produce 2364 the desired data string DS: 2366 DS = B1 || B2 || ... || Bn<0..j-1> 2368 Output the derived data DS. 2370 D.3.3. Example 2372 If we assume that sLen = 256 (two 128-octet long values) and dsLen = 2373 16, then: 2375 n = ROUND ( 16 / 32 ) = 1 2377 j = 16 - (1 - 1) * 32 = 16 2379 B1 = F (k, s, 1) = HMAC-SHA256 (k, INT (1) || s ) 2381 DS = B1<0 ... 15> 2383 I.e. the result will be the first 16 octets of the HMAC output. 2385 Appendix E. About OTPS 2387 The One-Time Password Specifications are documents produced by RSA 2388 Laboratories in cooperation with secure systems developers for the 2389 purpose of simplifying integration and management of strong 2390 authentication technology into secure applications, and to enhance 2391 the user experience of this technology. 2393 Further development of the OTPS series will occur through mailing 2394 list discussions and occasional workshops, and suggestions for 2395 improvement are welcome. As for our PKCS documents, results may also 2396 be submitted to standards forums. For more information, contact: 2398 OTPS Editor 2399 RSA Laboratories 2400 174 Middlesex Turnpike 2401 Bedford, MA 01730 USA 2402 otps-editor@rsasecurity.com 2403 http://www.rsasecurity.com/rsalabs/ 2405 Author's Address 2407 Magnus Nystroem 2408 RSA Security 2410 Email: magnus@rsasecurity.com 2412 Intellectual Property Statement 2414 The IETF takes no position regarding the validity or scope of any 2415 Intellectual Property Rights or other rights that might be claimed to 2416 pertain to the implementation or use of the technology described in 2417 this document or the extent to which any license under such rights 2418 might or might not be available; nor does it represent that it has 2419 made any independent effort to identify any such rights. Information 2420 on the procedures with respect to rights in RFC documents can be 2421 found in BCP 78 and BCP 79. 2423 Copies of IPR disclosures made to the IETF Secretariat and any 2424 assurances of licenses to be made available, or the result of an 2425 attempt made to obtain a general license or permission for the use of 2426 such proprietary rights by implementers or users of this 2427 specification can be obtained from the IETF on-line IPR repository at 2428 http://www.ietf.org/ipr. 2430 The IETF invites any interested party to bring to its attention any 2431 copyrights, patents or patent applications, or other proprietary 2432 rights that may cover technology that may be required to implement 2433 this standard. Please address the information to the IETF at 2434 ietf-ipr@ietf.org. 2436 Disclaimer of Validity 2438 This document and the information contained herein are provided on an 2439 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2440 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2441 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2442 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2443 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2444 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2446 Copyright Statement 2448 Copyright (C) The Internet Society (2006). This document is subject 2449 to the rights, licenses and restrictions contained in BCP 78, and 2450 except as set forth therein, the authors retain all their rights. 2452 Acknowledgment 2454 Funding for the RFC Editor function is currently provided by the 2455 Internet Society.