RFC 2444

RFC 2444: The One-Time-Password SASL Mechanism ✨

Okay bestie, let's get the paperwork out of the way first 💅 This one is by Chris Newman from Innosoft, published in October 1998, and it's a Standards Track document. It updates RFC 2222 (that's the SASL spec), so it's basically adding to that one. It doesn't obsolete anything. 🎀

Status of this Memo

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 For where this protocol actually stands, check the current "Internet Official Protocol Standards" (STD 1). And yes, distribution of this memo is unlimited, so share it with everyone 🌸

Copyright Notice

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

Abstract

OTP [OTP] is a really useful authentication mechanism when the client or the server can't be fully trusted 🔐 The problem is that right now OTP gets bolted onto protocols in an ad-hoc way with heuristic parsing, which is very messy 💀 This spec defines an OTP SASL [SASL] mechanism so it can be cleanly and formally plugged into lots of 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 read the way they're defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Pay attention to those, they're the official vocab 👑

This memo assumes you already know your stuff about OTP [OTP], OTP extended responses [OTP-EXT] and SASL [SASL]. No pressure, but it's giving "read the prerequisites first" 🙈

2. Intended Use 🍓

The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL]. OTP is a great pick when the client is untrusted, like a kiosk, because a one-time password only gives the client one chance to act on behalf of the user. Iconic behaviour from a security standpoint 😭

It's also a good fit when interactive logins are allowed to the server. A compromised OTP authentication database is only open to dictionary attacks, which is way better than other simple mechanisms like CRAM-MD5 [CRAM-MD5], whose authentication databases are a lot more exposed. Main character energy for OTP 💅

Heads up: every time someone uses the OTP mechanism, the authentication database entry for that user gets updated. Keep that in mind, it matters!

This SASL mechanism gives us a formal way to plug 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] come with a bunch of options, but here's the catch: for authentication to work, the client and server need compatible option sets 😤 So this spec locks things down to a single SASL mechanism, OTP, with the following rules:

• The extended response syntax MUST be used.
• 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. Servers aren't allowed to be gatekeepers for extra OTP stuff 🙅‍♀️
• Clients SHOULD support displaying the OTP challenge to the user and taking an OTP entered in multi-word format. Clients MAY also support direct entry of the pass phrase and compute the "hex" or "word" response themselves 🧚
• Clients MUST indicate when authentication fails because the sequence number got too low. They SHOULD also 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. MD5 is the must-have, SHA1 is the very-strongly-suggested bonus ✨

4. OTP Authentication Mechanism 🫶

The mechanism doesn't provide any security layer. Just so we're clear 💀

The client starts things off by sending a message to the server with the following two pieces of info:

1. An authorization identity. If the empty string is used, this defaults to the authentication identity. This is what system administrators or proxy servers use to log in as 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, but UTF-8 [UTF-8] printable characters are allowed too, so international names can get their moment 🌍 Using any character sets other than US-ASCII and UTF-8 is forbidden, so don't even try 🙅‍♀️
2. An authentication identity. This is the identity whose pass phrase will be used. This field may be up to 255 octets. Same deal here: US-ASCII printable characters are preferred, UTF-8 [UTF-8] printable characters are permitted for international names, and any other character sets are forbidden 💖

The server replies with a message containing the OTP challenge, as described in OTP [OTP] and OTP extended responses [OTP-EXT] 🦋

Now the messy-but-real situation: if a client sees an unknown hash algorithm name, it won't be able to process a pass phrase the user typed in. In that case the client MAY prompt for the six-word format, issue the cancel sequence specified by the SASL profile for the protocol in use and then try a different SASL mechanism, or close the connection and refuse to authenticate. Because of this behaviour, a server is restricted to one OTP hash algorithm per user. Choose wisely, babe 😭

On success, the client generates an extended response in the "hex", "word", "init-hex" or "init-word" format. The client is not required to end the response with a space or a newline, and it SHOULD NOT include unnecessary whitespace. Minimalism is the vibe 🌸

Servers MUST tolerate input of arbitrary length, but they MAY fail the authentication if the client's input is over a reasonable size. Being generous is a must, but there's a limit 🙈

5. Examples 💜

In these examples, "C:" marks lines sent from the client to the server and "S:" marks lines sent from the server to the client. The user name is "tim" and no authorization identity is provided. The "<NUL>" below stands for an ASCII NUL octet. Let's go!! 🎀

First up is the OTP mechanism using the ACAP [ACAP] profile of SASL. The pass phrase used here is: This is a test.

C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "hex:5bf075d9959d036f"
S: a001 OK "AUTHENTICATE completed"

Here's the same example using the six-word response:

C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "word:BOND FOGY DRAB NE RISE MART"
S: a001 OK "AUTHENTICATE completed"

Here's the same example using the OTP-SHA1 mechanism:

C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-sha1 499 ke1234 ext"
C: "hex:c90fc02cc488df5e"
S: a001 OK "AUTHENTICATE completed"

Here's the same example with the init-hex extended response:

C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1"
S: a001 OK "OTP sequence reset, authentication complete"

Next, the OTP mechanism using the IMAP [IMAP4] profile of SASL. The pass phrase used in this one is: this is a test

C: a001 AUTHENTICATE OTP
S: +
C: AHRpbQ==
S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==
C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE=
S: a001 OK AUTHENTICATE completed

Notice there's no initial client response here, and the base64 encoding, because those are the characteristics of the IMAP profile of SASL 👀 The server challenge is "otp-md5 123 ke1234 ext" and the client response is "hex:11d4c147e227c1f1". Decoded, it's giving 🧚

---

(Part 2 is coming up: Security Considerations, Multinational Considerations, IANA, References and the author's address. Stay tuned 💖)

11. Full Copyright Statement ✨

Okay so the copyright bit! 🎀 The Internet Society owns the copyright (1998), and all rights are reserved. 💅

Here's the deal: you're totally allowed to copy this document and share it with people, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions 🦋 as long as the copyright notice and this paragraph stay on every copy and every derivative work. Main character energy, but make sure the credits are there! 🫶

What you can't do is change the document itself. Like, you can't remove the copyright notice or the references to the Internet Society or other Internet organizations 🙅‍♀️ There are two exceptions. One is developing Internet standards, where you follow the copyright procedures defined in the Internet Standards process. The other is translating it into languages other than English 🌸

The permissions above are perpetual. The Internet Society and its successors or assigns can't take them back 💜

Last but not least, the disclaimer (iykyk, it's a big one 😭). This document and everything in it is provided "AS IS", and the Internet Society and the Internet Engineering Task Force disclaim all warranties:

THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

So yeah, it's giving "use at your own risk" 💀 Periodt. 💅