The SecurID(r) SASL Mechanism
RFC 2808
Document | Type |
RFC - Informational
(April 2000; No errata)
Was draft-nystrom-securid-sasl (individual)
|
|
---|---|---|---|
Author | Magnus Nystrom | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2808 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group M. Nystrom Request for Comments: 2808 RSA Laboratories Category: Informational April 2000 The SecurID(r) SASL Mechanism Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL. How to read this document The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in this document are to be interpreted as defined in [RFC2119]. In examples, "C:" and "S:" indicate messages sent by the client and server respectively. 1. Introduction The SECURID SASL mechanism is a good choice for usage scenarios where a client, acting on behalf of a user, is untrusted, as a one-time passcode will only give the client a single opportunity to act maliciously. This mechanism provides authentication only. Nystrom Informational [Page 1] RFC 2808 The SecurID(r) SASL Mechanism April 2000 The SECURID SASL mechanism provides a formal way to integrate the existing SecurID authentication method into SASL-enabled protocols including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3 [RFC2251]. 2. Authentication Model The SECURID SASL mechanism provides two-factor based user authentication as defined below. There are basically three entities in the authentication mechanism described here: A user, possessing a SecurID token, an application server, to which the user wants to connect, and an authentication server, capable of authenticating the user. Even though the application server in practice may function as a client with respect to the authentication server, relaying authentication credentials etc. as needed, both servers are, unless explicitly mentioned, collectively termed "the server" here. The protocol used between the application server and the authentication server is outside the scope of this memo. The application client, acting on behalf of the user, is termed "the client". The mechanism is based on the use of a shared secret key, or "seed", and a personal identification number (PIN), which is known both by the user and the authentication server. The secret seed is stored on a token that the user possesses, as well as on the authentication server. Hence the term "two-factor authentication", a user needs not only physical access to the token but also knowledge about the PIN in order to perform an authentication. Given the seed, current time of day, and the PIN, a "PASSCODE(r)" is generated by the user's token and sent to the server. The SECURID SASL mechanism provides one service: - User authentication where the user provides information to the server, so that the server can authenticate the user. This mechanism is identified with the SASL key "SECURID". 3. Authentication Procedure a) The client generates the credentials using local information (seed, current time and user PIN/password). Nystrom Informational [Page 2] RFC 2808 The SecurID(r) SASL Mechanism April 2000 b) If the underlying protocol permits, the client sends credentials to the server in an initial response message. Otherwise, the client sends a request to the server to initiate the authentication mechanism, and sends credentials after the server's response (see [RFC2222] section 5.1 for more information regarding the initial response option). Unless the server requests a new PIN (see below), the contents of the client's initial response SHALL be as follows: (1) An authorization identity. When this field is empty, it defaults to the authentication identity. This field MAY be used by system administrators or proxy servers to login with a different user identity. This field MUST NOT be longer than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded [RFC2279] printable characters only (US-ASCIIShow full document text