The One-Time-Password SASL Mechanism
RFC 2444

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                          C. Newman
Request for Comments: 2444                                      Innosoft
Updates: 2222                                               October 1998
Category: Standards Track

                  The One-Time-Password SASL Mechanism

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

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 many application protocols.

1. How to Read This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED" and "MAY" in this document are to be interpreted as
   defined in "Key words for use in RFCs to Indicate Requirement Levels"
   [KEYWORDS].

   This memo assumes the reader is familiar with OTP [OTP], OTP extended
   responses [OTP-EXT] and SASL [SASL].

2. Intended Use

   The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL].  OTP
   is a good choice for usage scenarios where the client is untrusted
   (e.g., a kiosk client), as a one-time password will only give the
   client a single opportunity to act on behalf of the user.  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 authentication
   databases for other simple mechanisms such as CRAM-MD5 [CRAM-MD5].

Newman                      Standards Track                     [Page 1]
RFC 2444                   OTP SASL Mechanism               October 1998

   It is important to note that each use of the OTP mechanism causes the
   authentication database entry for a user to be updated.

   This SASL mechanism provides a formal way to integrate OTP into
   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 a
   single SASL mechanism: OTP.  The following rules apply to this
   mechanism:

   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
       the "word" and "init-word" responses for the standard dictionary
       and SHOULD support alternate dictionaries.  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 an OTP in multi-word format.  Clients MAY also
       support direct entry of the pass phrase 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.

   Support for the MD5 algorithm is REQUIRED, and support for the SHA1
   algorithm is RECOMMENDED.

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

Newman                      Standards Track                     [Page 2]
RFC 2444                   OTP SASL Mechanism               October 1998

   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.

   (2) An authentication identity.  The identity whose pass phrase 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