As per Relevance of the word mechanism, we have this rfc below:
Network Working Group M.
Request for Comments: 2808 RSA
Category: Informational April 2000
The SecurID(r) SASL
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
SecurID is a hardware token card product (or software
thereof) produced by RSA Security Inc., which is used for end-
authentication. This document defines a SASL [RFC2222]
mechanism using these tokens, thereby providing a means for
tokens to be used in SASL environments. This mechanism is only
authentication, and has no effect on the protocol encoding and is
designed to provide integrity or confidentiality services
This memo assumes the reader has basic familiarity with the
token, its associated authentication protocol and SASL
How to read this
The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in
document are to be interpreted as defined in [RFC2119].
In examples, "C:" and "S:" indicate messages sent by the client
server respectively
1.
The SECURID SASL mechanism is a good choice for usage scenarios
a client, acting on behalf of a user, is untrusted, as a one-
passcode will only give the client a single opportunity to
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
existing SecurID authentication method into SASL-enabled
including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv
[RFC2251].
2. Authentication
The SECURID SASL mechanism provides two-factor based
authentication as defined below
There are basically three entities in the authentication
described here: A user, possessing a SecurID token, an
server, to which the user wants to connect, and an
server, capable of authenticating the user. Even though
application server in practice may function as a client with
to the authentication server, relaying authentication
etc. as needed, both servers are, unless explicitly mentioned
collectively termed "the server" here. The protocol used between
application server and the authentication server is outside the
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
the user and the authentication server. The secret seed is stored
a token that the user possesses, as well as on the
server. Hence the term "two-factor authentication", a user needs
only physical access to the token but also knowledge about the PIN
order to perform an authentication. Given the seed, current time
day, and the PIN, a "PASSCODE(r)" is generated by the user's
and sent to the server
The SECURID SASL mechanism provides one service
- User authentication where the user provides information to
server, so that the server can authenticate the user
This mechanism is identified with the SASL key "SECURID".
3. Authentication
a) The client generates the credentials using local
(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
to the server in an initial response message. Otherwise,
client sends a request to the server to initiate
authentication mechanism, and sends credentials after the server'
response (see [RFC2222] section 5.1 for more information
the initial response option).
Unless the server requests a new PIN (see below), the contents
the client's initial response SHALL be as follows
(1) An authorization identity. When this field is empty,
defaults to the authentication identity. This field MAY be
by system administrators or proxy servers to login with
different user identity. This field MUST NOT be longer than 255
octets, SHALL be terminated by a NUL (0) octet, and MUST
of UTF-8-encoded [RFC2279] printable characters only (US-
[X3.4] is a subset of UTF-8).
(2) An authentication identity. The identity whose passcode
be used. If this field is empty, it is assumed to have
transferred by other means (e.g. if the underlying protocol
support for this, like [RFC2251]). This field MUST NOT be
than 255 octets, SHALL be terminated by a NUL (0) octet, and
consist of UTF-8-encoded printable characters only
(3) A passcode. The one-time password that will be used to
access. This field MUST NOT be shorter than 4 octets, MUST NOT
longer than 32 octets, SHALL be terminated by a NUL (0) octet,
MUST consist of UTF-8-encoded printable characters only
Passcodes usually consist of 4-8 digits
The ABNF [RFC2234] form of this message is as follows
credential-pdu = authorization-id authentication-id passcode [pin
authorization-id = 0*255VUTF8 %x00
authentication-id = 0*255VUTF8 %x00
passcode = 4*32VUTF8 %x00
pin ::= 4*32VUTF8 %x00
VUTF8 = printable) UTF8-encoded characters
Regarding the rule, see d) below
Nystrom Informational [Page 3]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
c) The server verifies these credentials using its own information
If the verification succeeds, the server sends back a
indicating success to the client. After receiving this response
the client is authenticated. Otherwise, the verification
failed or the server needs an additional set of credentials
the client in order to authenticate the user
d) If the server needs an additional set of credentials, it
them now. This request has the following format, described in
notation
server-request = passcode |
passcode = "passcode" %x00
pin = "pin" %x00 [suggested-pin
suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8
The 'passcode' choice will be sent when the server
another passcode. The 'pin' choice will be sent when the
requests a new user PIN. The server will either send an
string or suggest a new user PIN in this message
e) The client generates a new set of credentials using
information and depending on the server's request and sends
to the server. Authentication now continues as in c) above
Note 1: Case d) above may occur e.g. when the clocks on which
server and the client relies are not synchronized
Note 2: If the server requests a new user PIN, the client
respond with a new user PIN (together with a passcode), encoded as
UTF-8 string. If the server supplies the client with a suggested PIN
the client accepts this by replying with the same PIN, but
replace it with another one. The length of the PIN is application
dependent as are any other requirements for the PIN, e.g.
characters. If the server for some reason does not accept
received PIN, the client MUST be prepared to receive either a
indicating the failure of the authentication or a repeated
for a new PIN. Mechanisms for transferring knowledge about
requirements from the server to the client are outside the scope
this memo. However, some information MAY be provided in
messages transferred from the server to the client when applicable
Nystrom Informational [Page 4]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
4.
4.1 IMAP
The following example shows the use of the SECURID SASL
with IMAP4. The example is only designed to illustrate the
interaction but do provide valid encoding examples
The base64 encoding of the last client response, as well as the "+ "
preceding the response, is part of the IMAP4 profile, and not a
of this specification itself
S: * OK IMAP4 server
C: A001
S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=
S: A001 OK
C: A002 AUTHENTICATE
S: +
C: AG1hZ251cwAxMjM0NTY3OAA
S: A002 OK Welcome, SECURID authenticated user:
4.2 LDAPv
The following examples show the use of the SECURID SASL
with LDAPv3. The examples are only designed to illustrate
protocol interaction, but do provide valid encoding examples
Usernames, passcodes and PINs are of course fictitious.
readability, all messages are shown in the value-notation defined
[X680]. <credential-pdu> values are shown hex-encoded in
'credentials' field of LDAP's 'BindRequest' and
values are shown hex-encoded in the 'serverSaslCreds' field of LDAP'
'BindResponse'.
4.2.1 LDAPv3 Example 1
Initial response message, successful authentication
C: { messageID 1,
protocolOp bindRequest :
{ version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS
authentication sasl :
{ mechanism '53454355524944'H, -- "SECURID
credentials '006d61676e757300313233343536373800'
}
}
}
Nystrom Informational [Page 5]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
S: { messageID 1,
protocolOp bindResponse :
{ resultCode success
matchedDN ''H
errorMessage ''H
}
}
4.2.2 LDAPv3 Example 2
Initial response message, server requires second passcode
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID
credentials '006d61676e757300313233343536373800'
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress
matchedDN ''H
errorMessage ''H
serverSaslCreds '70617373636f646500'
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID
credentials '006d61676e757300383736353433323100'
}
}
}
S: {
messageID 1,
Nystrom Informational [Page 6]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
protocolOp bindResponse : {
resultCode success
matchedDN ''H
errorMessage ''H
}
}
4.2.3 LDAPv3 Example 3
Initial response message, server requires new PIN and passcode,
supplies client with a suggested new PIN (which the client accepts).
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID
credentials '006d61676e757300313233343536373800'
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress
matchedDN ''H
errorMessage ''H
serverSaslCreds '70696e006b616c6c6500'
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID
credentials '006d61676e7573003837343434363734006b616c6c6500'
}
}
}
S: {
messageID 1,
Nystrom Informational [Page 7]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
protocolOp bindResponse : {
resultCode success
matchedDN ''H
errorMessage ''H
}
}
5. Security
This mechanism only provides protection against passive
attacks. It does not provide session privacy, server
or protection from active attacks. In particular, man-in-the-
attacks, were an attacker acts as an application server in order
acquire a valid passcode are possible
In order to protect against such attacks, the client SHOULD make
that the server is properly authenticated. When user PINs
transmitted, user authentication SHOULD take place on a server
authenticated and confidentiality-protected connection
Server implementations MUST protect against replay attacks, since
attacker could otherwise gain access by replaying a previous,
request. Clients MUST also protect against replay of PIN-
messages
5.1 The Race
It is possible for an attacker to listen to most of a passcode,
the remainder, and then race the legitimate user to complete
authentication. As for OTP [RFC2289], conforming
implementations MUST protect against this race condition. One
against this attack is outlined below and borrowed from [RFC2289];
implementations MAY use this approach or MAY select an
defense
One possible defense is to prevent a user from starting
simultaneous authentication sessions. This means that once
legitimate user has initiated authentication, an attacker would
blocked until the first authentication process has completed.
this approach, a timeout is necessary to thwart a denial of
attack
6. IANA
By registering the SecurID protocol as a SASL mechanism,
will have a well-defined way of adding this authentication
to their product. Here is the registration template for the
SASL mechanism
Nystrom Informational [Page 8]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
SASL mechanism name:
Security Considerations: See corresponding section of this
Published specification: This
Person & email address
contact for
information: See author's address section
Intended usage:
Author/Change controller: See author's address section
7. Intellectual Property
RSA Security Inc. does not make any claims on the
constructions described in this memo, although underlying
may be covered. Among the underlying techniques, the
technology is covered by a number of US patents (and
counterparts), in particular US patent no. 4,885,778, no. 5,097,505,
no. 5,168,520, and 5,657,388.
SecurID is a registered trademark, and PASSCODE is a trademark,
RSA Security Inc
8.
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[RFC2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996.
[RFC2060] Crispin, M., "Internet Message Access Protocol -
4rev1", RFC 2060, December 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer",
2222, October 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Access Protocol", RFC 2244, November 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight
Access Protocol (v3)", RFC 2251, December 1997.
Nystrom Informational [Page 9]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-
Password System", RFC 2289, February 1998.
[X3.4] ANSI, "ANSI X3.4: Information Systems - Coded
Sets - 7-Bit American National Standard Code
Information Interchange (7-Bit ASCII)," American
Standards Institute
[X680] ITU-T, "Information Technology - Abstract Syntax
One (ASN.1): Specification of Basic Notation,"
International Telecommunication Union, 1997.
9.
The author gratefully acknowledges the contributions of
reviewers of this memo, in particular the ones from John Myers.
have significantly clarified and improved the utility of
specification
10. Author's
Magnus
RSA
Box 10704
121 29
Phone: +46 8 725 0900
EMail: magnus@rsasecurity.
Nystrom Informational [Page 10]
RFC 2808 The SecurID(r) SASL Mechanism April 2000
11. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Nystrom Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
