One document matched: draft-bersani-eap-synthesis-sharedkeymethods-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 03:32:27 |