idnits 2.17.1 draft-mraihi-mutual-oath-hotp-variants-06.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 986. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 993. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 999. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2119], [C], [RFC2104], [T], [OATH], [RFC4226], [CN], [RFC1750], [BCK], [RFC3668]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 775 has weird spacing: '...eyBytes the ...' == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (December 2007) is 5976 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 section? 'RFC4226' on line 727 looks like a reference -- Missing reference section? 'OATH' on line 738 looks like a reference -- Missing reference section? 'RFC2119' on line 719 looks like a reference -- Missing reference section? 'RFC 4226' on line 267 looks like a reference -- Missing reference section? 'C' on line 570 looks like a reference -- Missing reference section? 'T' on line 564 looks like a reference -- Missing reference section? 'RFC2104' on line 711 looks like a reference -- Missing reference section? 'RFC1750' on line 715 looks like a reference -- Missing reference section? 'CN' on line 741 looks like a reference -- Missing reference section? 'RFC3668' on line 724 looks like a reference -- Missing reference section? 'BCK' on line 734 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft David M'Raihi 3 VeriSign 4 Category: Johan Rydell 5 Informational PortWise 6 Document: David Naccache 7 draft-mraihi-mutual-oath-hotp-variants-06.txt ENS 8 Salah Machani 9 Diversinet 10 Siddharth Bajaj 11 VeriSign 12 Expires: 13 June 2008 December 2007 15 OCRA: OATH Challenge-Response Algorithms 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress". 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document describes the OATH algorithm for challenge-response 43 authentication and signatures. This algorithm is based on the HOTP 44 algorithm [RFC4226] that was introduced by OATH (initiative for 45 Open AuTHentication) [OATH] and submitted as an individual draft to 46 the IETF last year. 48 OCRA: OATH Challenge Response Algorithms December 2007 50 Table of Contents 52 1. Introduction...............................................3 53 2. Requirements Terminology...................................3 54 3. Algorithm Requirements.....................................3 55 4. OCRA Background............................................4 56 4.1 HOTP Algorithm.............................................4 57 5. Definition of OCRA.........................................5 58 5.1 DataInput Parameters........................................5 59 5.2 CryptoFunction..............................................6 60 6. The OCRASuite..............................................7 61 7. Algorithm Modes for Authentication.........................8 62 7.1 One way Challenge-Response..................................8 63 7.2 Mutual Challenge-Response...................................9 64 8. Algorithm Modes for Signature.............................10 65 8.1 Plain Signature...........................................10 66 8.2 Signature with Server Authentication......................11 67 9. Security Considerations...................................13 68 9.1 Security Analysis of the OCRA algorithm....................13 69 9.2 Implementation Considerations..............................13 70 10. IANA Considerations.......................................15 71 11. Conclusion................................................15 72 12. Acknowledgements..........................................15 73 13. References................................................15 74 13.1 Normative.................................................15 75 13.2 Informative...............................................16 76 Appendix A: Source Code........................................16 77 Appendix B: Test Vectors.......................................19 78 14. Authors' Addresses........................................20 79 15. Full Copyright Statement..................................21 80 16. Intellectual Property.....................................21 81 OCRA: OATH Challenge Response Algorithms December 2007 83 1. Introduction 85 OATH has identified several use cases and scenarios that require an 86 asynchronous variant to accommodate users who do not want to 87 maintain a synchronized authentication system. The commonly 88 accepted method for this is to use a challenge-response scheme. 90 Such challenge response mode of authentication is widely adopted in 91 the industry. Several vendors already offer software applications 92 and hardware devices implementing challenge-response - but each of 93 those uses vendor-specific proprietary algorithms. For the benefits 94 of users we need a standardized challenge-response algorithm to 95 allow multi-sourcing of token purchases and validation systems to 96 facilitate the democratization of strong authentication. 97 Additionally, this specification can also be used to create 98 symmetric key based digital signatures. Such systems are variants 99 of challenge-response mode where the data to be signed becomes the 100 challenge. 102 2. Requirements Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 106 this document are to be interpreted as described in RFC 2119 107 [RFC2119]. 109 3. Algorithm Requirements 111 This section presents the main requirements that drove this 112 algorithm design. A lot of emphasis was placed on flexibility and 113 usability, under the constraints and specificity of the HOTP 114 algorithm and hardware token capabilities. 116 R1 - The algorithm MUST support asynchronous challenge-response 117 based authentication. 119 R2 - The algorithm MUST be capable of supporting symmetric key 120 based digital signatures. Essentially this is a variation of 121 challenge-response where the challenge is derived from the data 122 that needs to be signed. 124 R3 - The algorithm MUST be capable of supporting server- 125 authentication, whereby the user can verify that he/she is talking 126 to a valid server. 128 R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building 129 block. 131 OCRA: OATH Challenge Response Algorithms December 2007 133 R5 - The length and format for the input challenge SHOULD be 134 configurable. 136 R6 - The output length and format for the response SHOULD be 137 configurable. 139 R7 - The challenge MAY be generated with integrity checking (e.g., 140 parity bits). This will allow tokens with pin pads to perform 141 simple error checking if the user enters the value into a token. 143 R8 - There MUST be a unique secret (key) for each token/soft token 144 that is shared between the token and the authentication server. The 145 keys MUST be randomly generated or derived using some key 146 derivation algorithm. 148 R9 - The algorithm MUST enable additional data attributes such as a 149 counter, a time function or session information to be included in 150 the computation. These data inputs MAY be used individually or all 151 together. 153 4. OCRA Background 155 OATH introduced the HOTP algorithm as a first open, freely 156 available building block toward hardening authentication for end- 157 users in a variety of applications. One-time passwords are very 158 efficient at solving specific security issues thanks to the dynamic 159 nature of OTP computations. 161 After carefully analyzing different use cases, OATH came to the 162 conclusion that providing for extensions to the HOTP algorithms was 163 important. A very natural extension is to introduce a challenge 164 mode for computing HOTP values based on random questions. Equally 165 beneficial, being able to perform mutual authentication between two 166 parties, or short-signature computation for authenticating 167 transaction was also identified as critical for improving the 168 security of e-commerce applications. 170 4.1 HOTP Algorithm 172 The HOTP algorithm, as defined in [RFC4226] is based on an 173 increasing counter value and a static symmetric key known only to 174 the prover and verifier parties. 176 As a reminder: 178 HOTP(K,C) = Truncate(HMAC-SHA1(K,C)) 179 OCRA: OATH Challenge Response Algorithms December 2007 181 Where Truncate represents the function that converts an HMAC-SHA-1 182 value into an HOTP value. 184 We refer the reader to [RFC4226] for the full description and 185 further details on the rationale and security analysis of HOTP. 187 The present draft describes the different variants based on similar 188 constructions as HOTP. 190 5. Definition of OCRA 192 OCRA is a generalization of HOTP with variable data inputs not 193 solely based on an incremented counter and secret key values. 195 The definition of OCRA requires a cryptographic function, a key K 196 and a set of DataInput parameters. This section first formally 197 introduces the OCRA algorithm and then introduces the definitions 198 and default values recommended for all the parameters. 200 In a nutshell, 201 OCRA = CryptoFunction(K, DataInput) 203 Where: 205 - K: a shared secret key known to both parties; 206 - DataInput: a structure that contains the concatenation of the 207 various input data values. Defined in details in section 5.1; 208 - CryptoFunction: this is the function performing the OCRA 209 computation from the secret key K and DataInput material; 210 CryptoFunction is described in details in section 5.2. 212 5.1 DataInput Parameters 214 This structure is the concatenation of all the parameters used in 215 the computation of the OCRA values, save for the secret key K. 217 DataInput = {C | Q | P | S | T} where: 218 . C is a 8-byte counter value processed high-order bit first, 219 and MUST be synchronized between all parties; 220 . Q is the list of (concatenated) challenge question(s) 221 generated by the verifier(s);the questions SHOULD be L-byte 222 values and MUST be at least t-byte values; 223 . P is a SHA1-hash of PIN/password that is known to all parties 224 during the execution of the algorithm; 225 . S is a string that contains information about the current 226 session; 227 . T is a timestamp value in number of minutes since midnight UTC 228 of January 1, 1970. 230 OCRA: OATH Challenge Response Algorithms December 2007 232 When computing a response, the concatenation order is always the 233 following: 235 C, 236 OTHER-PARTY-GENERATED-CHALLENGE-QUESTION, 237 YOUR-GENERATED-CHALLENGE-QUESTION, 238 P, S and then T values. 240 If a value is empty (i.e. a certain input is not used in the 241 computation) then the value is simply not represented in the 242 string. 244 We always start with C to be compliant and follow the HOPT RFC when 245 all the other values are empty. The counter on the token or client 246 is incremented every time a new computation is requested by the 247 user. The server's counter value is only incremented after a 248 successful OCRA authentication 250 5.2 CryptoFunction 252 The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of 253 computation for OCRA is HOTP with the default 6-digit dynamic 254 truncation and a combination of DataInput values as the message to 255 compute the HMAC-SHA1 digest. 257 We denote t as the digit-length of the truncation output. For 258 instance, if t = 6, then the output of the truncation is a 6-digit 259 value. 261 We define the HOTP family of functions as an extension to HOTP: 262 - HOTP-H-t: these are the different possible truncated versions of 263 HOTP, using the dynamic truncation method for extracting an HOTP 264 value from the HMAC output; 265 - We will denote HOTP-H-t as the realization of an HOTP function 266 that uses an HMAC function with the hash function H, and the 267 dynamic truncation as described in [RFC 4226] to extract a t- 268 digit value; 269 - t=0 means that no truncation is performed and the full HMAC value 270 is used for authentication purpose. 272 We list the following preferred modes of computation, where * 273 denotes the default CryptoFunction: 274 . HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC 275 and a dynamic truncation to a 4-digit value; this mode is not 276 recommended in the general case but can be useful when a very 277 short authentication code is needed by an application; 278 . *HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC 279 and a dynamic truncation to a 6-digit value; 280 OCRA: OATH Challenge Response Algorithms December 2007 282 . HOTP-SHA256-6: HOTP with SHA-256 as the hash function for 283 HMAC and a dynamic truncation to a 6-digit value; 284 . HOTP-SHA512-6: HOTP with SHA-512 as the hash function for 285 HMAC and a dynamic truncation to a 6-digit value; 287 This table summarizes all possible values for the CryptoFunction: 289 Name HMAC Function Used Size of Truncation (t) 290 -------------------------------------------------------------- 291 HOTP-SHA1-t HMAC-SHA1 0 (no truncation), 4-10 292 HOTP-SHA256-t HMAC-SHA256 0 (no truncation), 4-10 293 HOTP-SHA512-t HMAC-SHA512 0 (no truncation), 4-10 295 6. The OCRASuite 297 The following values define the OCRASuite codes used in the 298 description of modes of operation for the OCRA algorithm. 300 An OCRASuite value defines an OCRA suite of operations as supported 301 in the present draft and is represented as follows: 303 Algorithm:CryptoFunction:DataInput 305 The client and server need to agree on one or two values of 306 OCRASuite. These values may be agreed at time of token provisioning 307 or for more sophisticated client-server interactions these values 308 may be negotiated for every transaction. Note that for Mutual 309 Challenge-Response or Signature with Server Authentication modes, 310 the client and server will need to agree on two values of OCRASuite 311 - one for server computation and another for client computation. 313 Algorithm 314 --------- 316 Description: Indicates the version of OCRA algorithm. 317 Values: OCRA-v where v represents the version number (e.g. 1, 2 318 etc.). This document describes version 1 of the OCRA algorithm. 320 CryptoFunction 321 -------------- 323 Description: Indicates the function used to compute OCRA values 324 Values: Permitted values are described in section 5.2 326 DataInput 327 --------- 328 OCRA: OATH Challenge Response Algorithms December 2007 330 Description: List of valid inputs for the computation; [] indicates 331 a value is optional. 332 Values: 333 [C] | Q | [P | S | T]: Challenge-Response computation 334 [C] | Q | [P | T]: Plain Signature computation 336 Example of possible values: OCRA-1:HOTP-SHA512-8:C-Q-P means 337 version 1 of the OCRA algorithm with HMAC-SHA512 function, 338 truncated to an 8-digit value, using the counter, a random 339 challenge and a hash of the PIN/Password as parameters. 341 7. Algorithm Modes for Authentication 343 In this section we describe the typical modes in which the above 344 defined computation can be used for authentication. 346 7.1 One way Challenge-Response 348 A challenge/response is a security mechanism in which the verifier 349 presents a question (challenge) to the prover who must provide a 350 valid answer (response) to be authenticated. 352 To use this algorithm for a one-way challenge-response, the 353 verifier will communicate a challenge value (typically randomly 354 generated) to the prover. The prover will use the challenge in the 355 computation as described above. The prover then communicates the 356 response to the verifier to authenticate. 358 Therefore in this mode, the typical data inputs will be: 360 C - Counter, optional. 361 Q - Challenge question, mandatory, supplied by the verifier. 362 P - Hashed version of PIN/password, optional. 363 S - Session information, optional 364 T - Timestamp, optional. 366 The picture below shows the messages that are exchanged between the 367 client (prover) and the server (verifier) to complete a one-way 368 challenge-response authentication. 370 We assume that the client and server have a pre-shared key K that 371 is used for the computation. 373 OCRA: OATH Challenge Response Algorithms December 2007 375 CLIENT SERVER 376 (PROVER) (VERIFIER) 377 | | 378 | Verifier sends challenge to prover | 379 | Challenge = Q | 380 |<------------------------------------------| 381 | | 382 | Prover Computes Response | 383 | R = OCRA(K, {[C] | Q | [P | S | T]}) | 384 | Response = R | 385 |------------------------------------------>| 386 | | 387 | Verifier Validates Response | 388 | Response = OK | 389 |<------------------------------------------| 390 | | 392 7.2 Mutual Challenge-Response 394 Mutual challenge-response is a variation of one-way challenge- 395 response where both the client and server and mutually authenticate 396 each other. 398 To use this algorithm, the client will first send a random client- 399 challenge to the server. The server computes the server-response 400 and sends it to the client along with a server-challenge. 402 The client will first verify the server-response to authenticate 403 that it is talking to a valid server. It will then compute the 404 client-response and send it to the server to authenticate. The 405 server verifies the client-response to complete the two-way 406 authentication process. 408 In this mode there are two computations: client-response and 409 server-response. There are two separate challenge questions, 410 generated by both parties. We denote these challenge questions Q1 411 and Q2. 413 Typical data inputs for server-response computation will be: 414 C - Counter, optional. 415 QC - Challenge question, mandatory, supplied by the client. 416 QS - Challenge question, mandatory, supplied by the server. 417 S - Session information, optional. 418 T - Timestamp, optional. 420 Typical data inputs for client-response computation will be: 421 C - Counter, optional. 422 QS - Challenge question, mandatory, supplied by the server. 423 QC - Challenge question, mandatory, supplied by the client. 425 OCRA: OATH Challenge Response Algorithms December 2007 427 P - Hashed version of PIN/password, optional. 428 S - Session information, optional. 429 T - Timestamp, optional. 431 The following picture shows the messages that are exchanged between 432 the client and the server to complete a two-way mutual challenge- 433 response authentication. 435 We assume that the client and server have a pre-shared key K that 436 is used for the computation. 438 CLIENT SERVER 439 | | 440 | 1. Client sends client-challenge | 441 | QC = Client-challenge | 442 |-------------------------------------------------->| 443 | | 444 | 2. Server computes server-response | 445 | and sends server-challenge | 446 | RS = OCRA(K, [C] | QC | QS | [S | T]) | 447 | QS = Server-challenge | 448 | Response = RS, QS | 449 |<--------------------------------------------------| 450 | | 451 | 3. Client verifies server-response | 452 | and computes client-response | 453 | OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP | 454 | RC = OCRA(K, [C] | QS | QC | [P | S | T]) | 455 | Response = RC | 456 |-------------------------------------------------->| 457 | | 458 | 4. Server verifies client-response | 459 | OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP | 460 | Response = OK | 461 |<--------------------------------------------------| 462 | | 464 8. Algorithm Modes for Signature 466 In this section we describe the typical modes in which the above 467 defined computation can be used for digital signatures. 469 8.1 Plain Signature 471 To use this algorithm in plain signature mode, the server will 472 communicate a signature-challenge value to the client (signer). The 473 OCRA: OATH Challenge Response Algorithms December 2007 475 signature-challenge is either the data to be signed or derived from 476 the data to be signed using a hash function, for example. 478 The client will use the signature-challenge in the computation as 479 described above. The client then communicates the signature value 480 (response) to the server to authenticate. 482 Therefore in this mode, the data inputs will be: 484 C - Counter, optional. 485 QS - Signature-challenge, mandatory, supplied by the server. 486 P - Hashed version of PIN/password, optional. 487 T - Timestamp, optional. 489 The picture below shows the messages that are exchanged between the 490 client (prover) and the server (verifier) to complete a plain 491 signature operation. 493 We assume that the client and server have a pre-shared key K that 494 is used for the computation. 496 CLIENT SERVER 497 (PROVER) (VERIFIER) 498 | | 499 | Verifier sends signature-challenge | 500 | Challenge = QS | 501 |<------------------------------------------| 502 | | 503 | Client Computes Response | 504 | SIGN = OCRA(K, [C] | QS | [P | T]) | 505 | Response = SIGN | 506 |------------------------------------------>| 507 | | 508 | Verifier Validates Response | 509 | Response = OK | 510 |<------------------------------------------| 511 | | 513 8.2 Signature with Server Authentication 515 This mode is a variation of the plain signature mode where the 516 client can first authenticates the server before generating a 517 digital signature. 519 To use this algorithm, the client will first send a random client- 520 challenge to the server. The server computes the server-response 521 and sends it to the client along with a signature-challenge. The 522 client will first verify the server-response to authenticate that 523 OCRA: OATH Challenge Response Algorithms December 2007 525 it is talking to a valid server. It will then compute the signature 526 and send it to the server. 528 In this mode there are two computations: client-signature and 529 server-response. 531 Typical data inputs for server-response computation will be: 532 C - Counter, optional. 533 QC - Challenge question, mandatory, supplied by the client. 534 T - Timestamp, optional. 536 Typical data inputs for client-signature computation will be: 537 C - Counter, optional. 538 QS - Signature-challenge, mandatory, supplied by the server. 539 P - Hashed version of PIN/password, optional. 540 T - Timestamp, optional. 542 The picture below shows the messages that are exchanged between the 543 client and the server to complete a signature with server 544 authentication transaction. 546 We assume that the client and server have a pre-shared key K that 547 is used for the computation. 549 CLIENT SERVER 550 | | 551 | 1. Client sends client-challenge | 552 | QC = Client-challenge | 553 |-------------------------------------------------->| 554 | | 555 | 2. Server computes server-response | 556 | and sends signature-challenge | 557 | RS = OCRA(K, [C] | QC | QS | [T]) | 558 | QS = signature-challenge | 559 | Response = RS, QS | 560 |<--------------------------------------------------| 561 | | 562 | 3. Client verifies server-response | 563 | and computes signature | 564 | OCRA(K, [C] | QC | QS | [T]) != R1 -> STOP | 565 | SIGN = OCRA( K, [C] | QS | QC | [P | T]) | 566 | Signature = SIGN | 567 |-------------------------------------------------->| 568 | | 569 | 4. Server verifies Signature | 570 | OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP | 571 | Response = OK | 572 |<--------------------------------------------------| 573 | | 574 OCRA: OATH Challenge Response Algorithms December 2007 576 9. Security Considerations 578 Any algorithm is only as secure as the application and the 579 authentication protocols that implement it. Therefore, this section 580 discusses the critical security requirements that our choice of 581 algorithm imposes on the authentication protocol and validation 582 software. 584 9.1 Security Analysis of the OCRA algorithm 586 The security and strength of this algorithm depends on the 587 properties of the underlying building block HOTP, which is a 588 construction based on HMAC [RFC2104] using SHA-1 as the hash 589 function. 591 The conclusion of the security analysis detailed in [RFC4226] is 592 that, for all practical purposes, the outputs of the dynamic 593 truncation on distinct counter inputs are uniformly and 594 independently distributed strings. 596 The analysis demonstrates that the best possible attack against the 597 HOTP function is the brute force attack. 599 9.2 Implementation Considerations 601 S1 - In the authentication mode, the client MUST support two-factor 602 authentication, i.e., the communication and verification of 603 something you know (secret code such as a Password, Pass phrase, 604 PIN code, etc.) and something you have (token). The secret code is 605 known only to the user and usually entered with the Response value 606 for authentication purpose (two-factor authentication). 607 Alternatively, instead of sending something you know to the server, 608 the client may use a hash of the Password or PIN code in the 609 computation itself, thus implicitly enabling two-factor 610 authentication. 612 S2 - The keys for HOTP can be of any length equal or longer than L 613 bytes, where L is the byte-length of the CryptoFunction output. 614 Keys longer than L bytes are acceptable; they are first hashed 615 using the supported hash function, e.g. SHA-1, to become usable. 616 Nevertheless, the extra length would not significantly increase the 617 cryptographic strength of OCRA, provided the randomness of the 618 original key material is sufficient. 620 S3 - Keys need to be chosen at random or using a cryptographically 621 strong pseudo-random generator properly seeded with a random value. 622 We RECOMMEND following the recommendations in [RFC1750] for all 623 pseudo-random and random generations. The pseudo-random numbers 624 OCRA: OATH Challenge Response Algorithms December 2007 626 used for generating the keys SHOULD successfully pass the 627 randomness test specified in [CN]. 629 S4 - On the client side, the keys MUST be embedded in a tamper 630 resistant device or securely implemented in a software application. 631 Additionally, by embedding the keys in a hardware device, you also 632 have the advantage of improving the flexibility (mobility). 634 S5 - For authentication computations, the challenge value MUST be 635 randomly generated and SHALL NOT be re-used. We RECOMMEND following 636 the recommendations in [RFC1750] for all pseudo-random and random 637 generations. 639 S6 - All the communications SHOULD take place over a secure channel 640 e.g. SSL/TLS, IPsec connections. 642 S7 - The OCRA algorithm when used in mutual authentication mode or 643 in signature with server authentication mode SHOULD use dual key 644 mode - i.e. there are two keys that are shared between the client 645 and the server. One shared key is used to generate the server 646 response on the server side and to verify it on the client side. 647 The other key is used to create the response or signature on the 648 client side and to verify the same on the server side. 650 S8 - We recommend that implementations MAY use the session 651 information, S as an additional input in the computation. For 652 example, S could be the session identifier from the TLS session. 653 This will enable you to counter certain types of man-in-the-middle 654 attacks. However, this will introduce the additional dependency 655 that first of all the prover needs to have access to the session 656 identifier to compute the response and the verifier will need 657 access to the session identifier to verify the response. 659 S9 - In the signature mode, whenever the counter or time (defined 660 as optional elements) are not used in the computation, there might 661 be a risk of replay attack and the implementers should carefully 662 consider this issue in the light of their specific application 663 requirements and security guidelines. 665 S10 - We also RECOMMEND storing the shared secrets securely in the 666 validation system, and more specifically encrypting the shared 667 secrets using tamper-resistant hardware encryption and exposing 668 them only when required: for example, the shared secret is 669 decrypted when needed to verify an HOTP value, and re-encrypted 670 immediately to limit exposure in the RAM for a short period of 671 time. The data store holding the shared secrets MUST be in a 672 secure area, to avoid as much as possible direct attack on the 673 validation system and secrets database. 675 OCRA: OATH Challenge Response Algorithms December 2007 677 Particularly, access to the shared secrets should be limited to 678 programs and processes required by the validation system only. We 679 will not elaborate on the different security mechanisms to put in 680 place, but obviously, the protection of shared secrets is of the 681 uttermost importance. 683 10. IANA Considerations 685 This document has no actions for IANA. 687 11. Conclusion 689 This draft introduced several variants of HOTP for challenge- 690 response based authentication and short signature-like 691 computations. 693 The OCRASuite provides for an easy integration and support of 694 different flavors within an authentication and validation system. 696 Finally, OCRA should enable cross-authentication both in connected 697 and off-line modes, with the support of different response sizes 698 and mode of operations. 700 12. Acknowledgements 702 We would like to thank Philip Hoyer, Jonathan Tuliani, Shuh Chang, 703 Stu Vaeth, Jon Martinsson, Jeff Burstein, Frederik Mennes, Oanh 704 Hoang, Mingliang Pei and Enrique Rodriguez for their comments and 705 suggestions to improve this draft document. 707 13. References 709 13.1 Normative 711 [RFC2104] M. Bellare, R. Canetti and H. Krawczyk, "HMAC: 712 Keyed-Hashing for Message Authentication", IETF Network 713 Working Group, RFC 2104, February 1997. 715 [RFC1750] D. Eastlake, 3rd., S. Crocker and J. Schiller, 716 "Randomness Recommendations for Security", IETF Network 717 Working Group, RFC 1750, December 2004. 719 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 720 Requirement Levels", BCP 14, RFC 2119, March 1997. 722 OCRA: OATH Challenge Response Algorithms December 2007 724 [RFC3668] S. Bradner, "Intellectual Property Rights in IETF 725 Technology", BCP 79, RFC 3668, February 2004. 727 [RFC4226] D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and 728 O. Ranen, "HOTP: An HMAC-based One Time Password 729 Algorithm", IETF Network Working Group, RFC 4226, 730 December 2005. 732 13.2 Informative 734 [BCK] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash 735 Functions and Message Authentication", Proceedings of 736 Crypto'96, LNCS Vol. 1109, pp. 1-15. 738 [OATH] Initiative for Open AuTHentication 739 http://www.openauthentication.org 741 [CN] J.S. Coron and D. Naccache, "An accurate evaluation of 742 Maurer's universal test" by Jean-Sebastien Coron and 743 David Naccache In Selected Areas in Cryptography (SAC 744 '98), vol. 1556 of Lecture Notes in Computer Science, 745 S. Tavares and H. Meijer, Eds., pp. 57-71, Springer- 746 Verlag, 1999 748 Appendix A: Source Code 750 import java.lang.reflect.UndeclaredThrowableException; 751 import java.security.GeneralSecurityException; 752 import javax.crypto.Mac; 753 import javax.crypto.spec.SecretKeySpec; 755 /** 756 * This an example implementation of the OATH OCRA algorithm. 757 * Visit www.openauthentication.org for more information. 758 * 759 * @author Johan Rydell, PortWise 760 */ 761 public class OCRA { 762 private OCRA() {} 764 /** 765 * This method uses the JCE to provide the crypto 766 * algorithm. 767 * HMAC computes a Hashed Message Authentication Code with the 768 * crypto hash algorithm as a parameter. 770 OCRA: OATH Challenge Response Algorithms December 2007 772 * 773 * @param crypto the crypto algorithm 774 * (HmacSHA1, HmacSHA256, HmacSHA512) 775 * @param keyBytes the bytes to use for the HMAC key 776 * @param text the message or text to be authenticated. 777 */ 778 public static byte[] hmac_sha1(String crypto, 779 byte[] keyBytes, 780 byte[] text) 781 { 782 try { 783 Mac hmac; 784 hmac = Mac.getInstance(crypto); 785 SecretKeySpec macKey = 786 new SecretKeySpec(keyBytes, "RAW"); 787 hmac.init(macKey); 788 return hmac.doFinal(text); 789 } catch (GeneralSecurityException gse) { 790 throw new UndeclaredThrowableException(gse); 791 } 792 } 794 private static final int[] DIGITS_POWER 795 // 0 1 2 3 4 5 6 7 8 796 = {1,10,100,1000,10000,100000,1000000,10000000,100000000}; 798 /** 799 * This method generates an OCRA HOTP value for the given 800 * set of parameters. 801 * 802 * @param crypto the crypto algorithm 803 * @param key the shared secret 804 * @param movingFactor the counter that changes 805 * on a per use basis 806 * @param question the challenge question 807 * @param password a password that can be used 808 * @param sessionInformation Static information that 809 * identifies the current session 810 * @param timeStamp a value that reflects a time 811 * @param codeDigits number of digits in the OTP 812 * 813 * @return A numeric String in base 10 that includes 814 * {@link truncationDigits} digits 815 */ 816 static public String generateOTP(String crypto, 817 String key, 818 String movingFactor, 819 String question, 820 String password, 821 OCRA: OATH Challenge Response Algorithms December 2007 823 String sessionInformation, 824 String timeStamp, 825 int codeDigits) 826 { 827 String result = null; 828 String messageStr = 829 question + password + 830 sessionInformation + timeStamp ; 831 byte[] msg; 833 // Using the counter 834 if (0 < movingFactor.length()){ 835 // First 8 bytes are for the movingFactor 836 // Complient with RFC 4226 837 messageStr = "00000000" + messageStr; 838 msg = messageStr.getBytes(); 839 long mFactor = Long.decode(movingFactor); 840 for (int i = 7; i >= 0; i--) { 841 msg[i] = (byte) (mFactor & 0xff); 842 mFactor >>= 8; 843 } 844 }else 845 msg = messageStr.getBytes(); 847 // compute hmac hash 848 byte[] hash = hmac_sha1(crypto, key.getBytes(), msg); 850 // put selected bytes into result int 851 int offset = hash[hash.length - 1] & 0xf; 853 int binary = 854 ((hash[offset] & 0x7f) << 24) | 855 ((hash[offset + 1] & 0xff) << 16) | 856 ((hash[offset + 2] & 0xff) << 8) | 857 (hash[offset + 3] & 0xff); 859 int otp = binary % DIGITS_POWER[codeDigits]; 861 result = Integer.toString(otp); 862 while (result.length() < codeDigits) { 863 result = "0" + result; 864 } 865 return result; 866 } 867 } 868 OCRA: OATH Challenge Response Algorithms December 2007 870 Appendix B: Test Vectors 872 Plain challenge response 873 ======================== 875 OCRA-HOTP-SHA1-8-Q 876 ------------------ 877 K = 12345678901234567890 Q = 10000000 OCRA = 57953866 878 K = 12345678901234567890 Q = 10000001 OCRA = 15772773 879 K = 12345678901234567890 Q = 10000002 OCRA = 68105940 881 OCRA-HOTP-SHA256-8-Q 882 -------------------- 883 K = 12345678901234567890 Q = 10000000 OCRA = 79730854 884 K = 12345678901234567890 Q = 10000001 OCRA = 22925447 885 K = 12345678901234567890 Q = 10000002 OCRA = 15947867 887 OCRA-HOTP-SHA512-8-Q 888 -------------------- 889 K = 12345678901234567890 Q = 10000000 OCRA = 68325835 890 K = 12345678901234567890 Q = 10000001 OCRA = 53995836 891 K = 12345678901234567890 Q = 10000002 OCRA = 89008345 893 Mutual challenge response 894 ========================= 896 OCRA-HOTP-SHA512-8-Q 897 -------------------- 898 (From server) K = 12345678901234567890 899 Q1 = 11111110 Q2 = 22222220 OCRA = 70933163 900 (From client) K = 12345678901234567890 901 Q1 = 11111110 Q2 = 22222220 OCRA = 63875222 903 (From server) K = 12345678901234567890 904 Q1 = 11111111 Q2 = 22222221 OCRA = 08364053 905 (From client) K = 12345678901234567890 906 Q1 = 11111111 Q2 = 22222221 OCRA = 91844292 908 (From server) K = 12345678901234567890 909 Q1 = 11111112 Q2 = 22222222 OCRA = 70960179 910 (From client) K = 12345678901234567890 911 Q1 = 11111112 Q2 = 22222222 OCRA = 75789938 912 OCRA: OATH Challenge Response Algorithms December 2007 914 Plain signature 915 =============== 917 OCRA-HOTP-SHA512-8-Q 918 -------------------- 919 K = 12345678901234567890 Q (value) = 00010000 920 OCRA (signature) = 13175449 921 K = 12345678901234567890 Q (value) = 00011000 922 OCRA (signature) = 41866883 923 K = 12345678901234567890 Q (value) = 00012000 924 OCRA (signature) = 82912137 926 14. Authors' Addresses 928 Primary point of contact (for sending comments and question): 930 David M'Raihi 931 VeriSign, Inc. 932 685 E. Middlefield Road Phone: 1-650-426-3832 933 Mountain View, CA 94043 USA Email: dmraihi@verisign.com 935 Other Authors' contact information: 937 Johan Rydell 938 Portwise, Inc. 939 275 Hawthorne Ave, Suite 119 Phone: 1-650-515-3569 940 Palo Alto, CA 94301 USA Email: johan.rydell@portwise.com 942 David Naccache 943 ENS, DI 944 45 rue d'Ulm Phone: +33 6 16 59 83 49 945 75005, Paris France Email: david.naccache@ens.fr 947 Salah Machani 948 Diversinet Corp. 949 2225 Sheppard Avenue East 950 Suite 1801 951 Toronto, Ontario M2J 5C2 Phone: 1-416-756-2324 Ext. 321 952 Canada Email: smachani@diversinet.com 954 Siddharth Bajaj 955 VeriSign, Inc. 956 487 E. Middlefield Road Phone: 1-650-426-3458 957 Mountain View, CA 94043 USA Email: sbajaj@verisign.com 958 OCRA: OATH Challenge Response Algorithms December 2007 960 15. Full Copyright Statement 962 Copyright (C) The IETF Trust (2007). 964 This document is subject to the rights, licenses and restrictions 965 contained in BCP 78, and except as set forth therein, the authors 966 retain all their rights. 968 This document and the information contained herein are provided on 969 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 970 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 971 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 972 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 973 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 974 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 975 FOR A PARTICULAR PURPOSE. 977 16. Intellectual Property 979 The IETF takes no position regarding the validity or scope of any 980 Intellectual Property Rights or other rights that might be claimed 981 to pertain to the implementation or use of the technology described 982 in this document or the extent to which any license under such 983 rights might or might not be available; nor does it represent that 984 it has made any independent effort to identify any such rights. 985 Information on the procedures with respect to rights in RFC 986 documents can be found in BCP 78 and BCP 79. 988 Copies of IPR disclosures made to the IETF Secretariat and any 989 assurances of licenses to be made available, or the result of an 990 attempt made to obtain a general license or permission for the use 991 of such proprietary rights by implementers or users of this 992 specification can be obtained from the IETF on-line IPR repository 993 at http://www.ietf.org/ipr. 995 The IETF invites any interested party to bring to its attention any 996 copyrights, patents or patent applications, or other proprietary 997 rights that may cover technology that may be required to implement 998 this standard. Please address the information to the IETF at ietf- 999 ipr@ietf.org.