Bump versions.

[gsasl.git] / doc / specification / draft-nystrom-securid-sasl-00.txt

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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
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]
\f
INTERNET DRAFT          EXPIRES JULY 1999               INTERNET DRAFT