[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                       S. Josefsson
Internet-Draft                                              RSA Security
Expires: August 23, 2002                               February 22, 2002


                      The EAP SecurID(r) Mechanism
                      draft-josefsson-eap-securid

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups 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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 23, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describe an EAP mechanism based on SecurID.  SecurID is
   a hardware token card product (or software emulation thereof)
   produced by RSA Security, which is used for end-user authentication.
   The SecurID EAP mechanism can be used to provide authentication in
   protocols utilizing EAP, such as PPP, IEEE 802.11 Wireless LAN and
   possibly Bluetooth in the future.

   The intent is to publish this as a Informational RFC.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].



Josefsson                Expires August 23, 2002                [Page 1]

Internet-Draft                 EAP-SecurID                 February 2002


Table of Contents

   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
   1.1 Rationale Behind the Design  . . . . . . . . . . . . . . . . .  3
   2.  Authentication Model . . . . . . . . . . . . . . . . . . . . .  4
   3.  Authentication Procedure . . . . . . . . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   4.1 The Race Attack  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Intellectual Property Considerations . . . . . . . . . . . . .  8
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10





































Josefsson                Expires August 23, 2002                [Page 2]

Internet-Draft                 EAP-SecurID                 February 2002


1. Introduction and Background

   The SecurID EAP mechanism is a good choice for authentication in
   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.

   The SecurID EAP mechanism provides a formal way to integrate the
   existing SecurID authentication method into EAP-enabled protocols
   including PPP, Wireless LAN and possibly Bluetooth in the future.

   Integrity and confidentiality of the one-time passcode are outside of
   the scope of this document, solutions such as PEAP [2] are
   recommended to solve this problem.

1.1 Rationale Behind the Design

   Integrating SecurID within EAP could also have been achieved by
   describing a profile of the existing EAP Generic Token Card (GTC)
   mechanism.

   The advantages of using a new EAP mechanism for SecurID is that the
   protocol syntax becomes well-defined.  This makes it easier to
   programmatically use the EAP mechanism in the client and server.
   This is unlike GTC, which uses text strings, intended to be
   interpreted and acted upon by humans.  The advantage of using a GTC
   profile for SecurID would be that of reduced deployment costs,
   assuming that existing EAP clients implement GTC because it is
   required by the EAP specification.  However, investigations have
   shown [1] that EAP implementations in general do not support GTC.
   Hence, the costs of introducing a new EAP mechanism for SecurID and a
   SecurID profile of GTC are roughly the same.  Thus our decision was
   based on the technical argument that a new EAP mechanism for SecurID
   makes for a cleaner design and easier implementation.
















Josefsson                Expires August 23, 2002                [Page 3]

Internet-Draft                 EAP-SecurID                 February 2002


2. Authentication Model

   The SecurID EAP mechanism provides two-factor based user
   authentication as defined below.

   There are basically three entities in the authentication mechanism
   described here:

   o  A client, acting on behalf of a user possessing a SecurID token.

   o  An application server, to which the user wants to connect.

   o  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 etcetera as needed, both servers are,
   unless explicitly mentioned, collectively denoted as "the server"
   here, or "authenticator" using EAP terminology.  The protocol used
   between the application server and the authentication server is
   outside the scope of this memo.  The client, acting on behalf of the
   user, is denoted as "peer" using EAP terminology.

   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" is generated by the user's token and
   sent to the server.

   The SecurID EAP mechanism provides only one service, namely user
   authentication where the user provides information to the server, so
   that the server can authenticate the user.

   The SecurID EAP mechanism type number is TBD.













Josefsson                Expires August 23, 2002                [Page 4]

Internet-Draft                 EAP-SecurID                 February 2002


3. Authentication Procedure

   a) The optional EAP Identity Request/Response is exchanged, as per
   RFC 2284 [3].  The Identity indicated here interacts with the
   "Authentication identity" below.

   b) The authenticator sends a EAP Request of type SecurID with a zero
   length Type-Data.

   c) The peer generates the credentials using local information (seed,
   current time and user PIN/password).

   d) The peer sends credentials to the server in a EAP Response of type
   SecurID.  The contents of the EAP Response Type-Data field in a
   peer's initial response contains the "credential-pdu" 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-ASCII [X3.4] is a subset of
   UTF-8).

   (2) An authentication identity.  The identity whose passcode will be
   used.  If this field is empty, it defaults to the EAP Identity above
   which in this case MUST have been sent.  This field MUST NOT be
   longer than 255 octets, SHALL be terminated by a NUL (0) octet, and
   MUST consist of UTF-8-encoded printable characters only.

   (3) A passcode.  The one-time password that will be used to grant
   access.  This field MUST NOT be shorter than 4 octets, MUST NOT be
   longer than 32 octets, SHALL be terminated by a NUL (0) octet, and
   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




Josefsson                Expires August 23, 2002                [Page 5]

