idnits 2.17.1 draft-mraihi-mutual-oath-hotp-variants-04.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 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1056. 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], [P], [RFC2104], [C,S,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 790 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 (October 2006) is 6395 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 744 looks like a reference -- Missing reference section? 'OATH' on line 755 looks like a reference -- Missing reference section? 'RFC2119' on line 738 looks like a reference -- Missing reference section? 'RFC 4226' on line 274 looks like a reference -- Missing reference section? 'P' on line 427 looks like a reference -- Missing reference section? 'RFC2104' on line 730 looks like a reference -- Missing reference section? 'RFC1750' on line 734 looks like a reference -- Missing reference section? 'CN' on line 758 looks like a reference -- Missing reference section? 'RFC3668' on line 741 looks like a reference -- Missing reference section? 'BCK' on line 751 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 18 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-04.txt ENS 8 Salah Machani 9 Diversinet 10 Siddharth Bajaj 11 VeriSign 12 Expires: 13 April 2007 October 2006 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 September 2006 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 4.2 OCRA Algorithm.............................................5 58 5. Definition of OCRA.........................................5 59 5.1 DataInput Parameters........................................6 60 5.2 CryptoFunction..............................................6 61 6. The OCRASuite..............................................7 62 7. Algorithm Modes for Authentication.........................8 63 7.1. One way Challenge-Response.................................8 64 7.2. Response Only (OTP) Mode...................................9 65 7.3. Mutual Challenge-Response.................................10 66 8. Algorithm Modes for Signature.............................11 67 8.1 Plain Signature...........................................11 68 8.2 Signature with Server Authentication......................12 69 9. Security Considerations...................................14 70 9.1 Security Analysis of the OCRA algorithm....................14 71 9.2 Implementation Considerations..............................14 72 10. IANA Considerations.......................................15 73 11. Conclusion................................................15 74 12. Acknowledgements..........................................16 75 13. References................................................16 76 13.1. Normative................................................16 77 13.2. Informative..............................................16 78 Appendix A: Code Source........................................17 79 Appendix B: Test Vectors.......................................19 80 14. Authors' Addresses........................................21 81 15. Full Copyright Statement..................................22 82 16. Intellectual Property.....................................22 83 OCRA: OATH Challenge Response Algorithms September 2006 85 1. Introduction 87 OATH has identified several use cases and scenarios that require an 88 asynchronous variant to accommodate users who do not want to 89 maintain a synchronized authentication system. The commonly 90 accepted method for this is to use a challenge-response scheme. 92 Such challenge response mode of authentication is widely adopted in 93 the industry. Several vendors already offer software applications 94 and hardware devices implementing challenge-response - but each of 95 those uses vendor-specific proprietary algorithms. For the benefits 96 of users we need a standardized challenge-response algorithm to 97 allow multi-sourcing of token purchases and validation systems to 98 facilitate the democratization of strong authentication. 99 Additionally, this specification can also be used to create 100 symmetric key based digital signatures. Such systems are variants 101 of challenge-response mode where the data to be signed becomes the 102 challenge. 104 2. Requirements Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 108 this document are to be interpreted as described in RFC 2119 109 [RFC2119]. 111 3. Algorithm Requirements 113 This section presents the main requirements that drove this 114 algorithm design. A lot of emphasis was placed on flexibility and 115 usability, under the constraints and specificity of the HOTP 116 algorithm and hardware token capabilities. 118 R1 - The algorithm MUST support asynchronous challenge-response 119 based authentication. 121 R2 - The algorithm MUST be capable of supporting symmetric key 122 based digital signatures. Essentially this is a variation of 123 challenge-response where the challenge is derived from the data 124 that needs to be signed. 126 R3 - The algorithm MUST be capable of supporting server- 127 authentication, whereby the user can verify that he/she is talking 128 to a valid server. 130 R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building 131 block. 133 OCRA: OATH Challenge Response Algorithms September 2006 135 R5 - The length and format for the input challenge SHOULD be 136 configurable. 138 R6 - The output length and format for the response SHOULD be 139 configurable. 141 R7 - The challenge MAY be generated with integrity checking (e.g., 142 parity bits). This will allow tokens with pin pads to perform 143 simple error checking if the user enters the value into a token. 145 R8 - There MUST be a fixed randomly generated secret (key) for each 146 token/soft token that is shared between the token and the 147 authentication server. 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 This section summarizes the HOTP algorithm and then, formally 171 introduces the OCRA algorithm. 173 4.1 HOTP Algorithm 175 The HOTP algorithm, as defined in [RFC4226] is based on an 176 increasing counter value and a static symmetric key known only to 177 the prover and verifier parties. 179 As a reminder: 181 HOTP(K,C) = Truncate(HMAC-SHA1(K,C)) 182 OCRA: OATH Challenge Response Algorithms September 2006 184 Where Truncate represents the function that converts an HMAC-SHA-1 185 value into an HOTP value. 187 The Key (K), the Counter (C) and Data values are hashed high-order 188 byte first. The HOTP values generated by the HOTP generator are 189 treated as big endian. 191 We refer the reader to [RFC4226] for the full description and 192 further details on the rationale and security analysis of HOTP. 194 The present draft describes the different variants based on similar 195 constructions as HOTP. 197 4.2 OCRA Algorithm 199 In a nutshell, OCRA is a generalization of HOTP with variable data 200 inputs not solely based on an incremented counter and secret key 201 values. 203 OCRA = CryptoFunction(K, DataInput) 205 Where: 207 - K: a shared secret key known to both parties; 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; 211 - DataInput: a structure that contains the concatenation of the 212 various input data values. Defined in details in section 5.1. 214 5. Definition of OCRA 216 The definition of OCRA requires a cryptographic function, a key K 217 and a set of DataInput parameters. This section introduces these 218 definitions and default value recommended for all the parameters. 220 We denote L as the byte-length of the CryptoFunction output. For 221 instance, if CryptoFunction was SHA-1, then L = 20. 223 We denote B as the byte-length of the blocks manipulated by the 224 core function internally. For instance if CryptoFunction was HMAC- 225 SHA-1, then B = 64 since SHA-1 manipulates 64-byte blocks. 227 We denote t as the byte-length of the truncation output. For 228 instance, if t = 6, then the output of the truncation is a 6-byte 229 value. 231 OCRA: OATH Challenge Response Algorithms September 2006 233 5.1 DataInput Parameters 235 This structure is the concatenation of all the parameters used in 236 the computation of the OCRA values, save for the secret key K. 238 DataInput = {Q | C | P | S | T} where: 239 . Q is the list of (concatenated) challenge question(s) 240 generated by the verifier(s);the questions SHOULD be L-byte 241 values and MUST be at least t-byte values; 242 . C is a 8-byte counter value processed high-order bit first, 243 and MUST be synchronized between all parties; 244 . P is a SHA1-hash of PIN/password that is known to all parties 245 during the execution of the algorithm; 246 . S is a string that contains information about the current 247 session; 248 . T is a timestamp value, UTC formatted. 250 When computing a response, the concatenation order is always the 251 following: 253 OTHER-PARTY-GENERATED-CHALLENGE-QUESTION 254 YOUR-GENERATED-CHALLENGE-QUESTION 255 C, P, S and then T values. 257 If a value is empty (i.e. a certain input is not used in the 258 computation) then the value is simply not represented in the 259 string. 261 5.2 CryptoFunction 263 The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of 264 computation for OCRA is HOTP with the default 6-digit dynamic 265 truncation and a combination of DataInput values as the message to 266 compute the HMAC-SHA1 digest. 268 We define the HOTP family of functions as an extension to HOTP: 269 - HOTP-H-t: these are the different possible truncated versions of 270 HOTP, using the dynamic truncation method for extracting an HOTP 271 value from the HMAC output; 272 - We will denote HOTP-H-t as the realization of an HOTP function 273 that uses an HMAC function with the hash function H, and the 274 dynamic truncation as described in [RFC 4226] to extract a t-byte 275 value; 276 - t=0 means that no truncation is performed and the full HMAC value 277 is used for authentication purpose. 279 OCRA: OATH Challenge Response Algorithms September 2006 281 We list the following preferred modes of computation, where * 282 denotes the default CryptoFunction: 283 . HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC 284 and a dynamic truncation to a 4-digit value; this mode is not 285 recommended in the general case but can be useful when a very 286 short authentication code is needed by an application; 287 . *HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC 288 and a dynamic truncation to a 6-digit value; 289 . HOTP-SHA256-6: HOTP with SHA-1 as the hash function for HMAC 290 and a dynamic truncation to a 6-digit value; 291 . HOTP-SHA512-6: HOTP with SHA-1 as the hash function for HMAC 292 and a dynamic truncation to a 6-digit value; 294 This table summarizes all possible values for the CryptoFunction: 296 Name HMAC Function Used Size of Truncation (t) 297 -------------------------------------------------------------- 298 HOTP-SHA1-t HMAC-SHA1 0 (no truncation), 4-10 299 HOTP-SHA256-t HMAC-SHA256 0 (no truncation), 4-10 300 HOTP-SHA512-t HMAC-SHA512 0 (no truncation), 4-10 302 6. The OCRASuite 304 The following values define the OcraSuite codes used in the 305 description of modes of operation for the OCRA algorithm. 307 An OCRASuite value defines an OCRA suite of operations as supported 308 in the present draft and is represented as follows: 310 Algorithm-CryptoFunction-DataInput 312 Algorithm 313 --------- 315 Description: Indicates the OCRA algorithm (possibly authenticated) 316 Values: String MUST contains OCRA and optionally, the OCRA computed 317 value of the string 319 CryptoFunction 320 -------------- 322 Description: Indicated the function used to compute OCRA values 323 Values: As described in previous section; other values COULD be 324 added in the future 325 OCRA: OATH Challenge Response Algorithms September 2006 327 DataInput 328 --------- 330 Description: List of valid inputs for the computation; [] indicates 331 a value is optional. 332 Values: 333 Q | [C | P | S | T]: Challenge-Response computation 334 C | [P]: Response-only (OTP) computation 335 Q | [C | P | T]: Plain Signature computation 337 Example of possible values: OCRA-HOTP-SHA512-8-C-P-Q means OCRA 338 algorithm with HMAC-SHA512 function, truncated to an 8-digit value, 339 using the counter, hash of the PIN/Password and a random challenge 340 as parameter, the other party MUST check the value received before 341 computing and sending his response. 343 7. Algorithm Modes for Authentication 345 In this section we describe the typical modes in which the above 346 defined computation can be used for authentication. 348 7.1. One way Challenge-Response 350 A challenge/response is a security mechanism in which the verifier 351 presents a question (challenge) to the prover who must provide a 352 valid answer (response) to be authenticated. 354 To use this algorithm for a one-way challenge-response, the 355 verifier will communicate a challenge value (typically randomly 356 generated) to the prover. The prover will use the challenge in the 357 computation as described above. The prover then communicates the 358 response to the verifier to authenticate. 360 Therefore in this mode, the typical data inputs will be: 362 Q - Challenge question, mandatory, supplied by the verifier. 363 C - Counter, optional. 364 P - Hashed version of PIN/password, optional. 365 S - Session information, optional 366 T - Timestamp, optional. 368 The picture below shows the messages that are exchanged between the 369 client (prover) and the server (verifier) to complete a one-way 370 challenge-response authentication. 372 We assume that the client and server have a pre-shared key K that 373 is used for the computation. 375 OCRA: OATH Challenge Response Algorithms September 2006 377 CLIENT SERVER 378 (PROVER) (VERIFIER) 379 | | 380 | Verifier sends challenge to prover | 381 | Challenge = Q | 382 |<------------------------------------------| 383 | | 384 | Prover Computes Response | 385 | R = OCRA(K, {Q| [C | P | S | T]}) | 386 | Response = R | 387 |------------------------------------------>| 388 | | 389 | Verifier Validates Response | 390 | Response = OK | 391 |<------------------------------------------| 392 | | 394 7.2. Response Only (OTP) Mode 396 Response Only mode is a variation of one-way challenge-response 397 where the challenge is implicitly derived. 399 In order to implicitly derive the challenge, the verifier and the 400 prover need to maintain a moving factor that is synchronized. 401 Commonly used moving factors include a counter, time or combination 402 of both. 404 To use this algorithm, the prover will use the implicit challenge 405 in the computation as described above. The prover then communicates 406 the response to the verifier to authenticate. 408 Therefore in this mode, the data inputs will be: 410 C - Counter mandatory. 411 P - Hashed version of PIN/password, optional. 413 The picture below shows the messages that are exchanged between the 414 client (prover) and the server (verifier) to complete a response 415 only authentication. 417 We assume that the client and server have a pre-shared key K that 418 is used for the computation. 420 OCRA: OATH Challenge Response Algorithms September 2006 422 CLIENT SERVER 423 (PROVER) (VERIFIER) 424 | | 425 | | 426 | Prover Computes Response | 427 | R = OCRA(K, C | [P]) | 428 | Response = R | 429 |------------------------------------------>| 430 | | 431 | Verifier Validates Response | 432 | Response = OK | 433 |<------------------------------------------| 434 | | 436 7.3. Mutual Challenge-Response 438 Mutual challenge-response is a variation of one-way challenge- 439 response where both the client and server and mutually authenticate 440 each other. 442 To use this algorithm, the client will first send a random client- 443 challenge to the server. The server computes the server-response 444 and sends it to the client along with a server-challenge. 446 The client will first verify the server-response to authenticate 447 that it is talking to a valid server. It will then compute the 448 client-response and send it to the server to authenticate. The 449 server verifies the client-response to complete the two-way 450 authentication process. 452 In this mode there are two computations: client-response and 453 server-response. There are two separate challenge questions, 454 generated by both parties. We denote these challenge questions Q1 455 and Q2. 457 Typical data inputs for server-response computation will be: 458 Q1 - Challenge question, mandatory, supplied by the client. 459 Q2 - Challenge question, mandatory, supplied by the server. 460 C - Counter, optional. 461 S - Session information, optional. 462 T - Timestamp, optional. 464 Typical data inputs for client-response computation will be: 465 Q2 - Challenge question, mandatory, supplied by the server. 466 Q1 - Challenge question, mandatory, supplied by the client. 467 C - Counter, optional. 468 P - Hashed version of PIN/password, optional. 469 S - Session information, optional. 470 T - Timestamp, optional. 472 OCRA: OATH Challenge Response Algorithms September 2006 474 The following picture shows the messages that are exchanged between 475 the client and the server to complete a two-way mutual challenge- 476 response authentication. 478 We assume that the client and server have a pre-shared key K that 479 is used for the computation. 481 CLIENT SERVER 482 | | 483 | 1. Client sends client-challenge | 484 | Q1 = Client-challenge | 485 |------------------------------------------>| 486 | | 487 | 2. Server computes server-response | 488 | and sends server-challenge | 489 | R1 = OCRA(K, Q1 | Q2 | [C | S | T]) | 490 | Q2 = Server-challenge | 491 | Response = R1, Q2 | 492 |<------------------------------------------| 493 | | 494 | 3. Client verifies server-response | 495 | and computes client-response | 496 | OCRA(K, Q1, Q2,[C,S,T]) != R1 -> STOP | 497 | R2 = ORCA( K,Q2 | Q1 | [C | P | S | T])| 498 | Response = R2 | 499 |------------------------------------------>| 500 | | 501 | 4. Server verifies client-response | 502 | OCRA(K, Q2|Q1|[C|P|S|T]) != R2 -> STOP | 503 | Response = OK | 504 |<------------------------------------------| 505 | | 507 8. Algorithm Modes for Signature 509 In this section we describe the typical modes in which the above 510 defined computation can be used for digital signatures. 512 8.1 Plain Signature 514 To use this algorithm in plain signature mode, the server will 515 communicate a signature-challenge value to the client (signer). The 516 signature-challenge is either the data to be signed or derived from 517 the data to be signed using a hash function, for example. 519 OCRA: OATH Challenge Response Algorithms September 2006 521 The client will use the signature-challenge in the computation as 522 described above. The client then communicates the signature value 523 (response) to the server to authenticate. 525 Therefore in this mode, the data inputs will be: 527 Q - Signature-challenge, mandatory, supplied by the server. 528 C - Counter, optional. 529 P - Hashed version of PIN/password, optional. 530 T - Timestamp, optional. 532 The picture below shows the messages that are exchanged between the 533 client (prover) and the server (verifier) to complete a plain 534 signature operation. 536 We assume that the client and server have a pre-shared key K that 537 is used for the computation. 539 CLIENT SERVER 540 (PROVER) (VERIFIER) 541 | | 542 | Verifier sends signature-challenge | 543 | Challenge = Q | 544 |<------------------------------------------| 545 | | 546 | Client Computes Response | 547 | SIGN = OCRA(K, Q | [C | P | T]) | 548 | Response = SIGN | 549 |------------------------------------------>| 550 | | 551 | Verifier Validates Response | 552 | Response = OK | 553 |<------------------------------------------| 554 | | 556 8.2 Signature with Server Authentication 558 This mode is a variation of the plain signature mode where the 559 client can first authenticate that it is talking to a valid server 560 before creating a digital signature. 562 To use this algorithm, the client will first send a random client- 563 challenge to the server. The server computes the server-response 564 and sends it to the client along with a signature-challenge. The 565 client will first verify the server-response to authenticate that 566 it is talking to a valid server. It will then compute the signature 567 and send it to the server. 569 OCRA: OATH Challenge Response Algorithms September 2006 571 In this mode there are two computations: client-signature and 572 server-response. 574 Typical data inputs for server-response computation will be: 575 Q - Challenge question, mandatory, supplied by the client. 576 C - Counter, optional. 577 T - Timestamp, optional. 579 Typical data inputs for client-signature computation will be: 580 Q - Signature-challenge, mandatory, supplied by the server. 581 P - Hashed version of PIN/password, optional. 582 C - Counter, optional. 583 T - Timestamp, optional. 585 The picture below shows the messages that are exchanged between the 586 client and the server to complete a signature with server 587 authentication transaction. 589 We assume that the client and server have a pre-shared key K that 590 is used for the computation. 592 CLIENT SERVER 593 | | 594 | 1. Client sends client-challenge | 595 | Q1 = Client-challenge | 596 |------------------------------------------>| 597 | | 598 | 2. Server computes server-response | 599 | and sends signature-challenge | 600 | R1 = OCRA(K, Q1 | Q2 | [C | T]) | 601 | Q2 = signature-challenge | 602 | Response = R1, Q2 | 603 |<------------------------------------------| 604 | | 605 | 3. Client verifies server-response | 606 | and computes signature | 607 | OCRA(K, Q1 | [T | C]) != R1 -> STOP | 608 | R2 = ORCA( K, Q2 | Q1 | [C | P | T]) | 609 | Signature = R2 | 610 |------------------------------------------>| 611 | | 612 | 4. Server verifies Signature | 613 | OCRA(K, Q2|Q1| [C|P|T]) != R2 -> STOP | 614 | Response = OK | 615 |<------------------------------------------| 616 | | 617 OCRA: OATH Challenge Response Algorithms September 2006 619 9. Security Considerations 621 Any algorithm is only as secure as the application and the 622 authentication protocols that implement it. Therefore, this section 623 discusses the critical security requirements that our choice of 624 algorithm imposes on the authentication protocol and validation 625 software. 627 9.1 Security Analysis of the OCRA algorithm 629 The security and strength of this algorithm depends on the 630 properties of the underlying building block HOTP, which is a 631 construction based on HMAC [RFC2104] using SHA-1 as the hash 632 function. 634 The conclusion of the security analysis detailed in [RFC4226] is 635 that, for all practical purposes, the outputs of the dynamic 636 truncation on distinct counter inputs are uniformly and 637 independently distributed strings. 639 The analysis demonstrates that the best possible attack against the 640 HOTP function is the brute force attack. 642 9.2 Implementation Considerations 644 In the authentication mode, the client MUST support two-factor 645 authentication, i.e., the communication and verification of 646 something you know (secret code such as a Password, Pass phrase, 647 PIN code, etc.) and something you have (token). The secret code is 648 known only to the user and usually entered with the Response value 649 for authentication purpose (two-factor authentication). 650 Alternatively, instead of sending something you know to the server, 651 the client may use a hash of the Password or PIN code in the 652 computation itself, thus implicitly enabling two-factor 653 authentication. 655 The keys for HOTP can be of any length equal or longer than L 656 bytes. Keys longer than L bytes are acceptable; they are first 657 hashed using the supported hash function, e.g. SHA-1, to become 658 usable. Nevertheless, the extra length would not significantly 659 increase the cryptographic strength of OCRA, provided the 660 randomness of the original key material is sufficient. 662 Keys need to be chosen at random or using a cryptographically 663 strong pseudo-random generator properly seeded with a random value. 664 We RECOMMEND following the recommendations in [RFC1750] for all 665 pseudo-random and random generations. The pseudo-random numbers 666 used for generating the keys SHOULD successfully pass the 667 randomness test specified in [CN]. 669 OCRA: OATH Challenge Response Algorithms September 2006 671 The keys MUST be embedded in a tamper resistance device or securely 672 implemented in a software application. Additionally, by embedding 673 the keys in a hardware device, you also have the advantage of 674 improving the flexibility (mobility). 676 The challenge value MUST be randomly generated for each use of the 677 authentication protocol and SHALL NOT be re-used. We RECOMMEND 678 following the recommendations in [RFC1750] for all pseudo-random 679 and random generations. 681 All the communications SHOULD take place over a secure channel e.g. 682 SSL/TLS, IPsec connections. 684 The OCRA algorithm when used in mutual authentication mode or in 685 signature with server authentication mode SHOULD use dual key mode 686 - i.e. there are two keys that are shared between the client and 687 the server. One shared key is used to generate the server response 688 on the server side and to verify it on the client side. The other 689 key is used to create the response or signature on the client side 690 and to verify the same on the server side. 692 We recommend that implementations MAY use the session information, 693 S as an additional input in the computation. For example, S could 694 be the session identifier from the TLS session. This will enable 695 you to counter certain types of man-in-the-middle attacks. However, 696 this will introduce the additional dependency that first of all the 697 prover needs to have access to the session identifier to compute 698 the response and the verifier will need access to the session 699 identifier to verify the response. 701 10. IANA Considerations 703 This document has no actions for IANA. 705 11. Conclusion 707 This draft introduced several variants of HOTP for challenge- 708 response based authentication and short signature-like 709 computations. 711 The OCRASuite provides for an easy integration and support of 712 different flavors within an authentication and validation system. 714 Finally, OCRA should enable cross-authentication both in connected 715 and off-line modes, with the support of different response sizes 716 and mode of operations. 718 OCRA: OATH Challenge Response Algorithms September 2006 720 12. Acknowledgements 722 We would like to thank Philip Hoyer, Jon Martinsson, Frederik 723 Mennes and Stu Vaeth for their comments and suggestions to improve 724 this draft document. 726 13. References 728 13.1. Normative 730 [RFC2104] M. Bellare, R. Canetti and H. Krawczyk, "HMAC: 731 Keyed-Hashing for Message Authentication", IETF Network 732 Working Group, RFC 2104, February 1997. 734 [RFC1750] D. Eastlake, 3rd., S. Crocker and J. Schiller, 735 "Randomness Recommendations for Security", IETF Network 736 Working Group, RFC 1750, December 2004. 738 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 [RFC3668] S. Bradner, "Intellectual Property Rights in IETF 742 Technology", BCP 79, RFC 3668, February 2004. 744 [RFC4226] D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and 745 O. Ranen, "HOTP: An HMAC-based One Time Password 746 Algorithm", IETF Network Working Group, RFC 4226, 747 December 2005. 749 13.2. Informative 751 [BCK] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash 752 Functions and Message Authentication", Proceedings of 753 Crypto'96, LNCS Vol. 1109, pp. 1-15. 755 [OATH] Initiative for Open AuTHentication 756 http://www.openauthentication.org 758 [CN] J.S. Coron and D. Naccache, "An accurate evaluation of 759 Maurer's universal test" by Jean-Sebastien Coron and 760 David Naccache In Selected Areas in Cryptography (SAC 761 '98), vol. 1556 of Lecture Notes in Computer Science, 762 S. Tavares and H. Meijer, Eds., pp. 57-71, Springer- 763 Verlag, 1999 764 OCRA: OATH Challenge Response Algorithms September 2006 766 Appendix A: Code Source 768 import java.lang.reflect.UndeclaredThrowableException; 769 import java.security.GeneralSecurityException; 770 import javax.crypto.Mac; 771 import javax.crypto.spec.SecretKeySpec; 773 /** 774 * This an example implementation of the OATH OCRA algorithm. 775 * Visit www.openauthentication.org for more information. 776 * 777 * @author Johan Rydell, PortWise 778 */ 779 public class OCRA { 780 private OCRA() {} 782 /** 783 * This method uses the JCE to provide the crypto 784 * algorithm. 785 * HMAC computes a Hashed Message Authentication Code with the 786 * crypto hash algorithm as a parameter. 787 * 788 * @param crypto the crypto algorithm 789 * (HmacSHA1, HmacSHA256, HmacSHA512) 790 * @param keyBytes the bytes to use for the HMAC key 791 * @param text the message or text to be authenticated. 792 */ 793 public static byte[] hmac_sha1(String crypto, 794 byte[] keyBytes, 795 byte[] text) 796 { 797 try { 798 Mac hmac; 799 hmac = Mac.getInstance(crypto); 800 SecretKeySpec macKey = 801 new SecretKeySpec(keyBytes, "RAW"); 802 hmac.init(macKey); 803 return hmac.doFinal(text); 804 } catch (GeneralSecurityException gse) { 805 throw new UndeclaredThrowableException(gse); 806 } 807 } 809 private static final int[] DIGITS_POWER 810 // 0 1 2 3 4 5 6 7 8 811 = {1,10,100,1000,10000,100000,1000000,10000000,100000000}; 813 /** 814 * This method generates an OCRA HOTP value for the given 815 OCRA: OATH Challenge Response Algorithms September 2006 817 * set of parameters. 818 * 819 * @param crypto the crypto algorithm 820 * @param key the shared secret 821 * @param movingFactor the counter that changes 822 * on a per use basis 823 * @param question the challenge question 824 * @param password a password that can be used 825 * @param sessionInformation Static information that 826 * identifies the current session 827 * @param timeStamp a value that reflects a time 828 * @param codeDigits number of digits in the OTP 829 * 830 * @return A numeric String in base 10 that includes 831 * {@link truncationDigits} digits 832 */ 833 static public String generateOTP(String crypto, 834 String key, 835 String movingFactor, 836 String question, 837 String password, 838 String sessionInformation, 839 String timeStamp, 840 int codeDigits) 841 { 842 String result = null; 843 String messageStr = 844 question + password + 845 sessionInformation + timeStamp ; 846 byte[] msg; 848 // Using the counter 849 if (0 < movingFactor.length()){ 850 // First 8 bytes are for the movingFactor 851 // Complient with RFC 4226 852 messageStr = "00000000" + messageStr; 853 msg = messageStr.getBytes(); 854 long mFactor = Long.decode(movingFactor); 855 for (int i = 7; i >= 0; i--) { 856 msg[i] = (byte) (mFactor & 0xff); 857 mFactor >>= 8; 858 } 859 }else 860 msg = messageStr.getBytes(); 862 // compute hmac hash 863 byte[] hash = hmac_sha1(crypto, key.getBytes(), msg); 865 // put selected bytes into result int 866 OCRA: OATH Challenge Response Algorithms September 2006 868 int offset = hash[hash.length - 1] & 0xf; 870 int binary = 871 ((hash[offset] & 0x7f) << 24) | 872 ((hash[offset + 1] & 0xff) << 16) | 873 ((hash[offset + 2] & 0xff) << 8) | 874 (hash[offset + 3] & 0xff); 876 int otp = binary % DIGITS_POWER[codeDigits]; 878 result = Integer.toString(otp); 879 while (result.length() < codeDigits) { 880 result = "0" + result; 881 } 882 return result; 883 } 884 } 886 Appendix B: Test Vectors 888 Plain challenge response 889 ======================== 891 OCRA-HOTP-SHA1-8-Q 892 ------------------ 893 K = 12345678901234567890 Q = 10000000 OCRA = 57953866 894 K = 12345678901234567890 Q = 10000001 OCRA = 15772773 895 K = 12345678901234567890 Q = 10000002 OCRA = 68105940 897 OCRA-HOTP-SHA256-8-Q 898 -------------------- 899 K = 12345678901234567890 Q = 10000000 OCRA = 79730854 900 K = 12345678901234567890 Q = 10000001 OCRA = 22925447 901 K = 12345678901234567890 Q = 10000002 OCRA = 15947867 903 OCRA-HOTP-SHA512-8-Q 904 -------------------- 905 K = 12345678901234567890 Q = 10000000 OCRA = 68325835 906 K = 12345678901234567890 Q = 10000001 OCRA = 53995836 907 K = 12345678901234567890 Q = 10000002 OCRA = 89008345 909 Response Only 910 ============= 912 OCRA-HOTP-SHA1-6-C 913 ------------------ 914 K = 12345678901234567890 C = 0 OCRA = 755224 915 K = 12345678901234567890 C = 1 OCRA = 287082 916 K = 12345678901234567890 C = 2 OCRA = 359152 917 OCRA: OATH Challenge Response Algorithms September 2006 919 OCRA-HOTP-SHA256-6-C 920 -------------------- 921 K = 12345678901234567890 C = 0 OCRA = 875740 922 K = 12345678901234567890 C = 1 OCRA = 247374 923 K = 12345678901234567890 C = 2 OCRA = 254785 925 OCRA-HOTP-SHA512-6-C 926 -------------------- 927 K = 12345678901234567890 C = 0 OCRA = 125165 928 K = 12345678901234567890 C = 1 OCRA = 342147 929 K = 12345678901234567890 C = 2 OCRA = 730102 931 OCRA-HOTP-SHA1-6-C-P 932 -------------------- 933 K = 12345678901234567890 C = 0 P = 12341234 OCRA = 106753 934 K = 12345678901234567890 C = 1 P = 12341234 OCRA = 747071 935 K = 12345678901234567890 C = 2 P = 12341234 OCRA = 714367 937 OCRA-HOTP-SHA256-6-C-P 938 ---------------------- 939 K = 12345678901234567890 C = 0 P = 12341234 OCRA = 744059 940 K = 12345678901234567890 C = 1 P = 12341234 OCRA = 735947 941 K = 12345678901234567890 C = 2 P = 12341234 OCRA = 167188 943 OCRA-HOTP-SHA512-6-C-P 944 ---------------------- 945 K = 12345678901234567890 C = 0 P = 12341234 OCRA = 249058 946 K = 12345678901234567890 C = 1 P = 12341234 OCRA = 738728 947 K = 12345678901234567890 C = 2 P = 12341234 OCRA = 556127 949 Mutual challenge response 950 ========================= 952 OCRA-HOTP-SHA512-8-Q 953 -------------------- 954 (From server) K = 12345678901234567890 955 Q1 = 11111110 Q2 = 22222220 OCRA = 70933163 956 (From client) K = 12345678901234567890 957 Q1 = 11111110 Q2 = 22222220 OCRA = 63875222 959 (From server) K = 12345678901234567890 960 Q1 = 11111111 Q2 = 22222221 OCRA = 08364053 961 (From client) K = 12345678901234567890 962 Q1 = 11111111 Q2 = 22222221 OCRA = 91844292 964 (From server) K = 12345678901234567890 965 Q1 = 11111112 Q2 = 22222222 OCRA = 70960179 966 OCRA: OATH Challenge Response Algorithms September 2006 968 (From client) K = 12345678901234567890 969 Q1 = 11111112 Q2 = 22222222 OCRA = 75789938 971 Plain signature 972 =============== 974 OCRA-HOTP-SHA512-8-Q 975 -------------------- 976 K = 12345678901234567890 Q (value) = 00010000 977 OCRA (signature) = 13175449 978 K = 12345678901234567890 Q (value) = 00011000 979 OCRA (signature) = 41866883 980 K = 12345678901234567890 Q (value) = 00012000 981 OCRA (signature) = 82912137 983 14. Authors' Addresses 985 Primary point of contact (for sending comments and question): 987 David M'Raihi 988 VeriSign, Inc. 989 685 E. Middlefield Road Phone: 1-650-426-3832 990 Mountain View, CA 94043 USA Email: dmraihi@verisign.com 992 Other Authors' contact information: 994 Johan Rydell 995 Portwise, Inc. 996 624 Ellis Street, Suite 102 Phone: 1-650-515-3569 997 Mountain View, CA 94043 USA Email: johan.rydell@portwise.com 999 David Naccache 1000 ENS, DI 1001 45 rue d'Ulm Phone: +33 6 16 59 83 49 1002 75005, Paris France Email: david.naccache@ens.fr 1004 Salah Machani 1005 Diversinet Corp. 1006 2225 Sheppard Avenue East 1007 Suite 1801 1008 Toronto, Ontario M2J 5C2 Phone: 1-416-756-2324 Ext. 321 1009 Canada Email: smachani@diversinet.com 1011 Siddharth Bajaj 1012 VeriSign, Inc. 1013 487 E. Middlefield Road Phone: 1-650-426-3458 1014 Mountain View, CA 94043 USA Email: sbajaj@verisign.com 1015 OCRA: OATH Challenge Response Algorithms September 2006 1017 15. Full Copyright Statement 1019 Copyright (C) The IETF Trust (2006). 1021 This document is subject to the rights, licenses and restrictions 1022 contained in BCP 78, and except as set forth therein, the authors 1023 retain all their rights. 1025 This document and the information contained herein are provided on 1026 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1027 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1028 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1029 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1030 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1031 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1032 FOR A PARTICULAR PURPOSE. 1034 16. Intellectual Property 1036 The IETF takes no position regarding the validity or scope of any 1037 Intellectual Property Rights or other rights that might be claimed 1038 to pertain to the implementation or use of the technology described 1039 in this document or the extent to which any license under such 1040 rights might or might not be available; nor does it represent that 1041 it has made any independent effort to identify any such rights. 1042 Information on the procedures with respect to rights in RFC 1043 documents can be found in BCP 78 and BCP 79. 1045 Copies of IPR disclosures made to the IETF Secretariat and any 1046 assurances of licenses to be made available, or the result of an 1047 attempt made to obtain a general license or permission for the use 1048 of such proprietary rights by implementers or users of this 1049 specification can be obtained from the IETF on-line IPR repository 1050 at http://www.ietf.org/ipr. 1052 The IETF invites any interested party to bring to its attention any 1053 copyrights, patents or patent applications, or other proprietary 1054 rights that may cover technology that may be required to implement 1055 this standard. Please address the information to the IETF at ietf- 1056 ipr@ietf.org.