idnits 2.17.1 draft-ietf-otp-ext-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1938]), 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. RFC 2119 keyword, line 70: '... token of data MUST be present....' RFC 2119 keyword, line 112: '... 1. MUST be able to receive and pa...' RFC 2119 keyword, line 114: '... 2. MUST be able to receive, parse...' RFC 2119 keyword, line 116: '... 3. MUST process the type field in...' RFC 2119 keyword, line 117: '... 4. MUST reject any authentication...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 17, 1997) is 9718 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) == Unused Reference: 'RFC 822' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC 1825' is defined on line 363, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1938 (Obsoleted by RFC 2289) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 One-Time Passwords Working Group Craig Metz 3 Internet Draft The Inner Net 4 draft-ietf-otp-ext-04.txt September 17, 1997 6 OTP Extended Responses 8 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas 11 and Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Drafts may be updated, replaced, or obsoleted by other 16 documents at any time. It is not appropriate to use Internet Drafts 17 as reference material or to cite them other than as a "working draft" 18 or "work in progress." 20 To learn the current status of any Internet Draft, please check the 21 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ds.internic.net (US East 23 Coast), nic.nordu.net (Europe), ftp.isi.com (US West Coast), or 24 munnari.oz.au (Pacific Rim). 26 The distribution of this Internet Draft is unlimited. It is filed as 27 and it expires on March 12, 1998. 29 Abstract 30 This document provides a specification for a type of response to an 31 OTP [RFC 1938] challenge that carries explicit indication of the 32 response's encoding. Codings for the two mandatory OTP data formats 33 using this new type of response are presented. 35 This document also provides a specification for a response that 36 allows an OTP generator to request that a server re-initialize a 37 sequence and change parameters such as the secret pass phrase. 39 1. Conventions, Terms, and Notation 41 This document specifies the data formats and software behaviors 42 needed to use OTP extended responses. The data formats are described 43 three ways: using an ad-hoc UNIX manual page style syntax, using 44 augmented BNF described in sections two and three of RFC 822, and by 45 examples. Should there be any conflict between these descriptions, 46 the augmented BNF takes precedence. The software behaviors are 47 described in words, and specific behavior compliance requirements are 48 itemized using the requirements terminology described in section four 49 of RFC 1938. 51 2. Extended Challenges and Extended Responses 53 This document builds on the protocol and terminology specified in RFC 54 1938 and assumes that you have already read this document and 55 understand its contents. 57 An extended challenge is a single line of printable text terminated 58 by either a new line sequence appropriate for the context of its use 59 (e.g., ASCII CR followed by ASCII LF) or a whitespace character. It 60 contains a standard OTP challenge, a whitespace character, and a list 61 that generators use to determine which extended responses are 62 supported by a server. 64 An extended response is a single line of printable text terminated by 65 a new line sequence appropriate for the context of its use. It 66 contains two or more tokens that are separated with a single colon 67 (':') character. The first token contains a type specifier that 68 indicates the format of the rest of the response. The tokens that 69 follow are argument data for the OTP extended response. At least one 70 token of data MUST be present. 72 2.1. Syntax 74 In UNIX manual page like syntax, the general form of an extended 75 challenge could be described as: 77 ext[,[, ...]] 79 And the general form of an extended response could be described as: 81 :[:[:...]] 83 In augmented BNF syntax, the syntax of the general form of an 84 extended challenge and an extended response is: 86 extended-challenge = otp-challenge 1*LWSP-char capability-list 87 (NL / *LWSP-char) 88 otp-challenge = 89 capability-list = "ext" *("," extension-set-id) 90 extension-set-id = * 91 extended-response = type 1*(":" argument) NL 92 type = token 93 argument = token 94 token = 1* 95 NL = 98 An example of an extended challenge indicating support for OTP 99 extended responses and for a mythical response set "foo" is: 101 otp-md5 123 mi1234 ext,foo 103 An example of an extended response using a mythical type named "foo" 104 is: 106 foo:some data:some more data:12345 108 2.2. Requirements 110 A server compliant with this specification: 112 1. MUST be able to receive and parse the general form of an 113 extended response 114 2. MUST be able to receive, parse, and correctly process all 115 extended responses specified in this document 116 3. MUST process the type field in a case-insensitive manner 117 4. MUST reject any authentication attempt using an extended 118 response if it does not support that type of response 119 5. SHOULD provide an appropriate indication to the generator if the 120 response was rejected because of (4) 121 6. MUST limit the length of the input reasonably 122 7. MUST accept otherwise arbitrary amounts of whitespace wherever a 123 response allows it 124 8. MUST be able to receive and correctly process standard OTP 125 responses 127 A generator compliant with this specification: 129 1. MUST be able to generate standard OTP responses 130 2. MUST use standard responses unless an extended challenge 131 has been received for the particular server AND seed 132 3. MUST generate the type field in lower case 133 4. MUST NOT send a response type for which the server has not 134 indicated support through an extended challenge 136 Extension set identifiers and extension type identifiers named with 137 the prefix "x-" are reserved for private use among mutually 138 consenting implementations. Implementations that do not recognise a 139 particular "x-" extension MUST ignore that extension. This means that 140 all "x-" extensions are likely to be non-interoperable with other 141 extensions. Careful consideration should be given to the possibility 142 of a server interacting with with a generator implementation which, 143 although it recognizes a given "x-" extension, uses it for a 144 different purpose. All of the remaining extension namespace is 145 reserved to IANA, which will only officially assign the extension 146 into this namespace after the IESG approves of such an assignment. 147 During the lifetime of the OTP WG, it is recommended that the IESG 148 consult with the OTP WG prior to approving such an assignment. 150 3. The "hex" and "word" Responses 152 There exists a very rare case in which a standard OTP response could 153 be a valid coding in both the hexadecimal and six-word formats. An 154 example of this is the response "ABE ACE ADA ADD BAD A." The 155 solution to this problem mandated by the OTP specification is that 156 compliant servers MUST attempt to parse and verify a standard 157 response in both hexadecimal and six-word formats and must consider 158 the authentication successful if either succeeds. 160 This problem can be solved easily using extended responses. The "hex" 161 response and the "word" response are two response types that encode 162 an OTP in an extended response that explicitly describes the 163 encoding. These responses start with a type label of "hex" for a 164 hexadecimal OTP and "word" for a six-word coded OTP. These responses 165 contain one argument field that contains a standard OTP response 166 coded in the indicated format. 168 3.1. Syntax 170 In UNIX manual page like syntax, the format of these responses could 171 be described as: 173 hex: 174 word: 176 In augmented BNF syntax and with the definitions already provided, 177 the syntax of these responses is: 179 hex-response = "hex:" hex-64bit NL 180 hex-64bit = 16(hex-char *LWSP-char) 181 hex-char = ("A" / "B" / "C" / "D" / "E" / "F" / 182 "a" / "b" / "c" / "d" / "e" / "f" / 183 "0" / "1" / "2" / "3" / "4" / "5" / 184 "6" / "7" / "8" / "9") 186 word-response = "word:" word-64bit NL 187 word-64bit = 6(otp-word 1*LWSP-char) 188 otp-word = 191 Examples of these responses are: 193 hex:8720 33d4 6202 9172 194 word:VAST SAUL TAKE SODA SUCH BOLT 196 3.2. Requirements 198 A server compliant with this specification: 200 1. MUST process all arguments in a case-insensitive manner 202 A generator compliant with this specification: 204 1. SHOULD generate otp-word tokens in upper case with single spaces 205 separating them 206 2. SHOULD generate hexadecimal numbers using only lower case for 207 letters 209 4. The "init-hex" and "init-word" Responses 211 The OTP specification requires that implementations provide a means 212 for a client to re-initialize or change its OTP information with a 213 server but does not require any specific protocol for doing it. 214 Implementations that support the OTP extended responses described in 215 this document MUST support the response with the "init-hex" and 216 "init-word" type specifiers, which provide a standard way for a 217 client to re-initialize its OTP information with a server. This 218 response is intended to be used only by automated clients. Because of 219 this, the recommended form of this response uses the hexadecimal 220 encoding for binary data. It is possible for a user to type an "init- 221 hex" or "init-word" response. 223 4.1. Syntax 225 In UNIX manual page like syntax, the format of these responses could 226 be described as: 228 init-hex::: 229 init-word::: 231 In augmented BNF syntax and with the definitions already provided, 232 the syntax of the "init-hex" response is: 234 init-hex-response = "init-hex:" current-OTP ":" new-params ":" 235 new-OTP NL 237 current-OTP = hex-64bit 238 new-OTP = hex-64bit 240 new-params = algorithm SPACE sequence-number SPACE seed 241 algorithm = "md4" / "md5" / "sha1" 242 sequence-number = 4*3DIGIT 243 seed = 16*1(ALPHA / DIGIT) 245 In augmented BNF syntax and with the definitions already provided, 246 the syntax of the "init-word" response is: 248 init-word-response = "init-word:" current-OTP ":" new-params ":" 249 new-OTP NL 251 current-OTP = word-64bit 252 new-OTP = word-64bit 254 new-params = algorithm SPACE sequence-number SPACE seed 255 algorithm = "md4" / "md5" / "sha1" 256 sequence-number = 4*3DIGIT 257 seed = 16*1(ALPHA / DIGIT) 259 Note that all appropriate fields for the "init-hex" response MUST be 260 hexadecimally coded and that all appropriate fields for the "init- 261 word" response MUST be six-word coded. 263 Examples of these responses are: 265 init-hex:f6bd 6b33 89b8 7203:md5 499 ke6118:23d1 b253 5ae0 2b7e 266 init-hex:c9b2 12bb 6425 5a0f:md5 499 ke0986:fd17 cef1 b4df 093e 268 init-word:MOOD SOFT POP COMB BOLO LIFE:md5 499 ke1235: 269 ARTY WEAR TAD RUG HALO GIVE 270 init-word:END KERN BALM NICK EROS WAVY:md5 499 ke1235: 271 BABY FAIN OILY NIL TIDY DADE 273 (Note that all of these responses are one line. Due to their length, 274 they had to be split into multiple lines in order to be included 275 here. These responses MUST NOT span more than one line in actual use) 277 4.2. Description of Fields 279 The current-OTP field contains the (RFC 1938) response to the OTP 280 challenge. The new-params field contains the parameters for the 281 client's new requested challenge and the new-OTP field contains a 282 response to that challenge. If the re-initialization is successful, a 283 server MUST store the new OTP in its database as the last successful 284 OTP received and the sequence number in the next challenge presented 285 by the server MUST be one less than the sequence number specified in 286 the new-params field. 288 The new-params field is hashed as a string the same way that a seed 289 or secret pass phrase would be. All other field values are hashed in 290 their uncoded binary forms, in network byte order and without any 291 padding. 293 4.3. Requirements 295 A server compliant with this specification: 297 1. SHOULD NOT allow a user to use the same value for their seed and 298 secret pass phrase. 299 2. MUST disable all OTP access to any principal whose sequence 300 number would be less than one 301 3. MUST decrement the sequence number if a reinitialization response 302 includes a valid current-OTP, but the server is unable to 303 successfully process the new-params or new-OTP for any reason. 305 A generator compliant with this specification: 307 1. SHOULD NOT allow a user to use the same value for their seed and 308 secret pass phrase 309 2. MUST take specific steps to prevent infinite loops of 310 re-initialization attempts in case of failure 311 3. SHOULD provide the user with some indication that the 312 re-initialization is taking place 313 4. SHOULD NOT do a re-initialization without the user's permission, 314 either for that specific instance or as a configuration option 315 5. SHOULD NOT retry a failed re-initialization without a user's 316 permission 317 6. SHOULD warn the user if the sequence number falls below ten 318 7. MUST refuse to generate OTPs with a sequence number below one 320 5. Security Considerations 322 All of the security considerations for the OTP system also apply to 323 the OTP system with extended responses. 325 These extended responses, like OTP itself, do not protect the user 326 against active attacks. The IPsec Authentication Header (RFC-1826) 327 (or another technique with at least as much strength as IPsec AH) 328 SHOULD be used to protect against such attacks. 330 The consequences of a successful active attack on the re- 331 initialization response may be more severe than simply hijacking a 332 single session. An attacker could substitute his own response for 333 that of a legitimate user. The attacker may then be able to use the 334 OTP system to authenticate himself as the user at will (at least 335 until detected). 337 Failure to implement server requirement 3 in section 4.3 opens an 338 implementation to an attack based on replay of the current-OTP part 339 of the response. 341 6. Acknowledgments 343 Like RFC 1938, the protocol described in this document was created by 344 contributors in the IETF OTP working group. Specific contributions 345 were made by Neil Haller, who provided input on the overall design 346 requirements of a re-initialization protocol, Denis Pinkas, who 347 suggested several modifications to the originally proposed re- 348 initialization protocol, and Phil Servita, who opened the debate with 349 the first real protocol proposal and provided lots of specific input 350 on the design of this and earlier protocols. The extensions to the 351 OTP challenge were suggested by Chris Newman and John Valdes. 353 Randall Atkinson and Ted T'so also contributed their views to 354 discussions about details of the protocol extensions in this 355 document. 357 References 359 [RFC 822] David H. Crocker, Standard for the Format of ARPA Internet 360 Text Messages, "Request for Comments (RFC) 822", August 361 13, 1982. 363 [RFC 1825] R. Atkinson, Security Architecture for the Internet 364 Protocol, "Request for Comments (RFC) 1825", August 9, 365 1995. 367 [RFC 1938] N. Haller and C. Metz, A One-Time Password System, 368 "Request for Comments (RFC) 1938", Bellcore and Kaman 369 Sciences Corporation, May 1996. 371 Author's Address 373 Craig Metz 374 The Inner Net 375 Box 10314-1936 376 Blacksburg, VA 24062-0314 377 (DSN) 354-8590 378 cmetz@inner.net 380 Appendix: Reference Responses 382 The following responses were generated by a development version of 383 the One-Time Passwords in Everything (OPIE) implementation of this 384 specification. 386 All of these are responses to the challenge: 388 otp-md5 499 ke1234 ext 390 Note that the re-initialization responses use the same secret pass 391 phrase for new and current and a new seed of "ke1235". Also, these 392 responses have been split for formatting purposes into multiple 393 lines; they MUST NOT be multiple lines in actual use. 395 The secret pass phrase for these responses is: 397 This is a test. 399 The OTP standard hexadecimal response is: 401 5bf0 75d9 959d 036f 403 The OTP standard six-word response is: 405 BOND FOGY DRAB NE RISE MART 407 The OTP extended "hex" response is: 409 hex:5Bf0 75d9 959d 036f 411 The OTP extended "word" response is: 413 word:BOND FOGY DRAB NE RISE MART 415 The OTP extended "init-hex" response is: 417 init-hex:5bf0 75d9 959d 036f:md5 499 ke1235:3712 dcb4 aa53 16c1 419 The OTP extended "init-word" response is: 421 init-word:BOND FOGY DRAB NE RISE MART:md5 499 ke1235: 422 RED HERD NOW BEAN PA BURG