INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT
INTERNET-DRAFT M. Nystrom
Expires: June 1999 J. Brainard
Intended Category: Informational RSA Laboratories
<draft-nystrom-securid-sasl-00.txt> 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:<STRING>"
or "Passcode:", UTF8 encoded. The former will be sent if the server
wants the user to enter a new PIN ("<STRING>" 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