Internet Draft Florent Bersani File: draft-bersani-eap-synthesis- France Telecom R&D sharedkeymethods-00.txt Expires: October 2004 April 2004 EAP shared key methods: a tentative synthesis of those proposed so far Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The purpose of this draft is to gives a broad picture of the existing proposed EAP methods, with a focus on shared key EAP methods. Indeed, it is the belief of the author that a standard replacement for EAP- MD5 (that is deprecated due to security reasons) is needed. By listing the existing shared key EAP methods, the goal is to gather consensus that such a multiplication of methods is detrimental and that a single methods retaining the best of the existing proposals could and should be drafted. Bersani Expires û October 2004 [Page 1] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Table of Contents 1. Introduction..................................................4 1.1 Purpose of this document...................................4 1.2 Material used for this document............................4 1.3 Organization of this document..............................5 1.4 Caveats....................................................5 2. Review of the proposed shared key EAP methods.................6 2.1 EAP-MD5....................................................6 2.2 EAP-Cisco Wireless.........................................7 2.3 EAP-SIM....................................................7 2.4 SRP-SHA1...................................................8 2.5 EAP-AKA....................................................9 2.6 MS-EAP-Authentication.....................................10 2.7 EAP MSCHAP-V2.............................................10 2.8 EAP-HTTP Digest...........................................11 2.9 EAP-SPEKE.................................................11 2.10 EAP-FAST.................................................12 2.11 EAP-Archie...............................................13 2.12 EAP-GSS..................................................14 2.13 EAP-IKEv2................................................14 2.14 EAP-LDAP.................................................15 2.15 EAP-MD5 Tunneled Authentication Protocol.................15 2.16 EAP-PSK..................................................15 2.17 EAP-SKE..................................................16 2.18 EAP-SSC..................................................17 3. Conclusion...................................................17 3.1 The different existing shared key EAP methods.............17 3.2 General conclusion on shared key EAP methods..............19 3.3 Miscellaneous conclusions.................................19 4. Review of the non shared key EAP methods.....................20 4.1 EAP-OTP...................................................20 4.2 EAP-GTC...................................................20 4.3 EAP RSA Public Key Authentication.........................21 4.4 EAP-DSS...................................................21 4.5 EAP-KEA...................................................22 4.6 EAP-TLS...................................................22 4.7 Defender Token (AXENT)....................................22 4.8 RSA Security SecurID EAP and SecurID EAP..................23 4.9 Arcot systems EAP.........................................23 4.10 EAP-TTLS.................................................24 4.11 Remote Access Service....................................24 4.12 EAP-3Com Wireless........................................24 4.13 PEAP.....................................................25 4.14 EAP-MAKE.................................................26 4.15 CRYPTOcard...............................................26 4.16 DynamID..................................................26 4.17 Rob EAP..................................................27 4.18 MS-Authentication TLV....................................27 Bersani Expires û October 2004 [Page 2] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 4.19 SentriNET................................................27 4.20 EAP-Actiontec Wireless...................................28 4.21 Cogent systems biometrics authentication EAP.............28 4.22 AirFortress EAP..........................................29 4.23 Securesuite EAP..........................................29 4.24 DeviceConnect EAP........................................29 4.25 EAP-MOBAC................................................29 4.26 ZoneLabs EAP (ZLXEAP)....................................30 4.27 EAP Bluetooth Application................................30 4.28 EAP-GPRS.................................................30 4.29 EAP support in smart cards...............................31 4.30 EAP-TLS SASL.............................................31 5. IANA considerations..........................................32 6. Security considerations......................................32 7. Acknowledgements.............................................32 8. References...................................................32 9. Authors' Addresses...........................................35 10. Full Copyright Statement....................................35 Bersani Expires û October 2004 [Page 3] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 1. Introduction 1.1 Purpose of this document The Extensible Authentication Protocol (EAP) [EAP], provides an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP [PPP] or IEEE 802 thanks to the IEEE 802.1X [IEEE 802.1X] framework., without requiring IP. EAP supports many authentication mechanisms usually called EAP methods. The purpose of this draft is to gives a broad picture of the existing proposed EAP methods, with a focus on shared key EAP methods. Although this has already done before, see [EAP-METHSTAT1] and [EAP- METHSTAT2], it appeared worth doing the exercise thoroughly again with a view towards requesting the opening of a work item at IETF, namely replacing EAP-MD5. Indeed, EAP methods have proliferated but only 4 are currently standardized - namely EAP-MD5, EAP-OTP and EAP-GTC in [EAP] and EAP- TLS in [EAP-TLS]. Due new security requirements, expressed for instance in IEEE 802 EAP Method Requirements for Wireless LANs [IEEE 802REQ], EAP-MD5 has been deprecated: it does neither provide mutual authentication nor key derivation. However, no simple shared key EAP method seems to be widely available to replace EAP-MD5. In parallel to a proposition for such a replacement ([EAP-PSK]), a documentation effort has been undertaken (see [EAP-SKMDTEMPL]) to assess the different proposals, confirm that no standard replacement for EAP-MD5 exists and open the way for such a replacement by allowing comparison/merger of the existing related work. This document is the synthesis of this effort. 1.2 Material used for this document This document has been elaborated thanks to: o The responses received to [EAP-SKMDTEMPL] that was posted March 2004 to the EAP mailing list o Investigation of the PPP EAP Request/Response Types registered by IANA ([IANA]) o Investigation of the methods quoted in [EAP-METHSTAT2] Although it is the intention of the author of this document to gather all the material relevant to EAP methods on a single location on the Internet, the readers might want to use the following URLs to Bersani Expires û October 2004 [Page 4] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 retrieve documents mentioned in this document while the aforementioned location is still under construction: o http://www.potaroo.net/ietf/old-ids/ o http://www.watersprings.org/pub/id/ 1.3 Organization of this document Section 2 is devoted to briefly present and analyze each proposed shared key EAP method the author of this document is aware of. Following this review, conclusions are drawn in section 3. After a brief review of the methods studied in section 2 for the sake of clarity to allow the impatient reader to directly jump to section 3 without reading section 2, a tentative conclusion on shared key EAP methods in general and replacement of EAP-MD5 in particular is proposed in this section, followed by miscellaneous points on alternative subjects noted while writing this document. Section 4 is included for the sake of exhaustively and consists in a brief review of the other existing non shared key EAP methods. This review had to be done to ensure that the methods mentioned in this section were indeed not shared key methods and thus did not belong to section 2. Within section 2 and 4, the EAP methods have been listed starting by those who have been attributed an EAP type number by IANA presented in increasing type number order, followed by those who have not, presented in alphabetical order according to their name. The other sections are the typical ones of an Internet Draft. 1.4 Caveats Though, the intention of this document was mainly to document the existing shared key EAP methods, the borderline between documenting and commenting upon was sometimes blurred. This was further complicated by the obvious potential bias of the author (who is himself the author of a proposed shared key EAP method, EAP-PSK). As the draft may evolve, this will be clarified (i.e. the analysis parts will be more clearly separated from the documentation ones and will be deepened). In the meanwhile, the reader is advised to differentiate in this document between facts and what may be considered opinions. Comments to help separate facts from opinions as well as to include other opinions are more than welcome! In addition, gathering documentation and digesting it did not prove to be that simple. Hence, this document may unfortunately contain some errors. Readers are encouraged to report any error they feel Bersani Expires û October 2004 [Page 5] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 they have spotted (especially if they are authors of an EAP method and are dissatisfied with the treatment their method has received). It was especially difficult to find out whether a method was still being developed or not as well as whether a method had been implemented. Hopefully future versions of this draft will clarify this. Last, the reader not familiar with the Internet Draft process is reminded that this document is only (for now) the expression of the work of an individual and by no way the expression of a consensus of the community. It is however the intention of the author that this document evolve from the understanding and appreciation of a single person to the statement of the point of view of the community. 2. Review of the proposed shared key EAP methods This section presents the different existing shared key EAP methods the author is aware of. These methods have been a priori deemed relevant for the drafting of a replacement for EAP-MD5. 2.1 EAP-MD5 Please refer to [EAP] and [EAPbis] for a description of EAP-MD5, which is thus a standardized method. This method has also been widely implemented. EAP-MD5 must have been included in [EAPbis] for backward compatibility, since [EAPbis] clearly presents the totally insufficient security claims of this method (I am not sure it was even a good idea to include this method in [EAPbis] but this is another debate, see for instance Issue 174 of the EAP Issues List [EAPIssues]). Apart from the issues already mentioned on EAP-MD5 and that are far enough to deprecate it (namely: no mutual authentication, no key derivation and high vulnerability to active brute-force/dictionary attacks), I'd like to raise two additional minor ones. First, in [CHAP], the length of the challenge does not appear to be fixed ("The length of the Challenge Value depends upon the method used to generate the octets, and is independent of the hash algorithm used). My understanding is also that the response to CHAP is Hash(Identifier||Secret||Challenge) where Hash denotes a hash function. It is now well-known that it is not a good idea to calculate the response this way (see [MDx]), even though the appending the length of the message in MD5 thwarts the most trivial extension attacks. Bersani Expires û October 2004 [Page 6] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Second, cryptographers tend to deprecate MD5 in favor of, for instance, SHA-1 because MD5 output is only 16 bytes and because collisions have been found for the MD5 compression function. 2.2 EAP-Cisco Wireless EAP-Cisco Wireless is also known as LEAP (Lightweight EAP) which has been registered to IANA by S. Norman (Cisco). It is an undocumented proprietary method of Cisco, that was shared by Cisco to participants in the CCX program. It has been reverse- engineered and analyzed (see [LEAP]). EAP-Cisco Wireless is an EAP method that has been allocated EAP Type 17 by IANA. It is a shared key method that builds on existing mechanisms (MS- CHAP). It has been found to be flawed due to cryptographic weaknesses inherited from MS-CHAP and very poor dictionary/brute-force offline attack resistance (see [LEAPVUL]). There does not seem to be any intention to officially document EAP- Cisco Wireless or to modify it to remedy its known flaws. The plan rather seems to be to develop a new and broader EAP method (namely EAP-FAST, see section 2.10). EAP-Cisco Wireless has been implemented. 2.3 EAP-SIM SIM stands for Subscriber Identity Module (it is a concept imported from the GSM world). It is an EAP method proposed by H. Haverinen (Nokia) and J. Salowey (Cisco). The first version of it was proposed in February 2001 as an individual Internet-Draft: draft-haverinen-pppext-eap-sim-00.txt. Version 01 published April 2001, Version 02 published November 2001, Version 03 published February 2002, Version 04 published June 2002, Version 05 published June 2002, Version 06 published October 2002, Version 07 published November 2002, Version 08 published December 2002, Version 09 published January 2003, Version 10 published February 2003, Version 11 published June 2003 and Version 12 published October 2003 are still to be found on the Internet. It is an EAP method based on symmetric cryptography that reuses the GSM authentication infrastructure. Although it could be used without a SIM (e.g. with a software virtual SIM) and therefore as a generic shared key EAP method, it is my opinion that doing would not be appropriate since EAP-SIM makes considerable effort to deal with the Bersani Expires û October 2004 [Page 7] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 limitation of the GSM authentication (e.g. 64 bit keys or unilateral authentication). In case, one would however want to reuse such a method as a generic shared key method, I suggest at least not considering EAP-SIM but only EAP-AKA, which reuses the much more evolved UMTS authentication scheme. Regarding IPR, some IPR claims seem to be related to EAP-SIM, please refer to: o http://www.ietf.org/ietf/IPR/NOKIA-draft-haverinen-pppext-eap- sim.txt o http://www.ietf.org/ietf/IPR/NOKIA-EAP.txt o http://www.ietf.org/ietf/IPR/nokia-ipr-draft-haverinen-pppext- eap-sim.txt EAP-SIM is an EAP method that has been allocated EAP Type 18 by IANA (under the name Nokia IP smart card authentication). EAP-SIM is quite mature and still being actively developed. It has also been implemented. It is backed by the GSM and UMTS world (for instance by the 3GPP and the GSMA). 2.4 SRP-SHA1 SRP stands for secure remote password, which refers to a protocol developed by Thomas Wu [SRP]. It is an EAP method proposed by J. Carlson (Sun Microsystems), B. Aboba (Microsoft) and H. Haverinen (Nokia). The first version of it was proposed in December 2000 as a PPPEXT WG Internet-Draft: draft-ietf-pppext-eap-srp-00.txt. Version 01 published March 2001, version 02 published June 2001 and version 03 published July 2001 are still to be found on the Internet. Hints to a version 04 may be found on the Internet but I did not manage to find the corresponding draft. It is an EAP method based on symmetric cryptography and asymmetric key cryptography to provide strong password only authenticated key exchange. This method is quite similar to EAP-SPEKE, please refer to section 2.9 for a discussion. Regarding IPR, some IPR claims seem to be related to SRP, please refer to: o http://www.ietf.org/ietf/IPR/LUCENT-SRP o http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt o http://www.ietf.org/ietf/IPR/WU-SRP Bersani Expires û October 2004 [Page 8] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 SRP-SHA1 is an EAP method that has been allocated EAP Type 19 and 20 by IANA. It is unclear whether this method is still being developed or not. According to [EAP-METHSTAT1], part of this method is claimed to have been implemented. 2.5 EAP-AKA AKA stands for Authentication and Key Agreement (it is a concept imported from the UMTS world). Where the GSM world uses the SIM, the UMTS world uses the USIM which stands for UMTS SIM. It is an EAP method proposed by J. Arkko (Ericsson) and H. Haverinen (Nokia). The first version of it was proposed in May 2001 as an individual Internet-Draft: draft-arkko-pppext-eap-aka-00.txt. Version 01 published November 2001, Version 03 published February 2002, Version 04 published June 2002, Version 05 published October 2002, Version 06 published November 2002, Version 07 published December 2002, Version 08 published January 2003, Version 09 published February 2003, Version 10 published June 2003 and Version 11 published October 2003 are still to be found on the Internet. I did not manage to find the Version 02 on the Internet. It is an EAP method based on symmetric cryptography that reuses the UMTS authentication infrastructure. Although it could be used without an USIM (e.g. with a software virtual USIM) and therefore as a generic shared key EAP method, it is my opinion that doing would not be most appropriate. However, in the case of EAP-AKA, I must confess that this opinion is rather a matter of taste, regarding for instance its potential complexity and its design compared to the ones of a standalone shared key EAP method. Further technical and scientific investigation is needed to confirm or infirm this opinion. Regarding IPR, an IPR claim seems to be related to EAP-AKA, please refer to: o http://www.ietf.org/ietf/IPR/NOKIA-EAP.txt Though I am not a lawyer, it seems that this claim does not really encumber EAP-AKA. EAP-SIM is quite mature and still being actively developed. It is unclear whether it has been implemented. It is backed by the GSM and UMTS world (for instance by the 3GPP and the GSMA). Bersani Expires û October 2004 [Page 9] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 2.6 MS-EAP-Authentication MS stands for Microsoft. It is an EAP method proposed by Vivek Kamath and Ashwin Palekar (Microsoft). The first version of it was proposed in September 2002 as an individual Internet-Draft: draft-kamath-pppext-eap-mschapv2-00.txt. Hints to a version 01 may be found on the Internet but I did not manage to find the corresponding draft. It is an EAP method based on symmetric cryptography that reuses the MS-CHAPv2 authentication protocol. It therefore bears the well-known security flaws of the MS-CHAPv2 protocol, see [MSCHAPVUL]. An interesting feature is though the password aging and changing process. MS-EAP-Authentication is an EAP method that has been allocated EAP Type 26 by IANA. This method does not seem to be any more under development, although it would require some, at least to comply to the [EAPbis] and [EKMF]. It has been implemented on Microsoft platforms. 2.7 EAP MSCHAP-V2 It is an EAP method proposed by D. Potter and J. Zamick (Cisco). The first version of it was proposed in January 2002 as an individual Internet-Draft: draft-dpotter-pppext-eap-mschap-00.txt. Hints to a version 01 may be found on the Internet but I did not manage to find the corresponding draft. It is an EAP method based on symmetric cryptography that reuses the MS-CHAPv2 authentication protocol. It therefore bears the well-known security flaws of the MS-CHAPv2 protocol, see [MSCHAPVUL]. This method resembles very closely MS-EAP-Authentication. EAP MSCHAP-V2 is an EAP method that has been allocated EAP Type 29 by IANA. This method does not seem to be any more under development, although it would require some, at least to comply to the [EAPbis] and [EKMF]. It is unclear whether it has been implemented. Bersani Expires û October 2004 [Page 10] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 2.8 EAP-HTTP Digest EAP-HTTP Digest is an EAP method that has been registered to IANA by O. Tavakoli (Funk Software). It is an undocumented EAP method, though some elements were kindly provided by [EAPHTTPDigest]. EAP-HTTP Digest is an EAP method that has been allocated EAP Type 38 by IANA. EAP-HTTP Digest is a shared key method that allows HTTP Digest authentication (defined in [HTTP-Digest]) to be offloaded from a gateway to an AAA server. It is applicable for use with HTTP servers as well as other protocols that use HTTP as a transport and require HTTP digest authentication (e.g. SIP). This protocol is not intended to be a shared key EAP method that replaces EAP-MD5 Challenge, as per [EAPHTTPDigest]. It is rather driven by legacy requirements (the definition of an authentication method for HTTP that is not compatible with any existing RADIUS credentials or EAP types). It is unclear whether this method will be publicly specified and whether it is implemented or not. 2.9 EAP-SPEKE SPEKE stands for simple password exponential key exchange. It is an EAP method proposed by D. Jablon (Phoenix Technologies). The actual EAP method was, as far as I know, never described. Hence, the following text only alludes to the SPEKE scheme by itself. The first version of it was proposed in February 2002 as an individual Internet-Draft: draft-jablon-speke-00.txt. Version 01 published April 2002 and version 02 published October 2002 are still to be found on the Internet. It is an EAP method based on symmetric cryptography and asymmetric key cryptography to provide strong password only authenticated key exchange. This method is quite similar to EAP-SRP. From a security point of view, this method seems to definitely have a better security level than EAP-PSK when a password is used because it uses techniques specially designed to sophisticatedly deal with Bersani Expires û October 2004 [Page 11] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 passwords (better than the classic tips provided in the Annex B of [EAP-PSK], which are salting and iterating a hash function). A simple presentation related to the more evolved techniques to deal with password is available at [SRPpres]. It would be interesting to investigate whether this increased security level has some concrete impact on realistic usage scenarios and whether it is necessary to provide such a strong password support. The reasons why EAP-PSK did not choose to try and provide strong password authentication in a similar way to SPEKE and SRP are: o EAP-PSK wanted to rely on a single cryptographic primitive (AES) whereas SPEKE or SRP have to use asymmetric cryptography o EAP-PSK wanted to avoid any patent-encumbrance whereas SPEKE and SRP seem to require clarification regarding their IPR status o EAP-PSK left totally open the way the PSK would be stored (in a human brain, in hardware or software containers,...) o EAP-PSK felt that it could provide a decent level of security to users that chose "reasonable" passwords (this point is of course to be investigated, justified and clarified). Regarding IPR, some IPR claims seem to be related to SPEKE, please refer to: o http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt EAP-SPEKE is an EAP method that has been allocated EAP Type 41 by IANA. It is unclear whether this method will be publicly specified and whether it is implemented or not. 2.10 EAP-FAST EAP-FAST stands for Flexible Authentication via Secure Tunneling (EAP-FAST). It is an EAP method proposed by N.Cam-Winget, D. McGrew, J. Salowey and H.Zhou (Cisco). The first version of it was proposed in February 2004 as an individual Internet-Draft: draft-cam-winget-eap-fast-00.txt. It is an EAP method based on symmetric cryptography and asymmetric key cryptography that reuses the TLS mechanisms. EAP-FAST has some nice features: o ¸ TLV design that allows for extensibility o ¸ Minimization of the per user authentication state requirement o ¸ Handling of legacy equipment (use of TLS and MSCHAPv2) o Fragmentation support Bersani Expires û October 2004 [Page 12] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 o ¸ Crypto-binding to allow sequence of EAP methods However, this protocol has in my opinion two main drawbacks: o Cryptographic design: choices were made to reuse flawed protocols (e.g. MSCHAPv2), new cryptographic designs were introduced without any explanations and the enrollment procedure is easily prone to attacks (especially in the anonymous Diffie- Hellman setting), which is acknowledged and justified by simplicity arguments. The cryptographic design could have benefited from the more evolved and secure password authentication techniques (e.g. EAP-SRP and EAP-SPEKE). o It is quite a heavy weight protocol since for instance it refers to no less than 5 or 6 cryptographic primitives, namely a stream cipher - RC4, a block cipher - AES and hash functions - MD4, MD5 and SHA-1, and focuses directly on tunneling. Regarding IPR, some IPR claims seem to be related to EAP-FAST, please refer to: o http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap- fast.txt EAP-FAST is an EAP method that has been allocated EAP Type 43 by IANA. This method has been released very recently and should be further developed and implemented. 2.11 EAP-Archie It is an EAP method proposed by Jesse Walker (Intel) and Russ Housley (Vigil Security). The first version of it was proposed in February 2003 as an individual Internet-Draft: draft-jwalker-eap-archie-00.txt. Version 01 published June 2003 is still to be found on the Internet. It is an EAP method based on symmetric cryptography. It is very closely related to EAP-PSK since it was the main source of inspiration for EAP-PSK. The main differences between EAP-Archie and EAP-PSK are: o Some cryptographic changes (use of OMAC in EAP-PSK instead of CBC-MAC that cannot handle variable length messages, use of a key derivation scheme that has been proven to be secure in EAP- PSK, use of EAX to set up a protected channel, removal of the AES key wrap algorithm from EAP-PSK) Bersani Expires û October 2004 [Page 13] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 o Some design changes (e.g. use of a TLV format in EAP-PSK instead of message types) EAP-Archie will not be maintained and developed in the future ([EAP- Archie]), so EAP-PSK may be considered its successor in my opinion. Some implementations of EAP-Archie have been available. 2.12 EAP-GSS GSS stands for Generic Security Service and is defined in RFC 2743. It is an EAP method proposed by B. Aboba and D. Simon (Microsoft). The first version of it was proposed in December 1999 under the title "PPP EAP GSS Authentication Protocol" as an individual Internet- Draft: draft-aboba-pppext-eapgss-00.txt. Version 02 published November 2000, version 03 published February 2001, version 05 published July 2001, version 06 published August 2001, version 07 published August 2001, version 08 published September 2001, version 09 published December 2001, version 10 published January 2002, version 11 published February 2002 and version 12 published April 2002 are still to be found on the Internet. Hints to a version 01 and 13 may be found on the Internet but I did not manage to find the corresponding draft. EAP-GSS enables the use of GSS-API mechanisms within EAP. As a result, any GSS-API mechanism providing initial authentication can be used with EAP GSS. Since some GSS-API mechanisms are shared key mechanisms, further investigation is required on this method (since I am currently not familiar with the GSS-API and GSS-API mechanisms). 2.13 EAP-IKEv2 IKEv2 stands for Internet Key Exchangev2. It is an EAP method proposed by H. Tschofenig and D. Kroeselberg (Siemens) and Y. Ohba (Toshiba). The first version of it was proposed in April 2003 as an individual Internet-Draft: draft-tschofenig-eap-ikev2-00.txt. Version 01 published June 2003, version 02 published October 2003 and version 03 published August 2004 are still to be found on the Internet. It is an EAP method based on the symmetric and asymmetric cryptography of IKEv2. Bersani Expires û October 2004 [Page 14] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Its main advantages consist in my opinion consist first in reusing a protocol which security has received considerable expert review, second reusing a protocol that could become widely implemented and third benefiting from all the nice features provided by IKEv2 (mutual authentication, key derivation, DoS resistance, fast reconnect, fragmentation support,...). Further investigation is needed to assess this proposal that would be more generic than a shared key method replacing EAP-MD5 since it also allows for asymmetric credentials such as certificates(in particular studying the goals and different features of IKEv2 might be quite inspiring for EAP methods). 2.14 EAP-LDAP LDAP is an EAP method proposed by H. Mancini (Bridgewater Systems). The first version of it was proposed in June 2003 under the title "EAP-LDAP Protocol" as an individual Internet-Draft: draft-mancini- pppext-eap-ldap-00.txt. Hints to a version 01 may be found on the Internet but I did not manage to find the corresponding draft. This document specifies an EAP method to enable the use of EAP-MD5 even though there is no access to the user's clear text password within an identity store. It merely uses the hash of the user's password, hash which is stored within the identity store, as the key to EAP-MD5. It thus inherits at least all the vulnerability of EAP- MD5 and therefore is not suitable as a replacement for EAP-MD5. 2.15 EAP-MD5 Tunneled Authentication Protocol EAP-MD5 Tunneled Authentication Protocol is an EAP method proposed by Paul Funk (Funk Software). The first version of it was proposed in March 2003 under the title " The EAP MD5-Tunneled Authentication Protocol " as an individual Internet-Draft: draft-funk-eap-md5-tunneled-00.txt. EAP-MD5-Tunneled is an EAP protocol designed for use as an inner authentication protocol within a tunneling EAP protocol such as EAP- TTLS or PEAP. It is cryptographically equivalent to standard CHAP and the EAP-MD5-Challenge protocol. Thus, EAP-MD5-Tunneled does not aim at proposing a generic shared key EAP method but rather the issues implied by tunneling EAP methods. In addition, EAP-MD5-Tunneled bears at least the same cryptographic weaknesses as EAP-MD5 and therefore is not suitable as a replacement for EAP-MD5. 2.16 EAP-PSK Bersani Expires û October 2004 [Page 15] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 EAP-PSK stands for EAP-Pre Shared Key. It is an EAP method proposed by F. Bersani (France Telecom R&D). The first version of it was proposed in January 2004 as an individual Internet-Draft: draft-bersani-eap-psk-00.txt. Version 01 published February 2004 is still to be found on the Internet. It is an EAP method based on symmetric cryptography. Its main design goals are: o Simplicity: It should be easy to implement and to deploy without any pre-existing infrastructure o Wide applicability: It should be possible to use this method to authenticate over any network. In particular, it should be suitable for IEEE 802.11 [IEEE 802.11] wireless LANs and thus comply to IEEE 802 EAP Method Requirements for Wireless LANs [IEEE 802REQ] o Security: It should be conservative in its cryptographic design and enjoy security proofs o Extensibility: It should be possible to add to this method the required extensions as their need appears o Patent-avoidance: It should be free of any Intellectual Property Right claims It views itself as the successor of EAP-Archie. It is intended to stimulate the debate on EAP-MD5 replacement and to be a proposal for such a replacement. 2.17 EAP-SKE EAP-SKE stands for EAP Shared Key Exchange. It is an EAP method proposed by L. Salgarelli (Bell Labs, Lucent Technologies) as the editor and many other co-authors. The first version of it was proposed in November 2001 as an individual Internet-Draft: draft-salgarelli-pppext-eap-ske-00.txt. Version 01 published April 2002, version 02 published November 2002 and version 03 published May 2003 are still to be found on the Internet. Hints to a version 04 may be found on the Internet but I did not manage to find the corresponding draft. It is an EAP method based on symmetric cryptography. Its main focus is, in my opinion, network efficiency in roaming situations. Bersani Expires û October 2004 [Page 16] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Work is going on between the authors of EAP-SKE and EAP-PSK to see if forces could be joined to produce a common proposal for a shared key method to the community [EAP-SKE]. 2.18 EAP-SSC SSC stands for Secured Smartcard Channel It is an EAP method proposed by P.Urien and M. Dandjinou (ENST). The first version of it was proposed in December 2003 under the title "EAP-SSC Secured Smartcard Channel " as an individual Internet-Draft: draft-urien-eap-ssc-00.txt. Version 01 published June 2004 is still to be found on the Internet. This document describes a means of setting up an EAP secured channel between a smart card and an Authentication Server as well according to an asymmetric key exchange model as a symmetric key exchange model. This channel would permit to convey securely all other types of payload between the smart card and the authentication server. It is not clear what exactly makes the content of this document specific to a smart card. It seems to me as though the proposed protocol could be viewed as a generic symmetric and asymmetric cryptography EAP method. If so, the proposed cryptographic mechanism would require, in my opinion, expert review and justification to back up their soundness since new mechanisms seem to be introduced without justification. In addition, further investigation would be needed to assess the pros and cons of this protocol. 3. Conclusion 3.1 The different existing shared key EAP methods This section attempts to provide a summary of the pros and cons of the existing shared key EAP methods listed in section 2. EAP-MD5 has several security flaws that cannot be tolerated in the new environments where EAP is intended to be used like WLANs (e.g. no mutual authentication, no key derivation and high vulnerability to active brute-force/dictionary attacks). However, it has some nice features that might be worth keeping in mind: it is standardized and it is simple. EAP-Cisco Wireless also has security flaws that should not be tolerated in the new environments where EAP is intended to be used like WLANs and it is an undocumented proprietary method. However, it Bersani Expires û October 2004 [Page 17] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 should be remembered as a proof of the need for a shared key EAP method as well as the feasibility of such a method. MS-EAP-Authentication and EAP MSCHAPv2 unfortunately inherit, like EAP-Cisco Wireless, the intolerable security flaws of the protocol they are based on, namely MS-CHAPv2. A nice feature though to retain from these methods is the password aging and changing process. EAP-MD5 Tunneled Authentication Protocol also inherit the weaknesses of EAP-MD5 and therefore cannot compete for its replacement. EAP-SIM and EAP-AKA are not, in their design intention, generic shared key EAP methods. However in case, one wants to use them as such, EAP-SIM should be dropped in favor of EAP-AKA which is more evolved. Whether EAP-AKA could or should be reused as a generic shared key EAP method will be further investigated in the following versions of this draft, although the current feeling is that it should not. EAP-HTTP Digest is a method designed to cope with legacy devices and protocols that is not publicly specified. It should therefore not impact the drafting of a replacement for EAP-MD5. EAP-SRP and EAP-SPEKE are two very interesting methods for the drafting of a replacement for EAP-MD5 that use evolved cryptography to very efficiently deal with passwords. Further investigation is needed to assess whether or not such efficiency with passwords is required from a security point of view and whether it is possible to move forward with such techniques while avoiding IPR claims. EAP-FAST is also an interesting method to take into account. However some choices it made seem to have been driven by a will to deal with legacy devices and infrastructures (e.g. reusing MS-CHAPv2). Further investigation is needed to determine whether dealing with legacy equipment should be a goal in the drafting of a replacement for EAP- MD5. EAP-FAST also provide fragmentation support. This leads to raising the question whether fragmentation support should be supported by the replacement of EAP-MD5 (the answer might be yes in my opinion since fragmentation support can probably be easily added and leaves the method open for future extensions that could require payloads larger than the MTU). EAP-IKEv2 definitely requires further investigation to better understand IKEv2 design goals and features and whether they suit EAP well. EAP-LDAP alludes to the possible problems that might arise when using a standard existing database to store the users' credentials. Similarly to EAP-FAST, further investigation is needed to see if Bersani Expires û October 2004 [Page 18] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 dealing with legacy devices and infrastructures should be a design goal and if yes, how to deal with them. EAP SSC needs further investigation to better understand its goals and its capabilities as well as the security level it provides. EAP GSS needs further investigation to assess to what extent it could be used in conjunction with a GSS-API mechanism to be specified to replace EAP MD5. The nice idea behind EAP GSS is the use of a generic API to access a range of different authentication mechanisms, although this might be redundant with EAP itself. Hopefully, EAP-PSK (which may be considered EAP-Archie's successor since EAP-Archie will not be further developed) and EAP-SKE will be merging to propose a base draft to the community for replacing EAP- MD5. It is believed to have a sound security basis as well as a simple and extensible design. 3.2 General conclusion on shared key EAP methods There is a wide range of existing shared key EAP methods which is good since it demonstrates the creativity of the community but is also dangerous since it first dilutes the review effort of the community which might result in flawed or broken protocols and second it does not help to provide interoperability. Thanks to all the good ideas contained in the drafts mentioned in the precedent section, it seems to be quite possible to draft a standard replacement for EAP-MD5 that would retain the best of all worlds, provided the community shows interest in doing so. Further work is needed to better assess the status of the different drafts mentioned in the precedent section and understand their pros and cons (especially those of EAP-AKA, EAP-FAST, SRP-SHA1, EAP-SPEKE, EAP GSS, EAP-PSK and EAP SSC). Hopefully, this will be done in future versions of this document. Most drafts do not comply to EAPbis or EKMF which understandable since those documents were themselves evolving. It would be a good idea to clarify the relationship between shared key EAP methods and OTP methods (since they both tend to use the same symmetric cryptography credentials). Hopefully, this will be done in future versions of this document. 3.3 Miscellaneous conclusions Similar unification work could be done in the following areas: Bersani Expires û October 2004 [Page 19] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 o OTP EAP methods (in case, they are deemed essentially different from EAP methods as a result of the further investigations announced in the previous subsection) o Biometrics EAP method (since like OTP EAP methods, there are numerous candidates available, yet none has acquired the maturity and extent of a widespread standard) o Public key EAP methods (although EAP-TLS has already emerged as a standard) o Hybrid methods (i.e. using public key on one side and private key on the other side) Such work could improve the quality of the methods and help users find they way through the myriads of EAP methods! 4. Review of the non shared key EAP methods The EAP methods presented here have been included for the sake of completeness: they are deemed totally irrelevant for the drafting of a replacement for EAP-MD5. 4.1 EAP-OTP EAP-OTP stands for one-time password. Please refer to [EAP] and [EAPbis] for a description of EAP-OTP, which is thus a standardized method. This EAP method has been defined for use with one-time password systems. Unfortunately, this method is quite simplistic and outdated (see for instance the security claims in [EAPbis]). Therefore, this method is, in my opinion, only specified for legacy reasons and its security and functionality levels do not match the current requirements. 4.2 EAP-GTC EAP-GTC stands for generic token card. Please refer to [EAP] and [EAPbis] for a description of EAP-GTC, which is thus a standardized method. This EAP method has been defined for use with various token card implementations that require user input. It consists in a challenge (containing a displayable message) and a response (containing the data entered by the user from the token card). Unfortunately, this method is so simplistic and outdated (since in only a round-trip, it is quite hard to provide a good level of Bersani Expires û October 2004 [Page 20] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 security - see for instance the security claims in [EAPbis]) that many token cards have chosen to develop their own methods (see e.g. section 4.8). Therefore, this method is, in my opinion, only specified for legacy reasons and its security and functionality levels do not match the current requirements. 4.3 EAP RSA Public Key Authentication EAP-RSA PKA stands for EAP RSA Public Key Authentication Protocol. It is an EAP method proposed by William T. Whelan (Network Express and later Cabletron Systems). The first version of it was proposed in November 1995 as a PPPEXT WG Internet-Draft: draft-ietf-pppext-eaprsa-00.txt. Version 01 published February 1996, version 02 published February 1996, Version 03 published January 1997 and Version 03 published January 1997 are still to be found on the Internet. EAP-RSA PKA is an EAP method that has been allocated EAP Type 9 by IANA. It is an EAP method based on asymmetric cryptography and the unilateral two pass authentication described in ISO/IEC 9798-3. It seems to be subject to patents by RSA Security, see http://www.ietf.org/ietf/IPR/pppext-eaprsa This method does not seem to be maintained any more. 4.4 EAP-DSS EAP-DSS stands for EAP DSS Public Key Authentication Protocol and DSS stands for Digital Signature Standard. It is an EAP method proposed by William A. Nace (NSA) and James E. Zmuda(SPYRUS). The first version of it was proposed in November 1997 as a PPPEXT WG Internet-Draft: draft-ietf-pppext-eapdss-00.txt. Version 01 published December 1997 is still to be found on the Internet. Hints to a version 02 may be found on the Internet but I did not manage to find the corresponding draft. EAP-DSS is an EAP method that has been allocated EAP Type 10 (Under the name DSS Unilateral) by IANA. Bersani Expires û October 2004 [Page 21] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 It is an EAP method that uses asymmetric cryptography (namely the DSA) and is based on unilateral two pass authentication as described in NIST FIPS PUB 196 "Standard for Public Key Cryptographic Entity Authentication Mechanisms". This method does not seem to be maintained any more. 4.5 EAP-KEA EAP-KEA stands for EAP KEA Public Key Authentication Protocol and KEA stands for Key Exchange Algorithm. It is an EAP method proposed by William A. Nace (NSA), Peter Yee and James E. Zmuda (both of SPYRUS). The first version of it was proposed in November 1997 as a PPPEXT WG Internet-Draft: draft-ietf-pppext-eapkea-00.txt. Version 01 published December 1997 is still to be found on the Internet. Hints to a version 02 may be found on the Internet but I did not manage to find the corresponding draft. EAP-KEA is an EAP method that has been allocated EAP Types 11 and 12 by IANA. It is an EAP method that uses asymmetric cryptography (namely Diffie- Hellman). This method does not seem to be maintained any more. 4.6 EAP-TLS Please refer to [EAP-TLS] for a description of this method. EAP-TLS is an EAP method that has been allocated EAP Type 13 (by IANA. EAP-TLS is an EAP method based on asymmetric cryptography reusing TLS mechanisms. 4.7 Defender Token (AXENT) Defender Token (AXENT) is an EAP method that has been registered to IANA by Michael Rosselli (Axent). It is an undocumented EAP method. The contact information indicated in IANA is outdated (AXENT has been merged to Symantec then sold to Passgo). Information request has been requested to Passgo which kindly provided some ([Defender]). Bersani Expires û October 2004 [Page 22] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Defender Token (AXENT) is an EAP method that has been allocated EAP Type 34 by IANA. The Defender Token (AXENT) EAP method was never completed. PassGo Technologies may continue this development at some point in the future but there are no immediate plans to do so at present. 4.8 RSA Security SecurID EAP and SecurID EAP Two EAP types have been allocated by IANA for RSA SecurID authentication: type 15 and type 32. Some documentation on these methods have been kindly communicated by [RSA SecurID]. EAP type 15 was developed for use with RSA Security clients and Agents on the Windows platform. It is proprietary and may remain that way. Seeing the need for an open EAP type to support RSA Tokens, EAP type 32 has been reserved. It is an EAP method proposed by S. Josefsson (RSA Security). The first version of it was proposed in January 2002 as an individual Internet-Draft: draft-josefsson-eap-securid-00.txt. Version 01 published February 2002 is still to be found on the Internet. Hints to a version 02 may be found on the Internet but I did not manage to find the corresponding draft. Temporarily there does not seem to be any (public) work done is this method any more. Both methods are basically OTP methods that rely on the RSA SecurID authentication token. 4.9 Arcot systems EAP Arcot systems EAP is an EAP method that has been registered to IANA by Rob Jerdonek (Arcot). It is an undocumented EAP method. Information has been requested from Arcot but no answer has yet been obtained. Arcot systems EAP is an EAP method that has been allocated EAP Type 16 by IANA. Bersani Expires û October 2004 [Page 23] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Arcot systems EAP is an EAP method that probably relies on a OTP scheme using a software authentication token. It should therefore not compete as a replacement for EAP-MD5 (see [Arcot] for general information). 4.10 EAP-TTLS EAP-TTLS stands for EAP Tunneled TLS Authentication Protocol. It is an EAP method proposed by Paul Funk (Funk Software) and Simon Blake-Wilson (Certicom). The first version of it was proposed in August 2001 as a PPEXT WG Internet-Draft: draft-ietf-pppext-eap-ttls-00.txt. Version 01 published February 2002, version 02 published November 2002, version 03 published August 2003 are still to be found on the Internet. Hints to a version 04 may be found on the Internet but I did not manage to find the corresponding draft. EAP-TTLS is an EAP method that has been allocated EAP Type 21 by IANA. EAP-TTLS is an EAP method based on asymmetric cryptography reusing TLS mechanisms. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication infrastructures such as RADIUS. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS- CHAP-V2. 4.11 Remote Access Service Remote Access Service is an EAP method that has been registered to IANA by Steven Fields (Identix). It is an undocumented EAP method. Information has been requested from Identix but no answer has yet been obtained. Remote Access Service is an EAP method that has been allocated EAP Type 22 by IANA. It is not clear to me how this EAP method works (though it probably relies on biometrics, see [Identix] for general information). 4.12 EAP-3Com Wireless Bersani Expires û October 2004 [Page 24] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 EAP-3Com Wireless is an EAP method that has been registered to IANA by Albert Young (3com). It is an undocumented EAP method. Information has been requested from but no answer has yet been obtained (the contact information indicated in IANA is outdated). EAP-3Com Wireless is an EAP method that has been allocated EAP Type 24 by IANA. It is not clear to me how this EAP method works (See [3com] for general information). 4.13 PEAP PEAP stands for Protected Extensible Authentication Protocol. It is an EAP method proposed by H. Andersson (RSA Security), S. Josefsson (RSA Security and later Extundo), Glen Zorn and Hao Zhou (Cisco), Dan Simon and Ashwin Palekar (Microsoft). The first version of it was proposed in August 2001 as an individual Internet-Draft under the title "Protecting EAP with TLS (EAP-TLS- EAP)": draft-josefsson-pppext-eap-tls-eap-00.txt. Version 01 published October 2001, version 02 published February 2002, version 03 published September 2002, version 04 published September 2002, version 05 published September 2002, version 06 published March 2003, version 07 published October 2003 are still to be found on the Internet. PEAP is an EAP method based on asymmetric cryptography reusing TLS mechanisms that has been allocated EAP Type 25 by IANA. PEAP is an EAP method based on asymmetric cryptography reusing TLS mechanisms which provides an encrypted and authenticated tunnel based on transport layer security (TLS) that encapsulates EAP authentication mechanisms. PEAP uses TLS to protect against rogue authenticators, protect against various attacks on the confidentiality and integrity of the inner EAP method exchange and provide EAP peer identity privacy. EAP also provides support for chaining multiple EAP mechanisms, cryptographic binding between authentications performed by inner EAP mechanisms and the tunnel, exchange of arbitrary parameters (TLVs), optimized session resumption, and fragmentation and reassembly. Regarding IPR, some IPR claims seem to be related to EAP-FAST, please refer to: http://www.ietf.org/ietf/IPR/MICROSOFT-PEAP.txt Bersani Expires û October 2004 [Page 25] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 4.14 EAP-MAKE EAP-MAKE stands for EAP Mutual Authentication with Key Exchange. It is an EAP method proposed by R. Berrendonner and H. Chabanne (both of Sagem). The first version of it was proposed in September 2001 as an individual Internet-Draft: draft-berrendo-chabanne-pppext-eapmake- 00.txt. Version 01 published October 2001 is still to be found on the Internet. Hints to a version 02 may be found on the Internet but I did not manage to find the corresponding draft. EAP-MAKE is an EAP method that has been allocated EAP Type 27 by IANA. It is an EAP method inspired by EAP-KEA that uses asymmetric cryptography (namely Diffie-Hellman). This method does not seem to be maintained any more. 4.15 CRYPTOcard CRYPTOcard is an EAP method that has been registered to IANA by Stephen Webb (Cryptocard). It is an undocumented EAP method. Information has been requested from CRYPTOcard but no answer has yet been obtained (there seemed to be a problem with the mail box of the contact indicated by IANA and no answer was yet obtained from the general support). CRYPTOcard is an EAP method that has been allocated EAP Type 28 by IANA. It is not clear to me how this EAP method works (it is probably an EAP method that relies on an authentication token, see [CRYPTOcard] for general documentation). 4.16 DynamID DynamID is an EAP method that has been registered to IANA by P. Merlin (SCrypto). It is an undocumented EAP method, though some elements were kindly provided by [DynamID].. DynamID is an EAP method that has been allocated EAP Type 30 by IANA. Bersani Expires û October 2004 [Page 26] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 It is an EAP method that uses asymmetric key cryptography (namely digital certificates stored on smart cards). It is a challenge- response method that only provides client authentication. This method also provides key derivation. 4.17 Rob EAP Rob EAP is an EAP method that has been registered to IANA by Sana Ullah. It is an undocumented EAP method. Information has been requested from Sana Ullah but no answer has yet been obtained. Rob EAP is an EAP method that has been allocated EAP Type 31 by IANA. It is not clear to me how this EAP method works (I found absolutely no information on it!). 4.18 MS-Authentication TLV TLV stands for Type-Length-Value. It is an EAP method proposed by T. Hiller (Lucent), A. Palekar (Microsoft) and G. Zorn (Cisco). The first version of it was proposed in October 2002 under the title "A Container Type for the Extensible Authentication Protocol (EAP)" as an individual Internet-Draft: draft-hiller-eap-tlv-00.txt. Version 01 published May 2003 is still to be found on the Internet. Hints to a version 02 may be found on the Internet but I did not manage to find the corresponding draft. MS-Authentication TLV is an EAP method that has been allocated EAP Type 33 (Under the name DSS Unilateral) by IANA. It is not really an authentication method but a proposed solution to some issues that arose within the EAP WG. 4.19 SentriNET SentriNET is an EAP method that has been registered to IANA by J. Kelleher (ISL Biometrics). It is an undocumented EAP method, though some elements were kindly provided by [SentriNET]. Bersani Expires û October 2004 [Page 27] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 SentriNET is an EAP method that has been allocated EAP Type 34 by IANA. SentriNET (per se, not the EAP method that bears the same name) is a biometric middleware product which adds biometrics to existing user accounts in their native location (e.g. NT SAM accounts, Active Directory, LDAP entries or entries in a database for web applications). Management and checking of these biometrics is similarly integrated (e.g. MMC and GINA for Microsoft Windows 2000/XP, ...). SentriNET (the EAP method) is a method designed to extend the biometric logon available to local users to remote access via a NAS or VPN. SentriNET (the EAP method) remains proprietary with no plans for publication in the near future. Its basic operation involves the supplying of a user name to the server which checks which biometrics have been enrolled and returns information on the appropriate hardware types to the client, the client captures a live biometric on a suitable device and returns it to the server for matching. 4.20 EAP-Actiontec Wireless EAP-Actiontec Wireless is an EAP method that has been registered to IANA by Victor Chang (Actiontec) It is an undocumented EAP method. Information has been requested from Actiontec but no answer has yet been obtained. EAP-Actiontec Wireless is an EAP method that has been allocated EAP Type 35 by IANA. It is not clear to me how this EAP method works (see [Actiontec] for general documentation). 4.21 Cogent systems biometrics authentication EAP Cogent systems biometrics authentication EAP is an EAP method that has been registered to IANA by John Xiong (Cogent systems) It is an undocumented EAP method. Information has been requested from Cogent systems but no answer has yet been obtained. Cogent systems biometrics authentication EAP is an EAP method that has been allocated EAP Type 36 by IANA. It is not clear to me how this EAP method works though it probably relies on biometrics (see [Cogent] for general documentation). Bersani Expires û October 2004 [Page 28] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 4.22 AirFortress EAP AirFortress EAP is an EAP method that has been registered to IANA by Richard Hibbard (Fortress technologies) It is an undocumented EAP method. Information has been requested from Fortress technologies but no answer has yet been obtained. AirFortress EAP is an EAP method that has been allocated EAP Type 37 by IANA. It is not clear to me how this EAP method works (see [Airfortress] for general documentation). 4.23 Securesuite EAP Securesuite EAP is an EAP method that has been registered to IANA by Matt Clements (Iosoftware). It is an undocumented EAP method. Information has been requested from Iosoftware but no answer has yet been obtained. Securesuite EAP is an EAP method that has been allocated EAP Type 39 by IANA. It is not clear to me how this EAP method works (see [Securesuite] for general documentation). 4.24 DeviceConnect EAP DeviceConnect EAP is an EAP method that has been registered to IANA by David Pitard (Phoenix). It is an undocumented EAP method. Information has been requested from Phoenix but no answer has yet been obtained. DeviceConnect EAP is an EAP method that has been allocated EAP Type 40 by IANA. It is not clear to me how this EAP method works (see [DeviceConnect] for general documentation). 4.25 EAP-MOBAC EAP-MOBAC is an EAP method that has been registered to IANA by T. Rixom (Alfa-Ariss). Bersani Expires û October 2004 [Page 29] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 It is an undocumented EAP method, though some elements were kindly provided by [EAP-MOBAC]. EAP-MOBAC is an EAP method that has been allocated EAP Type 42 by IANA. It is an EAP method that is basically OTP via SMS. It thus requires a special infrastructure (gateway to the SMS system and OTP server) and is therefore not a possible candidate for EAP-MD5 replacement. 4.26 ZoneLabs EAP (ZLXEAP) ZoneLabs EAP is an EAP method that has been registered to IANA by D. Bogue (ZoneLabs). It is an undocumented EAP method, though some elements were kindly provided by [ZoneLabs]. ZoneLabs EAP is an EAP method that has been allocated EAP Type 44 by IANA. It is an EAP method that should augment shared key EAP methods, not replace them. 4.27 EAP Bluetooth Application EAP Bluetooth Application is an EAP method proposed by H. Kim (INRIA), H. Afifi (INT) and M. Hayashi (Hitachi). The first version of it was proposed in February 2004 as an individual Internet-Draft under the title "EAP Bluetooth Application": draft-kim-eap-bluetooth-00. EAP Bluetooth Application is not an authentication method but rather a way to help to Bluetooth devices set up a secure channel thanks to EAP authentication through a IEEE 802.11 interface of one of the devices. It therefore merely tunnels other EAP authentication methods for what regards authentication. 4.28 EAP-GPRS GPRS stands for General Packet Radio Service (it is a concept imported from the GSM world). It is an EAP method proposed by A. Salkintzis (Motorola). The first version of it was proposed in December 2002 under the title "The EAP GPRS Protocol" as an individual Internet-Draft: draft-salki- pppext-eap-gprs-00.txt. Bersani Expires û October 2004 [Page 30] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Version 01 published June 2003 and version 02 published January 2004 are still to be found on the Internet. EAP-GPRS specifies an extension to EAP which allows GPRS clients to perform signaling procedures with a core GPRS network through devices that enforce EAP-based access control. For example, a GPRS client can use EAP-GPRS to attach to a GPRS network through an access point that enforces IEEE 802.1X access control. In this case, the GPRS attach signaling is performed in the context of the underlying 802.1X procedure and the GPRS messages are encapsulated into EAP-GPRS packets. If the GPRS client is permitted to attach to the GPRS network, then the 802.1X procedure ends successfully and the client is authorized access to the access point. In general, EAP-GPRS allows any type of signaling to take place during the EAP authentication as an embedded signaling procedure. It is not really an authentication method but rather a new transport mechanism for higher-layer protocols. 4.29 EAP support in smart cards EAP support in smart cards is an EAP method proposed by P. Urien (ENST), A. J. Farrugia (CSI), G. Pujolle (LIP6), J. Abellan (Axalto) and M. de Groot (Gemplus). The first version of it was proposed in October 2002 as an individual Internet-Draft under the title "EAP support in smartcards ": draft- urien-eap-smartcard-00.txt. Version 01 published February 2003, version 02 published June 2003, version 03 published September 2003 and version 04 published February 2004 are still to be found on the Internet. EAP support in smart cards is not an authentication method but rather describes the interface to the EAP protocol in smart cards, which could store multiple identities associated to Network Access Identifiers. It therefore merely tunnels other EAP authentication methods for what regards authentication. 4.30 EAP-TLS SASL SASL stands for Simple Authentication and Security Layer. It is an EAP method proposed by H. Andersson and S. Josefsson (RSA Security). The first version of it was proposed in June 2001 under the title "EAP Mechanism using TLS and SASL (Version 1)" as an individual Internet-Draft: draft-andersson-eap-tls-sasl-00.txt. Bersani Expires û October 2004 [Page 31] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Hints to a version 01 may be found on the Internet but I did not manage to find the corresponding draft. The development of this method seem to have been stopped as its authors moved to work on PEAP (please refer to section 4.13). 5. IANA considerations This document does not introduce any new IANA consideration. 6. Security considerations This document does not introduce any new security issue for the Internet. 7. Acknowledgements Many thanks to the EAP WG chairs (J. Arkko and B. Aboba) for motivating this work, to Laurent Butti, Olivier Charles, Aurelien Magniez and Jerome Razniewski for their feedback and to all those mentioned in the References section that kindly took some time to answer some of my questions! Special thanks to Henri Gilbert for some related cryptographic discussions on shared key EAP methods. 8. References [Actiontec] http://www.actiontec.com [AirFortress] http://www.fortresstech.com/ [Arcot] http://www.arcot.com/ [CHAP] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [Cogent] http://www.cogentsystems.com/cogent/cogenthome.html [CRYPTOcard] http://www.cryptocard.com/ [Defender] Peter Cooke, PCooke@passgo.com, Personal communication, March 2004 [DeviceConnect] http://www.phoenix.com/en/products /phoenix+deviceconnect/default1.htm [Dynamid] P Merlin (Scrypto), pmerlin@scrypto.fr, Bersani Expires û October 2004 [Page 32] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Personal Communication, March 2004 [EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [EAP-Archie] Russ Housley and Jesse Walker, Personal communications, February 2004 [EAPbis] Blunk, L. et al., "Extensible Authentication Protocol (EAP)", Internet-Draft (work in progress), February 2004, http://ietf.levkowetz.com/drafts/eap /rfc2284bis/draft-ietf-eap-rfc2284bis-09.txt [EAPHTTPDigest] O. Tavakoli (Funk Software), radagast@funk.com, Personal Communication, March 2004 [EAPIssues] EAP Open issues list, http://www.drizzle.com/~aboba/EAP/eapissues.html [EAP-METHSTAT1] Aboba B., "EAP and AAA update", NIST 802.11 security workshop, December 2002, http://csrc.nist.gov/wireless /S12_NIST-IETFpart2--ba.pdf [EAP-METHSTAT1] Arkko J. and Aboba, B., "EAP WG Methods Update", IETF 59, March 2004, http://www.arkko.com/publications/eap /ietf-59/ietf59_eap_methstatus.ppt [EAP-MOBAC] T. Rixom (Alfa-Ariss), tom.rixom@alfa-ariss.com, Personal Communication, March 2004 [EAP-PSK] Bersani, F., "The EAP-PSK protocol", Internet-Draft (work in progress), February 2004, draft-bersani-eap-psk-01.txt [EAP-SKE] Luca Salgarelli, Uri Blumenthal and Semyon Mizikovski, Personal communications, February and March 2004 [EAP-SKMDTEMPL] Bersani, F., " EAP shared key methods documentation template", Internet-Draft (work in progress), March 2004, draft-bersani-eap-sharedkeymethods-doctemplate-00.txt [EAP-TLS] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [EKMF] Aboba, B. et al., "EAP Key Management Framework", Bersani Expires û October 2004 [Page 33] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 Internet-Draft (work in progress), October 2003, draft-ietf-eap-keying-01.txt [HTTP-Digest] Franks, J. et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999 [IANA] Internet Assigned Numbers Authority, "Point-to-Point Protocol Field Assignments/PPP EAP Request/Response Types", http://www.iana.org/assignments/ppp-numbers [Identix] http://www.identix.com/ [IEEE 802.1X] IEEE STD 802.1X, Standards for Local and Metropolitan Area Networks: Port Based Access Control, June 14, 2001 [IEEE 802.11] Institute of Electrical and Electronics Engineers, "Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Network - Specific Requirements û Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11 [IEEE 802REQ] Stanley, Dorothy et al., ôEAP Method Requirements for Wireless LANsö, Internet-Draft (work in progress), January 2004, draft-walker-ieee802-req-00.txt [LEAP] Macnally, C., ôCisco LEAP protocol descriptionö, September 2001 [LEAPVUL] Wright, J., ôWeaknesses in LEAP Challenge/Responseö, Defcon 2003 [MDx] Preneel, B. and van Oorschot P. C., "MDx-MAC and Building Fast MACs from Hash Functions", Proceedings of Crypto'95, Springer-Verlag, LNCS, August 1995 [MSCHAPVUL] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", CQRE '99, Springer-Verlag, 1999, http://www.schneier.com/paper-pptpv2.pdf [PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RSA SecurID] D. Liberman (RSA Security), Bersani Expires û October 2004 [Page 34] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 dliberman@rsasecurity.com, Personal Communication, March 2004 [Securesuite] http://www.iosoftware.com/pages/Products /SecureSuite%20XS/index.asp [SentriNET] J. Kelleher (ISL Biometrics), joe.kelleher@isl-biometrics.com, Personal Communication, March 2004 [SRP] The Stanford SRP Authentication Project, http://srp.stanford.edu/ [SRPpres] Wu, T., "Secure Remote Password Authentication", NDSS 98 , http://srp.stanford.edu/ndss98s.ps [ZoneLabs] D. Bogue (ZoneLabs), dbogue@zonelabs.com, Personal Communication, March 2004 [3com] http://www.3com.com 9. Authors' Addresses Florent Bersani florent.bersani@francetelecom.com France Telecom R&D 38, rue du General Leclerc 92794 Issy Les Moulineaux Cedex 9 France 10. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Bersani Expires û October 2004 [Page 35] INTERNET-DRAFT EAP Shared Key Methods Synthesis April 2004 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Bersani Expires û October 2004 [Page 36]