The One-Time-Password SASL Mechanism
updates
- rfc-2222 — Simple Authentication and Security Layer (SASL)
Extracted elements (18)
A single SASL mechanism named OTP is defined rather than separate per-algorithm mechanisms, with algorithm negotiated via the challenge. This simplifies integration while the restriction of one hash algorithm per user ensures client-server compatibility.
OTP is favored for untrusted client scenarios (e.g., kiosk clients) because a one-time password gives the client only a single opportunity to act on behalf of the user. It is also preferred when interactive logins are permitted, since a compromised OTP database is only subject to dictionary attacks, unlike databases for mechanisms such as CRAM-MD5.
If a client encounters an unknown hash algorithm name in the server challenge, it may prompt for the six-word format, issue the SASL cancel sequence and try a different mechanism, or close the connection. A server is consequently restricted to one OTP hash algorithm per user.
The OTP SASL mechanism is formally integrated into SASL-enabled protocols including IMAP, ACAP, POP3, and LDAPv3, replacing the ad-hoc OTP integration and the SKEY SASL mechanism.
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.
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.
Server support for alternate dictionaries is strongly RECOMMENDED to permit use of the six-word format with non-English words, supporting multinational users.
Servers MUST support the four OTP extended responses: 'hex', 'word', 'init-hex', and 'init-word'. Servers MUST support 'word' and 'init-word' for the standard dictionary and SHOULD support alternate dictionaries. Servers MUST NOT require use of any additional OTP extensions or options.
Servers MUST tolerate input of arbitrary length, but MAY fail the authentication if the length of client input exceeds reasonable size.
Support for the MD5 algorithm is REQUIRED, and support for the SHA1 algorithm is RECOMMENDED.
The client is not required to terminate the extended response with a space or newline and SHOULD NOT include unnecessary whitespace.
The extended response syntax MUST be used in the OTP SASL mechanism.
The OTP SASL mechanism provides no security layer. The client initiates by sending an authorization identity (up to 255 octets, NUL-terminated) followed by an authentication identity (up to 255 octets). The server responds with an OTP challenge.
This document registers the OTP SASL mechanism with IANA (name: OTP, intended usage: COMMON) and amends the SKEY SASL mechanism registration by changing its intended usage to OBSOLETE.
The OTP SASL mechanism does not provide session privacy, server authentication, or protection from active attacks. It is subject to passive dictionary attacks, the severity of which can be reduced by choosing pass phrases well.
The server authentication database necessary for use with OTP need not be plaintext-equivalent. Server implementations MUST protect against the race attack as described in the OTP specification.
The authentication identity field is up to 255 octets. US-ASCII printable characters are preferred; UTF-8 printable characters are permitted. Character sets other than US-ASCII and UTF-8 are forbidden.
The authorization identity field is up to 255 octets, terminated by a NUL (0) octet. US-ASCII printable characters are preferred; UTF-8 printable characters are permitted. Character sets other than US-ASCII and UTF-8 are forbidden.