idnits 2.17.1 draft-mraihi-mutual-oath-hotp-variants-01.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 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 536. ** 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 6706 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 445 looks like a reference -- Missing reference section? 'OATH' on line 456 looks like a reference -- Missing reference section? 'RFC2104' on line 429 looks like a reference -- Missing reference section? 'RFC1750' on line 433 looks like a reference -- Missing reference section? 'CN' on line 459 looks like a reference -- Missing reference section? 'RFC2119' on line 437 looks like a reference -- Missing reference section? 'RFC3668' on line 440 looks like a reference -- Missing reference section? 'BCK' on line 452 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-01.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 applications, 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 (Personal Identification Number) or 163 password that is known to all parties 164 Q - Challenge, a predefined value that may change and is known to 165 all parties during execution of the algorithm 166 T - Fixed value that is used in a transaction 167 AI - Algorithm identifier, described in details in section 4.2 169 4.1 HOTP Algorithm 171 The HOTP algorithm is based on an increasing counter value and a 172 static symmetric key known only to the prover and verifier parties. 173 HOTP has been introduced as an internet draft and is currently in 174 the RFC-editor queue for final review. 176 As a reminder: 178 HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) 180 Where Truncate represents the function that converts an HMAC-SHA-1 181 value into an HOTP value of 6 to 8 digits. 183 The Key (K), the Counter (C) and Data values are hashed high-order 184 byte first. The HOTP values generated by the HOTP generator are 185 treated as big endian. 187 We refer the reader to [HOTP] for the full description and further 188 details on the rationale and security analysis of HOTP. 190 We introduced in [HOTP] the notion of a Data field that would be 191 used for generating the One-Time Password values. Using a Data 192 field opens for more flexibility in the algorithm implementation, 193 provided that the Data field is clearly specified. 195 A straightforward variant is to replace the counter value C by a 196 random question Q to define a Response as a function of the 197 challenge Q: 199 HOTP: An HMAC-based One Time Password Algorithm December 2005 201 Response = HOTP (K,Q) = Truncate (HMAC-SHA-1(K,Q)) 203 The present draft describes the different variants based on similar 204 constructions. 206 4.2 Algorithm Identifier 208 It is important for both parties willing to interact to know the 209 operations to be performed, namely which variant is to be used. 211 Let AI bit a binary string, and the different bits indicate which 212 combination of parameters is used to compute an HOTP response. 214 We could also specify the algorithm itself - by default, HOTP is 215 based on HMAC-SHA-1 but recent attacks on hash functions and new 216 standard works might result in recommendations to use another 217 function for HMAC. 219 We define the algorithm identifier AI as follows: 221 AI = Type | Pb | Qb | Cb | Tb | Mode 223 Where: 224 Type is a 4-bit value to specify the algorithm type; at the 225 moment, 4 types are defined: 226 0000: HMAC-SHA-1 without truncation 227 0001: HMAC-SHA-1 with Dynamic Truncation for 6-digit 228 0010: HMAC-SHA-1 with Dynamic Truncation for 7-digit 229 0011: HMAC-SHA-1 with Dynamic Truncation for 8-digit 230 Pb - single bit that indicates whether or not a hash of a PIN or 231 Password will be used in the computation; 232 Qb - single bit that indicates whether or not a random Q will be 233 used in the computation; 234 Cb - single bit that indicates whether or not a counter C will 235 be used in the computation; 236 Tb - single bit that indicates whether or not a fixed value T 237 will be used in the computation. 238 Mode is a 4-bit value that defines the different modes of 239 computation; at the moment, 4 types are defined: 240 0000: plain mode, single key 241 0001: plain mode, dual key 242 0010: chained mode, single key 243 0011: chained mode, dual key 244 With the chained mode as described in section 4.5 246 For instance, if the algorithm used is HOTP (K, C) with Dynamic 247 Truncation to generate 6-digit HOTP values as described in [HOTP] 248 as default mode then AI = 0001 0010 0000. 250 HOTP: An HMAC-based One Time Password Algorithm December 2005 252 4.3 Mutual OATH Authentication 254 A straightforward variant is to replace the counter value C by a 255 random question Q to define a randomized Response as a function of 256 the challenge Q: 258 Response = HOTP (K,Q) = Truncate (HMAC-SHA-1(K,Q)) 260 The challenge-response sequence is the following for parties A and 261 B sharing knowledge of secret (key) K and willing to perform Mutual 262 OATH authentication: 264 1- A sends a random question Q_A to B and AI = 0001 0100 0000 265 2- B computes Response_B = HOTP (K,Q_A) and sends it to A with 266 his own random question Q_B 267 3- A checks Response_B and if correct, computes Response_A = 268 HOTP (K,Q_B) 269 4- B checks Response_A and if correct, acknowledges party A 271 Both parties are authenticated. 273 4.4 Dual-key Mode 275 The key SHOULD be pre-divided into different usages. K1 is used for 276 computing responses and K2 to check responses. The opposite is used 277 for the other party. Depending on whether storage or computation is 278 cheaper, we could either store a longer key K = K1 | K2 or set K1 = 279 K and K2 = K xor Constant or K2 = SHA-1(K) for instance. 281 The challenge-response sequence is the following for parties A and 282 B sharing knowledge of secret (key) K. K is divided into K1 and K2. 284 1- A sends a random question Q_A to B and AI = 0001 0100 0001 285 2- B computes Response_B = HOTP (K2,Q_A) and sends it to A with 286 his own random question Q_B 287 3- A checks Response_B and if correct, computes Response_A = 288 HOTP (K1,Q_B) 289 4- B checks Response_A and if correct, acknowledges party A 291 Both parties are authenticated. Separating into K1 and K2 protects 292 against another party sending predefined questions "Q_A"'s to B for 293 querying specific information. 295 We recommend this mode of computation for mutual OATH. 297 HOTP: An HMAC-based One Time Password Algorithm December 2005 299 4.5 Chained Mode 301 Another interesting computation mode is to chain the computations 302 of different responses. It might have valuable applications such as 303 to verify that a certain sequence of operations has taken place. 305 The challenge-response sequence is the following for parties A and 306 B sharing knowledge of secret (key) K and willing to perform Mutual 307 OATH authentication in chained mode: 309 1- A sends a random question Q_A to B and AI = 0001 0100 0011 310 2- B computes Response_B = HOTP (K2,Q_A) and sends it to A with 311 his own random question Q_B 312 3- A checks Response_B and if correct, computes Response_A = 313 HOTP (K1,Q_B|Response_B) 314 4- B checks Response_A and if correct, acknowledges party A 316 Both parties are authenticated. 318 4.6 PIN/Password "salted" HOTP Response 320 In this case, the PIN/password value used to control the usage of 321 the token and/or protect access to the key embedded in the hardware 322 (or software) token can be injected in the Response computation, as 323 well as the random question Q: 325 Response = HOTP (K, Q|P) 327 Where | stands for concatenation. 329 The challenge-response sequence is the following for parties A and 330 B sharing knowledge of secret (key) K and willing to perform Mutual 331 OATH authentication: 333 1- A sends a random question Q_A to B and AI = 000110000 334 2- B computes Response_B = HOTP (K2,Q_A|P) and sends it to A 335 with his own random question Q_B 336 3- A checks Response_B and if correct, computes Response_A = 337 HOTP (K1,Q_B|P) 338 4- B checks Response_A and if correct, acknowledges party A 340 Obviously, the string P can be empty if party A or B does not have 341 a PIN or Password - e.g. a validation sever computing a response to 342 be authenticated by a user will probably not have the usage of a 343 PIN or password. 345 It opens for interesting combinations where the algorithm 346 identifier AI could be used to specify computations both ways - 347 e.g. the token could include the PIN in his computation and the 348 HOTP: An HMAC-based One Time Password Algorithm December 2005 350 server, knowing the hash checks the HOTP response; in its 351 calculation on the other hand, no PIN value would be included since 352 the server would not have one. 354 4.7 Signature - Using HOTP with challenge and fixed value 356 The combination of a fixed value and random value enables to 357 generate different signature values for different fixed values - 358 the computation is randomized by the question Q. This is important 359 when signing the same value more then once. 361 Signature = HOTP (K, Q|T) where | stands for concatenation. 363 The sequence for B generating a signature to be checked by A is the 364 following, assuming the mode of computation is dual-key plain mode: 365 1- A sends a fixed value C, a random question Q to B and AI = 366 0001 0110 0001 367 2- B computes Response_B = HOTP (K2,Q|T) and sends it to A 368 3- A checks Response_B and if correct, acknowledges party B has 369 validated the value T 371 In an hostile environment a third party can trick party B to reveal 372 the correct response for a given value. Again, all exchanges should 373 take place over a secure channel - using SSL/TLS, or similar 374 encryption mechanism. 376 5. Security Considerations 378 The keys for HOTP can be of any length equal or longer than 20 379 bytes. Keys longer than 20 bytes are acceptable; they are first 380 hashed using the supported hash function, e.g. SHA-1, to become 381 usable. Nevertheless, the extra length would not significantly 382 increase the cryptographic strength of Mutual OATH, provided the 383 randomness of the original key material is sufficient. 385 Keys need to be chosen at random or using a cryptographically 386 strong pseudo-random generator properly seeded with a random value. 387 We RECOMMEND to follow the recommendations in [RFC1750] for all 388 pseudo-random and random generations. The pseudo-random numbers 389 used for generating the keys SHOULD successfully pass the 390 randomness test specified in [CN]. 392 The conclusion of the security analysis detailed in [HOTP] is that, 393 for all practical purposes, the outputs of the dynamic truncation 394 on distinct counter inputs are uniformly and independently 395 distributed strings. 397 The analysis demonstrates that the best possible attack against the 398 HOTP function is the brute force attack. 400 HOTP: An HMAC-based One Time Password Algorithm December 2005 402 6. IANA Considerations 404 This document has no actions for IANA. 406 7. Conclusion 408 This draft introduced several variants of HOTP for randomized 409 response and short signature-like computations. 411 The algorithm identifier AI provides for an easy integration and 412 support of different HOTP flavors within an authentication and 413 validation system. 415 Mutual OATH should enable cross-authentication both in connected 416 and off-line modes, with the support of different response sizes 417 and mode of operations. 419 8. Acknowledgements 421 We would like to thank Siddharth Bajaj, Philip Hoyer, Jon 422 Martinsson and Stu Vaeth for their comments and suggestions to 423 improve this draft document. 425 9. References 427 10.1 Normative 429 [RFC2104] M. Bellare, R. Canetti and H. Krawczyk, "HMAC: 430 Keyed-Hashing for Message Authentication", IETF Network 431 Working Group, RFC 2104, February 1997. 433 [RFC1750] D. Eastlake, 3rd., S. Crocker and J. Schiller, 434 "Randomness Recommendantions for Security", IETF 435 Network Working Group, RFC 1750, December 2004. 437 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC3668] S. Bradner, "Intellectual Propery Rights in IETF 441 Technology", BCP 79, RFC 3668, February 2004. 443 10.2 Informative 445 [HOTP] D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and 446 O. Ranen, HOTP: HOTP: An HMAC-based One Time Password 447 Algorithm", Internet Draft, Informational. 448 http://www.ietf.org/internet-drafts/draft-mraihi-oath-hmac-otp- 449 04.txt 450 HOTP: An HMAC-based One Time Password Algorithm December 2005 452 [BCK] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash 453 Functions and Message Authentication", Proceedings of 454 Crypto'96, LNCS Vol. 1109, pp. 1-15. 456 [OATH] Initiative for Open AuTHentication 457 http://www.openauthentication.org 459 [CN] J.S. Coron and D. Naccache, "An accurate evaluation of 460 Maurer's universal test" by Jean-Sebastien Coron and 461 David Naccache In Selected Areas in Cryptography (SAC 462 '98), vol. 1556 of Lecture Notes in Computer Science, 463 S. Tavares and H. Meijer, Eds., pp. 57-71, Springer- 464 Verlag, 1999 466 10. Authors' Addresses 468 Primary point of contact (for sending comments and question): 470 David M'Raihi 471 VeriSign, Inc. 472 685 E. Middlefield Road Phone: 1-650-426-3832 473 Mountain View, CA 94043 USA Email: dmraihi@verisign.com 475 Other Authors' contact information: 477 Johan Rydell 478 Portwise, Inc. 479 624 Ellis Street, Suite 102 Phone: 1-650-472-3582 480 Mountain View, CA 94043 USA Email: johan.rydell@portwise.com 482 David Naccache 483 ENS, DI 484 45 rue d'Ulm Phone: +33 6 16 59 83 49 485 75005, Paris France Email: david.naccache@ens.fr 487 Salah Machani 488 Diversinet Corp. 489 2225 Sheppard Avenue East 490 Suite 1801 491 Toronto, Ontario M2J 5C2 Phone: 1-416-756-2324 Ext. 321 492 Canada Email: smachani@diversinet.com 493 HOTP: An HMAC-based One Time Password Algorithm December 2005 495 12. 496 Full Copyright Statement 498 Copyright (C) The Internet Society (2005). 500 This document is subject to the rights, licenses and restrictions 501 contained in BCP 78, and except as set forth therein, the authors 502 retain all their rights. 504 This document and the information contained herein are provided on 505 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 506 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 507 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 508 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 509 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 510 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 511 PARTICULAR PURPOSE. 513 13. 514 Intellectual Property 516 The IETF takes no position regarding the validity or scope of any 517 Intellectual Property Rights or other rights that might be claimed 518 to pertain to the implementation or use of the technology described 519 in this document or the extent to which any license under such 520 rights might or might not be available; nor does it represent that 521 it has made any independent effort to identify any such rights. 522 Information on the procedures with respect to rights in RFC 523 documents can be found in BCP 78 and BCP 79. 525 Copies of IPR disclosures made to the IETF Secretariat and any 526 assurances of licenses to be made available, or the result of an 527 attempt made to obtain a general license or permission for the use 528 of such proprietary rights by implementers or users of this 529 specification can be obtained from the IETF on-line IPR repository 530 at http://www.ietf.org/ipr. 532 The IETF invites any interested party to bring to its attention any 533 copyrights, patents or patent applications, or other proprietary 534 rights that may cover technology that may be required to implement 535 this standard. Please address the information to the IETF at ietf- 536 ipr@ietf.org.