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 = Regarding the 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 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]