idnits 2.17.1 draft-mraihi-mutual-oath-hotp-variants-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 21) being 59 lines 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. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([0-48], [RFC2119], [C], [1-59], [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 and authors Copyright Line does not match the current year == Line 822 has weird spacing: '...eyBytes the ...' == Line 849 has weird spacing: '...raSuite the O...' == Line 851 has weird spacing: '...counter the...' == Line 853 has weird spacing: '...uestion the...' == Line 854 has weird spacing: '...assword a pa...' == (1 more instance...) == 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 (July 2009) is 5398 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 775 looks like a reference -- Missing reference section? 'OATH' on line 786 looks like a reference -- Missing reference section? 'RFC2119' on line 769 looks like a reference -- Missing reference section? 'RFC 4226' on line 280 looks like a reference -- Missing reference section? 'C' on line 629 looks like a reference -- Missing reference section? 'T' on line 623 looks like a reference -- Missing reference section? 'RFC2104' on line 761 looks like a reference -- Missing reference section? 'RFC1750' on line 765 looks like a reference -- Missing reference section? 'CN' on line 789 looks like a reference -- Missing reference section? 'RFC3668' on line 772 looks like a reference -- Missing reference section? 'BCK' on line 782 looks like a reference -- Missing reference section? '0' on line 1022 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 15 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-09.txt ENS 8 Salah Machani 9 Diversinet 10 Siddharth Bajaj 11 VeriSign 12 Expires: 13 January 2010 July 2009 15 OCRA: OATH Challenge-Response Algorithms 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance 20 with the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working groups. 24 Note that other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license- 47 info). 48 Please review these documents carefully, as they describe your 49 rights and restrictions with respect to this document. 51 Abstract 53 This document describes the OATH algorithm for challenge-response 54 authentication and signatures. This algorithm is based on the HOTP 55 algorithm [RFC4226] that was introduced by OATH (initiative for 56 Open AuTHentication) [OATH] and submitted as an individual draft to 57 the IETF in 2006. 59 Table of Contents 61 1. Introduction...............................................3 62 2. Requirements Terminology...................................3 63 3. Algorithm Requirements.....................................3 64 4. OCRA Background............................................4 65 4.1 HOTP Algorithm.............................................4 66 5. Definition of OCRA.........................................5 67 5.1 DataInput Parameters........................................5 68 5.2 CryptoFunction..............................................6 69 6. The OCRASuite..............................................7 70 7. Algorithm Modes for Authentication.........................9 71 7.1 One way Challenge-Response..................................9 72 7.2 Mutual Challenge-Response..................................10 73 8. Algorithm Modes for Signature.............................12 74 8.1 Plain Signature...........................................12 75 8.2 Signature with Server Authentication......................13 76 9. Security Considerations...................................14 77 9.1 Security Analysis of the OCRA algorithm....................14 78 9.2 Implementation Considerations..............................15 79 10. IANA Considerations.......................................16 80 11. Conclusion................................................16 81 12. Acknowledgements..........................................17 82 13. References................................................17 83 13.1 Normative.................................................17 84 13.2 Informative...............................................17 85 Appendix A: Source Code........................................18 86 14. Authors' Addresses........................................25 87 1. Introduction 89 OATH has identified several use cases and scenarios that require an 90 asynchronous variant to accommodate users who do not want to 91 maintain a synchronized authentication system. A commonly accepted 92 method for this is to use a challenge-response scheme. 94 Such challenge response mode of authentication is widely adopted in 95 the industry. Several vendors already offer software applications 96 and hardware devices implementing challenge-response - but each of 97 those uses vendor-specific proprietary algorithms. For the benefits 98 of users there is a need for a standardized challenge-response 99 algorithm which allows multi-sourcing of token purchases and 100 validation systems to facilitate the democratization of strong 101 authentication. 102 Additionally, this specification describes the means to create 103 symmetric key based digital signatures. Such signatures are 104 variants of challenge-response mode where the data to be signed 105 becomes the challenge. 107 2. Requirements Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in RFC 2119 112 [RFC2119]. 114 3. Algorithm Requirements 116 This section presents the main requirements that drove this 117 algorithm design. A lot of emphasis was placed on flexibility and 118 usability, under the constraints and specificity of the HOTP 119 algorithm and hardware token capabilities. 121 R1 - The algorithm MUST support asynchronous challenge-response 122 based authentication. 124 R2 - The algorithm MUST be capable of supporting symmetric key 125 based digital signatures. Essentially this is a variation of 126 challenge-response where the challenge is derived from the data 127 that need to be signed. 129 R3 - The algorithm MUST be capable of supporting server- 130 authentication, whereby the user can verify that he/she is talking 131 to a trusted server. 133 R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building 134 block. 136 R5 - The length and format of the input challenge SHOULD be 137 configurable. 139 R6 - The output length and format of the generated response SHOULD 140 be configurable. 142 R7 - The challenge MAY be generated with integrity checking (e.g., 143 parity bits). This will allow tokens with pin pads to perform 144 simple error checking when the user enters the challenge value into 145 a token. 147 R8 - There MUST be a unique secret (key) for each token/soft token 148 that is shared between the token and the authentication server. The 149 keys MUST be randomly generated or derived using a key derivation 150 algorithm. 152 R9 - The algorithm MAY enable additional data attributes such as a 153 timestamp or session information to be included in the computation. 154 These data inputs MAY be used individually or all together. 156 4. OCRA Background 158 OATH introduced the HOTP algorithm as a first open, freely 159 available building block towards strengthening authentication for 160 end-users in a variety of applications. One-time passwords are very 161 efficient at solving specific security issues thanks to the dynamic 162 nature of OTP computations. 164 After carefully analyzing different use cases, OATH came to the 165 conclusion that providing for extensions to the HOTP algorithms was 166 important. A very natural extension is to introduce a challenge 167 mode for computing HOTP values based on random questions. Equally 168 beneficial is being able to perform mutual authentication between 169 two parties, or short-signature computation for authenticating 170 transaction to improve the security of e-commerce applications. 172 4.1 HOTP Algorithm 174 The HOTP algorithm, as defined in [RFC4226] is based on an 175 increasing counter value and a static symmetric key known only to 176 the prover and verifier parties. 178 As a reminder: 180 HOTP(K,C) = Truncate(HMAC-SHA1(K,C)) 182 Where Truncate represents the function that converts an HMAC-SHA-1 183 value into an HOTP value. 185 We refer the reader to [RFC4226] for the full description and 186 further details on the rationale and security analysis of HOTP. 188 The present draft describes the different variants based on similar 189 constructions as HOTP. 191 5. Definition of OCRA 193 OCRA is a generalization of HOTP with variable data inputs not 194 solely based on an incremented counter and secret key values. 196 The definition of OCRA requires a cryptographic function, a key K 197 and a set of DataInput parameters. This section first formally 198 introduces the OCRA algorithm and then introduces the definitions 199 and default values recommended for all parameters. 201 In a nutshell, 202 OCRA = CryptoFunction(K, DataInput) 204 Where: 206 - K: a shared secret key known to both parties; 207 - DataInput: a structure that contains the concatenation of the 208 various input data values defined in details in section 5.1; 209 - CryptoFunction: this is the function performing the OCRA 210 computation from the secret key K and the DataInput material; 211 CryptoFunction is described in details in section 5.2. 213 5.1 DataInput Parameters 215 This structure is the concatenation over byte array of the 216 OCRASuite value as defined in section 6 with the different 217 parameters used in the computation, save for the secret key K. 219 DataInput = {OCRASuite | 00 | C | Q | P | S | T} where: 220 . OCRASuite is a value representing the suite of operations to 221 compute an OCRA response; 222 . 00 is a byte value used as a separator; 223 . C is an unsigned 8-byte counter value processed high-order bit 224 first, and MUST be synchronized between all parties; It loops 225 around from "{Hex}0" to "{Hex}FFFFFFFFFFFFFFFF" and then starts 226 over at "{Hex}0"; 227 . Q, mandatory, is a 128-byte list of (concatenated) challenge 228 question(s) generated by the parties; if Q is less than 128 229 bytes, then it should be padded with zeroes to the right; 230 . P is a hash (SHA1, SHA256 and SHA512 are supported) value of 231 PIN/password that is known to all parties during the execution 232 of the algorithm; the length of P will depend on the hash 233 function that is used; 234 . S is an UTF-8 encoded string of length upto 512 bytes that 235 contains information about the current session; the length of 236 S is defined in the OCRASuite string; 237 . T is an 8-byte unsigned integer in big endian (i.e. network 238 byte order) representing the number of time-steps(seconds, 239 minutes, hours or days depending on the specified granularity) 240 since midnight UTC of January 1, 1970. More specificatlly, if 241 the OCRA computation includes a timestamp T, you SHOULD first 242 convert your current local time to UTC time (text form); you 243 can then derive the UTC time in the proper format (i.e. 244 seconds, minutes, hours or days elapsed from Epoch time); the 245 size of the time-step is defined in the OCRASuite string. 247 When computing a response, the concatenation order is always the 248 following: 249 C | 250 OTHER-PARTY-GENERATED-CHALLENGE-QUESTION | 251 YOUR-GENERATED-CHALLENGE-QUESTION | 252 P| S | T 254 If a value is empty (i.e. a certain input is not used in the 255 computation) then the value is simply not represented in the 256 string. 258 The counter on the token or client MUST be incremented every time a 259 new computation is requested by the user. The server's counter 260 value MUST only be incremented after a successful OCRA 261 authentication. 263 5.2 CryptoFunction 265 The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of 266 computation for OCRA is HOTP with the default 6-digit dynamic 267 truncation and a combination of DataInput values as the message to 268 compute the HMAC-SHA1 digest. 270 As indicated in section 5.1, we denote t as the length in digits of 271 the truncation output. For instance, if t = 6, then the output of 272 the truncation is a 6-digit value. 274 We define the HOTP family of functions as an extension to HOTP: 275 - HOTP-H-t: these are the different possible truncated versions of 276 HOTP, using the dynamic truncation method for extracting an HOTP 277 value from the HMAC output; 278 - We will denote HOTP-H-t as the realization of an HOTP function 279 that uses an HMAC function with the hash function H, and the 280 dynamic truncation as described in [RFC 4226] to extract a t- 281 digit value; 282 - t=0 means that no truncation is performed and the full HMAC value 283 is used for authentication purpose. 285 We list the following preferred modes of computation, where * 286 denotes the default CryptoFunction: 287 . HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC 288 and a dynamic truncation to a 4-digit value; this mode is not 289 recommended in the general case but can be useful when a very 290 short authentication code is needed by an application; 291 . *HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC 292 and a dynamic truncation to a 6-digit value; 293 . HOTP-SHA1-8: HOTP with SHA-1 as the hash function for HMAC 294 and a dynamic truncation to an 8-digit value; 295 . HOTP-SHA256-6: HOTP with SHA-256 as the hash function for 296 HMAC and a dynamic truncation to a 6-digit value; 297 . HOTP-SHA512-6: HOTP with SHA-512 as the hash function for 298 HMAC and a dynamic truncation to a 6-digit value; 300 This table summarizes all possible values for the CryptoFunction: 302 Name HMAC Function Used Size of Truncation (t) 303 -------------------------------------------------------------- 304 HOTP-SHA1-t HMAC-SHA1 0 (no truncation), 4-10 305 HOTP-SHA256-t HMAC-SHA256 0 (no truncation), 4-10 306 HOTP-SHA512-t HMAC-SHA512 0 (no truncation), 4-10 308 6. The OCRASuite 310 An OCRASuite value is a text string that captures one mode of 311 operation for the OCRA algorithm, completely specifying the various 312 options for that computation. An OCRASuite value is represented as 313 follows: 315 Algorithm:CryptoFunction:DataInput 317 The client and server need to agree on one or two values of 318 OCRASuite. These values may be agreed at time of token provisioning 319 or for more sophisticated client-server interactions these values 320 may be negotiated for every transaction. 322 Note that for Mutual Challenge-Response or Signature with Server 323 Authentication modes, the client and server will need to agree on 324 two values of OCRASuite - one for server computation and another 325 for client computation. 327 Algorithm 328 --------- 330 Description: Indicates the version of OCRA algorithm. 331 Values: OCRA-v where v represents the version number (e.g. 1, 2 332 etc.). This document specifies version 1 of the OCRA algorithm. 334 CryptoFunction 335 -------------- 337 Description: Indicates the function used to compute OCRA values 338 Values: Permitted values are described in section 5.2 340 DataInput 341 --------- 343 Description: This component of the OCRASuite string captures the 344 list of valid inputs for that computation; [] indicates a value is 345 optional: 346 [C] | QFxx | [PH | Snnn | TG] : Challenge-Response computation 347 [C] | QFxx | [PH | TG] : Plain Signature computation 349 Each input that is used for the computation is represented by a 350 single letter (except Q) and they are separated by a hyphen. 352 The input for challenge is further qualified by the formats 353 supported by the client for challenge question(s). Supported values 354 can be: 356 Format (F) Up To Length (xx) 357 -------------------------------------------------------------- 358 A (alphanumeric) 04-64 359 N (numeric) 04-64 360 H (hexadecimal) 04-64 362 The default challenge format is N08, numeric and upto 8 digits. 364 The input for P is further qualified by the hash function used for 365 the PIN/password. Supported values for hash function can be: 366 Hash function (H) - SHA1, SHA256, SHA512. 367 The default hash function for P is SHA1. 369 The input for S is further qualified by the length of the session 370 data in bytes. The client and server could agree to any length but 371 the typical values are: 372 Length (nnn) - 064, 128, 256 and 512. 373 The default length is 064 bytes. 375 The input for timestamps is further qualified by G, size of the 376 time-step. G can be specified in number of seconds, minutes or 377 hours: 379 Time-step size (G) 380 --------------------------------------------------------- 381 [1-59]S number of seconds, e.g. 20S 382 [1-59]M number of minutes, e.g. 5M 383 [0-48]H number of hours, e.g. 24H 385 Default value for G is 1M, i.e. time step size is one minute and 386 the T represents the number of minutes since Epoch time. 388 Here are some examples of OCRASuite strings: 389 - OCRA-1:HOTP-SHA512-8:C-QN08-PSHA1 means version 1 of the OCRA 390 algorithm with HMAC-SHA512 function, truncated to an 8-digit 391 value, using the counter, a random challenge and a SHA1 digest of 392 the PIN/Password as parameters. It also indicates that the client 393 supports only numeric challenge upto 8 digits in length; 394 - OCRA-1:HOTP-SHA256-6:QA10-T1M means version 1 of the OCRA 395 algorithm with HMAC-SHA256 function, truncated to a 6-digit 396 value, using a random alphanumeric challenge upto 10 characters 397 in length and a timestamp in number of minutes since Epoch time; 398 - OCRA-1:HOTP-SHA1-4:QH8-S512 means version 1 of the OCRA algorithm 399 with HMAC-SHA1 function, truncated to a 4-digit value, using a 400 random hexadecimal challenge upto 8 nibbles and a session value 401 of 512 bytes. 403 7. Algorithm Modes for Authentication 405 This section describes the typical modes in which the above defined 406 computation can be used for authentication. 408 7.1 One way Challenge-Response 410 A challenge/response is a security mechanism in which the verifier 411 presents a question (challenge) to the prover who must provide a 412 valid answer (response) to be authenticated. 414 To use this algorithm for a one-way challenge-response, the 415 verifier will communicate a challenge value (typically randomly 416 generated) to the prover. The prover will use the challenge in the 417 computation as described above. The prover then communicates the 418 response to the verifier to authenticate. 420 Therefore in this mode, the typical data inputs will be: 422 C - Counter, optional. 423 Q - Challenge question, mandatory, supplied by the verifier. 425 P - Hashed version of PIN/password, optional. 426 S - Session information, optional 427 T - Timestamp, optional. 428 The diagram below shows the message exchange between the client 429 (prover) and the server (verifier) to complete a one-way challenge- 430 response authentication. 432 It is assumed that the client and server have a pre-shared key K 433 that is used for the computation. 435 CLIENT SERVER 436 (PROVER) (VERIFIER) 437 | | 438 | Verifier sends challenge to prover | 439 | Challenge = Q | 440 |<------------------------------------------| 441 | | 442 | Prover Computes Response | 443 | R = OCRA(K, {[C] | Q | [P | S | T]}) | 444 | Prover sends Response = R | 445 |------------------------------------------>| 446 | | 447 | Verifier Validates Response | 448 | If Response is valid, Server sends OK | 449 | If Response is not, Server sends NOK | 450 |<------------------------------------------| 451 | | 453 7.2 Mutual Challenge-Response 455 Mutual challenge-response is a variation of one-way challenge- 456 response where both the client and server mutually authenticate 457 each other. 459 To use this algorithm, the client will first send a random client- 460 challenge to the server. The server computes the server-response 461 and sends it to the client along with a server-challenge. 463 The client will first verify the server-response to be assured that 464 it is talking to a valid server. It will then compute the client- 465 response and send it to the server to authenticate. The server 466 verifies the client-response to complete the two-way authentication 467 process. 469 In this mode there are two computations: client-response and 470 server-response. There are two separate challenge questions, 471 generated by both parties. We denote these challenge questions Q1 472 and Q2. 474 Typical data inputs for server-response computation will be: 475 C - Counter, optional. 476 QC - Challenge question, mandatory, supplied by the client. 477 QS - Challenge question, mandatory, supplied by the server. 478 S - Session information, optional. 479 T - Timestamp, optional. 481 Typical data inputs for client-response computation will be: 482 C - Counter, optional. 483 QS - Challenge question, mandatory, supplied by the server. 484 QC - Challenge question, mandatory, supplied by the client. 485 P - Hashed version of PIN/password, optional. 486 S - Session information, optional. 487 T - Timestamp, optional. 489 The following picture shows the messages that are exchanged between 490 the client and the server to complete a two-way mutual challenge- 491 response authentication. 493 It is assumed that the client and server have a pre-shared key K 494 (or pair of keys if using dual-key mode of computation) that is 495 used for the computation. 497 CLIENT SERVER 498 | | 499 | 1. Client sends client-challenge | 500 | QC = Client-challenge | 501 |-------------------------------------------------->| 502 | | 503 | 2. Server computes server-response | 504 | and sends server-challenge | 505 | RS = OCRA(K, [C] | QC | QS | [S | T]) | 506 | QS = Server-challenge | 507 | Response = RS, QS | 508 |<--------------------------------------------------| 509 | | 510 | 3. Client verifies server-response | 511 | and computes client-response | 512 | OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP | 513 | RC = OCRA(K, [C] | QS | QC | [P | S | T]) | 514 | Response = RC | 515 |-------------------------------------------------->| 516 | | 517 | 4. Server verifies client-response | 518 | OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP | 519 | Response = OK | 520 |<--------------------------------------------------| 521 | | 522 8. Algorithm Modes for Signature 524 In this section we describe the typical modes in which the above 525 defined computation can be used for digital signatures. 527 8.1 Plain Signature 529 To use this algorithm in plain signature mode, the server will 530 communicate a signature-challenge value to the client (signer). The 531 signature-challenge is either the data to be signed or derived from 532 the data to be signed using a hash function, for example. 534 The client will use the signature-challenge in the computation as 535 described above. The client then communicates the signature value 536 (response) to the server to authenticate. 538 Therefore in this mode, the data inputs will be: 540 C - Counter, optional. 541 QS - Signature-challenge, mandatory, supplied by the server. 542 P - Hashed version of PIN/password, optional. 543 T - Timestamp, optional. 545 The picture below shows the messages that are exchanged between the 546 client (prover) and the server (verifier) to complete a plain 547 signature operation. 549 It is assumed that the client and server have a pre-shared key K 550 that is used for the computation. 552 CLIENT SERVER 553 (PROVER) (VERIFIER) 554 | | 555 | Verifier sends signature-challenge | 556 | Challenge = QS | 557 |<------------------------------------------| 558 | | 559 | Client Computes Response | 560 | SIGN = OCRA(K, [C] | QS | [P | T]) | 561 | Response = SIGN | 562 |------------------------------------------>| 563 | | 564 | Verifier Validates Response | 565 | Response = OK | 566 |<------------------------------------------| 567 | | 568 8.2 Signature with Server Authentication 570 This mode is a variation of the plain signature mode where the 571 client can first authenticates the server before generating a 572 digital signature. 574 To use this algorithm, the client will first send a random client- 575 challenge to the server. The server computes the server-response 576 and sends it to the client along with a signature-challenge. 578 The client will first verify the server-response to authenticate 579 that it is talking to a valid server. It will then compute the 580 signature and send it to the server. 582 In this mode there are two computations: client-signature and 583 server-response. 585 Typical data inputs for server-response computation will be: 587 C - Counter, optional. 588 QC - Challenge question, mandatory, supplied by the client. 589 QS - Signature-challenge, mandatory, supplied by the server. 590 T - Timestamp, optional. 592 Typical data inputs for client-signature computation will be: 594 C - Counter, optional. 595 QC - Challenge question, mandatory, supplied by the client. 596 QS - Signature-challenge, mandatory, supplied by the server. 597 P - Hashed version of PIN/password, optional. 598 T - Timestamp, optional. 600 The diagram below shows the messages that are exchanged between the 601 client and the server to complete a signature with server 602 authentication transaction. 604 It is assumed that the client and server have a pre-shared key K 605 (or pair of keys if using dual-key mode of computation) that is 606 used for the computation. 608 CLIENT SERVER 609 | | 610 | 1. Client sends client-challenge | 611 | QC = Client-challenge | 612 |-------------------------------------------------->| 613 | | 614 | 2. Server computes server-response | 615 | and sends signature-challenge | 616 | RS = OCRA(K, [C] | QC | QS | [T]) | 617 | QS = signature-challenge | 618 | Response = RS, QS | 619 |<--------------------------------------------------| 620 | | 621 | 3. Client verifies server-response | 622 | and computes signature | 623 | OCRA(K, [C] | QC | QS | [T]) != RS -> STOP | 624 | SIGN = OCRA( K, [C] | QS | QC | [P | T]) | 625 | Response = SIGN | 626 |-------------------------------------------------->| 627 | | 628 | 4. Server verifies Signature | 629 | OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP | 630 | Response = OK | 631 |<--------------------------------------------------| 632 | | 634 9. Security Considerations 636 Any algorithm is only as secure as the application and the 637 authentication protocols that implement it. Therefore, this section 638 discusses the critical security requirements that our choice of 639 algorithm imposes on the authentication protocol and validation 640 software. 642 9.1 Security Analysis of the OCRA algorithm 644 The security and strength of this algorithm depends on the 645 properties of the underlying building block HOTP, which is a 646 construction based on HMAC [RFC2104] using SHA-1 as the hash 647 function. 649 The conclusion of the security analysis detailed in [RFC4226] is 650 that, for all practical purposes, the outputs of the dynamic 651 truncation on distinct counter inputs are uniformly and 652 independently distributed strings. 654 The analysis demonstrates that the best possible attack against the 655 HOTP function is the brute force attack. 657 9.2 Implementation Considerations 659 IC1 - In the authentication mode, the client MUST support two- 660 factor authentication, i.e., the communication and verification of 661 something you know (secret code such as a Password, Pass phrase, 662 PIN code, etc.) and something you have (token). The secret code is 663 known only to the user and usually entered with the Response value 664 for authentication purpose (two-factor authentication). 665 Alternatively, instead of sending something you know to the server, 666 the client may use a hash of the Password or PIN code in the 667 computation itself, thus implicitly enabling two-factor 668 authentication. 670 IC2 - Keys should be of the length of the CryptoFunction output to 671 facilitate interoperability. 673 IC3 - Keys SHOULD be chosen at random or using a cryptographically 674 strong pseudo-random generator properly seeded with a random value. 675 We RECOMMEND following the recommendations in [RFC1750] for all 676 pseudo-random and random generations. The pseudo-random numbers 677 used for generating the keys SHOULD successfully pass the 678 randomness test specified in [CN]. 680 IC4 - Challenge questions SHOULD be 20-byte values and MUST be at 681 least t-byte values where t stands for the digit-length of the OCRA 682 truncation output. 684 IC5 - On the client side, the keys SHOULD be embedded in a tamper 685 resistant device or securely implemented in a software application. 686 Additionally, by embedding the keys in a hardware device, you also 687 have the advantage of improving the flexibility (mobility) of the 688 authentication system. 690 IC6 - We RECOMMEND following the recommendations in [RFC1750] for 691 all pseudo-random and random challenge generations. 693 IC7 - All the communications SHOULD take place over a secure 694 channel e.g. SSL/TLS, IPsec connections. 696 IC8 - The OCRA algorithm when used in mutual authentication mode or 697 in signature with server authentication mode MAY use dual key mode 698 - i.e. there are two keys that are shared between the client and 699 the server. One shared key is used to generate the server response 700 on the server side and to verify it on the client side. The other 701 key is used to create the response or signature on the client side 702 and to verify it on the server side. 704 IC9 - We recommend that implementations MAY use the session 705 information, S as an additional input in the computation. For 706 example, S could be the session identifier from the TLS session. 707 This will enable you to counter certain types of man-in-the-middle 708 attacks. However, this will introduce the additional dependency 709 that first of all the prover needs to have access to the session 710 identifier to compute the response and the verifier will need 711 access to the session identifier to verify the response. 713 IC10 - In the signature mode, whenever the counter or time (defined 714 as optional elements) are not used in the computation, there might 715 be a risk of replay attack and the implementers should carefully 716 consider this issue in the light of their specific application 717 requirements and security guidelines. The server SHOULD also 718 provide whenever possible a mean for the client (if able) to verify 719 the validity of the signature challenge. 721 IC11 - We also RECOMMEND storing the keys securely in the 722 validation system, and more specifically encrypting them using 723 tamper-resistant hardware encryption and exposing them only when 724 required: for example, the key is decrypted when needed to verify 725 an OCRA response, and re-encrypted immediately to limit exposure in 726 the RAM for a short period of time. The key store MUST be in a 727 secure area, to avoid as much as possible direct attack on the 728 validation system and secrets database. Particularly, access to the 729 key material should be limited to programs and processes required 730 by the validation system only. 732 10. IANA Considerations 734 This document has no actions for IANA. 736 11. Conclusion 738 This draft introduced several variants of HOTP for challenge- 739 response based authentication and short signature-like 740 computations. 742 The OCRASuite provides for an easy integration and support of 743 different flavors within an authentication and validation system. 745 Finally, OCRA should enable mutual authentication both in connected 746 and off-line modes, with the support of different response sizes 747 and mode of operations. 749 12. Acknowledgements 751 We would like to thank Jeff Burstein, Shuh Chang, Oanh Hoang, 752 Philip Hoyer, Jon Martinsson, Frederik Mennes, Mingliang Pei, 753 Jonathan Tuliani, Stu Vaeth, Enrique Rodriguez and Robert 754 Zuccherato for their comments and suggestions to improve this draft 755 document. 757 13. References 759 13.1 Normative 761 [RFC2104] M. Bellare, R. Canetti and H. Krawczyk, "HMAC: 762 Keyed-Hashing for Message Authentication", IETF Network 763 Working Group, RFC 2104, February 1997. 765 [RFC1750] D. Eastlake, 3rd., S. Crocker and J. Schiller, 766 "Randomness Recommendations for Security", IETF Network 767 Working Group, RFC 1750, December 2004. 769 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, March 1997. 772 [RFC3668] S. Bradner, "Intellectual Property Rights in IETF 773 Technology", BCP 79, RFC 3668, February 2004. 775 [RFC4226] D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and 776 O. Ranen, "HOTP: An HMAC-based One Time Password 777 Algorithm", IETF Network Working Group, RFC 4226, 778 December 2005. 780 13.2 Informative 782 [BCK] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash 783 Functions and Message Authentication", Proceedings of 784 Crypto'96, LNCS Vol. 1109, pp. 1-15. 786 [OATH] Initiative for Open AuTHentication 787 http://www.openauthentication.org 789 [CN] J.S. Coron and D. Naccache, "An accurate evaluation of 790 Maurer's universal test" by Jean-Sebastien Coron and 791 David Naccache In Selected Areas in Cryptography (SAC 792 '98), vol. 1556 of Lecture Notes in Computer Science, 793 S. Tavares and H. Meijer, Eds., pp. 57-71, Springer- 794 Verlag, 1999 795 Appendix A: Source Code 797 import java.lang.reflect.UndeclaredThrowableException; 798 import java.security.GeneralSecurityException; 799 import javax.crypto.Mac; 800 import javax.crypto.spec.SecretKeySpec; 801 import java.math.BigInteger; 803 /** 804 * This an example implementation of the OATH OCRA algorithm. 805 * Visit www.openauthentication.org for more information. 806 * 807 * @author Johan Rydell, PortWise 808 */ 810 public class OCRA { 812 private OCRA() {} 814 /** 815 * This method uses the JCE to provide the crypto 816 * algorithm. 817 * HMAC computes a Hashed Message Authentication Code with the 818 * crypto hash algorithm as a parameter. 819 * 820 * @param crypto the crypto algorithm 821 * (HmacSHA1, HmacSHA256, HmacSHA512) 822 * @param keyBytes the bytes to use for the HMAC key 823 * @param text the message or text to be authenticated. 824 */ 825 public static byte[] hmac_sha1(String crypto, 826 byte[] keyBytes, 827 byte[] text){ 828 try { 829 Mac hmac; 830 hmac = Mac.getInstance(crypto); 831 SecretKeySpec macKey = 832 new SecretKeySpec(keyBytes, "RAW"); 833 hmac.init(macKey); 834 return hmac.doFinal(text); 835 } 836 catch (GeneralSecurityException gse) { 837 throw new UndeclaredThrowableException(gse); 838 } 839 } 841 private static final int[] DIGITS_POWER 842 // 0 1 2 3 4 5 6 7 8 843 = {1,10,100,1000,10000,100000,1000000,10000000,100000000 }; 845 /** 846 * This method generates an OCRA HOTP value for the given 847 * set of parameters. 848 * 849 * @param ocraSuite the OCRA Suite 850 * @param key the shared secret, HEX encoded 851 * @param counter the counter that changes on a per use basis, 852 * HEX encoded 853 * @param question the challenge question 854 * @param password a password that can be used 855 * @param sessionInformation Static information that identifies 856 * the current session 857 * @param timeStamp a value that reflects a time 858 * 859 * @return A numeric String in base 10 that includes 860 * {@link truncationDigits} digits 861 */ 862 static public String generateOCRA(String ocraSuite, 863 String key, 864 String counter, 865 String question, 866 String password, 867 String sessionInformation, 868 String timeStamp){ 870 int codeDigits = 0; 871 String crypto = ""; 872 String result = null; 873 int ocraSuiteLength = ocraSuite.length(); 874 int counterLength = 0; 875 int questionLength = 0; 876 int passwordLength = 0; 877 int sessionInformationLength = 0; 878 int timeStampLength = 0; 880 if(ocraSuite.toLowerCase().indexOf("sha1") > 1) 881 crypto = "HmacSHA1"; 882 if(ocraSuite.toLowerCase().indexOf("sha256") > 1) 883 crypto = "HmacSHA256"; 884 if(ocraSuite.toLowerCase().indexOf("sha512") > 1) 885 crypto = "HmacSHA512"; 887 // How many digits should we return 888 String oS = ocraSuite.substring(ocraSuite.indexOf(":"), 889 ocraSuite.indexOf(":", ocraSuite.indexOf(":") + 1)); 890 codeDigits = Integer.decode(oS.substring(oS.lastIndexOf("-")+1, 891 oS.length())); 893 // The size of the byte array message to be encrypted 894 // Counter 895 if(ocraSuite.toLowerCase().indexOf(":c") > 1) { 896 counterLength=8; 897 } 898 // Question 899 if((ocraSuite.toLowerCase().indexOf(":q") > 1) || 900 (ocraSuite.toLowerCase().indexOf("-q") > 1)) { 901 questionLength=128; 902 } 903 // Password - sha1 supported 904 if((ocraSuite.toLowerCase().indexOf(":psha1") > 1) || 905 (ocraSuite.toLowerCase().indexOf("-psha1") > 1)){ 906 passwordLength=20; 907 } 908 // sessionInformation 909 if((ocraSuite.toLowerCase().indexOf(":s") > 1) || 910 (ocraSuite.toLowerCase().indexOf("-s", 911 ocraSuite.indexOf(":", 912 ocraSuite.indexOf(":") + 1)) > 1)){ 913 sessionInformationLength=64; 914 } 915 // TimeStamp 916 if((ocraSuite.toLowerCase().indexOf(":t") > 1) || 917 (ocraSuite.toLowerCase().indexOf("-t") > 1)){ 918 timeStampLength=8; 919 } 921 // Remember to add "1" for the "00" byte delimiter 922 byte[] msg = new byte[ocraSuiteLength + 923 counterLength + 924 questionLength + 925 passwordLength + 926 sessionInformationLength + 927 timeStampLength + 928 1]; 930 // Put the bytes of "ocraSuite" parameters into the message 931 byte[] bArray = ocraSuite.getBytes(); 932 for(int i = 0; i < bArray.length; i++){ 933 msg[i] = bArray[i]; 934 } 936 // Put the bytes of "Counter" to the message 937 // Input is HEX encoded 938 if(counter.length() > 0 ){ 939 bArray = new BigInteger(counter,16).toByteArray(); 940 if(bArray.length == 9){ 941 // First byte is the "sign" byte 942 for (int i = 0; i < 8 && i < bArray.length ; i++) { 943 msg[i + 8 - bArray.length + ocraSuiteLength + 1] = 944 bArray[i+1]; 945 } 946 } 947 else { 948 for (int i = 0; i < 8 && i < bArray.length ; i++) { 949 msg[i + 8 - bArray.length + ocraSuiteLength + 1] 950 = bArray[i]; 951 } 952 } 953 } 955 // Put the bytes of "question" to the message 956 // Input is text encoded 957 if(question.length() > 0 ){ 958 bArray = question.getBytes(); 959 for (int i = 0; i < 128 && i < bArray.length ; i++) { 960 msg[i + ocraSuiteLength + 1 + counterLength] = bArray[i]; 961 } 962 } 964 // Put the bytes of "password" to the message 965 // Input is HEX encoded 966 if(password.length() > 0){ 967 bArray = new BigInteger(password,16).toByteArray(); 968 if(bArray.length == 21){ 969 // First byte is the "sign" byte 970 for (int i = 0; i < 20 && i < bArray.length ; i++) { 971 msg[i + ocraSuiteLength + 1 + 972 counterLength + questionLength] 973 = bArray[i+1]; 974 } 975 } 976 else { 977 for (int i = 0; i < 20 && i < bArray.length ; i++) { 978 msg[i + ocraSuiteLength + 1 + 979 counterLength + questionLength] 980 = bArray[i]; 981 } 982 } 983 } 985 // Put the bytes of "sessionInformation" to the message 986 // Input is text encoded 987 if(sessionInformation.length() > 0 ){ 988 bArray = sessionInformation.getBytes(); 989 for (int i = 0; i < 128 && i < bArray.length ; i++) { 990 msg[i + ocraSuiteLength + 1 + 991 counterLength + questionLength + 992 passwordLength] = bArray[i]; 993 } 994 } 996 // Put the bytes of "time" to the message 997 // Input is text value of minutes 998 if(timeStamp.length() > 0){ 999 bArray = new BigInteger(timeStamp,16).toByteArray(); 1000 if(bArray.length == 9){ 1001 // First byte is the "sign" byte 1002 for (int i = 0; i < 8 && i < bArray.length ; i++) { 1003 msg[i + 8 - bArray.length + ocraSuiteLength + 1 + 1004 counterLength + questionLength + 1005 passwordLength + sessionInformationLength] = 1006 bArray[i+1]; 1007 } 1008 } 1009 else { 1010 for (int i = 0; i < 8 && i < bArray.length ; i++) { 1011 msg[i + 8 - bArray.length + ocraSuiteLength + 1 + 1012 counterLength + questionLength + 1013 passwordLength + sessionInformationLength] = 1014 bArray[i]; 1015 } 1016 } 1018 } 1020 byte[] hash; 1021 bArray = new BigInteger(key,16).toByteArray(); 1022 if(bArray[0] == 0){ 1023 byte[] b = new byte[bArray.length - 1]; 1024 for(int i = 0 ; i < b.length; i++) 1025 b[i]=bArray[i+1]; 1026 hash = hmac_sha1(crypto, b, msg); 1027 } 1028 else{ 1029 // compute hmac hash 1030 hash = hmac_sha1(crypto, bArray, msg); 1031 } 1033 // put selected bytes into result int 1034 int offset = hash[hash.length - 1] & 0xf; 1036 int binary = 1037 ((hash[offset] & 0x7f) << 24) | 1038 ((hash[offset + 1] & 0xff) << 16) | 1039 ((hash[offset + 2] & 0xff) << 8) | 1040 (hash[offset + 3] & 0xff); 1042 int otp = binary % DIGITS_POWER[codeDigits]; 1044 result = Integer.toString(otp); 1045 while (result.length() < codeDigits) { 1046 result = "0" + result; 1047 } 1048 return result; 1049 } 1050 } 1051 Appendix B: Test Vectors 1053 Time of (Mar 25 2008, 12:06:30 GMT) is in 1054 (millis): 1206446790000 (min): 20107446 (HEX): 132d0b6 1055 Time of (Mar 25 2008, 12:06:30 GMT) is the same as this localized 1056 time: Tue Mar 25 05:06:30 PDT 2008 1058 Standard 20Byte key: 3132333435363738393031323334353637383930 1059 Standard 32Byte key: 3132333435363738393031323334353637383930 1060 313233343536373839303132 1061 Standard 64Byte key: 3132333435363738393031323334353637383930 1062 3132333435363738393031323334353637383930 1063 3132333435363738393031323334353637383930 1064 31323334 1066 Plain challenge response 1067 ======================== 1069 OCRA-1:HOTP-SHA1-6:QN08 1070 ======================= 1071 Key: Standard 20Byte Q: 00000000OCRA: 713673 1072 Key: Standard 20Byte Q: 11111111OCRA: 640542 1073 Key: Standard 20Byte Q: 22222222OCRA: 434144 1074 Key: Standard 20Byte Q: 33333333OCRA: 024883 1075 Key: Standard 20Byte Q: 44444444OCRA: 473006 1076 Key: Standard 20Byte Q: 55555555OCRA: 911781 1077 Key: Standard 20Byte Q: 66666666OCRA: 059218 1078 Key: Standard 20Byte Q: 77777777OCRA: 175339 1079 Key: Standard 20Byte Q: 88888888OCRA: 478461 1080 Key: Standard 20Byte Q: 99999999OCRA: 681743 1082 OCRA-1:HOTP-SHA256-8:QN08-PSHA1 1083 =============================== 1084 Key: Standard 32Byte Q: 00000000PIN (1234): 1085 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 40675653 1086 Key: Standard 32Byte Q: 11111111PIN (1234): 1087 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 14928254 1088 Key: Standard 32Byte Q: 22222222PIN (1234): 1089 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 09120993 1090 Key: Standard 32Byte Q: 33333333PIN (1234): 1091 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 50886787 1092 Key: Standard 32Byte Q: 44444444PIN (1234): 1093 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 23934759 1094 OCRA-1:HOTP-SHA512-8:C-QN08 1095 =========================== 1096 Key: Standard 64Byte C: 00000 Q: 00000000OCRA: 81947120 1097 Key: Standard 64Byte C: 00001 Q: 11111111OCRA: 46439675 1098 Key: Standard 64Byte C: 00002 Q: 22222222OCRA: 44178142 1099 Key: Standard 64Byte C: 00003 Q: 33333333OCRA: 33562866 1100 Key: Standard 64Byte C: 00004 Q: 44444444OCRA: 99699620 1101 Key: Standard 64Byte C: 00005 Q: 55555555OCRA: 73476531 1102 Key: Standard 64Byte C: 00006 Q: 66666666OCRA: 44853974 1103 Key: Standard 64Byte C: 00007 Q: 77777777OCRA: 99378156 1104 Key: Standard 64Byte C: 00008 Q: 88888888OCRA: 87993791 1105 Key: Standard 64Byte C: 00009 Q: 99999999OCRA: 56984649 1107 OCRA-1:HOTP-SHA512-8:QN08-T1M 1108 =========================== 1109 Key: Standard 64Byte Q: 00000000 T: 132d0b6 OCRA: 66401302 1110 Key: Standard 64Byte Q: 11111111 T: 132d0b6 OCRA: 23050616 1111 Key: Standard 64Byte Q: 22222222 T: 132d0b6 OCRA: 39524082 1112 Key: Standard 64Byte Q: 33333333 T: 132d0b6 OCRA: 97622335 1113 Key: Standard 64Byte Q: 44444444 T: 132d0b6 OCRA: 16392830 1115 Mutual Challenge Response 1116 ========================= 1118 OCRASuite (server computation) = OCRA-1:HOTP-SHA256-8:QA08 1119 OCRASuite (client computation) = OCRA-1:HOTP-SHA256-8:QA08 1120 ========================================================== 1121 (server)Key: Standard 32Byte Q: CLI22220SRV11110 OCRA: 28247970 1122 (client)Key: Standard 32Byte Q: SRV11110CLI22220 OCRA: 15510767 1123 (server)Key: Standard 32Byte Q: CLI22221SRV11111 OCRA: 01984843 1124 (client)Key: Standard 32Byte Q: SRV11111CLI22221 OCRA: 90175646 1125 (server)Key: Standard 32Byte Q: CLI22222SRV11112 OCRA: 65387857 1126 (client)Key: Standard 32Byte Q: SRV11112CLI22222 OCRA: 33777207 1127 (server)Key: Standard 32Byte Q: CLI22223SRV11113 OCRA: 03351211 1128 (client)Key: Standard 32Byte Q: SRV11113CLI22223 OCRA: 95285278 1129 (server)Key: Standard 32Byte Q: CLI22224SRV11114 OCRA: 83412541 1130 (client)Key: Standard 32Byte Q: SRV11114CLI22224 OCRA: 28934924 1132 OCRASuite (server computation) = OCRA-1:HOTP-SHA512-8:QA08 1133 OCRASuite (client computation) = OCRA-1:HOTP-SHA512-8:QA08-PSHA1 1134 ============================================================ 1135 (server)Key: Standard 64Byte Q: CLI22220SRV11110 OCRA: 79496648 1136 (client)Key: Standard 64Byte Q: SRV11110CLI22220 1137 P: 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 18806276 1138 (server)Key: Standard 64Byte Q: CLI22221SRV11111 OCRA: 76831980 1139 (client)Key: Standard 64Byte Q: SRV11111CLI22221 1140 P: 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 70020315 1141 (server)Key: Standard 64Byte Q: CLI22222SRV11112 OCRA: 12250499 1142 (client)Key: Standard 64Byte Q: SRV11112CLI22222 1143 P: 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 01600026 1144 (server)Key: Standard 64Byte Q: CLI22223SRV11113 OCRA: 90856481 1145 (client)Key: Standard 64Byte Q: SRV11113CLI22223 1146 P: 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 18951020 1147 (server)Key: Standard 64Byte Q: CLI22224SRV11114 OCRA: 12761449 1148 (client)Key: Standard 64Byte Q: SRV11114CLI22224 1149 P: 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 OCRA: 32528969 1151 Plain Signature 1152 =============== 1154 OCRA-1:HOTP-SHA256-8:QA08 1155 ========================= 1156 Key: Standard 32Byte Q(Signature challenge): SIG10000 1157 OCRA: 53095496 1158 Key: Standard 32Byte Q(Signature challenge): SIG11000 1159 OCRA: 04110475 1160 Key: Standard 32Byte Q(Signature challenge): SIG12000 1161 OCRA: 31331128 1162 Key: Standard 32Byte Q(Signature challenge): SIG13000 1163 OCRA: 76028668 1164 Key: Standard 32Byte Q(Signature challenge): SIG14000 1165 OCRA: 46554205 1167 OCRA-1:HOTP-SHA512-8:QA10-T1M 1168 ============================= 1169 Key: Standard 64Byte Q(Signature challenge): SIG1000000 1170 T: 132d0b6 OCRA: 77537423 1171 Key: Standard 64Byte Q(Signature challenge): SIG1100000 1172 T: 132d0b6 OCRA: 31970405 1173 Key: Standard 64Byte Q(Signature challenge): SIG1200000 1174 T: 132d0b6 OCRA: 10235557 1175 Key: Standard 64Byte Q(Signature challenge): SIG1300000 1176 T: 132d0b6 OCRA: 95213541 1177 Key: Standard 64Byte Q(Signature challenge): SIG1400000 1178 T: 132d0b6 OCRA: 65360607 1180 14. Authors' Addresses 1182 Primary point of contact (for sending comments and question): 1184 David M'Raihi 1185 VeriSign, Inc. 1186 685 E. Middlefield Road Phone: 1-650-426-3832 1187 Mountain View, CA 94043 USA Email: dmraihi@verisign.com 1188 Other Authors' contact information: 1190 Johan Rydell 1191 Portwise, Inc. 1192 275 Hawthorne Ave, Suite 119 Phone: 1-650-515-3569 1193 Palo Alto, CA 94301 USA Email: johan.rydell@portwise.com 1195 David Naccache 1196 ENS, DI 1197 45 rue d'Ulm Phone: +33 6 16 59 83 49 1198 75005, Paris France Email: david.naccache@ens.fr 1200 Salah Machani 1201 Diversinet Corp. 1202 2225 Sheppard Avenue East 1203 Suite 1801 1204 Toronto, Ontario M2J 5C2 Phone: 1-416-756-2324 Ext. 321 1205 Canada Email: smachani@diversinet.com 1207 Siddharth Bajaj 1208 VeriSign, Inc. 1209 487 E. Middlefield Road Phone: 1-650-426-3458 1210 Mountain View, CA 94043 USA Email: sbajaj@verisign.com