idnits 2.17.1 draft-ietf-otp-ext-03.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-20) 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-otp-ext-03.txt(when', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-otp-ext-03.txt(when', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-otp-ext-03.txt(when', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-otp-ext-03.txt(when', but the file name used is 'draft-ietf-otp-ext-03' == 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 90 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** 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 69: '... token of data MUST be present....' RFC 2119 keyword, line 111: '... 1. MUST be able to receive and pa...' RFC 2119 keyword, line 113: '... 2. MUST be able to receive, parse...' RFC 2119 keyword, line 115: '... 3. MUST process the type field in...' RFC 2119 keyword, line 116: '... 4. MUST reject any authentication...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 8 has weird spacing: '... This docum...' == Line 10 has weird spacing: '.... Note that ...' == Line 14 has weird spacing: '... Drafts may ...' == Line 19 has weird spacing: '... please check...' == Line 20 has weird spacing: '...cts.txt listi...' == (85 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 12, 1997) is 9717 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 349, but no explicit reference was found in the text == Unused Reference: 'RFC 1825' is defined on line 353, 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: 18 errors (**), 1 flaw (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 One-Time Passwords Working Group Craig Metz 2 Internet Draft The Inner Net 3 draft-ietf-otp-ext-03.txt(when posted) September 12, 1997 5 OTP Extended Responses 7 Status of this Memo 8 This document is an Internet Draft. Internet Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its Areas 10 and Working Groups. Note that other groups may also distribute 11 working documents as Internet Drafts. 13 Internet Drafts are draft documents valid for a maximum of six 14 months. Drafts may be updated, replaced, or obsoleted by other 15 documents at any time. It is not appropriate to use Internet Drafts 16 as reference material or to cite them other than as a "working draft" 17 or "work in progress." 19 To learn the current status of any Internet Draft, please check the 20 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), ds.internic.net (US East 22 Coast), nic.nordu.net (Europe), ftp.isi.com (US West Coast), or 23 munnari.oz.au (Pacific Rim). 25 The distribution of this Internet Draft is unlimited. It is filed as 26 and it expires on March 12, 1998. 28 Abstract 29 This document provides a specification for a type of response to an 30 OTP [RFC 1938] challenge that carries explicit indication of the 31 response's encoding. Codings for the two mandatory OTP data formats 32 using this new type of response are presented. 34 This document also provides a specification for a response that 35 allows an OTP generator to request that a server re-initialize a 36 sequence and change parameters such as the secret pass phrase. 38 1. Conventions, Terms, and Notation 40 This document specifies the data formats and software behaviors 41 needed to use OTP extended responses. The data formats are described 42 three ways: using an ad-hoc UNIX manual page style syntax, using 43 augmented BNF described in sections two and three of RFC 822, and by 44 examples. Should there be any conflict between these descriptions, 45 the augmented BNF takes precedence. The software behaviors are 46 described in words, and specific behavior compliance requirements are 47 itemized using the requirements terminology described in section four 48 of RFC 1938. 50 2. Extended Challenges and Extended Responses 52 This document builds on the protocol and terminology specified in RFC 53 1938 and assumes that you have already read this document and 54 understand its contents. 56 An extended challenge is a single line of printable text terminated 57 by either a new line sequence appropriate for the context of its use 58 (e.g., ASCII CR followed by ASCII LF) or a whitespace character. It 59 contains a standard OTP challenge, a single space character, and a 60 list that generators use to determine which extended responses are 61 supported by a server. 63 An extended response is a single line of printable text terminated by 64 a new line sequence appropriate for the context of its use. It 65 contains two or more tokens that are separated with a single colon 66 (':') character. The first token contains a type specifier that 67 indicates the format of the rest of the response. The tokens that 68 follow are argument data for the OTP extended response. At least one 69 token of data MUST be present. 71 2.1. Syntax 73 In UNIX manual page like syntax, the general form of an extended 74 challenge could be described as: 76 ext[,[, ...]] 78 And the general form of an extended response could be described as: 80 :[:[:...]] 82 In augmented BNF syntax, the syntax of the general form of an 83 extended challenge and an extended response is: 85 extended-challenge = otp-challenge 1*LWSP-char capability-list 86 (NL / *LWSP-char) 87 otp-challenge = 88 capability-list = "ext" *("," extension-set-id) 89 extension-set-id = * 90 extended-response = type 1*(":" argument) NL 91 type = token 92 argument = token 93 token = 1* 94 NL = 97 An example of an extended challenge indicating support for OTP 98 extended responses and for a mythical response set "foo" is: 100 otp-md5 123 mi1234 ext,foo 102 An example of an extended response using a mythical type named "foo" 103 is: 105 foo:some data:some more data:12345 107 2.2. Requirements 109 A server compliant with this specification: 111 1. MUST be able to receive and parse the general form of an 112 extended response 113 2. MUST be able to receive, parse, and correctly process all 114 extended responses specified in this document 115 3. MUST process the type field in a case-insensitive manner 116 4. MUST reject any authentication attempt using an extended 117 response if it does not support that type of response 118 5. SHOULD provide an appropriate indication to the generator if the 119 response was rejected because of (4) 120 6. MUST limit the length of the input reasonably 121 7. MUST accept otherwise arbitrary amounts of whitespace wherever a 122 response allows it 123 8. MUST be able to receive and correctly process standard OTP 124 responses 125 9. MUST NOT advertise an extension set ID that has not been 126 assigned by the Internet Assigned Numbers Authority (IANA). 127 That is, "private" or "extension" values are forbidden. 129 A generator compliant with this specification: 131 1. MUST be able to generate standard OTP responses 132 2. MUST use standard responses unless an extended challenge 133 has been received for the particular server AND seed 134 3. MUST generate the type field in lower case 135 4. MUST NOT send a response type for which the server has not 136 indicated support through an extended challenge 137 5. MUST NOT send a response type value that has not been 138 assigned by the Internet Assigned Numbers Authority (IANA). 139 That is, "private" or "extension" values are forbidden. 141 3. The "hex" and "word" Responses 143 There exists a very rare case in which a standard OTP response could 144 be a valid coding in both the hexadecimal and six-word formats. An 145 example of this is the response "ABE ACE ADA ADD BAD A." The 146 solution to this problem mandated by the OTP specification is that 147 compliant servers MUST attempt to parse and verify a standard 148 response in both hexadecimal and six-word formats and must consider 149 the authentication successful if either succeeds. 151 This problem can be solved easily using extended responses. The "hex" 152 response and the "word" response are two response types that encode 153 an OTP in an extended response that explicitly describes the 154 encoding. These responses start with a type label of "hex" for a 155 hexadecimal OTP and "word" for a six-word coded OTP. These responses 156 contain one argument field that contains a standard OTP response 157 coded in the indicated format. 159 3.1. Syntax 161 In UNIX manual page like syntax, the format of these responses could 162 be described as: 164 hex: 165 word: 167 In augmented BNF syntax and with the definitions already provided, 168 the syntax of these responses is: 170 hex-response = "hex:" hex-64bit NL 171 hex-64bit = 16(hex-char *LWSP-char) 172 hex-char = ("A" / "B" / "C" / "D" / "E" / "F" / 173 "a" / "b" / "c" / "d" / "e" / "f" / 174 "0" / "1" / "2" / "3" / "4" / "5" / 175 "6" / "7" / "8" / "9") 177 word-response = "word:" word-64bit NL 178 word-64bit = 6(otp-word 1*LWSP-char) 179 otp-word = 182 Examples of these responses are: 184 hex:8720 33d4 6202 9172 185 word:VAST SAUL TAKE SODA SUCH BOLT 187 3.2. Requirements 189 A server compliant with this specification: 191 1. MUST process all arguments in a case-insensitive manner 193 A generator compliant with this specification: 195 1. SHOULD generate otp-word tokens in upper case with single spaces 196 separating them 197 2. SHOULD generate hexadecimal numbers using only lower case for 198 letters 200 4. The "init-hex" and "init-word" Responses 202 The OTP specification requires that implementations provide a means 203 for a client to re-initialize or change its OTP information with a 204 server but does not require any specific protocol for doing it. 205 Implementations that support the OTP extended responses described in 206 this document MUST support the response with the "init-hex" and 207 "init-word" type specifiers, which provide a standard way for a 208 client to re-initialize its OTP information with a server. This 209 response is intended to be used only by automated clients. Because of 210 this, the recommended form of this response uses the hexadecimal 211 encoding for binary data. It is possible for a user to type an "init- 212 hex" or "init-word" response. 214 4.1. Syntax 216 In UNIX manual page like syntax, the format of these responses could 217 be described as: 219 init-hex::: 220 init-word::: 222 In augmented BNF syntax and with the definitions already provided, 223 the syntax of the "init-hex" response is: 225 init-hex-response = "init-hex:" current-OTP ":" new-params ":" 226 new-OTP NL 228 current-OTP = hex-64bit 229 new-OTP = hex-64bit 231 new-params = algorithm SPACE sequence-number SPACE seed 232 algorithm = "md4" / "md5" / "sha1" 233 sequence-number = 4*3DIGIT 234 seed = 16*1(ALPHA / DIGIT) 235 In augmented BNF syntax and with the definitions already provided, 236 the syntax of the "init-word" response is: 238 init-word-response = "init-word:" current-OTP ":" new-params ":" 239 new-OTP NL 241 current-OTP = word-64bit 242 new-OTP = word-64bit 244 new-params = algorithm SPACE sequence-number SPACE seed 245 algorithm = "md4" / "md5" / "sha1" 246 sequence-number = 4*3DIGIT 247 seed = 16*1(ALPHA / DIGIT) 249 Note that all appropriate fields for the "init-hex" response MUST be 250 hexadecimally coded and that all appropriate fields for the "init- 251 word" response MUST be six-word coded. 253 Examples of these responses are: 255 init-hex:f6bd 6b33 89b8 7203:md5 499 ke6118:23d1 b253 5ae0 2b7e 256 init-hex:c9b2 12bb 6425 5a0f:md5 499 ke0986:fd17 cef1 b4df 093e 258 init-word:MOOD SOFT POP COMB BOLO LIFE:md5 499 ke1235: 259 ARTY WEAR TAD RUG HALO GIVE 260 init-word:END KERN BALM NICK EROS WAVY:md5 499 ke1235: 261 BABY FAIN OILY NIL TIDY DADE 263 (Note that all of these responses are one line. Due to their length, 264 they had to be split into multiple lines in order to be included 265 here. These responses MUST NOT span more than one line in actual use) 267 4.2. Description of Fields 269 The current-OTP field contains the (RFC 1938) response to the OTP 270 challenge. The new-params field contains the parameters for the 271 client's new requested challenge and the new-OTP field contains a 272 response to that challenge. If the re-initialization is successful, a 273 server MUST store the new OTP in its database as the last successful 274 OTP received and the sequence number in the next challenge presented 275 by the server MUST be one less than the sequence number specified in 276 the new-params field. 278 The new-params field is hashed as a string the same way that a seed 279 or secret pass phrase would be. All other field values are hashed in 280 their uncoded binary forms, in network byte order and without any 281 padding. 283 4.3. Requirements 285 A server compliant with this specification: 287 1. SHOULD NOT allow a user to use the same value for their seed and 288 secret pass phrase. 289 2. MUST disable all OTP access to any principal whose sequence 290 number would be less than one 291 3. MUST decrement the sequence number if a reinitialization response 292 includes a valid current-OTP, but the server is unable to 293 successfully process the new-params or new-OTP for any reason. 295 A generator 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 take specific steps to prevent infinite loops of 300 re-initialization attempts in case of failure 301 3. SHOULD provide the user with some indication that the 302 re-initialization is taking place 303 4. SHOULD NOT do a re-initialization without the user's permission, 304 either for that specific instance or as a configuration option 305 5. SHOULD NOT retry a failed re-initialization without a user's 306 permission 307 6. SHOULD warn the user if the sequence number falls below ten 308 7. MUST refuse to generate OTPs with a sequence number below one 310 5. Security Considerations 312 All of the security considerations for the OTP system also apply to 313 the OTP system with extended responses. 315 These extended responses, like OTP itself, do not protect the user 316 against active attacks. The IPsec Authentication Header (RFC-1826) 317 (or another technique with at least as much strength as IPsec AH) 318 SHOULD be used to protect against such attacks. 320 The consequences of a successful active attack on the re- 321 initialization response may be more severe than simply hijacking a 322 single session. An attacker could substitute his own response for 323 that of a legitimate user. The attacker may then be able to use the 324 OTP system to authenticate himself as the user at will (at least 325 until detected). 327 Failure to implement server requirement 3 in section 4.3 opens an 328 implementation to an attack based on replay of the current-OTP part 329 of the response. 331 6. Acknowledgments 333 Like RFC 1938, the protocol described in this document was created by 334 contributors in the IETF OTP working group. Specific contributions 335 were made by Neil Haller, who provided input on the overall design 336 requirements of a re-initialization protocol, Denis Pinkas, who 337 suggested several modifications to the originally proposed re- 338 initialization protocol, and Phil Servita, who opened the debate with 339 the first real protocol proposal and provided lots of specific input 340 on the design of this and earlier protocols. The extensions to the 341 OTP challenge were suggested by Chris Newman and John Valdes. 343 Randall Atkinson and Ted T'so also contributed their views to 344 discussions about details of the protocol extensions in this 345 document. 347 References 349 [RFC 822] David H. Crocker, Standard for the Format of ARPA Internet 350 Text Messages, "Request for Comments (RFC) 822", August 351 13, 1982. 353 [RFC 1825] R. Atkinson, Security Architecture for the Internet 354 Protocol, "Request for Comments (RFC) 1825", August 9, 355 1995. 357 [RFC 1938] N. Haller and C. Metz, A One-Time Password System, 358 "Request for Comments (RFC) 1938", Bellcore and Kaman 359 Sciences Corporation, May 1996. 361 Author's Address 363 Craig Metz 364 The Inner Net 365 Box 10314-1936 366 Blacksburg, VA 24062-0314 367 (DSN) 354-8590 368 cmetz@inner.net 370 Appendix: Reference Responses 372 The following responses were generated by a development version of 373 the One-Time Passwords in Everything (OPIE) implementation of this 374 specification. 376 All of these are responses to the challenge: 378 otp-md5 499 ke1234 380 Note that the re-initialization responses use the same secret pass 381 phrase for new and current and a new seed of "ke1235". Also, these 382 responses have been split for formatting purposes into multiple 383 lines; they MUST NOT be multiple lines in actual use. 385 The secret pass phrase for these responses is: 387 This is a test. 389 The OTP standard hexadecimal response is: 391 5bf0 75d9 959d 036f 393 The OTP standard six-word response is: 395 BOND FOGY DRAB NE RISE MART 397 The OTP extended "hex" response is: 399 hex:5Bf0 75d9 959d 036f 401 The OTP extended "word" response is: 403 word:BOND FOGY DRAB NE RISE MART 405 The OTP extended "init-hex" response is: 407 init-hex:5bf0 75d9 959d 036f:md5 499 ke1235:3712 dcb4 aa53 16c1 409 The OTP extended "init-word" response is: 411 init-word:BOND FOGY DRAB NE RISE MART:md5 499 ke1235: 412 RED HERD NOW BEAN PA BURG