idnits 2.17.1 draft-ietf-otp-sasl-02.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-25) 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([OTP], [SASL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC2222, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2222, updated by this document, for RFC5378 checks: 1997-10-01) -- 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 (May 1998) is 9477 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: 'MD5' is defined on line 258, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 1734 (ref. 'POP-AUTH') (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: OTP SASL Mechanism Innosoft 4 Updates: 2222 May 1998 5 Document: draft-ietf-otp-sasl-02.txt Expires in six months 7 The One-Time-Password SASL Mechanism 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 27 West Coast). 29 Abstract 31 OTP [OTP] provides a useful authentication mechanism for situations 32 where there is limited client or server trust. Currently, OTP is 33 added to protocols in an ad-hoc fashion with heuristic parsing. 34 This specification defines an OTP SASL [SASL] mechanism so it can 35 be easily and formally integrated into many application protocols. 37 1. How to Read This Document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 40 NOT", "RECOMMENDED" and "MAY" in this document are to be 41 interpreted as defined in "Key words for use in RFCs to Indicate 42 Requirement Levels" [KEYWORDS]. 44 This memo assumes the reader is familiar with OTP [OTP], OTP 45 extended responses [OTP-EXT] and SASL [SASL]. 47 2. Intended Use 49 The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL]. 50 OTP is a good choice for usage scenarios where the client is 51 untrusted (e.g., a kiosk client), as a one-time password will only 52 give the client a single opportunity to act on behalf of the user. 53 OTP is also a good choice for situations where interactive logins 54 are permitted to the server, as a compromised OTP authentication 55 database is only subject to dictionary attacks, unlike 56 authentication databases for other simple mechanisms such as 57 CRAM-MD5 [CRAM-MD5]. It is important to note that each use of the 58 OTP mechanism causes the authentication database entry for a user 59 to be updated. 61 This SASL mechanism provides a formal way to integrate OTP into 62 SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3 63 [POP-AUTH] and LDAPv3 [LDAPv3]. 65 3. Profiling OTP for SASL 67 OTP [OTP] and OTP extended responses [OTP-EXT] offer a number of 68 options. However, for authentication to succeed, the client and 69 server need compatible option sets. This specification defines a 70 single SASL mechanism: OTP. The following rules apply to this 71 mechanism: 73 o The extended response syntax MUST be used. 75 o Servers MUST support the following four OTP extended responses: 76 "hex", "word", "init-hex" and "init-word". Servers MUST 77 support the "word" and "init-word" responses for the standard 78 dictionary and SHOULD support alternate dictionaries. Servers 79 MUST NOT require use of any additional OTP extensions or 80 options. 82 o Clients SHOULD support display of the OTP challenge to the user 83 and entry of an OTP in multi-word format. Clients MAY also 84 support direct entry of the pass phrase and compute the "hex" 85 or "word" response. 87 o Clients MUST indicate when authentication fails due to the 88 sequence number getting too low and SHOULD offer the user the 89 option to reset the sequence using the "init-hex" or 90 "init-word" response. 92 Support for the MD5 algorithm is REQUIRED, and support for the SHA1 93 algorithm is RECOMMENDED. 95 4. OTP Authentication Mechanism 97 The mechanism does not provide any security layer. 99 The client begins by sending a message to the server containing the 100 following two pieces of information. 102 (1) An authorization identity. When the empty string is used, this 103 defaults to the authentication identity. This is used by system 104 administrators or proxy servers to login with a different user 105 identity. This field may be up to 255 octets and is terminated by 106 a NUL (0) octet. US-ASCII printable characters are preferred, 107 although UTF-8 [UTF-8] printable characters are permitted to 108 support international names. Use of character sets other than 109 US-ASCII and UTF-8 is forbidden. 111 (2) An authentication identity. The identity whose pass phrase 112 will be used. This field may be up to 255 octets. US-ASCII 113 printable characters are preferred, although UTF-8 [UTF-8] 114 printable characters are permitted to support international names. 115 Use of character sets other than US-ASCII and UTF-8 is forbidden. 117 The server responds by sending a message containing the OTP 118 challenge as described in OTP [OTP] and OTP extended responses 119 [OTP-EXT]. 121 If a client sees an unknown hash algorithm name it will not be able 122 to process a pass phrase input by the user. In this situation the 123 client MAY prompt for the six-word format, issue the cancel 124 sequence as specified by the SASL profile for the protocol in use 125 and try a different SASL mechanism, or close the connection and 126 refuse to authenticate. As a result of this behavior, a server is 127 restricted to one OTP hash algorithm per user. 129 On success, the client generates an extended response in the "hex", 130 "word", "init-hex" or "init-word" format. The client is not 131 required to terminate the response with a space or a newline and 132 SHOULD NOT include unnecessary whitespace. 134 Servers MUST tolerate input of arbitrary length, but MAY fail the 135 authentication if the length of client input exceeds reasonable 136 size. 138 5. Examples 140 In these example, "C:" represents lines sent from the client to the 141 server and "S:" represents lines sent from the server to the 142 client. The user name is "tim" and no authorization identity is 143 provided. The "" below represents an ASCII NUL octet. 145 The following is an example of the OTP mechanism using the ACAP 146 [ACAP] profile of SASL. The pass phrase used in this example is: 147 This is a test. 149 C: a001 AUTHENTICATE "OTP" {4} 150 C: tim 151 S: + "otp-md5 499 ke1234 ext" 152 C: "hex:5bf075d9959d036f" 153 S: a001 OK "AUTHENTICATE completed" 155 Here is the same example using the six-words response: 157 C: a001 AUTHENTICATE "OTP" {4} 158 C: tim 159 S: + "otp-md5 499 ke1234 ext" 160 C: "word:BOND FOGY DRAB NE RISE MART" 161 S: a001 OK "AUTHENTICATE completed" 163 Here is the same example using the OTP-SHA1 mechanism: 165 C: a001 AUTHENTICATE "OTP" {4} 166 C: tim 167 S: + "otp-sha1 499 ke1234 ext" 168 C: "hex:c90fc02cc488df5e" 169 S: a001 OK "AUTHENTICATE completed" 171 Here is the same example with the init-hex extended response 173 C: a001 AUTHENTICATE "OTP" {4} 174 C: tim 175 S: + "otp-md5 499 ke1234 ext" 176 C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1" 177 S: a001 OK "OTP sequence reset, authentication complete" 179 The following is an example of the OTP mechanism using the IMAP 180 [IMAP4] profile of SASL. The pass phrase used in this example is: 181 this is a test 183 C: a001 AUTHENTICATE OTP 184 S: + 185 C: AHRpbQ== 186 S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA== 187 C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE= 188 S: a001 OK AUTHENTICATE completed 190 Note that the lack of an initial client response and the base64 191 encoding are characteristics of the IMAP profile of SASL. The 192 server challenge is "otp-md5 123 ke1234 ext" and the client 193 response is "hex:11d4c147e227c1f1". 195 6. Security Considerations 197 This specification introduces no security considerations beyond 198 those those described in SASL [SASL], OTP [OTP] and OTP extended 199 responses [OTP-EXT]. A brief summary of these considerations 200 follows: 202 This mechanism does not provide session privacy, server 203 authentication or protection from active attacks. 205 This mechanism is subject to passive dictionary attacks. The 206 severity of this attack can be reduced by choosing pass phrases 207 well. 209 The server authentication database necessary for use with OTP need 210 not be plaintext-equivalent. 212 Server implementations MUST protect against the race attack [OTP]. 214 7. Multinational Considerations 216 As remote access is a crucial service, users are encouraged to 217 restrict user names and pass phrases to the US-ASCII character set. 218 However, if characters outside the US-ASCII chracter set are used 219 in user names and pass phrases, then they are interpreted according 220 to UTF-8 [UTF-8]. 222 Server support for alternate dictionaries is strongly RECOMMENDED 223 to permit use of the six-word format with non-English words. 225 8. IANA Considerations 227 Here is the registration template for the OTP SASL mechanism: 229 SASL mechanism name: OTP 230 Security Considerations: See section 6 of this memo 231 Published specification: this memo 232 Person & email address to contact for futher information: 233 see author's address section below 234 Intended usage: COMMON 235 Author/Change controller: see author's address section below 237 This memo also amends the SKEY SASL mechanism registration [SASL] 238 by changing its intended usage to OBSOLETE. 240 9. References 242 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 243 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 245 [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 246 for Simple Challenge/Response", RFC 2195, MCI, September 1997. 248 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 249 4rev1", RFC 2060, University of Washington, December 1996. 251 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 252 Requirement Levels", RFC 2119, Harvard University, March 1997. 254 [LDAPv3] Wahl, M., Howes, T., Kille, S., "Lightweight Directory 255 Access Protocol (v3)", RFC 2251, Critical Angle Inc., Netscape 256 Communications Corp, Isode Limited, December 1997. 258 [MD5] Rivest, "The MD5 Message Digest Algorithm", RFC 1321, MIT 259 Laboratory for Computer Science, April 1992. 261 [OTP] Haller, Metz, Nesser, Straw, "A One-Time Password System", 262 RFC 2289, Bellcore, Kaman Sciences Corporation, Nesser & Nesser 263 Consulting, February 1998. 265 [OTP-EXT] Metz, "OTP Extended Responses", RFC 2243, The Inner Net, 266 November 1997. 268 [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie 269 Mellon, December 1994. 271 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", 272 RFC 2222, Netscape Communications, October 1997. 274 [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 275 RFC 2279, Alis Technologies, January 1998. 277 10. Author's Address 279 Chris Newman 280 Innosoft International, Inc. 281 1050 Lakes Drive 282 West Covina, CA 91790 USA 284 Email: chris.newman@innosoft.com