Internet-Draft                 EAP-SecurID                 February 2002


   VUTF8 = <Visible (printable) UTF8-encoded characters>

   Regarding the <pin> rule, see f) below.

   e) The authenticator verifies these credentials using its own
   information.  If the verification succeeds, the authenticator sends
   back a EAP Success.  After receiving this response, the peer is
   authenticated and this protocol is finished.  Otherwise, the
   verification either failed and a EAP Failure packet is sent and this
   protocol is finished, or the authenticator needs an additional set of
   credentials from the peer in order to authenticate it.

   f) If the authenticator needs an additional set of credentials, it
   sends a EAP Request with type SecurID now.  The Type-Data field of
   this request contains the "server-request" as follows:

   server-request = passcode | pin

   passcode      = "passcode" %x00

   pin           = "pin" %x00 [suggested-pin]

   suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters

   The 'passcode' choice will be sent when the server requests another
   passcode.  The 'pin' choice will be sent when the server requests a
   new user PIN.  The server will either send an empty string or suggest
   a new user PIN in this message.

   g) The peer generates a new set of credentials using local
   information and depending on the authenticator's request and sends
   them to the authenticator using the same format as in d) above, with
   the <pin> field present.  Authentication now continues as in e)
   above.

   Note 1: Case f) above may occur, e.g., when the clocks on which the
   server and the client relies are not synchronized.

   Note 2: If the server requests a new user PIN, the client MUST
   respond with a new user PIN (together with a passcode), encoded as a
   UTF-8 string.  If the server supplies 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 are any other requirements for the PIN, e.g., allowed
   characters.  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 using EAP Notification
   or a repeated request for a new PIN as described in the protocol



Josefsson                Expires August 23, 2002                [Page 6]

Internet-Draft                 EAP-SecurID                 February 2002


   above.  Mechanisms for transferring knowledge about PIN requirements
   from the server to the client are outside the scope of this memo.
   However, some information MAY be provided in error messages
   transferred from the server to the client when applicable.

4. Security Considerations

   This mechanism only provides protection against passive eavesdropping
   attacks.  It does not provide session privacy, session integrity,
   server authentication or protection from active attacks.  In
   particular, man-in-the-middle attacks, were an attacker acts as an
   application server in order to acquire a valid passcode are possible.
   Similarily, this mechanism does not protect from session hijacking
   taking place after authentication.  This mechanism do not protect
   against replay attacks, where the attacker gains access by replaying
   a previous, valid request.  When PIN codes are transmitted, they are
   sent without protection and is also subject to replay attacks.

   In order to protect against these attacks, the client MUST only use
   this mechanism over a server authenticated and (when PIN codes are
   exchanged) confidentiality-protected connection by using, e.g., PEAP
   [2].

   Server implementations MUST protect against replay attacks, since an
   attacker could otherwise gain access by replaying a previous, valid
   request.  Clients MUST also protect against replay of PIN-change
   messages.

4.1 The Race Attack

   It is possible for an attacker to listen to most of a passcode, guess
   the remainder, and then race the legitimate user to complete the
   authentication.  As for OTP [5] conforming server implementations
   MUST protect against this race condition.  One defense against this
   attack is outlined below and borrowed from [5]; implementations MAY
   use this approach or MAY select an alternative defense.

   One possible defense is to prevent a user from starting multiple
   simultaneous authentication sessions.  This means that once the
   legitimate user has initiated authentication, an attacker would be
   blocked until the first authentication process has completed.  In
   this approach, a timeout is necessary to thwart a denial of service
   attack.

5. IANA Considerations

   The IANA is asked to assign a new EAP mechanism number to the
   protocol defined in this document.



Josefsson                Expires August 23, 2002                [Page 7]

Internet-Draft                 EAP-SecurID                 February 2002


6. Intellectual Property Considerations

   RSA Security does not make 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 (and foreign 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, of
   RSA Security.

7. Acknowledgments

   This document is influenced by The SecurID(r) SASL Mechanism [6].
   This document was improved by comments from, and discussion with,
   H…kan Andersson, Jan-Ove Larsson and Magnus Nystr÷m.


































Josefsson                Expires August 23, 2002                [Page 8]

Internet-Draft                 EAP-SecurID                 February 2002


References

   [1]  Aboba, B., "Presentation to PPP Extensions WG at 52:th IETF
        meeting in Salt Lake City", December 2001.

   [2]  Andersson, H., Josefsson, S., Zorn, G. and B. Aboba, "Protected
        Extensible Authentication Protocol (PEAP)", Work in progress
        draft-josefsson-pppext-eap-tls-eap-01.txt, October 2001.

   [3]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [5]  Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
        Password System", RFC 2289, February 1998.

   [6]  Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808, April
        2000.


Author's Address

   Simon Josefsson
   RSA Security
   Arenav„gen 29
   Stockholm  121 29
   Sweden

   Phone: +46 8 7250914
   EMail: sjosefsson@rsasecurity.com



















Josefsson                Expires August 23, 2002                [Page 9]

Internet-Draft                 EAP-SecurID                 February 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Josefsson                Expires August 23, 2002               [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/