idnits 2.17.1 draft-mraihi-mutual-oath-hotp-variants-07.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 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1213. 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], [0], [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 773 has weird spacing: '...eyBytes the ...' == Line 799 has weird spacing: '...raSuite the...' == Line 808 has weird spacing: '...meStamp a v...' == 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 (April 03, 2008) is 5867 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 725 looks like a reference -- Missing reference section? 'OATH' on line 736 looks like a reference -- Missing reference section? 'RFC2119' on line 719 looks like a reference -- Missing reference section? 'RFC 4226' on line 266 looks like a reference -- Missing reference section? 'C' on line 581 looks like a reference -- Missing reference section? 'T' on line 575 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 739 looks like a reference -- Missing reference section? 'RFC3668' on line 722 looks like a reference -- Missing reference section? 'BCK' on line 732 looks like a reference -- Missing reference section? '0' on line 980 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 20 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-07.txt ENS 8 Salah Machani 9 Diversinet 10 Siddharth Bajaj 11 VeriSign 13 Expires: October 03, 2008 April 03, 2008 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 in 2006. 48 Table of Contents 50 1. Introduction...............................................3 51 2. Requirements Terminology...................................3 52 3. Algorithm Requirements.....................................3 53 4. OCRA Background............................................4 54 4.1 HOTP Algorithm.............................................4 55 5. Definition of OCRA.........................................5 56 5.1 DataInput Parameters........................................5 57 5.2 CryptoFunction..............................................6 58 6. The OCRASuite..............................................7 59 7. Algorithm Modes for Authentication.........................8 60 7.1 One way Challenge-Response..................................9 61 7.2 Mutual Challenge-Response..................................10 62 8. Algorithm Modes for Signature.............................11 63 8.1 Plain Signature...........................................11 64 8.2 Signature with Server Authentication......................12 65 9. Security Considerations...................................13 66 9.1 Security Analysis of the OCRA algorithm....................14 67 9.2 Implementation Considerations..............................14 68 10. IANA Considerations.......................................15 69 11. Conclusion................................................15 70 12. Acknowledgements..........................................16 71 13. References................................................16 72 13.1 Normative.................................................16 73 13.2 Informative...............................................16 74 Appendix A: Source Code........................................17 75 14. Authors' Addresses........................................24 76 15. Full Copyright Statement..................................25 77 16. Intellectual Property.....................................26 78 1. Introduction 80 OATH has identified several use cases and scenarios that require an 81 asynchronous variant to accommodate users who do not want to 82 maintain a synchronized authentication system. A commonly accepted 83 method for this is to use a challenge-response scheme. 85 Such challenge response mode of authentication is widely adopted in 86 the industry. Several vendors already offer software applications 87 and hardware devices implementing challenge-response - but each of 88 those uses vendor-specific proprietary algorithms. For the benefits 89 of users there is a need for a standardized challenge-response 90 algorithm which allows multi-sourcing of token purchases and 91 validation systems to facilitate the democratization of strong 92 authentication. 93 Additionally, this specification describes the means to create 94 symmetric key based digital signatures. Such signatures are 95 variants of challenge-response mode where the data to be signed 96 becomes the challenge. 98 2. Requirements Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 102 this document are to be interpreted as described in RFC 2119 103 [RFC2119]. 105 3. Algorithm Requirements 107 This section presents the main requirements that drove this 108 algorithm design. A lot of emphasis was placed on flexibility and 109 usability, under the constraints and specificity of the HOTP 110 algorithm and hardware token capabilities. 112 R1 - The algorithm MUST support asynchronous challenge-response 113 based authentication. 115 R2 - The algorithm MUST be capable of supporting symmetric key 116 based digital signatures. Essentially this is a variation of 117 challenge-response where the challenge is derived from the data 118 that need to be signed. 120 R3 - The algorithm MUST be capable of supporting server- 121 authentication, whereby the user can verify that he/she is talking 122 to a trusted server. 124 R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building 125 block. 127 R5 - The length and format of the input challenge SHOULD be 128 configurable. 130 R6 - The output length and format of the generated response SHOULD 131 be configurable. 133 R7 - The challenge MAY be generated with integrity checking (e.g., 134 parity bits). This will allow tokens with pin pads to perform 135 simple error checking when the user enters the challenge value into 136 a token. 138 R8 - There MUST be a unique secret (key) for each token/soft token 139 that is shared between the token and the authentication server. The 140 keys MUST be randomly generated or derived using a key derivation 141 algorithm. 143 R9 - The algorithm MAY enable additional data attributes such as a 144 timestamp or session information to be included in the computation. 145 These data inputs MAY be used individually or all together. 147 4. OCRA Background 149 OATH introduced the HOTP algorithm as a first open, freely 150 available building block towards strengthening authentication for 151 end-users in a variety of applications. One-time passwords are very 152 efficient at solving specific security issues thanks to the dynamic 153 nature of OTP computations. 155 After carefully analyzing different use cases, OATH came to the 156 conclusion that providing for extensions to the HOTP algorithms was 157 important. A very natural extension is to introduce a challenge 158 mode for computing HOTP values based on random questions. Equally 159 beneficial is being able to perform mutual authentication between 160 two parties, or short-signature computation for authenticating 161 transaction to improve the security of e-commerce applications. 163 4.1 HOTP Algorithm 165 The HOTP algorithm, as defined in [RFC4226] is based on an 166 increasing counter value and a static symmetric key known only to 167 the prover and verifier parties. 169 As a reminder: 171 HOTP(K,C) = Truncate(HMAC-SHA1(K,C)) 172 Where Truncate represents the function that converts an HMAC-SHA-1 173 value into an HOTP value. 175 We refer the reader to [RFC4226] for the full description and 176 further details on the rationale and security analysis of HOTP. 178 The present draft describes the different variants based on similar 179 constructions as HOTP. 181 5. Definition of OCRA 183 OCRA is a generalization of HOTP with variable data inputs not 184 solely based on an incremented counter and secret key values. 186 The definition of OCRA requires a cryptographic function, a key K 187 and a set of DataInput parameters. This section first formally 188 introduces the OCRA algorithm and then introduces the definitions 189 and default values recommended for all parameters. 191 In a nutshell, 192 OCRA = CryptoFunction(K, DataInput) 194 Where: 196 - K: a shared secret key known to both parties; 197 - DataInput: a structure that contains the concatenation of the 198 various input data values defined in details in section 5.1; 199 - CryptoFunction: this is the function performing the OCRA 200 computation from the secret key K and the DataInput material; 201 CryptoFunction is described in details in section 5.2. 203 5.1 DataInput Parameters 205 This structure is the concatenation over byte array of the 206 OCRASuite value as defined in section 6 with the different 207 parameters used in the computation, save for the secret key K. 209 DataInput = {OCRASuite | 00 | C | Q | P | S | T} where: 210 . OCRASuite is a value representing the suite of operations to 211 compute an OCRA response; 212 . 00 is a byte value used as a separator; 213 . C is an unsigned 8-byte counter value processed high-order bit 214 first, and MUST be synchronized between all parties; It loops 215 around from "{Hex}0" to "{Hex}FFFFFFFFFFFFFFFF" and then starts 216 . over at "{Hex}0"; 217 . Q, mandatory, is a 128-byte list of (concatenated) challenge 218 question(s) generated by the parties; if Q is less than 128 219 bytes, then it should be padded with zeroes to the right; 220 . P is a 20-byte SHA1-hash of PIN/password that is known to all 221 parties during the execution of the algorithm; 222 . S is a 64-byte UTF-8 encoded string that contains information 223 about the current session; 224 . T is an 8-byte unsigned integer in big endian (i.e. network 225 byte order) representing the number of minutes since midnight 226 UTC of January 1, 1970. More specificatlly, if the OCRA 227 computation includes a timestamp T, you SHOULD first convert 228 your current local time to UTC time (text form). You can then 229 derive the UTC time in milliseconds and T (minutes from Epoch 230 time). 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 | T 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 The counter on the token or client MUST be incremented every time a 245 new computation is requested by the user. The server's counter 246 value MUST only be incremented after a successful OCRA 247 authentication. 249 5.2 CryptoFunction 251 The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of 252 computation for OCRA is HOTP with the default 6-digit dynamic 253 truncation and a combination of DataInput values as the message to 254 compute the HMAC-SHA1 digest. 256 As indicated in section 5.1, we denote t as the length in digits of 257 the truncation output. For instance, if t = 6, then the output of 258 the truncation is a 6-digit value. 260 We define the HOTP family of functions as an extension to HOTP: 261 - HOTP-H-t: these are the different possible truncated versions of 262 HOTP, using the dynamic truncation method for extracting an HOTP 263 value from the HMAC output; 264 - We will denote HOTP-H-t as the realization of an HOTP function 265 that uses an HMAC function with the hash function H, and the 266 dynamic truncation as described in [RFC 4226] to extract a t- 267 digit value; 268 - t=0 means that no truncation is performed and the full HMAC value 269 is used for authentication purpose. 271 We list the following preferred modes of computation, where * 272 denotes the default CryptoFunction: 273 . HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC 274 and a dynamic truncation to a 4-digit value; this mode is not 275 recommended in the general case but can be useful when a very 276 short authentication code is needed by an application; 277 . *HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC 278 and a dynamic truncation to a 6-digit value; 279 . HOTP-SHA1-8: HOTP with SHA-1 as the hash function for HMAC 280 and a dynamic truncation to an 8-digit value; 281 . HOTP-SHA256-6: HOTP with SHA-256 as the hash function for 282 HMAC and a dynamic truncation to a 6-digit value; 283 . HOTP-SHA512-6: HOTP with SHA-512 as the hash function for 284 HMAC and a dynamic truncation to a 6-digit value; 286 This table summarizes all possible values for the CryptoFunction: 288 Name HMAC Function Used Size of Truncation (t) 289 -------------------------------------------------------------- 290 HOTP-SHA1-t HMAC-SHA1 0 (no truncation), 4-10 291 HOTP-SHA256-t HMAC-SHA256 0 (no truncation), 4-10 292 HOTP-SHA512-t HMAC-SHA512 0 (no truncation), 4-10 294 6. The OCRASuite 296 An OCRASuite value is a text string that captures one mode of 297 operation for the OCRA algorithm, completely specifying the various 298 options for that computation. An OCRASuite value is represented as 299 follows: 301 Algorithm:CryptoFunction:DataInput 303 The client and server need to agree on one or two values of 304 OCRASuite. These values may be agreed at time of token provisioning 305 or for more sophisticated client-server interactions these values 306 may be negotiated for every transaction. 308 Note that for Mutual Challenge-Response or Signature with Server 309 Authentication modes, the client and server will need to agree on 310 two values of OCRASuite - one for server computation and another 311 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 specifies 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 --------- 329 Description: This component of the OCRASuite string captures the 330 list of valid inputs for that computation; [] indicates a value is 331 optional: 332 [C] | QFxx | [P | S | T]: Challenge-Response computation 333 [C] | QFxx | [P | T]: Plain Signature computation 335 Each input that is used for the computation is represented by a 336 single letter (except Q) and they are separated by a hyphen. 338 The input for challenge is further qualified by the formats 339 supported by the client for challenge question(s). 340 Supported values can be: 342 Format (F) Up To Length (xx) 343 -------------------------------------------------------------- 344 A (alphanumeric) 04-64 345 N (numeric) 04-64 346 H (hexadecimal) 04-64 348 The default format for challenge question is N08, numeric and upto 349 8 digits. 351 For example OCRA-1:HOTP-SHA512-8:C-QN08-P means version 1 of the 352 OCRA algorithm with HMAC-SHA512 function, truncated to an 8-digit 353 value, using the counter, a random challenge and a hash of the 354 PIN/Password as parameters. It also indicates that the client 355 supports only numeric challenge upto 8 digits in length. 357 7. Algorithm Modes for Authentication 359 This section describes the typical modes in which the above defined 360 computation can be used for authentication. 362 7.1 One way Challenge-Response 364 A challenge/response is a security mechanism in which the verifier 365 presents a question (challenge) to the prover who must provide a 366 valid answer (response) to be authenticated. 368 To use this algorithm for a one-way challenge-response, the 369 verifier will communicate a challenge value (typically randomly 370 generated) to the prover. The prover will use the challenge in the 371 computation as described above. The prover then communicates the 372 response to the verifier to authenticate. 374 Therefore in this mode, the typical data inputs will be: 376 C - Counter, optional. 377 Q - Challenge question, mandatory, supplied by the verifier. 378 P - Hashed version of PIN/password, optional. 379 S - Session information, optional 380 T - Timestamp, optional. 382 The diagram below shows the message exchange between the client 383 (prover) and the server (verifier) to complete a one-way challenge- 384 response authentication. 386 It is assumed that the client and server have a pre-shared key K 387 that is used for the computation. 389 CLIENT SERVER 390 (PROVER) (VERIFIER) 391 | | 392 | Verifier sends challenge to prover | 393 | Challenge = Q | 394 |<------------------------------------------| 395 | | 396 | Prover Computes Response | 397 | R = OCRA(K, {[C] | Q | [P | S | T]}) | 398 | Prover sends Response = R | 399 |------------------------------------------>| 400 | | 401 | Verifier Validates Response | 402 | If Response is valid, Server sends OK | 403 | If Response is not, Server sends NOK | 404 |<------------------------------------------| 405 | | 406 7.2 Mutual Challenge-Response 408 Mutual challenge-response is a variation of one-way challenge- 409 response where both the client and server mutually authenticate 410 each other. 412 To use this algorithm, the client will first send a random client- 413 challenge to the server. The server computes the server-response 414 and sends it to the client along with a server-challenge. 416 The client will first verify the server-response to be assured that 417 it is talking to a valid server. It will then compute the client- 418 response and send it to the server to authenticate. The server 419 verifies the client-response to complete the two-way authentication 420 process. 422 In this mode there are two computations: client-response and 423 server-response. There are two separate challenge questions, 424 generated by both parties. We denote these challenge questions Q1 425 and Q2. 427 Typical data inputs for server-response computation will be: 428 C - Counter, optional. 429 QC - Challenge question, mandatory, supplied by the client. 430 QS - Challenge question, mandatory, supplied by the server. 431 S - Session information, optional. 432 T - Timestamp, optional. 434 Typical data inputs for client-response computation will be: 435 C - Counter, optional. 436 QS - Challenge question, mandatory, supplied by the server. 437 QC - Challenge question, mandatory, supplied by the client. 438 P - Hashed version of PIN/password, optional. 439 S - Session information, optional. 440 T - Timestamp, optional. 442 The following picture shows the messages that are exchanged between 443 the client and the server to complete a two-way mutual challenge- 444 response authentication. 446 It is assumed that the client and server have a pre-shared key K 447 (or pair of keys if using dual-key mode of computation) that is 448 used for the computation. 450 CLIENT SERVER 451 | | 452 | 1. Client sends client-challenge | 453 | QC = Client-challenge | 454 |-------------------------------------------------->| 455 | | 456 | 2. Server computes server-response | 457 | and sends server-challenge | 458 | RS = OCRA(K, [C] | QC | QS | [S | T]) | 459 | QS = Server-challenge | 460 | Response = RS, QS | 461 |<--------------------------------------------------| 462 | | 463 | 3. Client verifies server-response | 464 | and computes client-response | 465 | OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP | 466 | RC = OCRA(K, [C] | QS | QC | [P | S | T]) | 467 | Response = RC | 468 |-------------------------------------------------->| 469 | | 470 | 4. Server verifies client-response | 471 | OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP | 472 | Response = OK | 473 |<--------------------------------------------------| 474 | | 476 8. Algorithm Modes for Signature 478 In this section we describe the typical modes in which the above 479 defined computation can be used for digital signatures. 481 8.1 Plain Signature 483 To use this algorithm in plain signature mode, the server will 484 communicate a signature-challenge value to the client (signer). The 485 signature-challenge is either the data to be signed or derived from 486 the data to be signed using a hash function, for example. 488 The client will use the signature-challenge in the computation as 489 described above. The client then communicates the signature value 490 (response) to the server to authenticate. 492 Therefore in this mode, the data inputs will be: 494 C - Counter, optional. 495 QS - Signature-challenge, mandatory, supplied by the server. 496 P - Hashed version of PIN/password, optional. 497 T - Timestamp, optional. 499 The picture below shows the messages that are exchanged between the 500 client (prover) and the server (verifier) to complete a plain 501 signature operation. 503 It is assumed that the client and server have a pre-shared key K 504 that is used for the computation. 506 CLIENT SERVER 507 (PROVER) (VERIFIER) 508 | | 509 | Verifier sends signature-challenge | 510 | Challenge = QS | 511 |<------------------------------------------| 512 | | 513 | Client Computes Response | 514 | SIGN = OCRA(K, [C] | QS | [P | T]) | 515 | Response = SIGN | 516 |------------------------------------------>| 517 | | 518 | Verifier Validates Response | 519 | Response = OK | 520 |<------------------------------------------| 521 | | 523 8.2 Signature with Server Authentication 525 This mode is a variation of the plain signature mode where the 526 client can first authenticates the server before generating a 527 digital signature. 529 To use this algorithm, the client will first send a random client- 530 challenge to the server. The server computes the server-response 531 and sends it to the client along with a signature-challenge. The 532 client will first verify the server-response to authenticate that 533 it is talking to a valid server. It will then compute the signature 534 and send it to the server. 536 In this mode there are two computations: client-signature and 537 server-response. 539 Typical data inputs for server-response computation will be: 540 C - Counter, optional. 541 QC - Challenge question, mandatory, supplied by the client. 542 QS - Signature-challenge, mandatory, supplied by the server. 543 T - Timestamp, optional. 545 Typical data inputs for client-signature computation will be: 546 C - Counter, optional. 547 QC - Challenge question, mandatory, supplied by the client. 548 QS - Signature-challenge, mandatory, supplied by the server. 549 P - Hashed version of PIN/password, optional. 550 T - Timestamp, optional. 552 The diagram below shows the messages that are exchanged between the 553 client and the server to complete a signature with server 554 authentication transaction. 556 It is assumed that the client and server have a pre-shared key K 557 (or pair of keys if using dual-key mode of computation) that is 558 used for the computation. 560 CLIENT SERVER 561 | | 562 | 1. Client sends client-challenge | 563 | QC = Client-challenge | 564 |-------------------------------------------------->| 565 | | 566 | 2. Server computes server-response | 567 | and sends signature-challenge | 568 | RS = OCRA(K, [C] | QC | QS | [T]) | 569 | QS = signature-challenge | 570 | Response = RS, QS | 571 |<--------------------------------------------------| 572 | | 573 | 3. Client verifies server-response | 574 | and computes signature | 575 | OCRA(K, [C] | QC | QS | [T]) != RS -> STOP | 576 | SIGN = OCRA( K, [C] | QS | QC | [P | T]) | 577 | Response = SIGN | 578 |-------------------------------------------------->| 579 | | 580 | 4. Server verifies Signature | 581 | OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP | 582 | Response = OK | 583 |<--------------------------------------------------| 584 | | 586 9. Security Considerations 588 Any algorithm is only as secure as the application and the 589 authentication protocols that implement it. Therefore, this section 590 discusses the critical security requirements that our choice of 591 algorithm imposes on the authentication protocol and validation 592 software. 594 9.1 Security Analysis of the OCRA algorithm 596 The security and strength of this algorithm depends on the 597 properties of the underlying building block HOTP, which is a 598 construction based on HMAC [RFC2104] using SHA-1 as the hash 599 function. 601 The conclusion of the security analysis detailed in [RFC4226] is 602 that, for all practical purposes, the outputs of the dynamic 603 truncation on distinct counter inputs are uniformly and 604 independently distributed strings. 606 The analysis demonstrates that the best possible attack against the 607 HOTP function is the brute force attack. 609 9.2 Implementation Considerations 611 IC1 - In the authentication mode, the client MUST support two- 612 factor authentication, i.e., the communication and verification of 613 something you know (secret code such as a Password, Pass phrase, 614 PIN code, etc.) and something you have (token). The secret code is 615 known only to the user and usually entered with the Response value 616 for authentication purpose (two-factor authentication). 617 Alternatively, instead of sending something you know to the server, 618 the client may use a hash of the Password or PIN code in the 619 computation itself, thus implicitly enabling two-factor 620 authentication. 622 IC2 - Keys should be of the length of the CryptoFunction output to 623 facilitate interoperability. 625 IC3 - Keys SHOULD be chosen at random or using a cryptographically 626 strong pseudo-random generator properly seeded with a random value. 627 We RECOMMEND following the recommendations in [RFC1750] for all 628 pseudo-random and random generations. The pseudo-random numbers 629 used for generating the keys SHOULD successfully pass the 630 randomness test specified in [CN]. 632 IC4 - Challenge questions SHOULD be 20-byte values and MUST be at 633 least t-byte values where t stands for the digit-length of the OCRA 634 truncation output. 636 IC5 - On the client side, the keys SHOULD be embedded in a tamper 637 resistant device or securely implemented in a software application. 638 Additionally, by embedding the keys in a hardware device, you also 639 have the advantage of improving the flexibility (mobility) of the 640 authentication system. 642 IC6 - We RECOMMEND following the recommendations in [RFC1750] for 643 all pseudo-random and random challenge generations. 645 IC7 - All the communications SHOULD take place over a secure 646 channel e.g. SSL/TLS, IPsec connections. 648 IC8 - The OCRA algorithm when used in mutual authentication mode or 649 in signature with server authentication mode MAY use dual key mode 650 - i.e. there are two keys that are shared between the client and 651 the server. One shared key is used to generate the server response 652 on the server side and to verify it on the client side. The other 653 key is used to create the response or signature on the client side 654 and to verify it on the server side. 656 IC9 - We recommend that implementations MAY use the session 657 information, S as an additional input in the computation. For 658 example, S could be the session identifier from the TLS session. 659 This will enable you to counter certain types of man-in-the-middle 660 attacks. However, this will introduce the additional dependency 661 that first of all the prover needs to have access to the session 662 identifier to compute the response and the verifier will need 663 access to the session identifier to verify the response. 665 IC10 - In the signature mode, whenever the counter or time (defined 666 as optional elements) are not used in the computation, there might 667 be a risk of replay attack and the implementers should carefully 668 consider this issue in the light of their specific application 669 requirements and security guidelines. The server SHOULD also 670 provide whenever possible a mean for the client (if able) to verify 671 the validity of the signature challenge. 673 IC11 - We also RECOMMEND storing the keys securely in the 674 validation system, and more specifically encrypting them using 675 tamper-resistant hardware encryption and exposing them only when 676 required: for example, the key is decrypted when needed to verify 677 an OCRA response, and re-encrypted immediately to limit exposure in 678 the RAM for a short period of time. The key store MUST be in a 679 secure area, to avoid as much as possible direct attack on the 680 validation system and secrets database. Particularly, access to the 681 key material should be limited to programs and processes required 682 by the validation system only. 684 10. IANA Considerations 686 This document has no actions for IANA. 687 11. Conclusion 688 This draft introduced several variants of HOTP for challenge- 689 response based authentication and short signature-like 690 computations. 692 The OCRASuite provides for an easy integration and support of 693 different flavors within an authentication and validation system. 695 Finally, OCRA should enable mutual authentication both in connected 696 and off-line modes, with the support of different response sizes 697 and mode of operations. 699 12. Acknowledgements 701 We would like to thank Jeff Burstein, Shuh Chang, Oanh Hoang, 702 Philip Hoyer, Jon Martinsson, Frederik Mennes, Mingliang Pei, 703 Jonathan Tuliani, Stu Vaeth, Enrique Rodriguez and Robert 704 Zuccherato for their comments and suggestions to improve this draft 705 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 [RFC3668] S. Bradner, "Intellectual Property Rights in IETF 723 Technology", BCP 79, RFC 3668, February 2004. 725 [RFC4226] D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and 726 O. Ranen, "HOTP: An HMAC-based One Time Password 727 Algorithm", IETF Network Working Group, RFC 4226, 728 December 2005. 730 13.2 Informative 732 [BCK] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash 733 Functions and Message Authentication", Proceedings of 734 Crypto'96, LNCS Vol. 1109, pp. 1-15. 736 [OATH] Initiative for Open AuTHentication 737 http://www.openauthentication.org 739 [CN] J.S. Coron and D. Naccache, "An accurate evaluation of 740 Maurer's universal test" by Jean-Sebastien Coron and 741 David Naccache In Selected Areas in Cryptography (SAC 742 '98), vol. 1556 of Lecture Notes in Computer Science, 743 S. Tavares and H. Meijer, Eds., pp. 57-71, Springer- 744 Verlag, 1999 746 Appendix A: Source Code 748 import java.lang.reflect.UndeclaredThrowableException; 749 import java.security.GeneralSecurityException; 750 import javax.crypto.Mac; 751 import javax.crypto.spec.SecretKeySpec; 752 import java.math.BigInteger; 754 /** 755 * This an example implementation of the OATH OCRA algorithm. 756 * Visit www.openauthentication.org for more information. 757 * 758 * @author Johan Rydell, PortWise 759 */ 761 public class OCRA { 763 private OCRA() {} 765 /** 766 * This method uses the JCE to provide the crypto 767 * algorithm. 768 * HMAC computes a Hashed Message Authentication Code with the 769 * crypto hash algorithm as a parameter. 770 * 771 * @param crypto the crypto algorithm (HmacSHA1, HmacSHA256, 772 * HmacSHA512) 773 * @param keyBytes the bytes to use for the HMAC key 774 * @param text the message or text to be authenticated. 775 */ 776 public static byte[] hmac_sha1(String crypto, 777 byte[] keyBytes, byte[] text) 778 { 779 try { 780 Mac hmac; 781 hmac = Mac.getInstance(crypto); 782 SecretKeySpec macKey = 783 new SecretKeySpec(keyBytes, "RAW"); 784 hmac.init(macKey); 785 return hmac.doFinal(text); 786 } catch (GeneralSecurityException gse) { 787 throw new UndeclaredThrowableException(gse); 788 } 789 } 791 private static final int[] DIGITS_POWER 792 // 0 1 2 3 4 5 6 7 8 793 = {1,10,100,1000,10000,100000,1000000,10000000,100000000 }; 795 /** 796 * This method generates an OCRA HOTP value for the given 797 * set of parameters. 798 * 799 * @param ocraSuite the OCRA Suite 800 * @param key the shared secret, HEX encoded 801 * @param counter the counter that changes on a 802 * per use basis, HEX encoded 803 * @param question the challenge question 804 * @param password a password that can be used 805 * @param sessionInformation Static information 806 * that identifies the 807 * current session 808 * @param timeStamp a value that reflects a time 809 * 810 * @return A numeric String in base 10 that includes 811 * {@link truncationDigits} digits 812 */ 813 static public String generateOCRA(String ocraSuite, 814 String key, 815 String counter, 816 String question, 817 String password, 818 String sessionInformation, 819 String timeStamp) 820 { 821 int codeDigits = 0; 822 String crypto = ""; 823 String result = null; 824 int ocraSuiteLength = ocraSuite.length(); 825 int counterLength = 0; 826 int questionLength = 0; 827 int passwordLength = 0; 828 int sessionInformationLength = 0; 829 int timeStampLength = 0; 831 if(ocraSuite.toLowerCase().indexOf("sha1") > 1) 832 crypto = "HmacSHA1"; 833 if(ocraSuite.toLowerCase().indexOf("sha256") > 1) 834 crypto = "HmacSHA256"; 835 if(ocraSuite.toLowerCase().indexOf("sha512") > 1) 836 crypto = "HmacSHA512"; 837 // How many digits should we return 838 String oS = ocraSuite.substring(ocraSuite.indexOf(":"), 839 ocraSuite.indexOf(":", ocraSuite.indexOf(":") + 1)); 841 codeDigits = Integer.decode(oS.substring 842 (oS.lastIndexOf("-")+1, 843 oS.length())); 845 // The size of the byte array message to be encrypted 846 // Counter 847 if(ocraSuite.toLowerCase().indexOf(":c") > 1) { 848 counterLength=8; 849 } 850 // Question 851 if((ocraSuite.toLowerCase().indexOf(":q") > 1) || 852 (ocraSuite.toLowerCase().indexOf("-q") > 1)) { 853 questionLength=128; 854 } 856 // Password 857 if((ocraSuite.toLowerCase().indexOf(":p") > 1) || 858 (ocraSuite.toLowerCase().indexOf("-p") > 1)){ 859 passwordLength=20; 860 } 862 // sessionInformation 863 if((ocraSuite.toLowerCase().indexOf(":s") > 1) || 864 (ocraSuite.toLowerCase().indexOf("-s", 865 ocraSuite.indexOf(":", 866 ocraSuite.indexOf(":") + 1)) > 1)){ 867 sessionInformationLength=64; 868 } 869 // TimeStamp 870 if((ocraSuite.toLowerCase().indexOf(":t") > 1) || 871 (ocraSuite.toLowerCase().indexOf("-t") > 1)){ 872 timeStampLength=8; 873 } 875 // Remember to add "1" for the "00" byte delimiter 876 byte[] msg = new byte[ocraSuiteLength + 877 counterLength + 878 questionLength + 879 passwordLength + 880 sessionInformationLength + 881 timeStampLength + 882 1]; 884 // Put the bytes of "ocraSuite" parameters 885 // into the message 886 byte[] bArray = ocraSuite.getBytes(); 887 for(int i = 0; i < bArray.length; i++){ 888 msg[i] = bArray[i]; 889 } 890 // Put the bytes of "Counter" to the message 891 // Input is HEX encoded 892 if(counter.length() > 0 ){ 893 bArray = new BigInteger(counter,16).toByteArray(); 894 if(bArray.length == 9){ 895 // First byte is the "sign" byte 896 for (int i = 0; i < 8 && i < bArray.length ; i++) 897 { 898 msg[i + 8 - bArray.length 899 + ocraSuiteLength + 1] = 900 bArray[i+1]; 901 } 902 } 903 else { 904 for (int i = 0; i < 8 && i < bArray.length ; i++) 905 { 906 msg[i + 8 - bArray.length 907 + ocraSuiteLength + 1] = bArray[i]; 908 } 909 } 910 } 912 // Put the bytes of "question" to the message 913 // Input is text encoded 914 if(question.length() > 0 ){ 915 bArray = question.getBytes(); 916 for (int i = 0; i < 128 && i < bArray.length ; i++) 917 { 918 msg[i + ocraSuiteLength + 1 919 + counterLength] = bArray[i]; 920 } 921 } 923 // Put the bytes of "password" to the message 924 // Input is HEX encoded 925 if(password.length() > 0){ 926 bArray = new BigInteger(password,16).toByteArray(); 927 if(bArray.length == 21){ 928 // First byte is the "sign" byte 929 for (int i = 0; i < 20 && i < bArray.length ; i++) 930 { 931 msg[i + ocraSuiteLength + 1 + counterLength 932 + questionLength] = bArray[i+1]; 933 } 934 } 935 else { 936 for (int i = 0; i < 20 && i < bArray.length ; i++) 937 { 938 msg[i + ocraSuiteLength + 1 + counterLength + 939 questionLength] = bArray[i]; 940 } 941 } 942 } 943 // Put the bytes of "sessionInformation" to the message 944 // Input is text encoded 946 if(sessionInformation.length() > 0 ){ 947 bArray = sessionInformation.getBytes(); 948 for (int i = 0; i < 128 && i < bArray.length ; i++) { 949 msg[i + ocraSuiteLength + 1 950 + counterLength + questionLength 951 + passwordLength] = bArray[i]; 952 } 953 } 955 // Put the bytes of "time" to the message 956 // Input is text value of minutes 957 if(timeStamp.length() > 0){ 958 bArray = new BigInteger(timeStamp,16).toByteArray(); 959 if(bArray.length == 9){ 960 // First byte is the "sign" byte 961 for (int i = 0; i < 8 && i < bArray.length ; i++) { 962 msg[i + 8 - bArray.length + 963 ocraSuiteLength + 1 + counterLength 964 + questionLength + passwordLength + 965 sessionInformationLength] = bArray[i+1]; 966 } 967 } 968 else { 969 for (int i = 0; i < 8 && i < bArray.length ; i++) { 970 msg[i + 8 - bArray.length 971 + ocraSuiteLength + 1 + counterLength 972 + questionLength + passwordLength + 973 sessionInformationLength] = bArray[i]; 974 } 975 } 976 } 978 byte[] hash; 979 bArray = new BigInteger(key,16).toByteArray(); 980 if(bArray[0] == 0){ 981 byte[] b = new byte[bArray.length - 1]; 982 for(int i = 0 ; i < b.length; i++) 983 b[i]=bArray[i+1]; 984 hash = hmac_sha1(crypto, b, msg); 985 } 986 else{ 987 // compute hmac hash 988 hash = hmac_sha1(crypto, bArray, msg); 989 } 991 // put selected bytes into result int 992 int offset = hash[hash.length - 1] & 0xf; 994 int binary = 995 ((hash[offset] & 0x7f) << 24) 996 | ((hash[offset + 1] & 0xff) << 16) 997 |((hash[offset + 2] & 0xff) << 8) 998 | (hash[offset + 3] & 0xff); 1000 int otp = binary % DIGITS_POWER[codeDigits]; 1002 result = Integer.toString(otp); 1003 while (result.length() < codeDigits) { 1004 result = "0" + result; 1005 } 1006 return result; 1007 } 1008 } 1010 Appendix B: Test Vectors 1012 OCRA Test Vectors (OCRA Test Vectors generated on March 29, 2008) 1014 For all computations, Key (K) = 12345678901234567890 1016 ***** OCRA-V1 Plain Challenge Response ***** 1018 ==> Q only, Digit (D) = 6, Algorithm (A) = HMACSHA1 1019 ID OCRASuite Question(Q) OCRA(O) 1020 T1.1 OCRA-1:HOTP-SHA1-6:QN08 00000000 713673 1021 T1.2 OCRA-1:HOTP-SHA1-6:QN08 11111111 640542 1022 T1.3 OCRA-1:HOTP-SHA1-6:QN08 22222222 434144 1023 T1.4 OCRA-1:HOTP-SHA1-6:QN08 33333333 024883 1024 T1.5 OCRA-1:HOTP-SHA1-6:QN08 44444444 473006 1025 T1.6 OCRA-1:HOTP-SHA1-6:QN08 55555555 911781 1026 T1.7 OCRA-1:HOTP-SHA1-6:QN08 66666666 059218 1027 T1.8 OCRA-1:HOTP-SHA1-6:QN08 77777777 175339 1028 T1.9 OCRA-1:HOTP-SHA1-6:QN08 88888888 478461 1029 T1.10 OCRA-1:HOTP-SHA1-6:QN08 99999999 681743 1031 ==> Q and P = 1234, Digit (D) = 8, 1032 Algorithm (A) = HMACSHA256 1033 ID OCRASuite Question(Q) OCRA(O) 1034 T2.1 OCRA-1:HOTP-SHA256-8:QN08-P 00000000 98280381 1035 T2.2 OCRA-1:HOTP-SHA256-8:QN08-P 11111111 77892831 1036 T2.3 OCRA-1:HOTP-SHA256-8:QN08-P 22222222 11994562 1037 T2.4 OCRA-1:HOTP-SHA256-8:QN08-P 33333333 62731746 1038 T2.5 OCRA-1:HOTP-SHA256-8:QN08-P 44444444 27309033 1039 T2.6 OCRA-1:HOTP-SHA256-8:QN08-P 55555555 16123184 1040 T2.7 OCRA-1:HOTP-SHA256-8:QN08-P 66666666 29679588 1041 T2.8 OCRA-1:HOTP-SHA256-8:QN08-P 77777777 86592637 1042 T2.9 OCRA-1:HOTP-SHA256-8:QN08-P 88888888 65897507 1043 T2.10 OCRA-1:HOTP-SHA256-8:QN08-P 99999999 58356750 1044 ==> C & Q, Digit (D) = 8, Algorithm (A) = HMACSHA512 1045 ID OCRASuite Question(Q) Counter(C) OCRA(O) 1046 T3.1 OCRA-1:HOTP-SHA512-8:C-QN08 00000000 0 86391474 1047 T3.2 OCRA-1:HOTP-SHA512-8:C-QN08 11111111 1 05308362 1048 T3.3 OCRA-1:HOTP-SHA512-8:C-QN08 22222222 2 71230448 1049 T3.4 OCRA-1:HOTP-SHA512-8:C-QN08 33333333 3 24744363 1050 T3.5 OCRA-1:HOTP-SHA512-8:C-QN08 44444444 4 51162507 1051 T3.6 OCRA-1:HOTP-SHA512-8:C-QN08 55555555 5 69873452 1052 T3.7 OCRA-1:HOTP-SHA512-8:C-QN08 66666666 6 67398361 1053 T3.8 OCRA-1:HOTP-SHA512-8:C-QN08 77777777 7 78278396 1054 T3.9 OCRA-1:HOTP-SHA512-8:C-QN08 88888888 8 13228238 1055 T3.10 OCRA-1:HOTP-SHA512-8:C-QN08 99999999 9 40655008 1057 ==> Q & T, Digit (D) = 8, Algorithm (A) = HMACSHA512, 1058 Time (T) Mar 25 2008, 12:06:30 PM ie. OCRATime = 20107866 ***** 1059 ID OCRASuite Question(Q) OCRA(O) 1060 T4.1 OCRA-1:HOTP-SHA512-8:QN08-T 00000000 83093542 1061 T4.2 OCRA-1:HOTP-SHA512-8:QN08-T 11111111 90956975 1062 T4.3 OCRA-1:HOTP-SHA512-8:QN08-T 22222222 79746883 1063 T4.4 OCRA-1:HOTP-SHA512-8:QN08-T 33333333 93368550 1064 T4.5 OCRA-1:HOTP-SHA512-8:QN08-T 44444444 12212433 1065 T4.6 OCRA-1:HOTP-SHA512-8:QN08-T 55555555 02514283 1066 T4.7 OCRA-1:HOTP-SHA512-8:QN08-T 66666666 25817828 1067 T4.8 OCRA-1:HOTP-SHA512-8:QN08-T 77777777 52087425 1068 T4.9 OCRA-1:HOTP-SHA512-8:QN08-T 88888888 26000130 1069 T4.10 OCRA-1:HOTP-SHA512-8:QN08-T 99999999 66638242 1071 ***** OCRA-V1 Mutual Challenge/Response, Digit (D) = 8, 1072 Algorithm (A) = HMACSHA256 ***** 1074 ID OCRASuite Question(Q) OCRA(O) 1075 T5.1 OCRA-1:HOTP-SHA256-8:QA08 CLI22220SRV11110 25876570 1076 T5.2 OCRA-1:HOTP-SHA256-8:QA08 SRV11110CLI22220 65475908 1077 T5.3 OCRA-1:HOTP-SHA256-8:QA08 CLI22221SRV11111 68337907 1078 T5.4 OCRA-1:HOTP-SHA256-8:QA08 SRV11111CLI22221 36352242 1079 T5.5 OCRA-1:HOTP-SHA256-8:QA08 CLI22222SRV11112 51935447 1080 T5.6 OCRA-1:HOTP-SHA256-8:QA08 SRV11112CLI22222 20036871 1081 T5.7 OCRA-1:HOTP-SHA256-8:QA08 CLI22223SRV11113 12325872 1082 T5.8 OCRA-1:HOTP-SHA256-8:QA08 SRV11113CLI22223 58392008 1083 T5.9 OCRA-1:HOTP-SHA256-8:QA08 CLI22224SRV11114 50478153 1084 T5.10 OCRA-1:HOTP-SHA256-8:QA08 SRV11114CLI22224 53668312 1086 ***** OCRA-V1 Mutual Challenge/Response with Client PIN = 1234 ***** 1088 ID OCRASuite Question(Q) OCRA(O) 1089 T6.1 OCRA-1:HOTP-SHA512-8:QA08 CLI22220SRV11110 22014886 1090 T6.2 OCRA-1:HOTP-SHA512-8:QA08-P SRV11110CLI22220 55542963 1091 T6.3 OCRA-1:HOTP-SHA512-8:QA08 CLI22221SRV11111 52086443 1092 T6.4 OCRA-1:HOTP-SHA512-8:QA08-P SRV11111CLI22221 54291950 1093 T6.5 OCRA-1:HOTP-SHA512-8:QA08 CLI22222SRV11112 77303083 1094 T6.6 OCRA-1:HOTP-SHA512-8:QA08-P SRV11112CLI22222 39425683 1095 T6.7 OCRA-1:HOTP-SHA512-8:QA08 CLI22223SRV11113 39015190 1096 T6.8 OCRA-1:HOTP-SHA512-8:QA08-P SRV11113CLI22223 38936793 1097 T6.9 OCRA-1:HOTP-SHA512-8:QA08 CLI22224SRV11114 03327937 1098 T6.10 OCRA-1:HOTP-SHA512-8:QA08-P SRV11114CLI22224 89550664 1100 ***** OCRA-V1 Plain Signature (a) no time stamp, Digit (D) = 8, 1101 Algorithm (A) = HMACSHA256 ***** 1103 ID OCRASuite Question(Q) OCRA(O) 1104 T7.1 OCRA-1:HOTP-SHA256-8:QA08 SIG10000 90869451 1105 T7.2 OCRA-1:HOTP-SHA256-8:QA08 SIG11000 12253571 1106 T7.3 OCRA-1:HOTP-SHA256-8:QA08 SIG12000 13568297 1107 T7.4 OCRA-1:HOTP-SHA256-8:QA08 SIG13000 96520389 1108 T7.5 OCRA-1:HOTP-SHA256-8:QA08 SIG14000 57061117 1109 T7.6 OCRA-1:HOTP-SHA256-8:QA08 SIG15000 31653201 1110 T7.7 OCRA-1:HOTP-SHA256-8:QA08 SIG16000 87506781 1111 T7.8 OCRA-1:HOTP-SHA256-8:QA08 SIG17000 25237541 1112 T7.9 OCRA-1:HOTP-SHA256-8:QA08 SIG18000 48988608 1113 T7.10 OCRA-1:HOTP-SHA256-8:QA08 SIG19000 79070512 1115 ***** OCRA-V1 Plain Signature (b) with timestamp 1116 Time (T), Mar 25 2008, 12:06:30 PM, OCRATime = 20107866 ***** 1118 ID OCRASuite Question(Q) OCRA(O) 1119 T8.1 OCRA-1:HOTP-SHA512-8:QA10-T SIG1000000 00051074 1120 T8.2 OCRA-1:HOTP-SHA512-8:QA10-T SIG1100000 85317316 1121 T8.3 OCRA-1:HOTP-SHA512-8:QA10-T SIG1200000 67561993 1122 T8.4 OCRA-1:HOTP-SHA512-8:QA10-T SIG1300000 99207637 1123 T8.5 OCRA-1:HOTP-SHA512-8:QA10-T SIG1400000 81467939 1124 T8.6 OCRA-1:HOTP-SHA512-8:QA10-T SIG1500000 53960486 1125 T8.7 OCRA-1:HOTP-SHA512-8:QA10-T SIG1600000 13472538 1126 T8.8 OCRA-1:HOTP-SHA512-8:QA10-T SIG1700000 03719182 1127 T8.9 OCRA-1:HOTP-SHA512-8:QA10-T SIG1800000 20840783 1128 T8.10 OCRA-1:HOTP-SHA512-8:QA10-T SIG1900000 39923448 1130 Notes: 1131 1. Computations are done on March 21, 2008 based on the OCRA 1132 specification draft-mraihi-mutual-oath-hotp-variants-07.txt 1133 2. OCRA Time calculations: 1134 Local Time "Mar 25 2008, 12:06:30 PM" at "America/Los_Angeles" 1135 time zone (local OCRAtime=20107446) is converted (with time 1136 zone plus daylight time savings) to UTC Time "Mar 25 2008, 1137 19:06:30 PM" at "GMT" time zone (UTC OCRAtime=20107866) 1138 3. OCRA Time is treated the same as Counter of 8-byte long value 1139 with big-endian order and no base64 encoding. 1141 14. Authors' Addresses 1143 Primary point of contact (for sending comments and question): 1145 David M'Raihi 1146 VeriSign, Inc. 1147 685 E. Middlefield Road Phone: 1-650-426-3832 1148 Mountain View, CA 94043 USA Email: dmraihi@verisign.com 1150 Other Authors' contact information: 1152 Johan Rydell 1153 Portwise, Inc. 1154 275 Hawthorne Ave, Suite 119 Phone: 1-650-515-3569 1155 Palo Alto, CA 94301 USA Email: johan.rydell@portwise.com 1157 David Naccache 1158 ENS, DI 1159 45 rue d'Ulm Phone: +33 6 16 59 83 49 1160 75005, Paris France Email: david.naccache@ens.fr 1162 Salah Machani 1163 Diversinet Corp. 1164 2225 Sheppard Avenue East 1165 Suite 1801 1166 Toronto, Ontario M2J 5C2 Phone: 1-416-756-2324 Ext. 321 1167 Canada Email: smachani@diversinet.com 1169 Siddharth Bajaj 1170 VeriSign, Inc. 1171 487 E. Middlefield Road Phone: 1-650-426-3458 1172 Mountain View, CA 94043 USA Email: sbajaj@verisign.com 1174 15. Full Copyright Statement 1176 Copyright (C) The IETF Trust (2008). 1178 This document is subject to the rights, licenses and restrictions 1179 contained in BCP 78, and except as set forth therein, the authors 1180 retain all their rights. 1182 This document and the information contained herein are provided on 1183 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1184 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1185 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1186 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1187 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1188 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1189 FOR A PARTICULAR PURPOSE. 1191 16. Intellectual Property 1193 The IETF takes no position regarding the validity or scope of any 1194 Intellectual Property Rights or other rights that might be claimed 1195 to pertain to the implementation or use of the technology described 1196 in this document or the extent to which any license under such 1197 rights might or might not be available; nor does it represent that 1198 it has made any independent effort to identify any such rights. 1199 Information on the procedures with respect to rights in RFC 1200 documents can be found in BCP 78 and BCP 79. 1202 Copies of IPR disclosures made to the IETF Secretariat and any 1203 assurances of licenses to be made available, or the result of an 1204 attempt made to obtain a general license or permission for the use 1205 of such proprietary rights by implementers or users of this 1206 specification can be obtained from the IETF on-line IPR repository 1207 at http://www.ietf.org/ipr. 1209 The IETF invites any interested party to bring to its attention any 1210 copyrights, patents or patent applications, or other proprietary 1211 rights that may cover technology that may be required to implement 1212 this standard. Please address the information to the IETF at ietf- 1213 ipr@ietf.org.