INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT INTERNET-DRAFT M. Nystrom Expires: June 1999 J. Brainard Intended Category: Informational RSA Laboratories January 1999 The SecurID(r) 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 and individuals 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 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines a SASL [SASL] authentication mechanism based on Security Dynamics' SecurID authentication protocol, providing client authentication. 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 authentication protocol and SASL. 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]. In examples, "C:" and "S:" indicate messages sent by the client and server respectively. Nystrom & Brainard Expires: July 1999 [Page 1] INTERNET DRAFT SecurID SASL Mechanism January 1999 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. While this primarily is due to legacy reasons, it makes the mechanism very simple. When confidentiality and/or integrity are provided by lower layers (e.g., TLS) or by the application (e.g., signed and/or encrypted data), a confidentiality and/or integrity mechanism at the SASL layer may also be unnecessary or superfluous. The SECURID SASL mechanism provides a formal way to integrate the existing SecurID authentication method into SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3 [POP3AUTH] and LDAPv3 [LDAPv3]. 2. Authentication Model The SECURID SASL mechanism provides one-way two-factor based 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 client (user) possesses, as well as on the authentication server, Hence the term 'two-factor 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 protocol described here is the same as the one being used in current SecurID products from Security Dynamics Technologies, Inc. The SECURID SASL mechanism provides one service: - Client authentication where the client provides information to the server, so that the server can authenticate the client. Nystrom & Brainard Expires: July 1999 [Page 2] INTERNET DRAFT SecurID SASL Mechanism January 1999 This mechanism is identified with the SASL key "SECURID". 3. Authentication Procedure 1. The client generates the credentials using local information (seed, current time and user PIN). 2. 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. 3. The server verifies these credentials using its own information. If the verification succeeds, the server sends back a response indicating success to the client. After receiving this response, the client is authenticated. Otherwise, the verification either failed or the server needs an additional set of credentials from the client in order to authenticate the user. 4. If the server needs an additional set of credentials, it requests them now. 5. The client generates a new set of credentials using the local information and sends them to the server. 6. The server verifies these credentials using its copy of the shared seed. If the verification succeeds, the server sends back a response indicating success to the client. Otherwise, the authentication failed and the server sends back a response indicating this. Note 1: Case 4 above can occur e.g. when the clocks on which the server and the client relies are not synchronized. Note 2: In some cases, the initial server request may be a request for a new user PIN (or a suggestion for a new user PIN). In those cases, a different server request is transferred, and the clients response shall be the user's new PIN. After this, authentication proceeds as described above (the server sends a request for client credentials etc.). 3.1 Encoding Unless the underlying protocol supports the initial response message alternative, the servers initial message (its response to the clients request for authentication) is always "Username:", encoded in US- ASCII [ASCII]. Nystrom & Brainard Expires: July 1999 [Page 3] INTERNET DRAFT SecurID SASL Mechanism January 1999 The clients response to this message SHOULD be a US-ASCII encoded username. It MAY be a UTF8 [UTF8] encoded username. Only UTF8 or US- ASCII encoded usernames are allowed. Since US-ASCII is a true subset of UTF8, this will not affect the protocol. The next message from the server will either be "Password:" or "Passcode:", UTF8 encoded. The former will be sent if the server wants the user to enter a new PIN ("" is either empty or a suggested new PIN), the latter (normal) case is when the server simply wants the user's passcode. If the server did send the "Password:" message, the client MUST respond with a new user PIN. This PIN shall be encoded in UTF8. If the server supplied the client with a suggested PIN, the client accepts this by replying with the same PIN, but MAY replace it with another one. The length of the PIN is application-dependent as is any other requirements for the PIN, e.g. allowed characters. After having received the PIN, the server responds with a "Passcode:" message. If the server for some reason does not accept the received PIN, the client must be prepared to receive either a message indicating the failure of the authentication or a repeated request for a new PIN. Mechanisms for transferring knowledge about PIN requirements from the server to the client is outside of the scope for this memo. However, some information MAY be provided in error messages transferred from the server to the client when applicable. When the client receives the "Passcode:" message, it responds with the passcode. The passcode MUST be UTF8 encoded (it will normally consist only of digits, and therefore, in those cases, be equivalent to a US-ASCII encoding). After having received the passcode, the server verifies the passcode. If the verification indicates that the client's clock is out of synch with the server's, the server requests a second passcode by sending the "Passcode:" message to the client once more. Otherwise the verification either fails or succeeds. The server notifies the client of the outcome through the underlying protocol. If the client receives a second "Passcode:" message, it responds with a new UTF8 encoded passcode. After having received a message indicating successful verification of a sent passcode, the client is considered authenticated. 4. LDAPv3 Considerations In LDAPv3 the username SHALL always be provided in the "name" field of the BindRequest. The authenticating server does not therefore need to ask for usernames. Nystrom & Brainard Expires: July 1999 [Page 4] INTERNET DRAFT SecurID SASL Mechanism January 1999 LDAPv3 supports the initial response binding mechanism, and the use of this mechanism is the preferred way of authenticating to an LDAPv3 server which supports the SECURID SASL mechanism. The SecurIDSASLCredentials is defined in ASN.1 [X680] as follows: SecurIDSASLCredentials ::= CHOICE { passcode [0] IMPLICIT UTF8String, pin [1] IMPLICIT UTF8String, ... -- Allow for future expansion } This type is then BER-encoded and encapsulated within the "credentials" OCTET STRING. E.g., when sending the initial BindRequest, a passcode of "12345678" yields a value for the "credentials" type equal to (using the value notation defined in X.680 [X680]) '80083132333435363738'H. If the server is unable to process the initial response BindRequest, for example due to the fact that it needs a new user PIN, it simply responds with a BindResponse with resultCode "saslBindInProgress" and a "serverSaslCreds" containing a "SecurIDSASLCredentials" indicating the type of credential it needs. The value MAY be empty in this case. E.g., when requesting a second passcode from the client, the value of the "serverSaslCreds" will be '8000'H. 5. Examples 5.1 IMAP4 The following example shows the use of the SECURID SASL mechanism with IMAP4. The example is only designed to illustrate the protocol interaction but does provide valid encoding examples. S: * OK IMAP4 server ready C: AOO1 CAPABILITY S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID S: A001 OK done C: AOO2 AUTHENTICATE SECURID S: + VXNlcm5hbWU6Cg== C: bWFnbnVzCg== S: + UGFzc2NvZGU6Cg== C: MTIzNDU2NzgK S: AOO2 OK Welcome, SECURID authenticated user: magnus 5.2 LDAPv3 The following examples show the use of the SECURID SASL mechanism Nystrom & Brainard Expires: July 1999 [Page 5] INTERNET DRAFT SecurID SASL Mechanism January 1999 with LDAPv3. The examples are only designed to illustrate the protocol interaction, but does provide valid encoding examples. Usernames, passcodes and PINs are of course fictitious. For readability, all messages is shown in the value-notation defined in X.680. 5.2.1 LDAPv3 Example 1 Initial response message, successful authentication. C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, authentication sasl : { mechanism '53454355524944'H, credentials '80083132333435363738'H } } } S: { messageID 1, protocolOp bindResponse : { resultCode success, matchedDN ''H, errorMessage ''H, } } 5.2.2 LDAPv3 Example 2 Initial response message, server requires second passcode. C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, authentication sasl : { mechanism '53454355524944'H, credentials '80083132333435363738'H } } } S: { messageID 1, protocolOp bindResponse : { resultCode saslBindInProgress, matchedDN ''H, Nystrom & Brainard Expires: July 1999 [Page 6] INTERNET DRAFT SecurID SASL Mechanism January 1999 errorMessage ''H, serverSaslCreds '8000'H } } C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, authentication sasl : { mechanism '53454355524944'H, credentials '80083131323233333434'H } } } S: { messageID 1, protocolOp bindResponse : { resultCode success, matchedDN ''H, errorMessage ''H, } } 5.2.3 LDAPv3 Example 3 Initial response message, server requires new PIN and passcode, and supplies client with a suggested new PIN (which the client accepts). C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, authentication sasl : { mechanism '53454355524944'H, credentials '80083132333435363738'H } } } S: { messageID 1, protocolOp bindResponse : { resultCode saslBindInProgress, matchedDN ''H, errorMessage ''H, serverSaslCreds '810431323334'H } Nystrom & Brainard Expires: July 1999 [Page 7] INTERNET DRAFT SecurID SASL Mechanism January 1999 } C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, authentication sasl : { mechanism '53454355524944'H, credentials '810431323334'H } } } S: { messageID 1, protocolOp bindResponse : { resultCode saslBindInProgress, matchedDN ''H, errorMessage ''H, serverSaslCreds '8000'H } } C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, authentication sasl : { mechanism '53454355524944'H, credentials '80083131323233333434'H } } } S: { messageID 1, protocolOp bindResponse : { resultCode success, matchedDN ''H, errorMessage ''H, } } 6. Security Considerations This mechanism does not provide session privacy, server authentication or protection from active attacks. In order not to expose user PINs, the server SHOULD make sure that Nystrom & Brainard Expires: July 1999 [Page 8] INTERNET DRAFT SecurID SASL Mechanism January 1999 the authentication takes place on a confidentiality-protected connection in those cases where user PINs are requested. Server implementations MUST protect against replay attacks. 7. Multinational Considerations Usernames may be UTF-8 encoded as long as the underlying protocol allows it. 8. IANA Considerations By registering the SecurID protocol as a SASL mechanism, implementers will have a well-defined way of adding this authentication mechanism to their product. Here is the registration template for the SECURID SASL mechanism: SASL mechanism name: SECURID Security Considerations: See corresponding section of this memo Published specification: This memo Person & email address to contact for further information: See author's address section below Intended usage: COMMON Author/Change controller: See author's address section below 9. Intellectual Property Considerations Neither RSA Data Security Inc. or Security Dynamics Technologies Inc. makes any claims on the general constructions described in this memo, although underlying techniques may be covered. Among the underlying techniques, the SecurID technology is covered by a number of US patents, in particular US patent no. 4,885,778, no. 5,097,505, no. 5,168,520, and 5,657,388. Security Dynamics and SecurID are registered trademarks, and PASSCODE is a trademark, of Security Dynamics Technologies, Inc. 10. References [ACAP] Newman, C., "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [ASCII] "ANSI X3.4: Information Systems - Coded Character Sets - 7- Bit American National Standard Code for Information Interchange (7- Bit ASCII)", American National Standards Institute. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version Nystrom & Brainard Expires: July 1999 [Page 9] INTERNET DRAFT SecurID SASL Mechanism January 1999 4rev1", RFC 2060, December 1996. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [LDAPv3] Wahl, M., et al, "Lightweight Directory Access Protocol (v3)", RFC 2252, December 1997. [POP3AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994. [SASL] Meyers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997. [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [X680] "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 1994. Author's Address Magnus Nystrom RSA Laboratories 20 Crosby Drive Bedford, MA 01730 Phone: +1-781-687-7000 Email: magnus@rsa.com John Brainard RSA Laboratories 20 Crosby Drive Bedford, MA 01730 Phone: +1-781-687-7000 Email: jbrainard@rsa.com Nystrom & Brainard Expires: July 1999 [Page 10] INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT