idnits 2.17.1 draft-mraihi-mutual-oath-hotp-variants-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 535. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. 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: ' 6. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2104], [HOTP], [OATH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 115: '...he shared secret MUST be embedded in a...' RFC 2119 keyword, line 118: '... R2 - The secret SHOULD be stored in a...' RFC 2119 keyword, line 121: '... - The algorithm MUST be capable of su...' RFC 2119 keyword, line 124: '... challenge value MUST be randomly gene...' RFC 2119 keyword, line 125: '...ion protocol and SHALL NOT be re-used....' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2005) is 6701 days in the past. Is this intentional? 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? 'HOTP' on line 444 looks like a reference -- Missing reference section? 'OATH' on line 455 looks like a reference -- Missing reference section? 'RFC2104' on line 428 looks like a reference -- Missing reference section? 'RFC1750' on line 432 looks like a reference -- Missing reference section? 'CN' on line 458 looks like a reference -- Missing reference section? 'RFC2119' on line 436 looks like a reference -- Missing reference section? 'RFC3668' on line 439 looks like a reference -- Missing reference section? 'BCK' on line 451 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 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-00.txt ENS 8 Salah Machani 9 Diversinet 11 Expires: 12 June 2006 December 2005 14 Mutual OATH: HOTP Extensions for mutual authentication 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 This document describes Mutual OATH, a mechanism for mutual 42 authentication based on the HOTP algorithm [HOTP] introduced 43 recently by OATH (initiative for Open AuTHentication) [OATH] and 44 submitted as an individual draft to the IETF last year. The 45 security and strength of Mutual OATH depends on the properties of 46 the underlying building block HOTP, which is a construction based 47 on HMAC [RFC2104] using SHA-1 as the hash function. 49 HOTP: An HMAC-based One Time Password Algorithm December 2005 51 Table of Contents 53 1. Introduction...............................................2 54 2. Requirements Terminology...................................3 55 3. Algorithm Requirements.....................................3 56 4. Mutual OATH Definition.....................................4 57 4.1 HOTP Algorithm.............................................4 58 4.2 Algorithm Identifier.......................................5 59 4.3 Mutual OATH Authentication.................................6 60 4.4 Dual-key Mode..............................................6 61 4.5 Chained Mode...............................................7 62 4.6 PIN/Password "salted" HOTP Response........................7 63 4.7 Signature - Using HOTP with challenge and fixed value......8 64 5. Security Considerations....................................8 65 6. IANA Considerations........................................9 66 7. Conclusion.................................................9 67 8. Acknowledgements...........................................9 68 9. References.................................................9 69 10.1 Normative................................................9 70 10.2 Informative..............................................9 71 10. Authors' Addresses........................................10 72 12. Full Copyright Statement...................................11 73 13. Intellectual Property......................................11 75 1. Introduction 77 The HOTP algorithm is counter based and intended for synchronous 78 authentication mode systems. It has been implemented under various 79 form factors such as USB tokens, software client application, 80 validation servers, applets for smart-cards, etc. 82 OATH has identified several user cases and scenarios that require 83 an asynchronous variant to accommodate users who do not want to 84 maintain a synchronized authentication system. The commonly 85 accepted method for this is to use a challenge-response scheme. 87 This draft introduces the concept of randomized versions of HOTP, 88 where the counter field is replaced or extended by a function of 89 several parameters such as a random question and a personal 90 identification code or password. 92 Challenge response mode of authentication is widely adopted in the 93 industry. Several vendors already offer software applications and 94 hardware devices implementing challenge-response - but each of 95 those uses vendor-specific proprietary algorithms. For the benefits 96 of users we need a standardized challenge-response algorithm to 97 HOTP: An HMAC-based One Time Password Algorithm December 2005 99 allow multi-sourcing of token purchases and validation systems to 100 facilitate the democratization of strong authentication. 102 2. Requirements Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 106 this document are to be interpreted as described in BCP 14. 108 3. Algorithm Requirements 110 This section presents the main requirements that drove this 111 algorithm design. A lot of emphasis was placed on flexibility and 112 usability, under the constraints and specificity of the HOTP 113 algorithm and hardware token capabilities. 115 R1 - The shared secret MUST be embedded in a tamper resistance 116 device or securely implemented in a software application. 118 R2 - The secret SHOULD be stored in a hardware device for 119 additional flexibility (mobility) and security. 121 R3 - The algorithm MUST be capable of supporting different modes of 122 authentications. 124 R4 - The challenge value MUST be randomly generated for each use of 125 the authentication protocol and SHALL NOT be re-used. 127 R5 - The algorithm MUST allow for the challenge to be presented to 128 the user in numeric or alphanumeric form. 130 R6 - If the challenge is displayed to the user, the challenge 131 length SHOULD be selectable; the specification should define the 132 maximum length for a challenge. 134 R7 - There MUST be a fixed randomly generated secret (key) for each 135 token/soft token that is shared between the token and the 136 authentication server. 138 R8 - The challenge MAY be generated with integrity checking (e.g., 139 parity bits). This will allow tokens with pin pads to perform 140 simple error checking if the user enters the value into a token. 142 R9 - The algorithm MAY include a counter function. 144 R10 - The algorithm SHOULD be used in dual-key mode. The single key 145 is mainly to support legacy tokens. 147 HOTP: An HMAC-based One Time Password Algorithm December 2005 149 R11 - All the HOTP communications MUST take place over a secure 150 channel e.g. SSL/TLS, IPsec connections. 152 4. Mutual OATH Definition 154 In this section, we introduce the HOTP algorithm variants for 155 mutual authentication. 157 Words used in this chapter: 159 K - Key, a shared secret known to all parties 160 C - Counter, a predefined sequence of values that can be calculated 161 by all parties 162 P - Hashed version of PIN/password that is known to all parties 163 Q - Challenge, a predefined value that may change and is known to 164 all parties during execution of the algorithm 165 T - Fixed value that is used in a transaction 166 AI - Algorithm identifier, describes in detail in section 4.2 168 4.1 HOTP Algorithm 170 The HOTP algorithm is based on an increasing counter value and a 171 static symmetric key known only to the prover and verifier parties. 172 HOTP has been introduced as an internet draft and is currently in 173 the RFC-editor queue for final review. 175 As a reminder: 177 HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) 179 Where Truncate represents the function that converts an HMAC-SHA-1 180 value into an HOTP value of 6 to 8 digits. 182 The Key (K), the Counter (C) and Data values are hashed high-order 183 byte first. The HOTP values generated by the HOTP generator are 184 treated as big endian. 186 We refer the reader to [HOTP] for the full description and further 187 details on the rationale and security analysis of HOTP. 189 We introduced in [HOTP] the notion of a Data field that would be 190 used for generating the One-Time Password values. Using a Data 191 field opens for more flexibility in the algorithm implementation, 192 provided that the Data field is clearly specified. 194 A straightforward variant is to replace the counter value C by a 195 random question Q to define a Response as a function of the 196 challenge Q: 198 HOTP: An HMAC-based One Time Password Algorithm December 2005 200 Response = HOTP (K,Q) = Truncate (HMAC-SHA-1(K,Q)) 202 The present draft describes the different variants based on similar 203 constructions. 205 4.2 Algorithm Identifier 207 It is important for both parties willing to interact to know the 208 operations to be performed, namely which variant is to be used. 210 Let AI bit a binary string, and the different bits indicate which 211 combination of parameters is used to compute an HOTP response. 213 We could also specify the algorithm itself - by default, HOTP is 214 based on HMAC-SHA-1 but recent attacks on hash functions and new 215 standard works might result in recommendations to use another 216 function for HMAC. 218 We define the algorithm identifier AI as follows: 220 AI = Type | Pb | Qb | Cb | Tb | Mode 222 Where: 223 Type is a 4-bit value to specify the algorithm type; at the 224 moment, 4 types are defined: 225 0000: HMAC-SHA-1 without truncation 226 0001: HMAC-SHA-1 with Dynamic Truncation for 6-digit 227 0010: HMAC-SHA-1 with Dynamic Truncation for 7-digit 228 0011: HMAC-SHA-1 with Dynamic Truncation for 8-digit 229 Pb - single bit that indicates whether or not a hash of a PIN or 230 Password will be used in the computation; 231 Qb - single bit that indicates whether or not a random Q will be 232 used in the computation; 233 Cb - single bit that indicates whether or not a counter C will 234 be used in the computation; 235 Tb - single bit that indicates whether or not a fixed value T 236 will be used in the computation. 237 Mode is a 4-bit value that defines the different modes of 238 computation; at the moment, 4 types are defined: 239 0000: plain mode, single key 240 0001: plain mode, dual key 241 0010: chained mode, single key 242 0011: chained mode, dual key 243 With the chained mode as described in section 4.5 245 For instance, if the algorithm used is HOTP (K, C) with Dynamic 246 Truncation to generate 6-digit HOTP values as described in [HOTP] 247 as default mode then AI = 0001 0010 0000. 249 HOTP: An HMAC-based One Time Password Algorithm December 2005 251 4.3 Mutual OATH Authentication 253 A straightforward variant is to replace the counter value C by a 254 random question Q to define a randomized Response as a function of 255 the challenge Q: 257 Response = HOTP (K,Q) = Truncate (HMAC-SHA-1(K,Q)) 259 The challenge-response sequence is the following for parties A and 260 B sharing knowledge of secret (key) K and willing to perform Mutual 261 OATH authentication: 263 1- A sends a random question Q_A to B and AI = 0001 0100 0000 264 2- B computes Response_B = HOTP (K,Q_A) and sends it to A with 265 his own random question Q_B 266 3- A checks Response_B and if correct, computes Response_A = 267 HOTP (K,Q_B) 268 4- B checks Response_A and if correct, acknowledges party A 270 Both parties are authenticated. 272 4.4 Dual-key Mode 274 The key SHOULD be pre-divided into different usages. K1 is used for 275 computing responses and K2 to check responses. The opposite is used 276 for the other party. Depending on whether storage or computation is 277 cheaper, we could either store a longer key K = K1 | K2 or set K1 = 278 K and K2 = K xor Constant or K2 = SHA-1(K) for instance. 280 The challenge-response sequence is the following for parties A and 281 B sharing knowledge of secret (key) K. K is divided into K1 and K2. 283 1- A sends a random question Q_A to B and AI = 0001 0100 0001 284 2- B computes Response_B = HOTP (K2,Q_A) and sends it to A with 285 his own random question Q_B 286 3- A checks Response_B and if correct, computes Response_A = 287 HOTP (K1,Q_B) 288 4- B checks Response_A and if correct, acknowledges party A 290 Both parties are authenticated. Separating into K1 and K2 protects 291 against another party sending predefined questions "Q_A"'s to B for 292 querying specific information. 294 We recommend this mode of computation for mutual OATH. 296 HOTP: An HMAC-based One Time Password Algorithm December 2005 298 4.5 Chained Mode 300 Another interesting computation mode is to chain the computations 301 of different responses. It might have valuable applications such as 302 to verify that a certain sequence of operations has taken place. 304 The challenge-response sequence is the following for parties A and 305 B sharing knowledge of secret (key) K and willing to perform Mutual 306 OATH authentication in chained mode: 308 1- A sends a random question Q_A to B and AI = 0001 0100 0011 309 2- B computes Response_B = HOTP (K2,Q_A) and sends it to A with 310 his own random question Q_B 311 3- A checks Response_B and if correct, computes Response_A = 312 HOTP (K1,Q_B|Response_B) 313 4- B checks Response_A and if correct, acknowledges party A 315 Both parties are authenticated. 317 4.6 PIN/Password "salted" HOTP Response 319 In this case, the PIN/password value used to control the usage of 320 the token and/or protect access to the key embedded in the hardware 321 (or software) token can be injected in the Response computation, as 322 well as the random question Q: 324 Response = HOTP (K, Q|P) 326 Where | stands for concatenation. 328 The challenge-response sequence is the following for parties A and 329 B sharing knowledge of secret (key) K and willing to perform Mutual 330 OATH authentication: 332 1- A sends a random question Q_A to B and AI = 000110000 333 2- B computes Response_B = HOTP (K2,Q_A|P) and sends it to A 334 with his own random question Q_B 335 3- A checks Response_B and if correct, computes Response_A = 336 HOTP (K1,Q_B|P) 337 4- B checks Response_A and if correct, acknowledges party A 339 Obviously, the string P can be empty if party A or B does not have 340 a PIN or Password - e.g. a validation sever computing a response to 341 be authenticated by a user will probably not have the usage of a 342 PIN or password. 344 It opens for interesting combinations where the algorithm 345 identifier AI could be used to specify computations both ways - 346 e.g. the token could include the PIN in his computation and the 347 HOTP: An HMAC-based One Time Password Algorithm December 2005 349 server, knowing the hash checks the HOTP response; in its 350 calculation on the other hand, no PIN value would be included since 351 the server would not have one. 353 4.7 Signature - Using HOTP with challenge and fixed value 355 The combination of a fixed value and random value enables to 356 generate different signature values for different fixed values - 357 the computation is randomized by the question Q. This is important 358 when signing the same value more then once. 360 Signature = HOTP (K, Q|T) where | stands for concatenation. 362 The sequence for B generating a signature to be checked by A is the 363 following, assuming the mode of computation is dual-key plain mode: 364 1- A sends a fixed value C, a random question Q to B and AI = 365 0001 0110 0001 366 2- B computes Response_B = HOTP (K2,Q|T) and sends it to A 367 3- A checks Response_B and if correct, acknowledges party B has 368 validated the value T 370 In an hostile environment a third party can trick party B to reveal 371 the correct response for a given value. Again, all exchanges should 372 take place over a secure channel - using SSL/TLS, or similar 373 encryption mechanism. 375 5. Security Considerations 377 The keys for HOTP can be of any length equal or longer than 20 378 bytes. Keys longer than 20 bytes are acceptable; they are first 379 hashed using the supported hash function, e.g. SHA-1, to become 380 usable. Nevertheless, the extra length would not significantly 381 increase the cryptographic strength of Mutual OATH, provided the 382 randomness of the original key material is sufficient. 384 Keys need to be chosen at random or using a cryptographically 385 strong pseudo-random generator properly seeded with a random value. 386 We RECOMMEND to follow the recommendations in [RFC1750] for all 387 pseudo-random and random generations. The pseudo-random numbers 388 used for generating the keys SHOULD successfully pass the 389 randomness test specified in [CN]. 391 The conclusion of the security analysis detailed in [HOTP] is that, 392 for all practical purposes, the outputs of the dynamic truncation 393 on distinct counter inputs are uniformly and independently 394 distributed strings. 396 The analysis demonstrates that the best possible attack against the 397 HOTP function is the brute force attack. 399 HOTP: An HMAC-based One Time Password Algorithm December 2005 401 6. IANA Considerations 403 This document has no actions for IANA. 405 7. Conclusion 407 This draft introduced several variants of HOTP for randomized 408 response and short signature-like computations. 410 The algorithm identifier AI provides for an easy integration and 411 support of different HOTP flavors within an authentication and 412 validation system. 414 Mutual OATH should enable cross-authentication both in connected 415 and off-line modes, with the support of different response sizes 416 and mode of operations. 418 8. Acknowledgements 420 We would like to thank Siddharth Bajaj, Philip Hoyer, Jon 421 Martinsson and Stu Vaeth for their comments and suggestions to 422 improve this draft document. 424 9. References 426 10.1 Normative 428 [RFC2104] M. Bellare, R. Canetti and H. Krawczyk, "HMAC: 429 Keyed-Hashing for Message Authentication", IETF Network 430 Working Group, RFC 2104, February 1997. 432 [RFC1750] D. Eastlake, 3rd., S. Crocker and J. Schiller, 433 "Randomness Recommendantions for Security", IETF 434 Network Working Group, RFC 1750, December 2004. 436 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, March 1997. 439 [RFC3668] S. Bradner, "Intellectual Propery Rights in IETF 440 Technology", BCP 79, RFC 3668, February 2004. 442 10.2 Informative 444 [HOTP] D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and 445 O. Ranen, HOTP: HOTP: An HMAC-based One Time Password 446 Algorithm", Internet Draft, Informational. 447 http://www.ietf.org/internet-drafts/draft-mraihi-oath-hmac-otp- 448 04.txt 449 HOTP: An HMAC-based One Time Password Algorithm December 2005 451 [BCK] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash 452 Functions and Message Authentication", Proceedings of 453 Crypto'96, LNCS Vol. 1109, pp. 1-15. 455 [OATH] Initiative for Open AuTHentication 456 http://www.openauthentication.org 458 [CN] J.S. Coron and D. Naccache, "An accurate evaluation of 459 Maurer's universal test" by Jean-Sebastien Coron and 460 David Naccache In Selected Areas in Cryptography (SAC 461 '98), vol. 1556 of Lecture Notes in Computer Science, 462 S. Tavares and H. Meijer, Eds., pp. 57-71, Springer- 463 Verlag, 1999 465 10. Authors' Addresses 467 Primary point of contact (for sending comments and question): 469 David M'Raihi 470 VeriSign, Inc. 471 685 E. Middlefield Road Phone: 1-650-426-3832 472 Mountain View, CA 94043 USA Email: dmraihi@verisign.com 474 Other Authors' contact information: 476 Johan Rydell 477 Portwise, Inc. 478 624 Ellis Street, Suite 102 Phone: 1-650-472-3582 479 Mountain View, CA 94043 USA Email: johan.rydell@portwise.com 481 David Naccache 482 ENS, DI 483 45 rue d'Ulm Phone: +33 6 16 59 83 49 484 75005, Paris France Email: david.naccache@ens.fr 486 Salah Machani 487 Diversinet Corp. 488 2225 Sheppard Avenue East 489 Suite 1801 490 Toronto, Ontario M2J 5C2 Phone: 1-416-756-2324 Ext. 321 491 Canada Email: smachani@diversinet.com 492 HOTP: An HMAC-based One Time Password Algorithm December 2005 494 12. 495 Full Copyright Statement 497 Copyright (C) The Internet Society (2005). 499 This document is subject to the rights, licenses and restrictions 500 contained in BCP 78, and except as set forth therein, the authors 501 retain all their rights. 503 This document and the information contained herein are provided on 504 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 505 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 506 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 507 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 508 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 509 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 510 PARTICULAR PURPOSE. 512 13. 513 Intellectual Property 515 The IETF takes no position regarding the validity or scope of any 516 Intellectual Property Rights or other rights that might be claimed 517 to pertain to the implementation or use of the technology described 518 in this document or the extent to which any license under such 519 rights might or might not be available; nor does it represent that 520 it has made any independent effort to identify any such rights. 521 Information on the procedures with respect to rights in RFC 522 documents can be found in BCP 78 and BCP 79. 524 Copies of IPR disclosures made to the IETF Secretariat and any 525 assurances of licenses to be made available, or the result of an 526 attempt made to obtain a general license or permission for the use 527 of such proprietary rights by implementers or users of this 528 specification can be obtained from the IETF on-line IPR repository 529 at http://www.ietf.org/ipr. 531 The IETF invites any interested party to bring to its attention any 532 copyrights, patents or patent applications, or other proprietary 533 rights that may cover technology that may be required to implement 534 this standard. Please address the information to the IETF at ietf- 535 ipr@ietf.org.