idnits 2.17.1 draft-mraihi-mutual-oath-hotp-variants-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([RFC4226]), 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 885 has weird spacing: '...eyBytes the ...' == Line 911 has weird spacing: '...ram hex the ...' == Line 929 has weird spacing: '...raSuite the...' == Line 937 has weird spacing: '...meStamp a v...' -- 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 (March 11, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'C' is mentioned on line 662, but not defined == Missing Reference: 'T' is mentioned on line 656, but not defined == Unused Reference: 'RFC5929' is defined on line 834, but no explicit reference was found in the text == Unused Reference: 'UT' is defined on line 838, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. M'Raihi 3 Internet-Draft Verisign, Inc. 4 Intended status: Informational J. Rydell 5 Expires: September 12, 2011 Portwise, Inc. 6 S. Bajaj 7 Symantec Corp. 8 S. Machani 9 Diversinet Corp. 10 D. Naccache 11 Ecole Normale Superieure 12 March 11, 2011 14 OCRA: OATH Challenge-Response Algorithms 15 draft-mraihi-mutual-oath-hotp-variants-14.txt 17 Abstract 19 This document describes an algorithm for challenge-response 20 authentication developed by the "Initiative for Open AuTHentication" 21 (OATH). The specified mechanisms leverage the HMAC-based One-Time 22 Password algorithm (HOTP) [RFC4226] and offer one-way and mutual 23 authentication, and digital signature capabilities. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 12, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 3 61 3. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 3 62 4. OCRA Background . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. HOTP Algorithm . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Definition of OCRA . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. DataInput Parameters . . . . . . . . . . . . . . . . . . . 5 66 5.2. CryptoFunction . . . . . . . . . . . . . . . . . . . . . . 6 67 6. The OCRASuite . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.2. CryptoFunction . . . . . . . . . . . . . . . . . . . . . . 8 70 6.3. DataInput . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.4. OCRASuite Examples . . . . . . . . . . . . . . . . . . . . 10 72 7. Algorithm Modes for Authentication . . . . . . . . . . . . . . 10 73 7.1. One way Challenge-Response . . . . . . . . . . . . . . . . 10 74 7.2. Mutual Challenge-Response . . . . . . . . . . . . . . . . 11 75 7.3. Algorithm Modes for Signature . . . . . . . . . . . . . . 12 76 7.3.1. Plain Signature . . . . . . . . . . . . . . . . . . . 13 77 7.3.2. Signature with Server Authentication . . . . . . . . . 13 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 8.1. Security Analysis of the OCRA algorithm . . . . . . . . . 15 80 8.2. Implementation Considerations . . . . . . . . . . . . . . 16 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 12.1. Normative references . . . . . . . . . . . . . . . . . . . 18 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 87 Appendix A. Reference Implementation . . . . . . . . . . . . . . 19 88 Appendix B. Test Vectors Generation . . . . . . . . . . . . . . . 26 89 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 34 90 C.1. Plain challenge response . . . . . . . . . . . . . . . . . 34 91 C.2. Mutual Challenge Response . . . . . . . . . . . . . . . . 36 92 C.3. Plain Signature . . . . . . . . . . . . . . . . . . . . . 37 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 95 1. Introduction 97 OATH [OATH] has identified several use cases and scenarios that 98 require an asynchronous variant to accommodate users who do not want 99 to maintain a synchronized authentication system. A commonly 100 accepted method for this is to use a challenge-response scheme. 102 Such challenge response mode of authentication is widely adopted in 103 the industry. Several vendors already offer software applications 104 and hardware devices implementing challenge-response - but each of 105 those uses vendor-specific proprietary algorithms. For the benefits 106 of users there is a need for a standardized challenge-response 107 algorithm which allows multi-sourcing of token purchases and 108 validation systems to facilitate the democratization of strong 109 authentication. 111 Additionally, this specification describes the means to create 112 symmetric key based short digital signatures. Such signatures are 113 variants of challenge-response mode where the data to be signed 114 becomes the challenge. 116 2. Notation and Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Algorithm Requirements 124 This section presents the main requirements that drove this algorithm 125 design. A lot of emphasis was placed on flexibility and usability, 126 under the constraints and specificity of the HOTP algorithm and 127 hardware token capabilities. 129 R1 - The algorithm MUST support challenge-response based 130 authentication. 132 R2 - The algorithm MUST be capable of supporting symmetric key based 133 short digital signatures. Essentially this is a variation of 134 challenge-response where the challenge is derived from the data that 135 needs to be signed. 137 R3 - The algorithm MUST be capable of supporting server- 138 authentication, whereby the user can verify that he/she is talking to 139 a trusted server. 141 R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building block. 143 R5 - The length and format of the input challenge SHOULD be 144 configurable. 146 R6 - The output length and format of the generated response SHOULD be 147 configurable. 149 R7 - The challenge MAY be generated with integrity checking (e.g., 150 parity bits). This will allow tokens with pin pads to perform simple 151 error checking when the user enters the challenge value into a token. 153 R8 - There MUST be a unique secret (key) for each token/soft token 154 that is shared between the token and the authentication server. The 155 keys MUST be randomly generated or derived using a key derivation 156 algorithm. 158 R9 - The algorithm MAY enable additional data attributes such as a 159 timestamp or session information to be included in the computation. 160 These data inputs MAY be used individually or all together. 162 4. OCRA Background 164 OATH introduced the HOTP algorithm as a first open, freely available 165 building block towards strengthening authentication for end-users in 166 a variety of applications. One-time passwords are very efficient at 167 solving specific security issues thanks to the dynamic nature of OTP 168 computations. 170 After carefully analyzing different use cases, OATH came to the 171 conclusion that providing for extensions to the HOTP algorithms was 172 important. A very natural extension is to introduce a challenge mode 173 for computing HOTP values based on random questions. Equally 174 beneficial is being able to perform mutual authentication between two 175 parties, or short-signature computation for authenticating 176 transaction to improve the security of e-commerce applications. 178 4.1. HOTP Algorithm 180 The HOTP algorithm, as defined in [RFC4226] is based on an increasing 181 counter value and a static symmetric key known only to the prover and 182 verifier parties. 184 As a reminder: 185 HOTP(K,C) = Truncate(HMAC-SHA1(K,C)) 187 Where Truncate represents the function that converts an HMAC-SHA-1 188 value into an HOTP value. 190 We refer the reader to [RFC4226] for the full description and further 191 details on the rationale and security analysis of HOTP. 193 The present draft describes the different variants based on similar 194 constructions as HOTP. 196 5. Definition of OCRA 198 OCRA is a generalization of HOTP with variable data inputs not solely 199 based on an incremented counter and secret key values. 201 The definition of OCRA requires a cryptographic function, a key K and 202 a set of DataInput parameters. This section first formally 203 introduces the OCRA algorithm and then introduces the definitions and 204 default values recommended for all parameters. 206 In a nutshell, 207 OCRA = CryptoFunction(K, DataInput) 209 Where: 211 o K: a shared secret key known to both parties 212 o DataInput: a structure that contains the concatenation of the 213 various input data values defined in details in section 5.1 214 o CryptoFunction: this is the function performing the OCRA 215 computation from the secret key K and the DataInput material; 216 CryptoFunction is described in details in section Section 5.2 218 5.1. DataInput Parameters 220 This structure is the concatenation over byte array of the OCRASuite 221 value as defined in section 6 with the different parameters used in 222 the computation, save for the secret key K. 224 DataInput = {OCRASuite | 00 | C | Q | P | S | T} where: 226 o OCRASuite is a value representing the suite of operations to 227 compute an OCRA response 228 o 00 is a byte value used as a separator 229 o C is an unsigned 8-byte counter value processed high-order bit 230 first, and MUST be synchronized between all parties; It loops 231 around from "{Hex}0" to "{Hex}FFFFFFFFFFFFFFFF" and then starts 232 over at "{Hex}0". Note that 'C' is optional for all OCRA modes 233 described in this document. 235 o Q, mandatory, is a 128-byte list of (concatenated) challenge 236 question(s) generated by the parties; if Q is less than 128 bytes, 237 then it should be padded with zeroes to the right 238 o P is a hash (SHA1 [RFC3174], SHA256 and SHA512 [SHA2] are 239 supported) value of PIN/password that is known to all parties 240 during the execution of the algorithm; the length of P will depend 241 on the hash function that is used 242 o S is an UTF-8 [RFC2279] encoded string of length upto 512 bytes 243 that contains information about the current session; the length of 244 S is defined in the OCRASuite string 245 o T is an 8-byte unsigned integer in big endian (i.e. network byte 246 order) representing the number of time-steps(seconds, minutes, 247 hours or days depending on the specified granularity) since 248 midnight UTC of January 1, 1970. More specificatlly, if the OCRA 249 computation includes a timestamp T, you should first convert your 250 current local time to UTC time; you can then derive the UTC time 251 in the proper format (i.e. seconds, minutes, hours or days elapsed 252 from Epoch time); the size of the time-step is defined in the 253 OCRASuite string 255 When computing a response, the concatenation order is always the 256 following: 258 C | 260 OTHER-PARTY-GENERATED-CHALLENGE-QUESTION | 262 YOUR-GENERATED-CHALLENGE-QUESTION | 264 P| S | T 266 If a value is empty (i.e. a certain input is not used in the 267 computation) then the value is simply not represented in the string. 269 The counter on the token or client MUST be incremented every time a 270 new computation is requested by the user. The server's counter value 271 MUST only be incremented after a successful OCRA authentication. 273 5.2. CryptoFunction 275 The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of 276 computation for OCRA is HOTP with the default 6-digit dynamic 277 truncation and a combination of DataInput values as the message to 278 compute the HMAC-SHA1 digest. 280 We denote t as the length in decimal digits of the truncation output. 281 For instance, if t = 6, then the output of the truncation is a 282 6-digit (decimal) value. 284 We define the HOTP family of functions as an extension to HOTP: 286 1. HOTP-H-t: these are the different possible truncated versions of 287 HOTP, using the dynamic truncation method for extracting an HOTP 288 value from the HMAC output 289 2. We will denote HOTP-H-t as the realization of an HOTP function 290 that uses an HMAC function with the hash function H, and the 291 dynamic truncation as described in [RFC4226] to extract a t-digit 292 value 293 3. t=0 means that no truncation is performed and the full HMAC value 294 is used for authentication purpose 296 We list the following preferred modes of computation, where * denotes 297 the default CryptoFunction: 299 o HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC and a 300 dynamic truncation to a 4-digit value; this mode is not 301 recommended in the general case but can be useful when a very 302 short authentication code is needed by an application 303 o HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC and a 304 dynamic truncation to a 6-digit value 305 o HOTP-SHA1-8: HOTP with SHA-1 as the hash function for HMAC and a 306 dynamic truncation to an 8-digit value 307 o HOTP-SHA256-6: HOTP with SHA-256 as the hash function for HMAC and 308 a dynamic truncation to a 6-digit value 309 o HOTP-SHA512-6: HOTP with SHA-512 as the hash function for HMAC and 310 a dynamic truncation to a 6-digit value 312 This table summarizes all possible values for the CryptoFunction: 314 +---------------+--------------------+-------------------------+ 315 | Name | HMAC Function Used | Size of Truncation (t) | 316 +---------------+--------------------+-------------------------+ 317 | HOTP-SHA1-t | HMAC-SHA1 | 0 (no truncation), 4-10 | 318 | HOTP-SHA256-t | HMAC-SHA256 | 0 (no truncation), 4-10 | 319 | HOTP-SHA512-t | HMAC-SHA512 | 0 (no truncation), 4-10 | 320 +---------------+--------------------+-------------------------+ 322 Table 1: CryptoFunction Table 324 6. The OCRASuite 326 An OCRASuite value is a text string that captures one mode of 327 operation for the OCRA algorithm, completely specifying the various 328 options for that computation. An OCRASuite value is represented as 329 follows: 331 :: 333 The OCRASuite value is the concatenation of three sub-components that 334 are described below. Some example OCRASuite strings are described in 335 section 6.4. 337 The client and server need to agree on one or two values of 338 OCRASuite. These values may be agreed at time of token provisioning 339 or for more sophisticated client-server interactions these values may 340 be negotiated for every transaction. 342 Note that for Mutual Challenge-Response or Signature with Server 343 Authentication modes, the client and server will need to agree on two 344 values of OCRASuite - one for server computation and another for 345 client computation. 347 6.1. Algorithm 349 Description: Indicates the version of OCRA algorithm. 351 Values: OCRA-v where v represents the version number (e.g. 1, 2 352 etc.). This document specifies version 1 of the OCRA algorithm. 354 6.2. CryptoFunction 356 Description: Indicates the function used to compute OCRA values 358 Values: Permitted values are described in section 5.2 360 6.3. DataInput 362 Description: This component of the OCRASuite string captures the list 363 of valid inputs for that computation; [] indicates a value is 364 optional: 366 [C] | QFxx | [PH | Snnn | TG] : Challenge-Response computation 368 [C] | QFxx | [PH | TG] : Plain Signature computation 370 Each input that is used for the computation is represented by a 371 single letter (except Q) and they are separated by a hyphen. 373 The input for challenge is further qualified by the formats supported 374 by the client for challenge question(s). Supported values can be: 376 +------------------+-------------------+ 377 | Format (F) | Up to Length (xx) | 378 +------------------+-------------------+ 379 | A (alphanumeric) | 04-64 | 380 | N (numeric) | 04-64 | 381 | H (hexadecimal) | 04-64 | 382 +------------------+-------------------+ 384 Table 2: Challenge Format Table 386 The default challenge format is N08, numeric and upto 8 digits. 388 The input for P is further qualified by the hash function used for 389 the PIN/password. Supported values for hash function can be: 391 Hash function (H) - SHA1, SHA256, SHA512. 393 The default hash function for P is SHA1. 395 The input for S is further qualified by the length of the session 396 data in bytes. The client and server could agree to any length but 397 the typical values are: 399 Length (nnn) - 064, 128, 256 and 512. 401 The default length is 064 bytes. 403 The input for timestamps is further qualified by G, size of the time- 404 step. G can be specified in number of seconds, minutes or hours: 406 +--------------------+-----------------------------+ 407 | Time-step Size (G) | Examples | 408 +--------------------+-----------------------------+ 409 | [1-59]S | number of seconds, e.g. 20S | 410 | [1-59]M | number of minutes, e.g. 5M | 411 | [0-48]H | number of hours, e.g. 24H | 412 +--------------------+-----------------------------+ 414 Table 3: Time-step Size Table 416 Default value for G is 1M, i.e. time step size is one minute and the 417 T represents the number of minutes since Epoch time. 419 6.4. OCRASuite Examples 421 Here are some examples of OCRASuite strings: 422 o "OCRA-1:HOTP-SHA512-8:C-QN08-PSHA1" means version 1 of the OCRA 423 algorithm with HMAC-SHA512 function, truncated to an 8-digit 424 value, using the counter, a random challenge and a SHA1 digest of 425 the PIN/Password as parameters. It also indicates that the client 426 supports only numeric challenge upto 8 digits in length 427 o "OCRA-1:HOTP-SHA256-6:QA10-T1M" means version 1 of the OCRA 428 algorithm with HMAC-SHA256 function, truncated to a 6-digit value, 429 using a random alphanumeric challenge upto 10 characters in length 430 and a timestamp in number of minutes since Epoch time 431 o "OCRA-1:HOTP-SHA1-4:QH8-S512" means version 1 of the OCRA 432 algorithm with HMAC-SHA1 function, truncated to a 4-digit value, 433 using a random hexadecimal challenge upto 8 nibbles and a session 434 value of 512 bytes 436 7. Algorithm Modes for Authentication 438 This section describes the typical modes in which the above defined 439 computation can be used for authentication. 441 7.1. One way Challenge-Response 443 A challenge/response is a security mechanism in which the verifier 444 presents a question (challenge) to the prover who must provide a 445 valid answer (response) to be authenticated. 447 To use this algorithm for a one-way challenge-response, the verifier 448 will communicate a challenge value (typically randomly generated) to 449 the prover. The prover will use the challenge in the computation as 450 described above. The prover then communicates the response to the 451 verifier to authenticate. 453 Therefore in this mode, the typical data inputs will be: 454 C - Counter, optional. 455 Q - Challenge question, mandatory, supplied by the verifier. 456 P - Hashed version of PIN/password, optional. 457 S - Session information, optional. 458 T - Timestamp, optional. 460 The diagram below shows the message exchange between the client 461 (prover) and the server (verifier) to complete a one-way challenge- 462 response authentication. 464 It is assumed that the client and server have a pre-shared key K that 465 is used for the computation. 467 CLIENT SERVER 468 (PROVER) VERIFIER) 469 | | 470 | Verifier sends challenge to prover | 471 | Challenge = Q | 472 |<---------------------------------------| 473 | | 474 | Prover Computes Response | 475 | R = OCRA(K, {[C] | Q | [P | S | T]}) | 476 | Prover sends Response = R | 477 |--------------------------------------->| 478 | | 479 | Verifier Validates Response | 480 | If Response is valid, Server sends OK | 481 | If Response is not, Server sends NOK | 482 |<---------------------------------------| 483 | | 485 7.2. Mutual Challenge-Response 487 Mutual challenge-response is a variation of one-way challenge- 488 response where both the client and server mutually authenticate each 489 other. 491 To use this algorithm, the client will first send a random client- 492 challenge to the server. The server computes the server-response and 493 sends it to the client along with a server-challenge. 495 The client will first verify the server-response to be assured that 496 it is talking to a valid server. It will then compute the client- 497 response and send it to the server to authenticate. The server 498 verifies the client-response to complete the two-way authentication 499 process. 501 In this mode there are two computations: client-response and server- 502 response. There are two separate challenge questions, generated by 503 both parties. We denote these challenge questions Q1 and Q2. 505 Typical data inputs for server-response computation will be: 506 C - Counter, optional. 507 QC - Challenge question, mandatory, supplied by the client. 508 QS - Challenge question, mandatory, supplied by the server. 509 S - Session information, optional. 510 T - Timestamp, optional. 512 Typical data inputs for client-response computation will be: 514 C - Counter, optional. 515 QS - Challenge question, mandatory, supplied by the server. 516 QC - Challenge question, mandatory, supplied by the client. 517 P - Hashed version of PIN/password, optional. 518 S - Session information, optional. 519 T - Timestamp, optional. 521 The following picture shows the messages that are exchanged between 522 the client and the server to complete a two-way mutual challenge- 523 response authentication. 525 It is assumed that the client and server have a pre-shared key K (or 526 pair of keys if using dual-key mode of computation) that is used for 527 the computation. 529 CLIENT SERVER 530 (PROVER) (VERIFIER) 531 | | 532 | 1. Client sends client-challenge | 533 | QC = Client-challenge | 534 |------------------------------------------------->| 535 | | 536 | 2. Server computes server-response | 537 | and sends server-challenge | 538 | RS = OCRA(K, [C] | QC | QS | [S | T]) | 539 | QS = Server-challenge | 540 | Response = RS, QS | 541 |<-------------------------------------------------| 542 | | 543 | 3. Client verifies server-response | 544 | and computes client-response | 545 | OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP | 546 | RC = OCRA(K, [C] | QS | QC | [P | S | T]) | 547 | Response = RC | 548 |------------------------------------------------->| 549 | | 550 | 4. Server verifies client-response | 551 | OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP | 552 | Response = OK | 553 |<-------------------------------------------------| 554 | | 556 7.3. Algorithm Modes for Signature 558 In this section we describe the typical modes in which the above 559 defined computation can be used for digital signatures. 561 7.3.1. Plain Signature 563 To use this algorithm in plain signature mode, the server will 564 communicate a signature-challenge value to the client (signer). The 565 signature-challenge is either the data to be signed or derived from 566 the data to be signed using a hash function, for example. 568 The client will use the signature-challenge in the computation as 569 described above. The client then communicates the signature value 570 (response) to the server to authenticate. 572 Therefore in this mode, the data inputs will be: 573 C - Counter, optional. 574 QS - Signature-challenge, mandatory, supplied by the server. 575 P - Hashed version of PIN/password, optional. 576 T - Timestamp, optional. 578 The picture below shows the messages that are exchanged between the 579 client (prover) and the server (verifier) to complete a plain 580 signature operation. 582 It is assumed that the client and server have a pre-shared key K that 583 is used for the computation. 585 CLIENT SERVER 586 (PROVER) (VERIFIER) 587 | | 588 | Verifier sends signature-challenge | 589 | Challenge = QS | 590 |<------------------------------------------| 591 | | 592 | Client Computes Response | 593 | SIGN = OCRA(K, [C] | QS | [P | T]) | 594 | Response = SIGN | 595 |------------------------------------------>| 596 | | 597 | Verifier Validates Response | 598 | Response = OK | 599 |<------------------------------------------| 600 | | 602 7.3.2. Signature with Server Authentication 604 This mode is a variation of the plain signature mode where the client 605 can first authenticates the server before generating a digital 606 signature. 608 To use this algorithm, the client will first send a random client- 609 challenge to the server. The server computes the server-response and 610 sends it to the client along with a signature-challenge. 612 The client will first verify the server-response to authenticate that 613 it is talking to a valid server. It will then compute the signature 614 and send it to the server. 616 In this mode there are two computations: client-signature and server- 617 response. 619 Typical data inputs for server-response computation will be: 620 C - Counter, optional. 621 QC - Challenge question, mandatory, supplied by the client. 622 QS - Signature-challenge, mandatory, supplied by the server. 623 T - Timestamp, optional. 625 Typical data inputs for client-signature computation will be: 626 C - Counter, optional. 627 QC - Challenge question, mandatory, supplied by the client. 628 QS - Signature-challenge, mandatory, supplied by the server. 629 P - Hashed version of PIN/password, optional. 630 T - Timestamp, optional. 632 The diagram below shows the messages that are exchanged between the 633 client and the server to complete a signature with server 634 authentication transaction. 636 It is assumed that the client and server have a pre-shared key K (or 637 pair of keys if using dual-key mode of computation) that is used for 638 the computation. 640 CLIENT SERVER 641 (PROVER) VERIFIER) 642 | | 643 | 1. Client sends client-challenge | 644 | QC = Client-challenge | 645 |-------------------------------------------------->| 646 | | 647 | 2. Server computes server-response | 648 | and sends signature-challenge | 649 | RS = OCRA(K, [C] | QC | QS | [T]) | 650 | QS = signature-challenge | 651 | Response = RS, QS | 652 |<--------------------------------------------------| 653 | | 654 | 3. Client verifies server-response | 655 | and computes signature | 656 | OCRA(K, [C] | QC | QS | [T]) != RS -> STOP | 657 | SIGN = OCRA( K, [C] | QS | QC | [P | T]) | 658 | Response = SIGN | 659 |-------------------------------------------------->| 660 | | 661 | 4. Server verifies Signature | 662 | OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP | 663 | Response = OK | 664 |<--------------------------------------------------| 665 | | 667 8. Security Considerations 669 Any algorithm is only as secure as the application and the 670 authentication protocols that implement it. Therefore, this section 671 discusses the critical security requirements that our choice of 672 algorithm imposes on the authentication protocol and validation 673 software. 675 8.1. Security Analysis of the OCRA algorithm 677 The security and strength of this algorithm depends on the properties 678 of the underlying building block HOTP, which is a construction based 679 on HMAC [RFC2104] using SHA-1 [RFC3174] (or SHA-256 or SHA-512 680 [SHA2]) as the hash function. 682 The conclusion of the security analysis detailed in [RFC4226] is 683 that, for all practical purposes, the outputs of the dynamic 684 truncation on distinct counter inputs are uniformly and independently 685 distributed strings. 687 The analysis demonstrates that the best possible attack against the 688 HOTP function is the brute force attack. 690 8.2. Implementation Considerations 692 IC1 - In the authentication mode, the client MUST support two- factor 693 authentication, i.e., the communication and verification of something 694 you know (secret code such as a Password, Pass phrase, PIN code, 695 etc.) and something you have (token). The secret code is known only 696 to the user and usually entered with the Response value for 697 authentication purpose (two-factor authentication). Alternatively, 698 instead of sending something you know to the server, the client may 699 use a hash of the Password or PIN code in the computation itself, 700 thus implicitly enabling two-factor authentication. 702 IC2 - Keys SHOULD be of the length of the CryptoFunction output to 703 facilitate interoperability. 705 IC3 - Keys SHOULD be chosen at random or using a cryptographically 706 strong pseudo-random generator properly seeded with a random value. 707 We RECOMMEND following the recommendations in [RFC4086] for all 708 pseudo-random and random generations. The pseudo-random numbers used 709 for generating the keys SHOULD successfully pass the randomness test 710 specified in [CN]. 712 IC4 - Challenge questions SHOULD be 20-byte values and MUST be at 713 least t-byte values where t stands for the digit-length of the OCRA 714 truncation output. 716 IC5 - On the client side, the keys SHOULD be embedded in a tamper 717 resistant device or securely implemented in a software application. 718 Additionally, by embedding the keys in a hardware device, you also 719 have the advantage of improving the flexibility (mobility) of the 720 authentication system. 722 IC6 - All the communications SHOULD take place over a secure channel 723 e.g. SSL/TLS [RFC5246], IPsec connections. 725 IC7 - The OCRA algorithm when used in mutual authentication mode or 726 in signature with server authentication mode MAY use dual key mode - 727 i.e. there are two keys that are shared between the client and the 728 server. One shared key is used to generate the server response on 729 the server side and to verify it on the client side. The other key 730 is used to create the response or signature on the client side and to 731 verify it on the server side. 733 IC8 - We recommend that implementations MAY use the session 734 information, S as an additional input in the computation. For 735 example, S could be the session identifier from the TLS session. 736 This will mitigate against certain types of man-in-the-middle 737 attacks. However, this will introduce the additional dependency that 738 first of all the prover needs to have access to the session 739 identifier to compute the response and the verifier will need access 740 to the session identifier to verify the response. [RFC5056] contains 741 a relevant discussion of using Channel Bindings to Secure Channels 743 IC9 - In the signature mode, whenever the counter or time (defined as 744 optional elements) are not used in the computation, there might be a 745 risk of replay attack and the implementers should carefully consider 746 this issue in the light of their specific application requirements 747 and security guidelines. The server SHOULD also provide whenever 748 possible a mean for the client (if able) to verify the validity of 749 the signature challenge. 751 IC10 - We also RECOMMEND storing the keys securely in the validation 752 system, and more specifically encrypting them using tamper-resistant 753 hardware encryption and exposing them only when required: for 754 example, the key is decrypted when needed to verify an OCRA response, 755 and re-encrypted immediately to limit exposure in the RAM for a short 756 period of time. The key store MUST be in a secure area, to avoid as 757 much as possible direct attack on the validation system and secrets 758 database. Particularly, access to the key material should be limited 759 to programs and processes required by the validation system only. 761 9. IANA Considerations 763 This document has no actions for IANA. 765 10. Conclusion 767 This draft introduced several variants of HOTP for challenge- 768 response based authentication and short signature-like computations. 770 The OCRASuite provides for an easy integration and support of 771 different flavors within an authentication and validation system. 773 Finally, OCRA should enable mutual authentication both in connected 774 and off-line modes, with the support of different response sizes and 775 mode of operations. 777 11. Acknowledgements 779 We would like to thank Jeff Burstein, Shuh Chang, Oanh Hoang, Philip 780 Hoyer, Jon Martinsson, Frederik Mennes, Mingliang Pei, Jonathan 781 Tuliani, Stu Vaeth, Enrique Rodriguez and Robert Zuccherato for their 782 comments and suggestions to improve this draft document. 784 12. References 786 12.1. Normative references 788 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 789 Hashing for Message Authentication", RFC 2104, 790 February 1997, . 792 [RFC2119] "Key words for use in RFCs to Indicate Requirement 793 Levels", BCP 14, RFC 2119, March 1997, 794 . 796 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 797 10646", RFC 2279, January 1998, 798 . 800 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 801 (SHA1)", RFC 3174, September 2001, 802 . 804 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 805 Recommendations for Security", RFC 4086, June 2005, 806 . 808 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 809 O. Ranen, "HOTP: An HMAC-Based One-Time Password 810 Algorithm", RFC 4226, December 2005, 811 . 813 [SHA2] NIST, "FIPS PUB 180-3: Secure Hash Standard (SHS)", 814 October 2008, . 817 12.2. Informative References 819 [CN] Coron, J. and D. Naccache, "An accurate evaluation of 820 Maurer's universal test", LNCS 1556, February 1999, . 823 [OATH] Initiative for Open AuTHentication, "OATH Vision", 824 . 826 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 827 Channels", RFC 5056, November 2007, 828 . 830 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 831 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 832 . 834 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 835 for TLS", RFC 5929, July 2010, 836 . 838 [UT] Wikipedia, "Unix time", 839 . 841 Appendix A. Reference Implementation 843 845 /** 846 Copyright (c) 2011 IETF Trust and the persons identified as authors of 847 the code. All rights reserved. 849 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 850 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 851 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 852 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 853 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 854 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 855 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 856 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 857 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 858 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 859 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 860 */ 862 import javax.crypto.Mac; 863 import javax.crypto.spec.SecretKeySpec; 864 import java.math.BigInteger; 866 /** 867 * This an example implementation of the OATH OCRA algorithm. 868 * Visit www.openauthentication.org for more information. 869 * 870 * @author Johan Rydell, PortWise 871 */ 873 public class OCRA { 875 private OCRA() {} 877 /** 878 * This method uses the JCE to provide the crypto 879 * algorithm. 880 * HMAC computes a Hashed Message Authentication Code with the 881 * crypto hash algorithm as a parameter. 882 * 883 * @param crypto the crypto algorithm (HmacSHA1, HmacSHA256, 884 * HmacSHA512) 885 * @param keyBytes the bytes to use for the HMAC key 886 * @param text the message or text to be authenticated. 887 */ 889 private static byte[] hmac_sha1(String crypto, 890 byte[] keyBytes, byte[] text){ 891 Mac hmac = null; 892 try { 893 hmac = Mac.getInstance(crypto); 894 SecretKeySpec macKey = 895 new SecretKeySpec(keyBytes, "RAW"); 896 hmac.init(macKey); 897 return hmac.doFinal(text); 898 } catch (Exception e) { 899 e.printStackTrace(); 900 } 901 return null; 902 } 904 private static final int[] DIGITS_POWER 905 // 0 1 2 3 4 5 6 7 8 906 = {1,10,100,1000,10000,100000,1000000,10000000,100000000 }; 908 /** 909 * This method converts HEX string to Byte[] 910 * 911 * @param hex the HEX string 912 * 913 * @return A byte array 914 */ 915 private static byte[] hexStr2Bytes(String hex){ 916 // Adding one byte to get the right conversion 917 // values starting with "0" can be converted 918 byte[] bArray = new BigInteger("10" + hex,16).toByteArray(); 919 // Copy all the REAL bytes, not the "first" 920 byte[] ret = new byte[bArray.length - 1]; 921 System.arraycopy(bArray, 1, ret, 0, ret.length); 922 return ret; 923 } 925 /** 926 * This method generates an OCRA HOTP value for the given 927 * set of parameters. 928 * 929 * @param ocraSuite the OCRA Suite 930 * @param key the shared secret, HEX encoded 931 * @param counter the counter that changes on a per use 932 * basis, HEX encoded 933 * @param question the challenge question, HEX encoded 934 * @param password a password that can be used, HEX encoded 935 * @param sessionInformation Static information that identifies 936 * the current session, Hex encoded 937 * @param timeStamp a value that reflects a time 938 * 939 * @return A numeric String in base 10 that includes 940 * {@link truncationDigits} digits 941 */ 942 static public String generateOCRA(String ocraSuite, 943 String key, 944 String counter, 945 String question, 946 String password, 947 String sessionInformation, 948 String timeStamp){ 950 int codeDigits = 0; 951 String crypto = ""; 952 String result = null; 953 int ocraSuiteLength = (ocraSuite.getBytes()).length; 954 int counterLength = 0; 955 int questionLength = 0; 956 int passwordLength = 0; 957 int sessionInformationLength = 0; 958 int timeStampLength = 0; 960 // The OCRASuites components 961 String CryptoFunction = ocraSuite.split(":")[1]; 962 String DataInput = ocraSuite.split(":")[2]; 964 if(CryptoFunction.toLowerCase().indexOf("sha1") > 1) 965 crypto = "HmacSHA1"; 966 if(CryptoFunction.toLowerCase().indexOf("sha256") > 1) 967 crypto = "HmacSHA256"; 968 if(CryptoFunction.toLowerCase().indexOf("sha512") > 1) 969 crypto = "HmacSHA512"; 971 // How many digits should we return 972 codeDigits = Integer.decode(CryptoFunction.substring( 973 CryptoFunction.lastIndexOf("-")+1)); 975 // The size of the byte array message to be encrypted 976 // Counter 977 if(DataInput.toLowerCase().startsWith("c")) { 978 // Fix the length of the HEX string 979 while(counter.length() < 16) 980 counter = "0" + counter; 981 counterLength=8; 982 } 983 // Question - always 128 bytes 984 if(DataInput.toLowerCase().startsWith("q") || 985 (DataInput.toLowerCase().indexOf("-q") >= 0)) { 986 while(question.length() < 256) 987 question = question + "0"; 988 questionLength=128; 989 } 991 // Password - sha1 992 if(DataInput.toLowerCase().indexOf("psha1") > 1){ 993 while(password.length() < 40) 994 password = "0" + password; 995 passwordLength=20; 996 } 998 // Password - sha256 999 if(DataInput.toLowerCase().indexOf("psha256") > 1){ 1000 while(password.length() < 64) 1001 password = "0" + password; 1002 passwordLength=32; 1003 } 1005 // Password - sha512 1006 if(DataInput.toLowerCase().indexOf("psha512") > 1){ 1007 while(password.length() < 128) 1008 password = "0" + password; 1009 passwordLength=64; 1010 } 1012 // sessionInformation - s064 1013 if(DataInput.toLowerCase().indexOf("s064") > 1){ 1014 while(sessionInformation.length() < 128) 1015 sessionInformation = "0" + sessionInformation; 1016 sessionInformationLength=64; 1017 } 1019 // sessionInformation - s128 1020 if(DataInput.toLowerCase().indexOf("s128") > 1){ 1021 while(sessionInformation.length() < 256) 1022 sessionInformation = "0" + sessionInformation; 1023 sessionInformationLength=128; 1024 } 1026 // sessionInformation - s256 1027 if(DataInput.toLowerCase().indexOf("s256") > 1){ 1028 while(sessionInformation.length() < 512) 1029 sessionInformation = "0" + sessionInformation; 1030 sessionInformationLength=256; 1031 } 1033 // sessionInformation - s512 1034 if(DataInput.toLowerCase().indexOf("s512") > 1){ 1035 while(sessionInformation.length() < 1024) 1036 sessionInformation = "0" + sessionInformation; 1037 sessionInformationLength=512; 1038 } 1040 // TimeStamp 1041 if(DataInput.toLowerCase().startsWith("t") || 1042 (DataInput.toLowerCase().indexOf("-t") > 1)){ 1043 while(timeStamp.length() < 16) 1044 timeStamp = "0" + timeStamp; 1045 timeStampLength=8; 1046 } 1048 // Remember to add "1" for the "00" byte delimiter 1049 byte[] msg = new byte[ocraSuiteLength + 1050 counterLength + 1051 questionLength + 1052 passwordLength + 1053 sessionInformationLength + 1054 timeStampLength + 1055 1]; 1057 // Put the bytes of "ocraSuite" parameters into the message 1058 byte[] bArray = ocraSuite.getBytes(); 1059 System.arraycopy(bArray, 0, msg, 0, bArray.length); 1060 // Delimiter 1061 msg[bArray.length] = 0x00; 1063 // Put the bytes of "Counter" to the message 1064 // Input is HEX encoded 1065 if(counterLength > 0 ){ 1066 bArray = hexStr2Bytes(counter); 1067 System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1, 1068 bArray.length); 1069 } 1071 // Put the bytes of "question" to the message 1072 // Input is text encoded 1073 if(questionLength > 0 ){ 1074 bArray = hexStr2Bytes(question); 1075 System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 + 1076 counterLength, bArray.length); 1077 } 1079 // Put the bytes of "password" to the message 1080 // Input is HEX encoded 1081 if(passwordLength > 0){ 1082 bArray = hexStr2Bytes(password); 1083 System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 + 1084 counterLength + questionLength, bArray.length); 1085 } 1087 // Put the bytes of "sessionInformation" to the message 1088 // Input is text encoded 1089 if(sessionInformationLength > 0 ){ 1090 bArray = hexStr2Bytes(sessionInformation); 1091 System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 + 1092 counterLength + questionLength + 1093 passwordLength, bArray.length); 1094 } 1096 // Put the bytes of "time" to the message 1097 // Input is text value of minutes 1098 if(timeStampLength > 0){ 1099 bArray = hexStr2Bytes(timeStamp); 1100 System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 + 1101 counterLength + questionLength + 1102 passwordLength + sessionInformationLength, 1103 bArray.length); 1104 } 1106 bArray = hexStr2Bytes(key); 1107 byte[] hash = hmac_sha1(crypto, bArray, msg); 1109 // put selected bytes into result int 1110 int offset = hash[hash.length - 1] & 0xf; 1112 int binary = 1113 ((hash[offset] & 0x7f) << 24) | 1114 ((hash[offset + 1] & 0xff) << 16) | 1115 ((hash[offset + 2] & 0xff) << 8) | 1116 (hash[offset + 3] & 0xff); 1118 int otp = binary % DIGITS_POWER[codeDigits]; 1120 result = Integer.toString(otp); 1121 while (result.length() < codeDigits) { 1122 result = "0" + result; 1123 } 1124 return result; 1125 } 1126 } 1128 1129 Appendix B. Test Vectors Generation 1131 1133 /** 1134 Copyright (c) 2011 IETF Trust and the persons identified as authors of 1135 the code. All rights reserved. 1137 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1138 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1139 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1140 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1141 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1142 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1143 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1144 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1145 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1146 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1147 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1148 */ 1150 import java.math.BigInteger; 1151 import java.util.*; 1152 import java.text.DateFormat; 1153 import java.text.SimpleDateFormat; 1155 public class TestOCRA { 1157 public static String asHex (byte buf[]) { 1158 StringBuffer strbuf = new StringBuffer(buf.length * 2); 1159 int i; 1161 for (i = 0; i < buf.length; i++) { 1162 if (((int) buf[i] & 0xff) < 0x10) 1163 strbuf.append("0"); 1164 strbuf.append(Long.toString((int) buf[i] & 0xff, 16)); 1165 } 1166 return strbuf.toString(); 1167 } 1169 /** 1170 * @param args 1171 */ 1172 public static void main(String[] args) { 1174 String ocra = ""; 1175 String seed = ""; 1176 String ocraSuite = ""; 1177 String counter = ""; 1178 String password = ""; 1179 String sessionInformation = ""; 1180 String question = ""; 1181 String qHex = ""; 1182 String timeStamp = ""; 1184 // PASS1234 is SHA1 hash of "1234" 1185 String PASS1234 = "7110eda4d09e062aa5e4a390b0a572ac0d2c0220"; 1187 String SEED = "3132333435363738393031323334353637383930"; 1188 String SEED32 = "31323334353637383930313233343536373839" + 1189 "30313233343536373839303132"; 1190 String SEED64 = "31323334353637383930313233343536373839" + 1191 "3031323334353637383930313233343536373839" + 1192 "3031323334353637383930313233343536373839" + 1193 "3031323334"; 1194 int STOP = 5; 1196 Date myDate = Calendar.getInstance().getTime(); 1197 BigInteger b = new BigInteger("0"); 1198 String sDate = "Mar 25 2008, 12:06:30 GMT"; 1200 try{ 1201 DateFormat df = 1202 new SimpleDateFormat("MMM dd yyyy, HH:mm:ss zzz"); 1203 myDate = df.parse(sDate); 1204 b = new BigInteger("0" + myDate.getTime()); 1205 b = b.divide(new BigInteger("60000")); 1207 System.out.println("Time of \"" + sDate + "\" is in"); 1208 System.out.println("milli sec: " + myDate.getTime()); 1209 System.out.println("minutes: " + b.toString()); 1210 System.out.println("minutes (HEX encoded): " 1211 + b.toString(16).toUpperCase()); 1212 System.out.println("Time of \"" + sDate 1213 + "\" is the same as this localized"); 1214 System.out.println("time, \"" 1215 + new Date(myDate.getTime()) + "\""); 1217 System.out.println(); 1218 System.out.println("Standard 20Byte key: " + 1219 "3132333435363738393031323334353637383930"); 1220 System.out.println("Standard 32Byte key: " + 1221 "3132333435363738393031323334353637383930"); 1223 System.out.println(" " + 1224 "313233343536373839303132"); 1225 System.out.println("Standard 64Byte key: 313233343536373839" 1226 + "3031323334353637383930"); 1227 System.out.println(" 313233343536373839" 1228 + "3031323334353637383930"); 1229 System.out.println(" 313233343536373839" 1230 + "3031323334353637383930"); 1231 System.out.println(" 31323334"); 1233 System.out.println(); 1234 System.out.println("Plain challenge response"); 1235 System.out.println("========================"); 1236 System.out.println(); 1238 ocraSuite = "OCRA-1:HOTP-SHA1-6:QN08"; 1239 System.out.println(ocraSuite); 1240 System.out.println("======================="); 1241 seed = SEED; 1242 counter = ""; 1243 question = ""; 1244 password = ""; 1245 sessionInformation = ""; 1246 timeStamp = ""; 1247 for(int i=0; i < 10; i++){ 1248 question = "" + i + i + i + i + i + i + i + i; 1249 qHex = new String((new BigInteger(question,10)) 1250 .toString(16)).toUpperCase(); 1251 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1252 qHex,password, 1253 sessionInformation,timeStamp); 1254 System.out.println("Key: Standard 20Byte Q: " 1255 + question + " OCRA: " + ocra); 1256 } 1257 System.out.println(); 1259 ocraSuite = "OCRA-1:HOTP-SHA256-8:C-QN08-PSHA1"; 1260 System.out.println(ocraSuite); 1261 System.out.println("================================="); 1262 seed = SEED32; 1263 counter = ""; 1264 question = "12345678"; 1265 password = PASS1234; 1266 sessionInformation = ""; 1267 timeStamp = ""; 1268 for(int i=0; i < 10; i++){ 1269 counter = "" + i; 1270 qHex = new String((new BigInteger(question,10)) 1271 .toString(16)).toUpperCase(); 1272 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1273 qHex,password,sessionInformation,timeStamp); 1274 System.out.println("Key: Standard 32Byte C: " 1275 + counter + " Q: " 1276 + question + " PIN(1234): "); 1277 System.out.println(password + " OCRA: " + ocra); 1278 } 1279 System.out.println(); 1281 ocraSuite = "OCRA-1:HOTP-SHA256-8:QN08-PSHA1"; 1282 System.out.println(ocraSuite); 1283 System.out.println("==============================="); 1284 seed = SEED32; 1285 counter = ""; 1286 question = ""; 1287 password = PASS1234; 1288 sessionInformation = ""; 1289 timeStamp = ""; 1290 for(int i=0; i < STOP; i++){ 1291 question = "" + i + i + i + i + i + i + i + i; 1293 qHex = new String((new BigInteger(question,10)) 1294 .toString(16)).toUpperCase(); 1295 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1296 qHex,password,sessionInformation,timeStamp); 1297 System.out.println("Key: Standard 32Byte Q: " 1298 + question + " PIN(1234): "); 1299 System.out.println(password + " OCRA: " + ocra); 1300 } 1301 System.out.println(); 1303 ocraSuite = "OCRA-1:HOTP-SHA512-8:C-QN08"; 1304 System.out.println(ocraSuite); 1305 System.out.println("==========================="); 1306 seed = SEED64; 1307 counter = ""; 1308 question = ""; 1309 password = ""; 1310 sessionInformation = ""; 1311 timeStamp = ""; 1312 for(int i=0; i < 10; i++){ 1313 question = "" + i + i + i + i + i + i + i + i; 1314 qHex = new String((new BigInteger(question,10)) 1315 .toString(16)).toUpperCase(); 1316 counter = "0000" + i; 1317 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1318 qHex,password,sessionInformation,timeStamp); 1320 System.out.println("Key: Standard 64Byte C: " 1321 + counter + " Q: " 1322 + question + " OCRA: " + ocra); 1323 } 1324 System.out.println(); 1326 ocraSuite = "OCRA-1:HOTP-SHA512-8:QN08-T1M"; 1327 System.out.println(ocraSuite); 1328 System.out.println("============================="); 1329 seed = SEED64; 1330 counter = ""; 1331 question = ""; 1332 password = ""; 1333 sessionInformation = ""; 1334 timeStamp = b.toString(16); 1335 for(int i=0; i < STOP; i++){ 1336 question = "" + i + i + i + i + i + i + i + i; 1337 counter = ""; 1338 qHex = new String((new BigInteger(question,10)) 1339 .toString(16)).toUpperCase(); 1340 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1341 qHex,password,sessionInformation,timeStamp); 1343 System.out.println("Key: Standard 64Byte Q: " 1344 + question +" T: " 1345 + timeStamp.toUpperCase() 1346 + " OCRA: " + ocra); 1347 } 1348 System.out.println(); 1350 System.out.println(); 1351 System.out.println("Mutual Challenge Response"); 1352 System.out.println("========================="); 1353 System.out.println(); 1355 ocraSuite = "OCRA-1:HOTP-SHA256-8:QA08"; 1356 System.out.println("OCRASuite (server computation) = " 1357 + ocraSuite); 1358 System.out.println("OCRASuite (client computation) = " 1359 + ocraSuite); 1360 System.out.println("===============================" + 1361 "==========================="); 1362 seed = SEED32; 1363 counter = ""; 1364 question = ""; 1365 password = ""; 1366 sessionInformation = ""; 1367 timeStamp = ""; 1368 for(int i=0; i < STOP; i++){ 1369 question = "CLI2222" + i + "SRV1111" + i; 1370 qHex = asHex(question.getBytes()); 1371 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1372 password,sessionInformation,timeStamp); 1373 System.out.println( 1374 "(server)Key: Standard 32Byte Q: " 1375 + question + " OCRA: " 1376 + ocra); 1377 question = "SRV1111" + i + "CLI2222" + i; 1378 qHex = asHex(question.getBytes()); 1379 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1380 password,sessionInformation,timeStamp); 1381 System.out.println( 1382 "(client)Key: Standard 32Byte Q: " 1383 + question + " OCRA: " 1384 + ocra); 1385 } 1386 System.out.println(); 1388 String ocraSuite1 = "OCRA-1:HOTP-SHA512-8:QA08"; 1389 String ocraSuite2 = "OCRA-1:HOTP-SHA512-8:QA08-PSHA1"; 1390 System.out.println("OCRASuite (server computation) = " 1391 + ocraSuite1); 1392 System.out.println("OCRASuite (client computation) = " 1393 + ocraSuite2); 1394 System.out.println("===============================" + 1395 "================================="); 1396 ocraSuite = ""; 1397 seed = SEED64; 1398 counter = ""; 1399 question = ""; 1400 password = ""; 1401 sessionInformation = ""; 1402 timeStamp = ""; 1403 for(int i=0; i < STOP; i++){ 1404 ocraSuite = ocraSuite1; 1405 question = "CLI2222" + i + "SRV1111" + i; 1406 qHex = asHex(question.getBytes()); 1407 password = ""; 1408 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1409 password,sessionInformation,timeStamp); 1410 System.out.println( 1411 "(server)Key: Standard 64Byte Q: " 1412 + question + " OCRA: " 1413 + ocra); 1414 ocraSuite = ocraSuite2; 1415 question = "SRV1111" + i + "CLI2222" + i; 1416 qHex = asHex(question.getBytes()); 1417 password = PASS1234; 1418 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1419 password,sessionInformation,timeStamp); 1420 System.out.println("(client)Key: Standard 64Byte Q: " 1421 + question); 1422 System.out.println("P: " + password.toUpperCase() 1423 + " OCRA: " + ocra); 1424 } 1425 System.out.println(); 1427 System.out.println(); 1428 System.out.println("Plain Signature"); 1429 System.out.println("==============="); 1430 System.out.println(); 1431 ocraSuite = "OCRA-1:HOTP-SHA256-8:QA08"; 1432 System.out.println(ocraSuite); 1433 System.out.println("========================="); 1434 seed = SEED32; 1435 counter = ""; 1436 question = ""; 1437 password = ""; 1438 sessionInformation = ""; 1439 timeStamp = ""; 1440 for(int i=0; i < STOP; i++){ 1441 question = "SIG1" + i + "000"; 1442 qHex = asHex(question.getBytes()); 1443 ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex, 1444 password,sessionInformation,timeStamp); 1445 System.out.println( 1446 "Key: Standard 32Byte Q(Signature challenge): " 1447 + question); 1448 System.out.println(" OCRA: " + ocra); 1449 } 1450 System.out.println(); 1452 ocraSuite = "OCRA-1:HOTP-SHA512-8:QA10-T1M"; 1453 System.out.println(ocraSuite); 1454 System.out.println("============================="); 1455 seed = SEED64; 1456 counter = ""; 1457 question = ""; 1458 password = ""; 1459 sessionInformation = ""; 1460 timeStamp = b.toString(16); 1461 for(int i=0; i < STOP; i++){ 1462 question = "SIG1" + i + "00000"; 1463 qHex = asHex(question.getBytes()); 1464 ocra = OCRA.generateOCRA(ocraSuite,seed,counter, 1465 qHex,password,sessionInformation,timeStamp); 1466 System.out.println( 1467 "Key: Standard 64Byte Q(Signature challenge): " 1468 + question); 1469 System.out.println(" T: " 1470 + timeStamp.toUpperCase() + " OCRA: " 1471 + ocra); 1472 } 1474 }catch (Exception e){ 1475 System.out.println("Error : " + e); 1476 } 1477 } 1478 } 1479 1480 Appendix C. Test Vectors 1482 This section provides test values that can be used for OCRA algorithm 1483 interoperability test. 1485 Standard 20Byte key: 1487 3132333435363738393031323334353637383930 1489 Standard 32Byte key: 1491 3132333435363738393031323334353637383930313233343536373839303132 1493 Standard 64Byte key: 1495 313233343536373839303132333435363738393031323334353637383930313233343 1496 53637383930313233343536373839303132333435363738393031323334 1498 PIN (1234) SHA1 hash value: 1500 7110eda4d09e062aa5e4a390b0a572ac0d2c0220 1502 C.1. Plain challenge response 1504 +-----------------+----------+------------+ 1505 | Key | Q | OCRA Value | 1506 +-----------------+----------+------------+ 1507 | Standard 20Byte | 00000000 | 237653 | 1508 | Standard 20Byte | 11111111 | 243178 | 1509 | Standard 20Byte | 22222222 | 653583 | 1510 | Standard 20Byte | 33333333 | 740991 | 1511 | Standard 20Byte | 44444444 | 608993 | 1512 | Standard 20Byte | 55555555 | 388898 | 1513 | Standard 20Byte | 66666666 | 816933 | 1514 | Standard 20Byte | 77777777 | 224598 | 1515 | Standard 20Byte | 88888888 | 750600 | 1516 | Standard 20Byte | 99999999 | 294470 | 1517 +-----------------+----------+------------+ 1519 OCRA-1:HOTP-SHA1-6:QN08 1521 +-----------------+---+----------+------------+ 1522 | Key | C | Q | OCRA Value | 1523 +-----------------+---+----------+------------+ 1524 | Standard 32Byte | 0 | 12345678 | 65347737 | 1525 | Standard 32Byte | 1 | 12345678 | 86775851 | 1526 | Standard 32Byte | 2 | 12345678 | 78192410 | 1527 | Standard 32Byte | 3 | 12345678 | 71565254 | 1528 | Standard 32Byte | 4 | 12345678 | 10104329 | 1529 | Standard 32Byte | 5 | 12345678 | 65983500 | 1530 | Standard 32Byte | 6 | 12345678 | 70069104 | 1531 | Standard 32Byte | 7 | 12345678 | 91771096 | 1532 | Standard 32Byte | 8 | 12345678 | 75011558 | 1533 | Standard 32Byte | 9 | 12345678 | 08522129 | 1534 +-----------------+---+----------+------------+ 1536 OCRA-1:HOTP-SHA256-8:C-QN08-PSHA1 1538 +-----------------+----------+------------+ 1539 | Key | Q | OCRA Value | 1540 +-----------------+----------+------------+ 1541 | Standard 32Byte | 00000000 | 83238735 | 1542 | Standard 32Byte | 11111111 | 01501458 | 1543 | Standard 32Byte | 22222222 | 17957585 | 1544 | Standard 32Byte | 33333333 | 86776967 | 1545 | Standard 32Byte | 44444444 | 86807031 | 1546 +-----------------+----------+------------+ 1548 OCRA-1:HOTP-SHA256-8:QN08-PSHA1 1550 +-----------------+-------+----------+------------+ 1551 | Key | C | Q | OCRA Value | 1552 +-----------------+-------+----------+------------+ 1553 | Standard 64Byte | 00000 | 00000000 | 07016083 | 1554 | Standard 64Byte | 00001 | 11111111 | 63947962 | 1555 | Standard 64Byte | 00002 | 22222222 | 70123924 | 1556 | Standard 64Byte | 00003 | 33333333 | 25341727 | 1557 | Standard 64Byte | 00004 | 44444444 | 33203315 | 1558 | Standard 64Byte | 00005 | 55555555 | 34205738 | 1559 | Standard 64Byte | 00006 | 66666666 | 44343969 | 1560 | Standard 64Byte | 00007 | 77777777 | 51946085 | 1561 | Standard 64Byte | 00008 | 88888888 | 20403879 | 1562 | Standard 64Byte | 00009 | 99999999 | 31409299 | 1563 +-----------------+-------+----------+------------+ 1565 OCRA-1:HOTP-SHA512-8:C-QN08 1567 +-----------------+----------+---------+------------+ 1568 | Key | Q | T | OCRA Value | 1569 +-----------------+----------+---------+------------+ 1570 | Standard 64Byte | 00000000 | 132d0b6 | 95209754 | 1571 | Standard 64Byte | 11111111 | 132d0b6 | 55907591 | 1572 | Standard 64Byte | 22222222 | 132d0b6 | 22048402 | 1573 | Standard 64Byte | 33333333 | 132d0b6 | 24218844 | 1574 | Standard 64Byte | 44444444 | 132d0b6 | 36209546 | 1575 +-----------------+----------+---------+------------+ 1577 OCRA-1:HOTP-SHA512-8:QN08-T1M 1579 C.2. Mutual Challenge Response 1581 OCRASuite (server computation) = OCRA-1:HOTP-SHA256-8:QA08 1583 OCRASuite (client computation) = OCRA-1:HOTP-SHA256-8:QA08 1585 +-----------------+------------------+------------+ 1586 | Key | Q | OCRA Value | 1587 +-----------------+------------------+------------+ 1588 | Standard 32Byte | CLI22220SRV11110 | 28247970 | 1589 | Standard 32Byte | CLI22221SRV11111 | 01984843 | 1590 | Standard 32Byte | CLI22222SRV11112 | 65387857 | 1591 | Standard 32Byte | CLI22223SRV11113 | 03351211 | 1592 | Standard 32Byte | CLI22224SRV11114 | 83412541 | 1593 +-----------------+------------------+------------+ 1595 Server -- OCRA-1:HOTP-SHA256-8:QA08 1597 +-----------------+------------------+------------+ 1598 | Key | Q | OCRA Value | 1599 +-----------------+------------------+------------+ 1600 | Standard 32Byte | SRV11110CLI22220 | 15510767 | 1601 | Standard 32Byte | SRV11111CLI22221 | 90175646 | 1602 | Standard 32Byte | SRV11112CLI22222 | 33777207 | 1603 | Standard 32Byte | SRV11113CLI22223 | 95285278 | 1604 | Standard 32Byte | SRV11114CLI22224 | 28934924 | 1605 +-----------------+------------------+------------+ 1607 Client -- OCRA-1:HOTP-SHA256-8:QA08 1609 OCRASuite (server computation) = OCRA-1:HOTP-SHA512-8:QA08 1611 OCRASuite (client computation) = OCRA-1:HOTP-SHA512-8:QA08-PSHA1 1613 +-----------------+------------------+------------+ 1614 | Key | Q | OCRA Value | 1615 +-----------------+------------------+------------+ 1616 | Standard 64Byte | CLI22220SRV11110 | 79496648 | 1617 | Standard 64Byte | CLI22221SRV11111 | 76831980 | 1618 | Standard 64Byte | CLI22222SRV11112 | 12250499 | 1619 | Standard 64Byte | CLI22223SRV11113 | 90856481 | 1620 | Standard 64Byte | CLI22224SRV11114 | 12761449 | 1621 +-----------------+------------------+------------+ 1623 Server -- OCRA-1:HOTP-SHA512-8:QA08 1625 +-----------------+------------------+------------+ 1626 | Key | Q | OCRA Value | 1627 +-----------------+------------------+------------+ 1628 | Standard 64Byte | SRV11110CLI22220 | 18806276 | 1629 | Standard 64Byte | SRV11111CLI22221 | 70020315 | 1630 | Standard 64Byte | SRV11112CLI22222 | 01600026 | 1631 | Standard 64Byte | SRV11113CLI22223 | 18951020 | 1632 | Standard 64Byte | SRV11114CLI22224 | 32528969 | 1633 +-----------------+------------------+------------+ 1635 Client -- OCRA-1:HOTP-SHA512-8:QA08-PSHA1 1637 C.3. Plain Signature 1639 In this mode of operation, Q represents the signature challenge. 1641 +-----------------+----------+------------+ 1642 | Key | Q | OCRA Value | 1643 +-----------------+----------+------------+ 1644 | Standard 32Byte | SIG10000 | 53095496 | 1645 | Standard 32Byte | SIG11000 | 04110475 | 1646 | Standard 32Byte | SIG12000 | 31331128 | 1647 | Standard 32Byte | SIG13000 | 76028668 | 1648 | Standard 32Byte | SIG14000 | 46554205 | 1649 +-----------------+----------+------------+ 1651 OCRA-1:HOTP-SHA256-8:QA08 1653 +-----------------+------------+---------+------------+ 1654 | Key | Q | T | OCRA Value | 1655 +-----------------+------------+---------+------------+ 1656 | Standard 64Byte | SIG1000000 | 132d0b6 | 77537423 | 1657 | Standard 64Byte | SIG1100000 | 132d0b6 | 31970405 | 1658 | Standard 64Byte | SIG1200000 | 132d0b6 | 10235557 | 1659 | Standard 64Byte | SIG1300000 | 132d0b6 | 95213541 | 1660 | Standard 64Byte | SIG1400000 | 132d0b6 | 65360607 | 1661 +-----------------+------------+---------+------------+ 1663 OCRA-1:HOTP-SHA512-8:QA10-T1M 1665 Authors' Addresses 1667 David M'Raihi 1668 Verisign, Inc. 1669 487 E. Middlefield Road 1670 Mountain View, CA 94043 1671 USA 1673 Email: davidietf@gmail.com 1675 Johan Rydell 1676 Portwise, Inc. 1677 275 Hawthorne Ave, Suite 119 1678 Palo Alto, CA 94301 1679 USA 1681 Email: johanietf@gmail.com 1683 Siddharth Bajaj 1684 Symantec Corp. 1685 350 Ellis Street 1686 Mountain View, CA 94043 1687 USA 1689 Email: siddharthietf@gmail.com 1690 Salah Machani 1691 Diversinet Corp. 1692 2225 Sheppard Avenue East, Suite 1801 1693 Toronto, Ontario M2J 5C2 1694 Canada 1696 Email: smachani@diversinet.com 1698 David Naccache 1699 Ecole Normale Superieure 1700 ENS DI, 45 rue d'Ulm 1701 Paris, 75005 1702 France 1704 Email: david.naccache@ens.fr