idnits 2.17.1 draft-bersani-eap-synthesis-sharedkeymethods-00.txt: -(1598): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1605): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-bersani-eap-synthesis-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-bersani-eap-synthesis-', 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-bersani-eap-synthesis-', but the file name used is 'draft-bersani-eap-synthesis-sharedkeymethods-00' == There are 9 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 2004) is 7314 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) == Missing Reference: 'EAP-METHSTAT2' is mentioned on line 155, but not defined == Missing Reference: 'DynamID' is mentioned on line 1230, but not defined == Missing Reference: 'Airfortress' is mentioned on line 1342, but not defined == Unused Reference: 'AirFortress' is defined on line 1507, but no explicit reference was found in the text == Unused Reference: 'Dynamid' is defined on line 1524, but no explicit reference was found in the text == Unused Reference: 'EAP-Archie' is defined on line 1530, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Actiontec' -- Possible downref: Non-RFC (?) normative reference: ref. 'AirFortress' -- Possible downref: Non-RFC (?) normative reference: ref. 'Arcot' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cogent' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTOcard' -- Possible downref: Non-RFC (?) normative reference: ref. 'Defender' -- Possible downref: Non-RFC (?) normative reference: ref. 'DeviceConnect' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dynamid' ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. 'EAP-Archie' -- Duplicate reference: RFC2284, mentioned in 'EAPbis', was also mentioned in 'EAP'. ** Obsolete normative reference: RFC 2284 (ref. 'EAPbis') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. 'EAPHTTPDigest' -- Possible downref: Non-RFC (?) normative reference: ref. 'EAPIssues' -- Possible downref: Non-RFC (?) normative reference: ref. 'EAP-METHSTAT1' -- Possible downref: Non-RFC (?) normative reference: ref. 'EAP-MOBAC' == Outdated reference: A later version (-11) exists of draft-bersani-eap-psk-01 ** Downref: Normative reference to an Experimental draft: draft-bersani-eap-psk (ref. 'EAP-PSK') -- Possible downref: Non-RFC (?) normative reference: ref. 'EAP-SKE' -- Possible downref: Normative reference to a draft: ref. 'EAP-SKMDTEMPL' ** Obsolete normative reference: RFC 2716 (ref. 'EAP-TLS') (Obsoleted by RFC 5216) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-01 ** Obsolete normative reference: RFC 2617 (ref. 'HTTP-Digest') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'Identix' == Outdated reference: A later version (-04) exists of draft-walker-ieee802-req-00 ** Downref: Normative reference to an Informational draft: draft-walker-ieee802-req (ref. 'IEEE 802REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'LEAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LEAPVUL' -- Possible downref: Non-RFC (?) normative reference: ref. 'MDx' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSCHAPVUL' -- Possible downref: Non-RFC (?) normative reference: ref. 'Securesuite' -- Possible downref: Non-RFC (?) normative reference: ref. 'SentriNET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRPpres' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZoneLabs' -- Possible downref: Non-RFC (?) normative reference: ref. '3com' Summary: 9 errors (**), 1 flaw (~~), 14 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Florent Bersani 3 File: draft-bersani-eap-synthesis- France Telecom R&D 4 sharedkeymethods-00.txt 5 Expires: October 2004 April 2004 7 EAP shared key methods: a tentative synthesis of those proposed so 8 far 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-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 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2004). All Rights Reserved. 33 Abstract 35 The purpose of this draft is to gives a broad picture of the existing 36 proposed EAP methods, with a focus on shared key EAP methods. Indeed, 37 it is the belief of the author that a standard replacement for EAP- 38 MD5 (that is deprecated due to security reasons) is needed. By 39 listing the existing shared key EAP methods, the goal is to gather 40 consensus that such a multiplication of methods is detrimental and 41 that a single methods retaining the best of the existing proposals 42 could and should be drafted. 44 Table of Contents 46 1. Introduction..................................................4 47 1.1 Purpose of this document...................................4 48 1.2 Material used for this document............................4 49 1.3 Organization of this document..............................5 50 1.4 Caveats....................................................5 51 2. Review of the proposed shared key EAP methods.................6 52 2.1 EAP-MD5....................................................6 53 2.2 EAP-Cisco Wireless.........................................7 54 2.3 EAP-SIM....................................................7 55 2.4 SRP-SHA1...................................................8 56 2.5 EAP-AKA....................................................9 57 2.6 MS-EAP-Authentication.....................................10 58 2.7 EAP MSCHAP-V2.............................................10 59 2.8 EAP-HTTP Digest...........................................11 60 2.9 EAP-SPEKE.................................................11 61 2.10 EAP-FAST.................................................12 62 2.11 EAP-Archie...............................................13 63 2.12 EAP-GSS..................................................14 64 2.13 EAP-IKEv2................................................14 65 2.14 EAP-LDAP.................................................15 66 2.15 EAP-MD5 Tunneled Authentication Protocol.................15 67 2.16 EAP-PSK..................................................15 68 2.17 EAP-SKE..................................................16 69 2.18 EAP-SSC..................................................17 70 3. Conclusion...................................................17 71 3.1 The different existing shared key EAP methods.............17 72 3.2 General conclusion on shared key EAP methods..............19 73 3.3 Miscellaneous conclusions.................................19 74 4. Review of the non shared key EAP methods.....................20 75 4.1 EAP-OTP...................................................20 76 4.2 EAP-GTC...................................................20 77 4.3 EAP RSA Public Key Authentication.........................21 78 4.4 EAP-DSS...................................................21 79 4.5 EAP-KEA...................................................22 80 4.6 EAP-TLS...................................................22 81 4.7 Defender Token (AXENT)....................................22 82 4.8 RSA Security SecurID EAP and SecurID EAP..................23 83 4.9 Arcot systems EAP.........................................23 84 4.10 EAP-TTLS.................................................24 85 4.11 Remote Access Service....................................24 86 4.12 EAP-3Com Wireless........................................24 87 4.13 PEAP.....................................................25 88 4.14 EAP-MAKE.................................................26 89 4.15 CRYPTOcard...............................................26 90 4.16 DynamID..................................................26 91 4.17 Rob EAP..................................................27 92 4.18 MS-Authentication TLV....................................27 93 4.19 SentriNET................................................27 94 4.20 EAP-Actiontec Wireless...................................28 95 4.21 Cogent systems biometrics authentication EAP.............28 96 4.22 AirFortress EAP..........................................29 97 4.23 Securesuite EAP..........................................29 98 4.24 DeviceConnect EAP........................................29 99 4.25 EAP-MOBAC................................................29 100 4.26 ZoneLabs EAP (ZLXEAP)....................................30 101 4.27 EAP Bluetooth Application................................30 102 4.28 EAP-GPRS.................................................30 103 4.29 EAP support in smart cards...............................31 104 4.30 EAP-TLS SASL.............................................31 105 5. IANA considerations..........................................32 106 6. Security considerations......................................32 107 7. Acknowledgements.............................................32 108 8. References...................................................32 109 9. Authors' Addresses...........................................35 110 10. Full Copyright Statement....................................35 112 1. Introduction 114 1.1 Purpose of this document 116 The Extensible Authentication Protocol (EAP) [EAP], provides an 117 authentication framework which supports multiple authentication 118 methods. EAP typically runs directly over data link layers such as 119 PPP [PPP] or IEEE 802 thanks to the IEEE 802.1X [IEEE 802.1X] 120 framework., without requiring IP. 122 EAP supports many authentication mechanisms usually called EAP 123 methods. 125 The purpose of this draft is to gives a broad picture of the existing 126 proposed EAP methods, with a focus on shared key EAP methods. 128 Although this has already done before, see [EAP-METHSTAT1] and [EAP- 129 METHSTAT2], it appeared worth doing the exercise thoroughly again 130 with a view towards requesting the opening of a work item at IETF, 131 namely replacing EAP-MD5. 133 Indeed, EAP methods have proliferated but only 4 are currently 134 standardized - namely EAP-MD5, EAP-OTP and EAP-GTC in [EAP] and EAP- 135 TLS in [EAP-TLS]. Due new security requirements, expressed for 136 instance in IEEE 802 EAP Method Requirements for Wireless LANs [IEEE 137 802REQ], EAP-MD5 has been deprecated: it does neither provide mutual 138 authentication nor key derivation. However, no simple shared key EAP 139 method seems to be widely available to replace EAP-MD5. 141 In parallel to a proposition for such a replacement ([EAP-PSK]), a 142 documentation effort has been undertaken (see [EAP-SKMDTEMPL]) to 143 assess the different proposals, confirm that no standard replacement 144 for EAP-MD5 exists and open the way for such a replacement by 145 allowing comparison/merger of the existing related work. This 146 document is the synthesis of this effort. 148 1.2 Material used for this document 150 This document has been elaborated thanks to: 151 o The responses received to [EAP-SKMDTEMPL] that was posted March 152 2004 to the EAP mailing list 153 o Investigation of the PPP EAP Request/Response Types registered 154 by IANA ([IANA]) 155 o Investigation of the methods quoted in [EAP-METHSTAT2] 157 Although it is the intention of the author of this document to gather 158 all the material relevant to EAP methods on a single location on the 159 Internet, the readers might want to use the following URLs to 160 retrieve documents mentioned in this document while the 161 aforementioned location is still under construction: 162 o http://www.potaroo.net/ietf/old-ids/ 163 o http://www.watersprings.org/pub/id/ 165 1.3 Organization of this document 167 Section 2 is devoted to briefly present and analyze each proposed 168 shared key EAP method the author of this document is aware of. 170 Following this review, conclusions are drawn in section 3. After a 171 brief review of the methods studied in section 2 for the sake of 172 clarity to allow the impatient reader to directly jump to section 3 173 without reading section 2, a tentative conclusion on shared key EAP 174 methods in general and replacement of EAP-MD5 in particular is 175 proposed in this section, followed by miscellaneous points on 176 alternative subjects noted while writing this document. 178 Section 4 is included for the sake of exhaustively and consists in a 179 brief review of the other existing non shared key EAP methods. This 180 review had to be done to ensure that the methods mentioned in this 181 section were indeed not shared key methods and thus did not belong to 182 section 2. 184 Within section 2 and 4, the EAP methods have been listed starting by 185 those who have been attributed an EAP type number by IANA presented 186 in increasing type number order, followed by those who have not, 187 presented in alphabetical order according to their name. 189 The other sections are the typical ones of an Internet Draft. 191 1.4 Caveats 193 Though, the intention of this document was mainly to document the 194 existing shared key EAP methods, the borderline between documenting 195 and commenting upon was sometimes blurred. This was further 196 complicated by the obvious potential bias of the author (who is 197 himself the author of a proposed shared key EAP method, EAP-PSK). As 198 the draft may evolve, this will be clarified (i.e. the analysis parts 199 will be more clearly separated from the documentation ones and will 200 be deepened). In the meanwhile, the reader is advised to 201 differentiate in this document between facts and what may be 202 considered opinions. Comments to help separate facts from opinions as 203 well as to include other opinions are more than welcome! 205 In addition, gathering documentation and digesting it did not prove 206 to be that simple. Hence, this document may unfortunately contain 207 some errors. Readers are encouraged to report any error they feel 208 they have spotted (especially if they are authors of an EAP method 209 and are dissatisfied with the treatment their method has received). 211 It was especially difficult to find out whether a method was still 212 being developed or not as well as whether a method had been 213 implemented. Hopefully future versions of this draft will clarify 214 this. 216 Last, the reader not familiar with the Internet Draft process is 217 reminded that this document is only (for now) the expression of the 218 work of an individual and by no way the expression of a consensus of 219 the community. It is however the intention of the author that this 220 document evolve from the understanding and appreciation of a single 221 person to the statement of the point of view of the community. 223 2. Review of the proposed shared key EAP methods 225 This section presents the different existing shared key EAP methods 226 the author is aware of. These methods have been a priori deemed 227 relevant for the drafting of a replacement for EAP-MD5. 229 2.1 EAP-MD5 231 Please refer to [EAP] and [EAPbis] for a description of EAP-MD5, 232 which is thus a standardized method. This method has also been widely 233 implemented. 235 EAP-MD5 must have been included in [EAPbis] for backward 236 compatibility, since [EAPbis] clearly presents the totally 237 insufficient security claims of this method (I am not sure it was 238 even a good idea to include this method in [EAPbis] but this is 239 another debate, see for instance Issue 174 of the EAP Issues List 240 [EAPIssues]). 242 Apart from the issues already mentioned on EAP-MD5 and that are far 243 enough to deprecate it (namely: no mutual authentication, no key 244 derivation and high vulnerability to active brute-force/dictionary 245 attacks), I'd like to raise two additional minor ones. 247 First, in [CHAP], the length of the challenge does not appear to be 248 fixed ("The length of the Challenge Value depends upon the method 249 used to generate the octets, and is independent of the hash algorithm 250 used). My understanding is also that the response to CHAP is 251 Hash(Identifier||Secret||Challenge) where Hash denotes a hash 252 function. It is now well-known that it is not a good idea to 253 calculate the response this way (see [MDx]), even though the 254 appending the length of the message in MD5 thwarts the most trivial 255 extension attacks. 257 Second, cryptographers tend to deprecate MD5 in favor of, for 258 instance, SHA-1 because MD5 output is only 16 bytes and because 259 collisions have been found for the MD5 compression function. 261 2.2 EAP-Cisco Wireless 263 EAP-Cisco Wireless is also known as LEAP (Lightweight EAP) which has 264 been registered to IANA by S. Norman (Cisco). 266 It is an undocumented proprietary method of Cisco, that was shared by 267 Cisco to participants in the CCX program. It has been reverse- 268 engineered and analyzed (see [LEAP]). 270 EAP-Cisco Wireless is an EAP method that has been allocated EAP Type 271 17 by IANA. 273 It is a shared key method that builds on existing mechanisms (MS- 274 CHAP). It has been found to be flawed due to cryptographic weaknesses 275 inherited from MS-CHAP and very poor dictionary/brute-force offline 276 attack resistance (see [LEAPVUL]). 278 There does not seem to be any intention to officially document EAP- 279 Cisco Wireless or to modify it to remedy its known flaws. The plan 280 rather seems to be to develop a new and broader EAP method (namely 281 EAP-FAST, see section 2.10). EAP-Cisco Wireless has been implemented. 283 2.3 EAP-SIM 285 SIM stands for Subscriber Identity Module (it is a concept imported 286 from the GSM world). 288 It is an EAP method proposed by H. Haverinen (Nokia) and J. Salowey 289 (Cisco). 291 The first version of it was proposed in February 2001 as an 292 individual Internet-Draft: draft-haverinen-pppext-eap-sim-00.txt. 293 Version 01 published April 2001, Version 02 published November 2001, 294 Version 03 published February 2002, Version 04 published June 2002, 295 Version 05 published June 2002, Version 06 published October 2002, 296 Version 07 published November 2002, Version 08 published December 297 2002, Version 09 published January 2003, Version 10 published 298 February 2003, Version 11 published June 2003 and Version 12 299 published October 2003 are still to be found on the Internet. 301 It is an EAP method based on symmetric cryptography that reuses the 302 GSM authentication infrastructure. Although it could be used without 303 a SIM (e.g. with a software virtual SIM) and therefore as a generic 304 shared key EAP method, it is my opinion that doing would not be 305 appropriate since EAP-SIM makes considerable effort to deal with the 306 limitation of the GSM authentication (e.g. 64 bit keys or unilateral 307 authentication). In case, one would however want to reuse such a 308 method as a generic shared key method, I suggest at least not 309 considering EAP-SIM but only EAP-AKA, which reuses the much more 310 evolved UMTS authentication scheme. 312 Regarding IPR, some IPR claims seem to be related to EAP-SIM, please 313 refer to: 315 o http://www.ietf.org/ietf/IPR/NOKIA-draft-haverinen-pppext-eap- 316 sim.txt 317 o http://www.ietf.org/ietf/IPR/NOKIA-EAP.txt 318 o http://www.ietf.org/ietf/IPR/nokia-ipr-draft-haverinen-pppext- 319 eap-sim.txt 321 EAP-SIM is an EAP method that has been allocated EAP Type 18 by IANA 322 (under the name Nokia IP smart card authentication). 324 EAP-SIM is quite mature and still being actively developed. It has 325 also been implemented. It is backed by the GSM and UMTS world (for 326 instance by the 3GPP and the GSMA). 328 2.4 SRP-SHA1 330 SRP stands for secure remote password, which refers to a protocol 331 developed by Thomas Wu [SRP]. 333 It is an EAP method proposed by J. Carlson (Sun Microsystems), B. 334 Aboba (Microsoft) and H. Haverinen (Nokia). 336 The first version of it was proposed in December 2000 as a PPPEXT WG 337 Internet-Draft: draft-ietf-pppext-eap-srp-00.txt. 339 Version 01 published March 2001, version 02 published June 2001 and 340 version 03 published July 2001 are still to be found on the Internet. 341 Hints to a version 04 may be found on the Internet but I did not 342 manage to find the corresponding draft. 344 It is an EAP method based on symmetric cryptography and asymmetric 345 key cryptography to provide strong password only authenticated key 346 exchange. This method is quite similar to EAP-SPEKE, please refer to 347 section 2.9 for a discussion. 349 Regarding IPR, some IPR claims seem to be related to SRP, please 350 refer to: 352 o http://www.ietf.org/ietf/IPR/LUCENT-SRP 353 o http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt 354 o http://www.ietf.org/ietf/IPR/WU-SRP 356 SRP-SHA1 is an EAP method that has been allocated EAP Type 19 and 20 357 by IANA. 359 It is unclear whether this method is still being developed or not. 360 According to [EAP-METHSTAT1], part of this method is claimed to have 361 been implemented. 363 2.5 EAP-AKA 365 AKA stands for Authentication and Key Agreement (it is a concept 366 imported from the UMTS world). Where the GSM world uses the SIM, the 367 UMTS world uses the USIM which stands for UMTS SIM. 369 It is an EAP method proposed by J. Arkko (Ericsson) and H. Haverinen 370 (Nokia). 372 The first version of it was proposed in May 2001 as an individual 373 Internet-Draft: draft-arkko-pppext-eap-aka-00.txt. Version 01 374 published November 2001, Version 03 published February 2002, Version 375 04 published June 2002, Version 05 published October 2002, Version 06 376 published November 2002, Version 07 published December 2002, Version 377 08 published January 2003, Version 09 published February 2003, 378 Version 10 published June 2003 and Version 11 published October 2003 379 are still to be found on the Internet. I did not manage to find the 380 Version 02 on the Internet. 382 It is an EAP method based on symmetric cryptography that reuses the 383 UMTS authentication infrastructure. Although it could be used without 384 an USIM (e.g. with a software virtual USIM) and therefore as a 385 generic shared key EAP method, it is my opinion that doing would not 386 be most appropriate. However, in the case of EAP-AKA, I must confess 387 that this opinion is rather a matter of taste, regarding for instance 388 its potential complexity and its design compared to the ones of a 389 standalone shared key EAP method. Further technical and scientific 390 investigation is needed to confirm or infirm this opinion. 392 Regarding IPR, an IPR claim seems to be related to EAP-AKA, please 393 refer to: 395 o http://www.ietf.org/ietf/IPR/NOKIA-EAP.txt 397 Though I am not a lawyer, it seems that this claim does not really 398 encumber EAP-AKA. 400 EAP-SIM is quite mature and still being actively developed. It is 401 unclear whether it has been implemented. It is backed by the GSM and 402 UMTS world (for instance by the 3GPP and the GSMA). 404 2.6 MS-EAP-Authentication 406 MS stands for Microsoft. 408 It is an EAP method proposed by Vivek Kamath and Ashwin Palekar 409 (Microsoft). 411 The first version of it was proposed in September 2002 as an 412 individual Internet-Draft: draft-kamath-pppext-eap-mschapv2-00.txt. 414 Hints to a version 01 may be found on the Internet but I did not 415 manage to find the corresponding draft. 417 It is an EAP method based on symmetric cryptography that reuses the 418 MS-CHAPv2 authentication protocol. It therefore bears the well-known 419 security flaws of the MS-CHAPv2 protocol, see [MSCHAPVUL]. An 420 interesting feature is though the password aging and changing 421 process. 423 MS-EAP-Authentication is an EAP method that has been allocated EAP 424 Type 26 by IANA. 426 This method does not seem to be any more under development, although 427 it would require some, at least to comply to the [EAPbis] and [EKMF]. 428 It has been implemented on Microsoft platforms. 430 2.7 EAP MSCHAP-V2 432 It is an EAP method proposed by D. Potter and J. Zamick (Cisco). 434 The first version of it was proposed in January 2002 as an individual 435 Internet-Draft: draft-dpotter-pppext-eap-mschap-00.txt. 437 Hints to a version 01 may be found on the Internet but I did not 438 manage to find the corresponding draft. 440 It is an EAP method based on symmetric cryptography that reuses the 441 MS-CHAPv2 authentication protocol. It therefore bears the well-known 442 security flaws of the MS-CHAPv2 protocol, see [MSCHAPVUL]. This 443 method resembles very closely MS-EAP-Authentication. 445 EAP MSCHAP-V2 is an EAP method that has been allocated EAP Type 29 by 446 IANA. 448 This method does not seem to be any more under development, although 449 it would require some, at least to comply to the [EAPbis] and [EKMF]. 450 It is unclear whether it has been implemented. 452 2.8 EAP-HTTP Digest 454 EAP-HTTP Digest is an EAP method that has been registered to IANA by 455 O. Tavakoli (Funk Software). 457 It is an undocumented EAP method, though some elements were kindly 458 provided by [EAPHTTPDigest]. 460 EAP-HTTP Digest is an EAP method that has been allocated EAP Type 38 461 by IANA. 463 EAP-HTTP Digest is a shared key method that allows HTTP Digest 464 authentication (defined in [HTTP-Digest]) to be offloaded from a 465 gateway to an AAA server. It is applicable for use with HTTP servers 466 as well as other protocols that use HTTP as a transport and require 467 HTTP digest authentication (e.g. SIP). 469 This protocol is not intended to be a shared key EAP method that 470 replaces EAP-MD5 Challenge, as per [EAPHTTPDigest]. It is rather 471 driven by legacy requirements (the definition of an authentication 472 method for HTTP that is not compatible with any existing RADIUS 473 credentials or EAP types). 475 It is unclear whether this method will be publicly specified and 476 whether it is implemented or not. 478 2.9 EAP-SPEKE 480 SPEKE stands for simple password exponential key exchange. 482 It is an EAP method proposed by D. Jablon (Phoenix Technologies). The 483 actual EAP method was, as far as I know, never described. Hence, the 484 following text only alludes to the SPEKE scheme by itself. 486 The first version of it was proposed in February 2002 as an 487 individual Internet-Draft: draft-jablon-speke-00.txt. 489 Version 01 published April 2002 and version 02 published October 2002 490 are still to be found on the Internet. 492 It is an EAP method based on symmetric cryptography and asymmetric 493 key cryptography to provide strong password only authenticated key 494 exchange. 496 This method is quite similar to EAP-SRP. 498 From a security point of view, this method seems to definitely have a 499 better security level than EAP-PSK when a password is used because it 500 uses techniques specially designed to sophisticatedly deal with 501 passwords (better than the classic tips provided in the Annex B of 502 [EAP-PSK], which are salting and iterating a hash function). A simple 503 presentation related to the more evolved techniques to deal with 504 password is available at [SRPpres]. 506 It would be interesting to investigate whether this increased 507 security level has some concrete impact on realistic usage scenarios 508 and whether it is necessary to provide such a strong password 509 support. The reasons why EAP-PSK did not choose to try and provide 510 strong password authentication in a similar way to SPEKE and SRP are: 511 o EAP-PSK wanted to rely on a single cryptographic primitive (AES) 512 whereas SPEKE or SRP have to use asymmetric cryptography 513 o EAP-PSK wanted to avoid any patent-encumbrance whereas SPEKE and 514 SRP seem to require clarification regarding their IPR status 515 o EAP-PSK left totally open the way the PSK would be stored (in a 516 human brain, in hardware or software containers,...) 517 o EAP-PSK felt that it could provide a decent level of security to 518 users that chose "reasonable" passwords (this point is of course 519 to be investigated, justified and clarified). 521 Regarding IPR, some IPR claims seem to be related to SPEKE, please 522 refer to: 524 o http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt 526 EAP-SPEKE is an EAP method that has been allocated EAP Type 41 by 527 IANA. 529 It is unclear whether this method will be publicly specified and 530 whether it is implemented or not. 532 2.10 EAP-FAST 534 EAP-FAST stands for Flexible Authentication via Secure Tunneling 535 (EAP-FAST). 537 It is an EAP method proposed by N.Cam-Winget, D. McGrew, J. Salowey 538 and H.Zhou (Cisco). 540 The first version of it was proposed in February 2004 as an 541 individual Internet-Draft: draft-cam-winget-eap-fast-00.txt. 543 It is an EAP method based on symmetric cryptography and asymmetric 544 key cryptography that reuses the TLS mechanisms. EAP-FAST has some 545 nice features: 546 o � TLV design that allows for extensibility 547 o � Minimization of the per user authentication state requirement 548 o � Handling of legacy equipment (use of TLS and MSCHAPv2) 549 o Fragmentation support 550 o � Crypto-binding to allow sequence of EAP methods 552 However, this protocol has in my opinion two main drawbacks: 553 o Cryptographic design: choices were made to reuse flawed 554 protocols (e.g. MSCHAPv2), new cryptographic designs were 555 introduced without any explanations and the enrollment procedure 556 is easily prone to attacks (especially in the anonymous Diffie- 557 Hellman setting), which is acknowledged and justified by 558 simplicity arguments. The cryptographic design could have 559 benefited from the more evolved and secure password 560 authentication techniques (e.g. EAP-SRP and EAP-SPEKE). 561 o It is quite a heavy weight protocol since for instance it refers 562 to no less than 5 or 6 cryptographic primitives, namely a stream 563 cipher - RC4, a block cipher - AES and hash functions - MD4, MD5 564 and SHA-1, and focuses directly on tunneling. 566 Regarding IPR, some IPR claims seem to be related to EAP-FAST, please 567 refer to: 569 o http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap- 570 fast.txt 572 EAP-FAST is an EAP method that has been allocated EAP Type 43 by 573 IANA. 575 This method has been released very recently and should be further 576 developed and implemented. 578 2.11 EAP-Archie 580 It is an EAP method proposed by Jesse Walker (Intel) and Russ Housley 581 (Vigil Security). 583 The first version of it was proposed in February 2003 as an 584 individual Internet-Draft: draft-jwalker-eap-archie-00.txt. 586 Version 01 published June 2003 is still to be found on the Internet. 588 It is an EAP method based on symmetric cryptography. It is very 589 closely related to EAP-PSK since it was the main source of 590 inspiration for EAP-PSK. 592 The main differences between EAP-Archie and EAP-PSK are: 593 o Some cryptographic changes (use of OMAC in EAP-PSK instead of 594 CBC-MAC that cannot handle variable length messages, use of a 595 key derivation scheme that has been proven to be secure in EAP- 596 PSK, use of EAX to set up a protected channel, removal of the 597 AES key wrap algorithm from EAP-PSK) 599 o Some design changes (e.g. use of a TLV format in EAP-PSK instead 600 of message types) 602 EAP-Archie will not be maintained and developed in the future ([EAP- 603 Archie]), so EAP-PSK may be considered its successor in my opinion. 604 Some implementations of EAP-Archie have been available. 606 2.12 EAP-GSS 608 GSS stands for Generic Security Service and is defined in RFC 2743. 610 It is an EAP method proposed by B. Aboba and D. Simon (Microsoft). 612 The first version of it was proposed in December 1999 under the title 613 "PPP EAP GSS Authentication Protocol" as an individual Internet- 614 Draft: draft-aboba-pppext-eapgss-00.txt. 616 Version 02 published November 2000, version 03 published February 617 2001, version 05 published July 2001, version 06 published August 618 2001, version 07 published August 2001, version 08 published 619 September 2001, version 09 published December 2001, version 10 620 published January 2002, version 11 published February 2002 and 621 version 12 published April 2002 are still to be found on the 622 Internet. Hints to a version 01 and 13 may be found on the Internet 623 but I did not manage to find the corresponding draft. 625 EAP-GSS enables the use of GSS-API mechanisms within EAP. As a 626 result, any GSS-API mechanism providing initial authentication can be 627 used with EAP GSS. Since some GSS-API mechanisms are shared key 628 mechanisms, further investigation is required on this method (since I 629 am currently not familiar with the GSS-API and GSS-API mechanisms). 631 2.13 EAP-IKEv2 633 IKEv2 stands for Internet Key Exchangev2. 635 It is an EAP method proposed by H. Tschofenig and D. Kroeselberg 636 (Siemens) and Y. Ohba (Toshiba). 638 The first version of it was proposed in April 2003 as an individual 639 Internet-Draft: draft-tschofenig-eap-ikev2-00.txt. 641 Version 01 published June 2003, version 02 published October 2003 and 642 version 03 published August 2004 are still to be found on the 643 Internet. 645 It is an EAP method based on the symmetric and asymmetric 646 cryptography of IKEv2. 648 Its main advantages consist in my opinion consist first in reusing a 649 protocol which security has received considerable expert review, 650 second reusing a protocol that could become widely implemented and 651 third benefiting from all the nice features provided by IKEv2 (mutual 652 authentication, key derivation, DoS resistance, fast reconnect, 653 fragmentation support,...). Further investigation is needed to assess 654 this proposal that would be more generic than a shared key method 655 replacing EAP-MD5 since it also allows for asymmetric credentials 656 such as certificates(in particular studying the goals and different 657 features of IKEv2 might be quite inspiring for EAP methods). 659 2.14 EAP-LDAP 661 LDAP is an EAP method proposed by H. Mancini (Bridgewater Systems). 663 The first version of it was proposed in June 2003 under the title 664 "EAP-LDAP Protocol" as an individual Internet-Draft: draft-mancini- 665 pppext-eap-ldap-00.txt. 667 Hints to a version 01 may be found on the Internet but I did not 668 manage to find the corresponding draft. 670 This document specifies an EAP method to enable the use of EAP-MD5 671 even though there is no access to the user's clear text password 672 within an identity store. It merely uses the hash of the user's 673 password, hash which is stored within the identity store, as the key 674 to EAP-MD5. It thus inherits at least all the vulnerability of EAP- 675 MD5 and therefore is not suitable as a replacement for EAP-MD5. 677 2.15 EAP-MD5 Tunneled Authentication Protocol 679 EAP-MD5 Tunneled Authentication Protocol is an EAP method proposed by 680 Paul Funk (Funk Software). 682 The first version of it was proposed in March 2003 under the title " 683 The EAP MD5-Tunneled Authentication Protocol " as an individual 684 Internet-Draft: draft-funk-eap-md5-tunneled-00.txt. 686 EAP-MD5-Tunneled is an EAP protocol designed for use as an inner 687 authentication protocol within a tunneling EAP protocol such as EAP- 688 TTLS or PEAP. It is cryptographically equivalent to standard CHAP and 689 the EAP-MD5-Challenge protocol. Thus, EAP-MD5-Tunneled does not aim 690 at proposing a generic shared key EAP method but rather the issues 691 implied by tunneling EAP methods. In addition, EAP-MD5-Tunneled bears 692 at least the same cryptographic weaknesses as EAP-MD5 and therefore 693 is not suitable as a replacement for EAP-MD5. 695 2.16 EAP-PSK 696 EAP-PSK stands for EAP-Pre Shared Key. 698 It is an EAP method proposed by F. Bersani (France Telecom R&D). 700 The first version of it was proposed in January 2004 as an individual 701 Internet-Draft: draft-bersani-eap-psk-00.txt. 703 Version 01 published February 2004 is still to be found on the 704 Internet. 706 It is an EAP method based on symmetric cryptography. Its main design 707 goals are: 708 o Simplicity: It should be easy to implement and to deploy without 709 any pre-existing infrastructure 710 o Wide applicability: It should be possible to use this method to 711 authenticate over any network. In particular, it should be 712 suitable for IEEE 802.11 [IEEE 802.11] wireless LANs and thus 713 comply to IEEE 802 EAP Method Requirements for Wireless LANs 714 [IEEE 802REQ] 715 o Security: It should be conservative in its cryptographic design 716 and enjoy security proofs 717 o Extensibility: It should be possible to add to this method the 718 required extensions as their need appears 719 o Patent-avoidance: It should be free of any Intellectual Property 720 Right claims 722 It views itself as the successor of EAP-Archie. 724 It is intended to stimulate the debate on EAP-MD5 replacement and to 725 be a proposal for such a replacement. 727 2.17 EAP-SKE 729 EAP-SKE stands for EAP Shared Key Exchange. 731 It is an EAP method proposed by L. Salgarelli (Bell Labs, Lucent 732 Technologies) as the editor and many other co-authors. 734 The first version of it was proposed in November 2001 as an 735 individual Internet-Draft: draft-salgarelli-pppext-eap-ske-00.txt. 737 Version 01 published April 2002, version 02 published November 2002 738 and version 03 published May 2003 are still to be found on the 739 Internet. Hints to a version 04 may be found on the Internet but I 740 did not manage to find the corresponding draft. 742 It is an EAP method based on symmetric cryptography. Its main focus 743 is, in my opinion, network efficiency in roaming situations. 745 Work is going on between the authors of EAP-SKE and EAP-PSK to see if 746 forces could be joined to produce a common proposal for a shared key 747 method to the community [EAP-SKE]. 749 2.18 EAP-SSC 751 SSC stands for Secured Smartcard Channel 753 It is an EAP method proposed by P.Urien and M. Dandjinou (ENST). 755 The first version of it was proposed in December 2003 under the title 756 "EAP-SSC Secured Smartcard Channel " as an individual Internet-Draft: 757 draft-urien-eap-ssc-00.txt. 759 Version 01 published June 2004 is still to be found on the Internet. 761 This document describes a means of setting up an EAP secured channel 762 between a smart card and an Authentication Server as well according 763 to an asymmetric key exchange model as a symmetric key exchange 764 model. This channel would permit to convey securely all other types 765 of payload between the smart card and the authentication server. 767 It is not clear what exactly makes the content of this document 768 specific to a smart card. It seems to me as though the proposed 769 protocol could be viewed as a generic symmetric and asymmetric 770 cryptography EAP method. If so, the proposed cryptographic mechanism 771 would require, in my opinion, expert review and justification to back 772 up their soundness since new mechanisms seem to be introduced without 773 justification. In addition, further investigation would be needed to 774 assess the pros and cons of this protocol. 776 3. Conclusion 778 3.1 The different existing shared key EAP methods 780 This section attempts to provide a summary of the pros and cons of 781 the existing shared key EAP methods listed in section 2. 783 EAP-MD5 has several security flaws that cannot be tolerated in the 784 new environments where EAP is intended to be used like WLANs (e.g. no 785 mutual authentication, no key derivation and high vulnerability to 786 active brute-force/dictionary attacks). However, it has some nice 787 features that might be worth keeping in mind: it is standardized and 788 it is simple. 790 EAP-Cisco Wireless also has security flaws that should not be 791 tolerated in the new environments where EAP is intended to be used 792 like WLANs and it is an undocumented proprietary method. However, it 793 should be remembered as a proof of the need for a shared key EAP 794 method as well as the feasibility of such a method. 796 MS-EAP-Authentication and EAP MSCHAPv2 unfortunately inherit, like 797 EAP-Cisco Wireless, the intolerable security flaws of the protocol 798 they are based on, namely MS-CHAPv2. A nice feature though to retain 799 from these methods is the password aging and changing process. 801 EAP-MD5 Tunneled Authentication Protocol also inherit the weaknesses 802 of EAP-MD5 and therefore cannot compete for its replacement. 804 EAP-SIM and EAP-AKA are not, in their design intention, generic 805 shared key EAP methods. However in case, one wants to use them as 806 such, EAP-SIM should be dropped in favor of EAP-AKA which is more 807 evolved. Whether EAP-AKA could or should be reused as a generic 808 shared key EAP method will be further investigated in the following 809 versions of this draft, although the current feeling is that it 810 should not. 812 EAP-HTTP Digest is a method designed to cope with legacy devices and 813 protocols that is not publicly specified. It should therefore not 814 impact the drafting of a replacement for EAP-MD5. 816 EAP-SRP and EAP-SPEKE are two very interesting methods for the 817 drafting of a replacement for EAP-MD5 that use evolved cryptography 818 to very efficiently deal with passwords. Further investigation is 819 needed to assess whether or not such efficiency with passwords is 820 required from a security point of view and whether it is possible to 821 move forward with such techniques while avoiding IPR claims. 823 EAP-FAST is also an interesting method to take into account. However 824 some choices it made seem to have been driven by a will to deal with 825 legacy devices and infrastructures (e.g. reusing MS-CHAPv2). Further 826 investigation is needed to determine whether dealing with legacy 827 equipment should be a goal in the drafting of a replacement for EAP- 828 MD5. EAP-FAST also provide fragmentation support. This leads to 829 raising the question whether fragmentation support should be 830 supported by the replacement of EAP-MD5 (the answer might be yes in 831 my opinion since fragmentation support can probably be easily added 832 and leaves the method open for future extensions that could require 833 payloads larger than the MTU). 835 EAP-IKEv2 definitely requires further investigation to better 836 understand IKEv2 design goals and features and whether they suit EAP 837 well. 839 EAP-LDAP alludes to the possible problems that might arise when using 840 a standard existing database to store the users' credentials. 841 Similarly to EAP-FAST, further investigation is needed to see if 842 dealing with legacy devices and infrastructures should be a design 843 goal and if yes, how to deal with them. 845 EAP SSC needs further investigation to better understand its goals 846 and its capabilities as well as the security level it provides. 848 EAP GSS needs further investigation to assess to what extent it could 849 be used in conjunction with a GSS-API mechanism to be specified to 850 replace EAP MD5. The nice idea behind EAP GSS is the use of a generic 851 API to access a range of different authentication mechanisms, 852 although this might be redundant with EAP itself. 854 Hopefully, EAP-PSK (which may be considered EAP-Archie's successor 855 since EAP-Archie will not be further developed) and EAP-SKE will be 856 merging to propose a base draft to the community for replacing EAP- 857 MD5. It is believed to have a sound security basis as well as a 858 simple and extensible design. 860 3.2 General conclusion on shared key EAP methods 862 There is a wide range of existing shared key EAP methods which is 863 good since it demonstrates the creativity of the community but is 864 also dangerous since it first dilutes the review effort of the 865 community which might result in flawed or broken protocols and second 866 it does not help to provide interoperability. 868 Thanks to all the good ideas contained in the drafts mentioned in the 869 precedent section, it seems to be quite possible to draft a standard 870 replacement for EAP-MD5 that would retain the best of all worlds, 871 provided the community shows interest in doing so. 873 Further work is needed to better assess the status of the different 874 drafts mentioned in the precedent section and understand their pros 875 and cons (especially those of EAP-AKA, EAP-FAST, SRP-SHA1, EAP-SPEKE, 876 EAP GSS, EAP-PSK and EAP SSC). Hopefully, this will be done in future 877 versions of this document. 879 Most drafts do not comply to EAPbis or EKMF which understandable 880 since those documents were themselves evolving. 882 It would be a good idea to clarify the relationship between shared 883 key EAP methods and OTP methods (since they both tend to use the same 884 symmetric cryptography credentials). Hopefully, this will be done in 885 future versions of this document. 887 3.3 Miscellaneous conclusions 889 Similar unification work could be done in the following areas: 891 o OTP EAP methods (in case, they are deemed essentially different 892 from EAP methods as a result of the further investigations 893 announced in the previous subsection) 894 o Biometrics EAP method (since like OTP EAP methods, there are 895 numerous candidates available, yet none has acquired the 896 maturity and extent of a widespread standard) 897 o Public key EAP methods (although EAP-TLS has already emerged as 898 a standard) 899 o Hybrid methods (i.e. using public key on one side and private 900 key on the other side) 902 Such work could improve the quality of the methods and help users 903 find they way through the myriads of EAP methods! 905 4. Review of the non shared key EAP methods 907 The EAP methods presented here have been included for the sake of 908 completeness: they are deemed totally irrelevant for the drafting of 909 a replacement for EAP-MD5. 911 4.1 EAP-OTP 913 EAP-OTP stands for one-time password. 915 Please refer to [EAP] and [EAPbis] for a description of EAP-OTP, 916 which is thus a standardized method. 918 This EAP method has been defined for use with one-time password 919 systems. 921 Unfortunately, this method is quite simplistic and outdated (see for 922 instance the security claims in [EAPbis]). Therefore, this method is, 923 in my opinion, only specified for legacy reasons and its security and 924 functionality levels do not match the current requirements. 926 4.2 EAP-GTC 928 EAP-GTC stands for generic token card. 930 Please refer to [EAP] and [EAPbis] for a description of EAP-GTC, 931 which is thus a standardized method. 933 This EAP method has been defined for use with various token card 934 implementations that require user input. It consists in a challenge 935 (containing a displayable message) and a response (containing the 936 data entered by the user from the token card). 938 Unfortunately, this method is so simplistic and outdated (since in 939 only a round-trip, it is quite hard to provide a good level of 940 security - see for instance the security claims in [EAPbis]) that 941 many token cards have chosen to develop their own methods (see e.g. 942 section 4.8). Therefore, this method is, in my opinion, only 943 specified for legacy reasons and its security and functionality 944 levels do not match the current requirements. 946 4.3 EAP RSA Public Key Authentication 948 EAP-RSA PKA stands for EAP RSA Public Key Authentication Protocol. 950 It is an EAP method proposed by William T. Whelan (Network Express 951 and later Cabletron Systems). 953 The first version of it was proposed in November 1995 as a PPPEXT WG 954 Internet-Draft: draft-ietf-pppext-eaprsa-00.txt. 956 Version 01 published February 1996, version 02 published February 957 1996, Version 03 published January 1997 and Version 03 published 958 January 1997 are still to be found on the Internet. 960 EAP-RSA PKA is an EAP method that has been allocated EAP Type 9 by 961 IANA. 963 It is an EAP method based on asymmetric cryptography and the 964 unilateral two pass authentication described in ISO/IEC 9798-3. 966 It seems to be subject to patents by RSA Security, see 967 http://www.ietf.org/ietf/IPR/pppext-eaprsa 969 This method does not seem to be maintained any more. 971 4.4 EAP-DSS 973 EAP-DSS stands for EAP DSS Public Key Authentication Protocol and DSS 974 stands for Digital Signature Standard. 976 It is an EAP method proposed by William A. Nace (NSA) and James E. 977 Zmuda(SPYRUS). 979 The first version of it was proposed in November 1997 as a PPPEXT WG 980 Internet-Draft: draft-ietf-pppext-eapdss-00.txt. 982 Version 01 published December 1997 is still to be found on the 983 Internet. Hints to a version 02 may be found on the Internet but I 984 did not manage to find the corresponding draft. 986 EAP-DSS is an EAP method that has been allocated EAP Type 10 (Under 987 the name DSS Unilateral) by IANA. 989 It is an EAP method that uses asymmetric cryptography (namely the 990 DSA) and is based on unilateral two pass authentication as described 991 in NIST FIPS PUB 196 "Standard for Public Key Cryptographic Entity 992 Authentication Mechanisms". 994 This method does not seem to be maintained any more. 996 4.5 EAP-KEA 998 EAP-KEA stands for EAP KEA Public Key Authentication Protocol and KEA 999 stands for Key Exchange Algorithm. 1001 It is an EAP method proposed by William A. Nace (NSA), Peter Yee and 1002 James E. Zmuda (both of SPYRUS). 1004 The first version of it was proposed in November 1997 as a PPPEXT WG 1005 Internet-Draft: draft-ietf-pppext-eapkea-00.txt. 1007 Version 01 published December 1997 is still to be found on the 1008 Internet. Hints to a version 02 may be found on the Internet but I 1009 did not manage to find the corresponding draft. 1011 EAP-KEA is an EAP method that has been allocated EAP Types 11 and 12 1012 by IANA. 1014 It is an EAP method that uses asymmetric cryptography (namely Diffie- 1015 Hellman). 1017 This method does not seem to be maintained any more. 1019 4.6 EAP-TLS 1021 Please refer to [EAP-TLS] for a description of this method. 1023 EAP-TLS is an EAP method that has been allocated EAP Type 13 (by 1024 IANA. 1026 EAP-TLS is an EAP method based on asymmetric cryptography reusing TLS 1027 mechanisms. 1029 4.7 Defender Token (AXENT) 1031 Defender Token (AXENT) is an EAP method that has been registered to 1032 IANA by Michael Rosselli (Axent). 1034 It is an undocumented EAP method. The contact information indicated 1035 in IANA is outdated (AXENT has been merged to Symantec then sold to 1036 Passgo). Information request has been requested to Passgo which 1037 kindly provided some ([Defender]). 1039 Defender Token (AXENT) is an EAP method that has been allocated EAP 1040 Type 34 by IANA. 1042 The Defender Token (AXENT) EAP method was never completed. PassGo 1043 Technologies may continue this development at some point in the 1044 future but there are no immediate plans to do so at present. 1046 4.8 RSA Security SecurID EAP and SecurID EAP 1048 Two EAP types have been allocated by IANA for RSA SecurID 1049 authentication: type 15 and type 32. 1051 Some documentation on these methods have been kindly communicated by 1052 [RSA SecurID]. 1054 EAP type 15 was developed for use with RSA Security clients and 1055 Agents on the Windows platform. It is proprietary and may remain that 1056 way. 1058 Seeing the need for an open EAP type to support RSA Tokens, EAP type 1059 32 has been reserved. 1061 It is an EAP method proposed by S. Josefsson (RSA Security). 1063 The first version of it was proposed in January 2002 as an individual 1064 Internet-Draft: draft-josefsson-eap-securid-00.txt. 1066 Version 01 published February 2002 is still to be found on the 1067 Internet. Hints to a version 02 may be found on the Internet but I 1068 did not manage to find the corresponding draft. 1070 Temporarily there does not seem to be any (public) work done is this 1071 method any more. 1073 Both methods are basically OTP methods that rely on the RSA SecurID 1074 authentication token. 1076 4.9 Arcot systems EAP 1078 Arcot systems EAP is an EAP method that has been registered to IANA 1079 by Rob Jerdonek (Arcot). 1081 It is an undocumented EAP method. Information has been requested from 1082 Arcot but no answer has yet been obtained. 1084 Arcot systems EAP is an EAP method that has been allocated EAP Type 1085 16 by IANA. 1087 Arcot systems EAP is an EAP method that probably relies on a OTP 1088 scheme using a software authentication token. It should therefore not 1089 compete as a replacement for EAP-MD5 (see [Arcot] for general 1090 information). 1092 4.10 EAP-TTLS 1094 EAP-TTLS stands for EAP Tunneled TLS Authentication Protocol. 1096 It is an EAP method proposed by Paul Funk (Funk Software) and Simon 1097 Blake-Wilson (Certicom). 1099 The first version of it was proposed in August 2001 as a PPEXT WG 1100 Internet-Draft: draft-ietf-pppext-eap-ttls-00.txt. 1102 Version 01 published February 2002, version 02 published November 1103 2002, version 03 published August 2003 are still to be found on the 1104 Internet. Hints to a version 04 may be found on the Internet but I 1105 did not manage to find the corresponding draft. 1107 EAP-TTLS is an EAP method that has been allocated EAP Type 21 by 1108 IANA. 1110 EAP-TTLS is an EAP method based on asymmetric cryptography reusing 1111 TLS mechanisms. In EAP-TTLS, the TLS handshake may be mutual; or it 1112 may be one-way, in which only the server is authenticated to the 1113 client. The secure connection established by the handshake may then 1114 be used to allow the server to authenticate the client using 1115 existing, widely-deployed authentication infrastructures such as 1116 RADIUS. The authentication of the client may itself be EAP, or it may 1117 be another authentication protocol such as PAP, CHAP, MS-CHAP or MS- 1118 CHAP-V2. 1120 4.11 Remote Access Service 1122 Remote Access Service is an EAP method that has been registered to 1123 IANA by Steven Fields (Identix). 1125 It is an undocumented EAP method. Information has been requested from 1126 Identix but no answer has yet been obtained. 1128 Remote Access Service is an EAP method that has been allocated EAP 1129 Type 22 by IANA. 1131 It is not clear to me how this EAP method works (though it probably 1132 relies on biometrics, see [Identix] for general information). 1134 4.12 EAP-3Com Wireless 1135 EAP-3Com Wireless is an EAP method that has been registered to IANA 1136 by Albert Young (3com). 1138 It is an undocumented EAP method. Information has been requested from 1139 but no answer has yet been obtained (the contact information 1140 indicated in IANA is outdated). 1142 EAP-3Com Wireless is an EAP method that has been allocated EAP Type 1143 24 by IANA. 1145 It is not clear to me how this EAP method works (See [3com] for 1146 general information). 1148 4.13 PEAP 1150 PEAP stands for Protected Extensible Authentication Protocol. 1152 It is an EAP method proposed by H. Andersson (RSA Security), S. 1153 Josefsson (RSA Security and later Extundo), Glen Zorn and Hao Zhou 1154 (Cisco), Dan Simon and Ashwin Palekar (Microsoft). 1156 The first version of it was proposed in August 2001 as an individual 1157 Internet-Draft under the title "Protecting EAP with TLS (EAP-TLS- 1158 EAP)": draft-josefsson-pppext-eap-tls-eap-00.txt. 1160 Version 01 published October 2001, version 02 published February 1161 2002, version 03 published September 2002, version 04 published 1162 September 2002, version 05 published September 2002, version 06 1163 published March 2003, version 07 published October 2003 are still to 1164 be found on the Internet. 1166 PEAP is an EAP method based on asymmetric cryptography reusing TLS 1167 mechanisms that has been allocated EAP Type 25 by IANA. 1169 PEAP is an EAP method based on asymmetric cryptography reusing TLS 1170 mechanisms which provides an encrypted and authenticated tunnel based 1171 on transport layer security (TLS) that encapsulates EAP 1172 authentication mechanisms. PEAP uses TLS to protect against rogue 1173 authenticators, protect against various attacks on the 1174 confidentiality and integrity of the inner EAP method exchange and 1175 provide EAP peer identity privacy. EAP also provides support for 1176 chaining multiple EAP mechanisms, cryptographic binding between 1177 authentications performed by inner EAP mechanisms and the tunnel, 1178 exchange of arbitrary parameters (TLVs), optimized session 1179 resumption, and fragmentation and reassembly. 1181 Regarding IPR, some IPR claims seem to be related to EAP-FAST, please 1182 refer to: http://www.ietf.org/ietf/IPR/MICROSOFT-PEAP.txt 1184 4.14 EAP-MAKE 1186 EAP-MAKE stands for EAP Mutual Authentication with Key Exchange. 1188 It is an EAP method proposed by R. Berrendonner and H. Chabanne (both 1189 of Sagem). 1191 The first version of it was proposed in September 2001 as an 1192 individual Internet-Draft: draft-berrendo-chabanne-pppext-eapmake- 1193 00.txt. 1195 Version 01 published October 2001 is still to be found on the 1196 Internet. Hints to a version 02 may be found on the Internet but I 1197 did not manage to find the corresponding draft. 1199 EAP-MAKE is an EAP method that has been allocated EAP Type 27 by 1200 IANA. 1202 It is an EAP method inspired by EAP-KEA that uses asymmetric 1203 cryptography (namely Diffie-Hellman). 1205 This method does not seem to be maintained any more. 1207 4.15 CRYPTOcard 1209 CRYPTOcard is an EAP method that has been registered to IANA by 1210 Stephen Webb (Cryptocard). 1212 It is an undocumented EAP method. Information has been requested from 1213 CRYPTOcard but no answer has yet been obtained (there seemed to be a 1214 problem with the mail box of the contact indicated by IANA and no 1215 answer was yet obtained from the general support). 1217 CRYPTOcard is an EAP method that has been allocated EAP Type 28 by 1218 IANA. 1220 It is not clear to me how this EAP method works (it is probably an 1221 EAP method that relies on an authentication token, see [CRYPTOcard] 1222 for general documentation). 1224 4.16 DynamID 1226 DynamID is an EAP method that has been registered to IANA by P. 1227 Merlin (SCrypto). 1229 It is an undocumented EAP method, though some elements were kindly 1230 provided by [DynamID].. 1232 DynamID is an EAP method that has been allocated EAP Type 30 by IANA. 1234 It is an EAP method that uses asymmetric key cryptography (namely 1235 digital certificates stored on smart cards). It is a challenge- 1236 response method that only provides client authentication. This method 1237 also provides key derivation. 1239 4.17 Rob EAP 1241 Rob EAP is an EAP method that has been registered to IANA by Sana 1242 Ullah. 1244 It is an undocumented EAP method. Information has been requested from 1245 Sana Ullah but no answer has yet been obtained. 1247 Rob EAP is an EAP method that has been allocated EAP Type 31 by IANA. 1249 It is not clear to me how this EAP method works (I found absolutely 1250 no information on it!). 1252 4.18 MS-Authentication TLV 1254 TLV stands for Type-Length-Value. 1256 It is an EAP method proposed by T. Hiller (Lucent), A. Palekar 1257 (Microsoft) and G. Zorn (Cisco). 1259 The first version of it was proposed in October 2002 under the title 1260 "A Container Type for the Extensible Authentication Protocol (EAP)" 1261 as an individual Internet-Draft: draft-hiller-eap-tlv-00.txt. 1263 Version 01 published May 2003 is still to be found on the Internet. 1264 Hints to a version 02 may be found on the Internet but I did not 1265 manage to find the corresponding draft. 1267 MS-Authentication TLV is an EAP method that has been allocated EAP 1268 Type 33 (Under the name DSS Unilateral) by IANA. 1270 It is not really an authentication method but a proposed solution to 1271 some issues that arose within the EAP WG. 1273 4.19 SentriNET 1275 SentriNET is an EAP method that has been registered to IANA by J. 1276 Kelleher (ISL Biometrics). 1278 It is an undocumented EAP method, though some elements were kindly 1279 provided by [SentriNET]. 1281 SentriNET is an EAP method that has been allocated EAP Type 34 by 1282 IANA. 1284 SentriNET (per se, not the EAP method that bears the same name) is a 1285 biometric middleware product which adds biometrics to existing user 1286 accounts in their native location (e.g. NT SAM accounts, Active 1287 Directory, LDAP entries or entries in a database for web 1288 applications). Management and checking of these biometrics is 1289 similarly integrated (e.g. MMC and GINA for Microsoft Windows 1290 2000/XP, ...). 1292 SentriNET (the EAP method) is a method designed to extend the 1293 biometric logon available to local users to remote access via a NAS 1294 or VPN. 1296 SentriNET (the EAP method) remains proprietary with no plans for 1297 publication in the near future. Its basic operation involves the 1298 supplying of a user name to the server which checks which biometrics 1299 have been enrolled and returns information on the appropriate 1300 hardware types to the client, the client captures a live biometric on 1301 a suitable device and returns it to the server for matching. 1303 4.20 EAP-Actiontec Wireless 1305 EAP-Actiontec Wireless is an EAP method that has been registered to 1306 IANA by Victor Chang (Actiontec) 1308 It is an undocumented EAP method. Information has been requested from 1309 Actiontec but no answer has yet been obtained. 1311 EAP-Actiontec Wireless is an EAP method that has been allocated EAP 1312 Type 35 by IANA. 1314 It is not clear to me how this EAP method works (see [Actiontec] for 1315 general documentation). 1317 4.21 Cogent systems biometrics authentication EAP 1319 Cogent systems biometrics authentication EAP is an EAP method that 1320 has been registered to IANA by John Xiong (Cogent systems) 1322 It is an undocumented EAP method. Information has been requested from 1323 Cogent systems but no answer has yet been obtained. 1325 Cogent systems biometrics authentication EAP is an EAP method that 1326 has been allocated EAP Type 36 by IANA. 1328 It is not clear to me how this EAP method works though it probably 1329 relies on biometrics (see [Cogent] for general documentation). 1331 4.22 AirFortress EAP 1333 AirFortress EAP is an EAP method that has been registered to IANA by 1334 Richard Hibbard (Fortress technologies) 1336 It is an undocumented EAP method. Information has been requested from 1337 Fortress technologies but no answer has yet been obtained. 1339 AirFortress EAP is an EAP method that has been allocated EAP Type 37 1340 by IANA. 1342 It is not clear to me how this EAP method works (see [Airfortress] 1343 for general documentation). 1345 4.23 Securesuite EAP 1347 Securesuite EAP is an EAP method that has been registered to IANA by 1348 Matt Clements (Iosoftware). 1350 It is an undocumented EAP method. Information has been requested from 1351 Iosoftware but no answer has yet been obtained. 1353 Securesuite EAP is an EAP method that has been allocated EAP Type 39 1354 by IANA. 1356 It is not clear to me how this EAP method works (see [Securesuite] 1357 for general documentation). 1359 4.24 DeviceConnect EAP 1361 DeviceConnect EAP is an EAP method that has been registered to IANA 1362 by David Pitard (Phoenix). 1364 It is an undocumented EAP method. Information has been requested from 1365 Phoenix but no answer has yet been obtained. 1367 DeviceConnect EAP is an EAP method that has been allocated EAP Type 1368 40 by IANA. 1370 It is not clear to me how this EAP method works (see [DeviceConnect] 1371 for general documentation). 1373 4.25 EAP-MOBAC 1375 EAP-MOBAC is an EAP method that has been registered to IANA by T. 1376 Rixom (Alfa-Ariss). 1378 It is an undocumented EAP method, though some elements were kindly 1379 provided by [EAP-MOBAC]. 1381 EAP-MOBAC is an EAP method that has been allocated EAP Type 42 by 1382 IANA. 1384 It is an EAP method that is basically OTP via SMS. It thus requires a 1385 special infrastructure (gateway to the SMS system and OTP server) and 1386 is therefore not a possible candidate for EAP-MD5 replacement. 1388 4.26 ZoneLabs EAP (ZLXEAP) 1390 ZoneLabs EAP is an EAP method that has been registered to IANA by D. 1391 Bogue (ZoneLabs). 1393 It is an undocumented EAP method, though some elements were kindly 1394 provided by [ZoneLabs]. 1396 ZoneLabs EAP is an EAP method that has been allocated EAP Type 44 by 1397 IANA. 1399 It is an EAP method that should augment shared key EAP methods, not 1400 replace them. 1401 4.27 EAP Bluetooth Application 1403 EAP Bluetooth Application is an EAP method proposed by H. Kim 1404 (INRIA), H. Afifi (INT) and M. Hayashi (Hitachi). 1406 The first version of it was proposed in February 2004 as an 1407 individual Internet-Draft under the title "EAP Bluetooth 1408 Application": draft-kim-eap-bluetooth-00. 1410 EAP Bluetooth Application is not an authentication method but rather 1411 a way to help to Bluetooth devices set up a secure channel thanks to 1412 EAP authentication through a IEEE 802.11 interface of one of the 1413 devices. It therefore merely tunnels other EAP authentication methods 1414 for what regards authentication. 1416 4.28 EAP-GPRS 1418 GPRS stands for General Packet Radio Service (it is a concept 1419 imported from the GSM world). 1421 It is an EAP method proposed by A. Salkintzis (Motorola). 1423 The first version of it was proposed in December 2002 under the title 1424 "The EAP GPRS Protocol" as an individual Internet-Draft: draft-salki- 1425 pppext-eap-gprs-00.txt. 1427 Version 01 published June 2003 and version 02 published January 2004 1428 are still to be found on the Internet. 1430 EAP-GPRS specifies an extension to EAP which allows GPRS clients to 1431 perform signaling procedures with a core GPRS network through devices 1432 that enforce EAP-based access control. For example, a GPRS client can 1433 use EAP-GPRS to attach to a GPRS network through an access point that 1434 enforces IEEE 802.1X access control. In this case, the GPRS attach 1435 signaling is performed in the context of the underlying 802.1X 1436 procedure and the GPRS messages are encapsulated into EAP-GPRS 1437 packets. If the GPRS client is permitted to attach to the GPRS 1438 network, then the 802.1X procedure ends successfully and the client 1439 is authorized access to the access point. In general, EAP-GPRS allows 1440 any type of signaling to take place during the EAP authentication as 1441 an embedded signaling procedure. 1443 It is not really an authentication method but rather a new transport 1444 mechanism for higher-layer protocols. 1446 4.29 EAP support in smart cards 1448 EAP support in smart cards is an EAP method proposed by P. Urien 1449 (ENST), A. J. Farrugia (CSI), G. Pujolle (LIP6), J. Abellan (Axalto) 1450 and M. de Groot (Gemplus). 1452 The first version of it was proposed in October 2002 as an individual 1453 Internet-Draft under the title "EAP support in smartcards ": draft- 1454 urien-eap-smartcard-00.txt. 1456 Version 01 published February 2003, version 02 published June 2003, 1457 version 03 published September 2003 and version 04 published February 1458 2004 are still to be found on the Internet. 1460 EAP support in smart cards is not an authentication method but rather 1461 describes the interface to the EAP protocol in smart cards, which 1462 could store multiple identities associated to Network Access 1463 Identifiers. It therefore merely tunnels other EAP authentication 1464 methods for what regards authentication. 1466 4.30 EAP-TLS SASL 1468 SASL stands for Simple Authentication and Security Layer. 1470 It is an EAP method proposed by H. Andersson and S. Josefsson (RSA 1471 Security). 1473 The first version of it was proposed in June 2001 under the title 1474 "EAP Mechanism using TLS and SASL (Version 1)" as an individual 1475 Internet-Draft: draft-andersson-eap-tls-sasl-00.txt. 1477 Hints to a version 01 may be found on the Internet but I did not 1478 manage to find the corresponding draft. 1480 The development of this method seem to have been stopped as its 1481 authors moved to work on PEAP (please refer to section 4.13). 1483 5. IANA considerations 1485 This document does not introduce any new IANA consideration. 1487 6. Security considerations 1489 This document does not introduce any new security issue for the 1490 Internet. 1492 7. Acknowledgements 1494 Many thanks to the EAP WG chairs (J. Arkko and B. Aboba) for 1495 motivating this work, to Laurent Butti, Olivier Charles, Aurelien 1496 Magniez and Jerome Razniewski for their feedback and to all those 1497 mentioned in the References section that kindly took some time to 1498 answer some of my questions! 1500 Special thanks to Henri Gilbert for some related cryptographic 1501 discussions on shared key EAP methods. 1503 8. References 1505 [Actiontec] http://www.actiontec.com 1507 [AirFortress] http://www.fortresstech.com/ 1509 [Arcot] http://www.arcot.com/ 1511 [CHAP] Simpson, W., "PPP Challenge Handshake Authentication 1512 Protocol (CHAP)", RFC 1994, August 1996. 1514 [Cogent] http://www.cogentsystems.com/cogent/cogenthome.html 1516 [CRYPTOcard] http://www.cryptocard.com/ 1518 [Defender] Peter Cooke, PCooke@passgo.com, 1519 Personal communication, March 2004 1521 [DeviceConnect] http://www.phoenix.com/en/products 1522 /phoenix+deviceconnect/default1.htm 1524 [Dynamid] P Merlin (Scrypto), pmerlin@scrypto.fr, 1525 Personal Communication, March 2004 1527 [EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible 1528 Authentication Protocol (EAP)", RFC 2284, March 1998. 1530 [EAP-Archie] Russ Housley and Jesse Walker, 1531 Personal communications, February 2004 1533 [EAPbis] Blunk, L. et al., "Extensible Authentication Protocol 1534 (EAP)", Internet-Draft (work in progress), February 1535 2004, http://ietf.levkowetz.com/drafts/eap 1536 /rfc2284bis/draft-ietf-eap-rfc2284bis-09.txt 1538 [EAPHTTPDigest] O. Tavakoli (Funk Software), radagast@funk.com, 1539 Personal Communication, March 2004 1541 [EAPIssues] EAP Open issues list, 1542 http://www.drizzle.com/~aboba/EAP/eapissues.html 1544 [EAP-METHSTAT1] Aboba B., "EAP and AAA update", NIST 802.11 security 1545 workshop, December 2002, 1546 http://csrc.nist.gov/wireless 1547 /S12_NIST-IETFpart2--ba.pdf 1549 [EAP-METHSTAT1] Arkko J. and Aboba, B., "EAP WG Methods Update", 1550 IETF 59, March 2004, 1551 http://www.arkko.com/publications/eap 1552 /ietf-59/ietf59_eap_methstatus.ppt 1554 [EAP-MOBAC] T. Rixom (Alfa-Ariss), tom.rixom@alfa-ariss.com, 1555 Personal Communication, March 2004 1557 [EAP-PSK] Bersani, F., "The EAP-PSK protocol", Internet-Draft 1558 (work in progress), February 2004, 1559 draft-bersani-eap-psk-01.txt 1561 [EAP-SKE] Luca Salgarelli, Uri Blumenthal and Semyon 1562 Mizikovski, Personal communications, 1563 February and March 2004 1565 [EAP-SKMDTEMPL] Bersani, F., " EAP shared key methods documentation 1566 template", Internet-Draft (work in progress), 1567 March 2004, 1568 draft-bersani-eap-sharedkeymethods-doctemplate-00.txt 1570 [EAP-TLS] Aboba, B., Simon, D., "PPP EAP TLS Authentication 1571 Protocol", RFC 2716, October 1999. 1573 [EKMF] Aboba, B. et al., "EAP Key Management Framework", 1574 Internet-Draft (work in progress), October 2003, 1575 draft-ietf-eap-keying-01.txt 1577 [HTTP-Digest] Franks, J. et al., "HTTP Authentication: Basic and 1578 Digest Access Authentication", RFC 2617, June 1999 1580 [IANA] Internet Assigned Numbers Authority, "Point-to-Point 1581 Protocol Field Assignments/PPP EAP Request/Response 1582 Types", http://www.iana.org/assignments/ppp-numbers 1584 [Identix] http://www.identix.com/ 1586 [IEEE 802.1X] IEEE STD 802.1X, Standards for Local and Metropolitan 1587 Area Networks: Port Based Access Control, June 14, 1588 2001 1590 [IEEE 802.11] Institute of Electrical and Electronics Engineers, 1591 "Information Technology - Telecommunications and 1592 Information Exchange between Systems - Local and 1593 Metropolitan Area Network - Specific Requirements � 1594 Part 11: Wireless LAN Medium Access Control (MAC) and 1595 Physical Layer (PHY) Specifications", IEEE Standard 1596 802.11 1598 [IEEE 802REQ] Stanley, Dorothy et al., �EAP Method Requirements for 1599 Wireless LANs�, Internet-Draft (work in progress), 1600 January 2004, draft-walker-ieee802-req-00.txt 1602 [LEAP] Macnally, C., �Cisco LEAP protocol description�, 1603 September 2001 1605 [LEAPVUL] Wright, J., �Weaknesses in LEAP Challenge/Response�, 1606 Defcon 2003 1608 [MDx] Preneel, B. and van Oorschot P. C., 1609 "MDx-MAC and Building Fast MACs from Hash Functions", 1610 Proceedings of Crypto'95, Springer-Verlag, LNCS, 1611 August 1995 1613 [MSCHAPVUL] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's 1614 PPTP Authentication Extensions (MS-CHAPv2)", 1615 CQRE '99, Springer-Verlag, 1999, 1616 http://www.schneier.com/paper-pptpv2.pdf 1618 [PPP] Simpson, W., Editor, "The Point-to-Point Protocol 1619 (PPP)", STD 51, RFC 1661, July 1994. 1621 [RSA SecurID] D. Liberman (RSA Security), 1622 dliberman@rsasecurity.com, Personal Communication, 1623 March 2004 1625 [Securesuite] http://www.iosoftware.com/pages/Products 1626 /SecureSuite%20XS/index.asp 1628 [SentriNET] J. Kelleher (ISL Biometrics), 1629 joe.kelleher@isl-biometrics.com, 1630 Personal Communication, March 2004 1632 [SRP] The Stanford SRP Authentication Project, 1633 http://srp.stanford.edu/ 1635 [SRPpres] Wu, T., "Secure Remote Password Authentication", 1636 NDSS 98 , http://srp.stanford.edu/ndss98s.ps 1638 [ZoneLabs] D. Bogue (ZoneLabs), dbogue@zonelabs.com, 1639 Personal Communication, March 2004 1641 [3com] http://www.3com.com 1643 9. Authors' Addresses 1645 Florent Bersani florent.bersani@francetelecom.com 1646 France Telecom R&D 1647 38, rue du General Leclerc 1648 92794 Issy Les Moulineaux Cedex 9 1649 France 1651 10. Full Copyright Statement 1653 Copyright (C) The Internet Society (2004). All Rights Reserved. 1655 This document and translations of it may be copied and furnished to 1656 others, and derivative works that comment on or otherwise explain it 1657 or assist in its implementation may be prepared, copied, published 1658 and distributed, in whole or in part, without restriction of any 1659 kind, provided that the above copyright notice and this paragraph are 1660 included on all such copies and derivative works. However, this 1661 document itself may not be modified in any way, such as by removing 1662 the copyright notice or references to the Internet Society or other 1663 Internet organizations, except as needed for the purpose of 1664 developing Internet standards in which case the procedures for 1665 copyrights defined in the Internet Standards process must be 1666 followed, or as required to translate it into languages other than 1667 English. 1669 The limited permissions granted above are perpetual and will not be 1670 revoked by the Internet Society or its successors or assignees. 1672 This document and the information contained herein is provided on an 1673 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1674 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1675 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1676 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1677 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."