idnits 2.17.1 draft-josefsson-eap-securid-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-josefsson-eap-securid', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-josefsson-eap-securid', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-josefsson-eap-securid', but the file name used is 'draft-josefsson-eap-securid-01' == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2002) is 8091 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2279' on line 162 -- Looks like a reference, but probably isn't: 'RFC2234' on line 177 -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-01 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2284 (ref. '3') (Obsoleted by RFC 3748) ** Downref: Normative reference to an Informational RFC: RFC 2808 (ref. '6') Summary: 6 errors (**), 1 flaw (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft RSA Security 4 Expires: August 23, 2002 February 22, 2002 6 The EAP SecurID(r) Mechanism 7 draft-josefsson-eap-securid 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 23, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document describe an EAP mechanism based on SecurID. SecurID is 39 a hardware token card product (or software emulation thereof) 40 produced by RSA Security, which is used for end-user authentication. 41 The SecurID EAP mechanism can be used to provide authentication in 42 protocols utilizing EAP, such as PPP, IEEE 802.11 Wireless LAN and 43 possibly Bluetooth in the future. 45 The intent is to publish this as a Informational RFC. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [4]. 51 Table of Contents 53 1. Introduction and Background . . . . . . . . . . . . . . . . . 3 54 1.1 Rationale Behind the Design . . . . . . . . . . . . . . . . . 3 55 2. Authentication Model . . . . . . . . . . . . . . . . . . . . . 4 56 3. Authentication Procedure . . . . . . . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 4.1 The Race Attack . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6. Intellectual Property Considerations . . . . . . . . . . . . . 8 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction and Background 68 The SecurID EAP mechanism is a good choice for authentication in 69 usage scenarios where a client, acting on behalf of a user, is 70 untrusted, as a one-time passcode will only give the client a single 71 opportunity to act maliciously. This mechanism provides 72 authentication only. 74 The SecurID EAP mechanism provides a formal way to integrate the 75 existing SecurID authentication method into EAP-enabled protocols 76 including PPP, Wireless LAN and possibly Bluetooth in the future. 78 Integrity and confidentiality of the one-time passcode are outside of 79 the scope of this document, solutions such as PEAP [2] are 80 recommended to solve this problem. 82 1.1 Rationale Behind the Design 84 Integrating SecurID within EAP could also have been achieved by 85 describing a profile of the existing EAP Generic Token Card (GTC) 86 mechanism. 88 The advantages of using a new EAP mechanism for SecurID is that the 89 protocol syntax becomes well-defined. This makes it easier to 90 programmatically use the EAP mechanism in the client and server. 91 This is unlike GTC, which uses text strings, intended to be 92 interpreted and acted upon by humans. The advantage of using a GTC 93 profile for SecurID would be that of reduced deployment costs, 94 assuming that existing EAP clients implement GTC because it is 95 required by the EAP specification. However, investigations have 96 shown [1] that EAP implementations in general do not support GTC. 97 Hence, the costs of introducing a new EAP mechanism for SecurID and a 98 SecurID profile of GTC are roughly the same. Thus our decision was 99 based on the technical argument that a new EAP mechanism for SecurID 100 makes for a cleaner design and easier implementation. 102 2. Authentication Model 104 The SecurID EAP mechanism provides two-factor based user 105 authentication as defined below. 107 There are basically three entities in the authentication mechanism 108 described here: 110 o A client, acting on behalf of a user possessing a SecurID token. 112 o An application server, to which the user wants to connect. 114 o An authentication server, capable of authenticating the user. 116 Even though the application server in practice may function as a 117 client with respect to the authentication server, relaying 118 authentication credentials etcetera as needed, both servers are, 119 unless explicitly mentioned, collectively denoted as "the server" 120 here, or "authenticator" using EAP terminology. The protocol used 121 between the application server and the authentication server is 122 outside the scope of this memo. The client, acting on behalf of the 123 user, is denoted as "peer" using EAP terminology. 125 The mechanism is based on the use of a shared secret key, or "seed", 126 and a personal identification number (PIN), which is known both by 127 the user and the authentication server. The secret seed is stored on 128 a token that the user possesses, as well as on the authentication 129 server. Hence the term "two-factor authentication", a user needs not 130 only physical access to the token but also knowledge about the PIN in 131 order to perform an authentication. Given the seed, current time of 132 day, and the PIN, a "PASSCODE" is generated by the user's token and 133 sent to the server. 135 The SecurID EAP mechanism provides only one service, namely user 136 authentication where the user provides information to the server, so 137 that the server can authenticate the user. 139 The SecurID EAP mechanism type number is TBD. 141 3. Authentication Procedure 143 a) The optional EAP Identity Request/Response is exchanged, as per 144 RFC 2284 [3]. The Identity indicated here interacts with the 145 "Authentication identity" below. 147 b) The authenticator sends a EAP Request of type SecurID with a zero 148 length Type-Data. 150 c) The peer generates the credentials using local information (seed, 151 current time and user PIN/password). 153 d) The peer sends credentials to the server in a EAP Response of type 154 SecurID. The contents of the EAP Response Type-Data field in a 155 peer's initial response contains the "credential-pdu" as follows: 157 (1) An authorization identity. When this field is empty, it defaults 158 to the authentication identity. This field MAY be used by system 159 administrators or proxy servers to login with a different user 160 identity. This field MUST NOT be longer than 255 octets, SHALL be 161 terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded 162 [RFC2279] printable characters only (US-ASCII [X3.4] is a subset of 163 UTF-8). 165 (2) An authentication identity. The identity whose passcode will be 166 used. If this field is empty, it defaults to the EAP Identity above 167 which in this case MUST have been sent. This field MUST NOT be 168 longer than 255 octets, SHALL be terminated by a NUL (0) octet, and 169 MUST consist of UTF-8-encoded printable characters only. 171 (3) A passcode. The one-time password that will be used to grant 172 access. This field MUST NOT be shorter than 4 octets, MUST NOT be 173 longer than 32 octets, SHALL be terminated by a NUL (0) octet, and 174 MUST consist of UTF-8-encoded printable characters only. Passcodes 175 usually consist of 4-8 digits. 177 The ABNF [RFC2234] form of this message is as follows: 179 credential-pdu = authorization-id authentication-id passcode [pin] 181 authorization-id = 0*255VUTF8 %x00 183 authentication-id = 0*255VUTF8 %x00 185 passcode = 4*32VUTF8 %x00 187 pin ::= 4*32VUTF8 %x00 188 VUTF8 = 190 Regarding the rule, see f) below. 192 e) The authenticator verifies these credentials using its own 193 information. If the verification succeeds, the authenticator sends 194 back a EAP Success. After receiving this response, the peer is 195 authenticated and this protocol is finished. Otherwise, the 196 verification either failed and a EAP Failure packet is sent and this 197 protocol is finished, or the authenticator needs an additional set of 198 credentials from the peer in order to authenticate it. 200 f) If the authenticator needs an additional set of credentials, it 201 sends a EAP Request with type SecurID now. The Type-Data field of 202 this request contains the "server-request" as follows: 204 server-request = passcode | pin 206 passcode = "passcode" %x00 208 pin = "pin" %x00 [suggested-pin] 210 suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters 212 The 'passcode' choice will be sent when the server requests another 213 passcode. The 'pin' choice will be sent when the server requests a 214 new user PIN. The server will either send an empty string or suggest 215 a new user PIN in this message. 217 g) The peer generates a new set of credentials using local 218 information and depending on the authenticator's request and sends 219 them to the authenticator using the same format as in d) above, with 220 the field present. Authentication now continues as in e) 221 above. 223 Note 1: Case f) above may occur, e.g., when the clocks on which the 224 server and the client relies are not synchronized. 226 Note 2: If the server requests a new user PIN, the client MUST 227 respond with a new user PIN (together with a passcode), encoded as a 228 UTF-8 string. If the server supplies the client with a suggested 229 PIN, the client accepts this by replying with the same PIN, but MAY 230 replace it with another one. The length of the PIN is application- 231 dependent as are any other requirements for the PIN, e.g., allowed 232 characters. If the server for some reason does not accept the 233 received PIN, the client MUST be prepared to receive either a message 234 indicating the failure of the authentication using EAP Notification 235 or a repeated request for a new PIN as described in the protocol 236 above. Mechanisms for transferring knowledge about PIN requirements 237 from the server to the client are outside the scope of this memo. 238 However, some information MAY be provided in error messages 239 transferred from the server to the client when applicable. 241 4. Security Considerations 243 This mechanism only provides protection against passive eavesdropping 244 attacks. It does not provide session privacy, session integrity, 245 server authentication or protection from active attacks. In 246 particular, man-in-the-middle attacks, were an attacker acts as an 247 application server in order to acquire a valid passcode are possible. 248 Similarily, this mechanism does not protect from session hijacking 249 taking place after authentication. This mechanism do not protect 250 against replay attacks, where the attacker gains access by replaying 251 a previous, valid request. When PIN codes are transmitted, they are 252 sent without protection and is also subject to replay attacks. 254 In order to protect against these attacks, the client MUST only use 255 this mechanism over a server authenticated and (when PIN codes are 256 exchanged) confidentiality-protected connection by using, e.g., PEAP 257 [2]. 259 Server implementations MUST protect against replay attacks, since an 260 attacker could otherwise gain access by replaying a previous, valid 261 request. Clients MUST also protect against replay of PIN-change 262 messages. 264 4.1 The Race Attack 266 It is possible for an attacker to listen to most of a passcode, guess 267 the remainder, and then race the legitimate user to complete the 268 authentication. As for OTP [5] conforming server implementations 269 MUST protect against this race condition. One defense against this 270 attack is outlined below and borrowed from [5]; implementations MAY 271 use this approach or MAY select an alternative defense. 273 One possible defense is to prevent a user from starting multiple 274 simultaneous authentication sessions. This means that once the 275 legitimate user has initiated authentication, an attacker would be 276 blocked until the first authentication process has completed. In 277 this approach, a timeout is necessary to thwart a denial of service 278 attack. 280 5. IANA Considerations 282 The IANA is asked to assign a new EAP mechanism number to the 283 protocol defined in this document. 285 6. Intellectual Property Considerations 287 RSA Security does not make any claims on the general constructions 288 described in this memo, although underlying techniques may be 289 covered. Among the underlying techniques, the SecurID technology is 290 covered by a number of US patents (and foreign counterparts), in 291 particular US patent no. 4,885,778, no. 5,097,505, no. 5,168,520, 292 and 5,657,388. 294 SecurID is a registered trademark, and PASSCODE is a trademark, of 295 RSA Security. 297 7. Acknowledgments 299 This document is influenced by The SecurID(r) SASL Mechanism [6]. 300 This document was improved by comments from, and discussion with, 301 H�kan Andersson, Jan-Ove Larsson and Magnus Nystr�m. 303 References 305 [1] Aboba, B., "Presentation to PPP Extensions WG at 52:th IETF 306 meeting in Salt Lake City", December 2001. 308 [2] Andersson, H., Josefsson, S., Zorn, G. and B. Aboba, "Protected 309 Extensible Authentication Protocol (PEAP)", Work in progress 310 draft-josefsson-pppext-eap-tls-eap-01.txt, October 2001. 312 [3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 313 Protocol (EAP)", RFC 2284, March 1998. 315 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 316 Levels", RFC 2119, March 1997. 318 [5] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time 319 Password System", RFC 2289, February 1998. 321 [6] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808, April 322 2000. 324 Author's Address 326 Simon Josefsson 327 RSA Security 328 Arenav�gen 29 329 Stockholm 121 29 330 Sweden 332 Phone: +46 8 7250914 333 EMail: sjosefsson@rsasecurity.com 335 Full Copyright Statement 337 Copyright (C) The Internet Society (2002). All Rights Reserved. 339 This document and translations of it may be copied and furnished to 340 others, and derivative works that comment on or otherwise explain it 341 or assist in its implementation may be prepared, copied, published 342 and distributed, in whole or in part, without restriction of any 343 kind, provided that the above copyright notice and this paragraph are 344 included on all such copies and derivative works. However, this 345 document itself may not be modified in any way, such as by removing 346 the copyright notice or references to the Internet Society or other 347 Internet organizations, except as needed for the purpose of 348 developing Internet standards in which case the procedures for 349 copyrights defined in the Internet Standards process must be 350 followed, or as required to translate it into languages other than 351 English. 353 The limited permissions granted above are perpetual and will not be 354 revoked by the Internet Society or its successors or assigns. 356 This document and the information contained herein is provided on an 357 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 358 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 359 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 360 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 361 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 363 Acknowledgement 365 Funding for the RFC Editor function is currently provided by the 366 Internet Society.