Network Working Group C. Newman Internet Draft: OTP SASL Mechanism Innosoft Document: draft-newman-sasl-otp-00.txt January 1998 Expires in six months One Time Password SASL mechanism Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract OTP [OTP] provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL [SASL] mechanism so it can be easily and formally integrated into application protocols. [NOTE: Public discussion of this spec may take place on the ietf-otp@bellcore.com mailing list with a subscription address of ietf-otp-request@bellcore.com. Private comments may be sent to the author]. 1. How to Read This Document The key words "MUST", "MUST NOT", "MANDATORY", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Newman [Page 1] Internet Draft OTP SASL Mechanism January 1998 Requirement Levels" [KEYWORDS]. 2. Intended Use OTP is intended to replace the SKEY SASL mechanism [SASL]. OTP is a good choice for usage scenarios where the client is untrusted, as a one time passphrase will only give the client a single opportunity to act on behalf of the user. Other simple mechanisms such as CRAM-MD5 [CRAM-MD5] do not have this characteristic. OTP is also a good choice for situations where interactive logins are permitted to the server as a compromised OTP authentication database is only subject to dictionary attacks, unlike a compromised CRAM-MD5 authentication database (which can be used to impersonate all the users). However, OTP has a number of drawbacks. First, it requires the OTP authentication database to be locked and updated with each user authentication. This exposes an additional denial of service problem as well as preventing the server from supporting multiple simultaneous authentications by the same user. In addition, it requires repeated applications of the hash function resulting in slower performance than the simpler CRAM-MD5 mechanism. Finally, the OTP sequence needs to be periodically updated and when it is done according to OTP extended responses [OTP-EXT], an active attacker gains the ability to hijack the user's account. If these concerns outweigh the concerns with a compromised client or server, then either the CRAM-MD5 or SCRAM-MD5 [SCRAM] mechanism may be preferable. OTP does not provide protection from active attacks. If a lightweight mechanism is desired which provides such protection, then SCRAM-MD5 [SCRAM] is a good candidate. This is intended to be the standards track method to integrate OTP with SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3 [POP-AUTH] and LDAPv3 [LDAPv3]. 3. Profiling OTP for SASL OTP [OTP] and OTP extended responses [OTP-EXT] offer a number of options. However, for authentication to succeed, the client and server need compatible option sets. This specification defines two SASL mechanisms: OTP-MD5 and OTP-SHA1 (the MD4 hash funtion is not used with SASL's profile of OTP). The following rules apply to these mechanisms: Newman [Page 2] Internet Draft OTP SASL Mechanism January 1998 o The extended response syntax MUST be used. o Servers MUST support the following four OTP extended responses: "hex", "word", "init-hex" and "init-word". Servers MUST support both standard and alternate dictionaries for the "word" and "init-word" responses. Servers MUST NOT require use of any additional OTP extensions or options. o Clients SHOULD support display of the OTP challenge to the user and entry of a one time passphrase in multi-word format. Clients MAY also support direct entry of the passphrase and compute the "hex" or "word" response. o Clients MUST indicate when authentication fails due to the sequence number getting too low and SHOULD offer the user the option to reset the sequence using the "init-hex" or "init- word" response. o The hash function identified in the SASL mechanism name MUST be used. The OTP-MD5 mechanism is MANDATORY to implement and the OTP-SHA1 mechanism is RECOMMENDED. However, it is also RECOMMENDED that only one of these mechanisms is available on a given server. [Ed Note: the alternative design would be to have one OTP mechanism and REQUIRE both MD5 and SHA1 and if a new hash function is ever needed, that would be a different SASL mechanism. However, allowing options within the SASL negotiation creates interoperability problems and unnecessary levels of negotiation complexity]. 4. OTP Authentication Mechanism The mechanism does not provide any security layer. The client begins by sending a message to the server containing the following two pieces of information. (1) An authorization identity. When the empty string is used, this defaults to the authentication identity. This is used by system administrators or proxy servers to login with a different user identity. This field may be up to 255 octets and is terminated by a NUL (0) octet. US-ASCII printable characters are preferred, although UTF-8 [UTF-8] printable characters are permitted to support international names. Use of character sets other than US-ASCII and UTF-8 is forbidden. Newman [Page 3] Internet Draft OTP SASL Mechanism January 1998 (2) An authentication identity. The identity whose passphrase will be used. This field may be up to 255 octets. US-ASCII printable characters are preferred, although UTF-8 [UTF-8] printable characters are permitted to support international names. Use of character sets other than US-ASCII and UTF-8 is forbidden. The server responds by sending a message containing the OTP challenge as described in OTP [OTP] and OTP extended responses [OTP-EXT]. It is a protocol violation if the hash function name in the server challenge fails to match the hash function in the SASL mechanism name. The client then generates an extended response in the "hex", "word", "init-hex" or "init-word" format. The client is not required to terminate the response with a space or a newline and SHOULD NOT include unnecessary whitespace. 5. Examples In these example, "C:" represents lines sent from the client to the server and "S:" represents lines sent from the server to the client. The user name is "tim" and no authorization identity is provided. The "" below represents an ASCII NUL octet. The following is an example of the OTP mechanism using the ACAP [ACAP] profile of SASL. The passphrase used in this example is: This is a test. C: a001 AUTHENTICATE "OTP-MD5" {4} C: tim S: + "S: otp-md5 499 ke1234 ext" C: "hex:5bf075d9959d036f" S: a001 OK "AUTHENTICATE completed" Here is the same example using the OTP-SHA1 mechanism: C: a001 AUTHENTICATE "OTP-SHA1" {4} C: tim S: + "otp-sha1 499 ke1234 ext" C: "hex:c90fc02cc488df5e" S: a001 OK "AUTHENTICATE completed" The following is an example of the OTP mechanism using the IMAP [IMAP4] profile of SASL. The passphrase used in this example is: this is a test C: a001 AUTHENTICATE OTP-MD5 Newman [Page 4] Internet Draft OTP SASL Mechanism January 1998 S: + C: AHRpbQ== S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA== C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE= S: a001 OK AUTHENTICATE completed Note that the lack of an initial client response and the base64 encoding are characteristics of the IMAP profile of SASL. The server challenge is "otp-md5 123 ke1234 ext" and the client response is "hex:11d4c147e227c1f1". 6. Security Considerations This specification introduces no security considerations beyond those those described in SASL [SASL], OTP [OTP] and OTP extended responses [OTP-EXT]. Some of those considerations are mentioned in section 2. 7. Multinational Considerations As remote access is a crucial service, users are encouraged to restrict user names and passphrases to the US-ASCII character set. However, if characters outside the US-ASCII chracter set are used in user names and passphrases, then they are interpreted according to UTF-8 [UTF-8] and it is a protocol error to include any octet sequences not legal for UTF-8. Servers are encourged to enforce this restriction to discourage clients which use unlabelled character sets in this context. 8. References [ACAP] Newman, Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, Innosoft, Netscape, November 1997. [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, MCI, September 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. Newman [Page 5] Internet Draft OTP SASL Mechanism January 1998 [LDAPv3] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, Critical Angle Inc., Netscape Communications Corp, Isode Limited, December 1997. [MD5] Rivest, "The MD5 Message Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992. [OTP] Haller, Metz, "A One-Time Password System", RFC 1938, Bellcore, Kaman Sciences Corporation, May 1996. [OTP-EXT] Metz, "OTP Extended Responses", RFC 2243, The Inner Net, November 1997. [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC 2222, Netscape Communications, October 1997. [SCRAM] Newman, "Salted Challenge Response Authentication Mechanism (SCRAM)", work in progress. [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, Alis Technologies, October 1996. 9. Author's Address Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman [Page 6]