1. SECMECH BOF EAP Methods
IETF-63
Jari Arkko

2. Outline Existing EAP methods Technical requirements
EAP WG process for new methods
Need for new EAP methods

3. EAP methods Name Publication Demand Status
MD5 (4) RFC2284bis Existing RFC
OTP (5) RFC2284bis Existing RFC
GTC (6) RFC2284bis Existing RFC
EAP TLS (13) RFC Existing RFC
EAP SIM (18) draft-haverinen 3GPP RFC-to-be
EAP AKA (23) draft-arkko 3GPP RFC-to-be

4. EAP methods Name Publication Demand Status
EAP TTLS (21) draft-ietf-pppext Vendor I-D
PEAPv0/1/2 (25) draft-joseffson* Vendor I-D
MSCHAPv2 (26) draft-kamath Vendor Expired
EAP SSC (-) draft-urien Vendor I-D
EAP GSS (-) draft-aboba Vendor Expired
EAP TLS SASL (-) draft-andersson Vendor Expired

5. EAP methods Name Publication Demand Status
EAP MAKE (27) draft-berrendo Vendor Expired
EAP PSK (-) draft-bersani Vendor New I-D
EAP FAST (43) draft-cam Vendor New I-D
MD5 Tunneled (-) draft-funk Vendor I-D
EAP TLV (33) draft-josefsson* Vendor Expired
EAP SRP-SHA1 (19) draft-ietf-pppext IETF Expired

6. EAP methods Name Publication Demand Status
EAP SecurID (32) draft-josefsson Vendor Expired
EAP Archie (-) draft-jwalker Vendor Expired
EAP Bluetooth (-) draft-kim Vendor New I-D
EAP LDAP (-) draft-mancini Vendor Expired
EAP SKE (-) draft-salgarelli Vendor Expired
EAP GPRS (-) draft-salki Vendor I-D

7. EAP methods Name Publication Demand Status
EAP IKEv2 (-) draft-tschofenig Vendor I-D
EAP POTP (32) draft-nystrom Vendor I-D
EAP KEA (11) - Vendor Undoc
EAP KEA Valid. (12)- Vendor Undoc
EAP Defender (14) - Vendor Undoc
EAP SecurID (15) - Vendor Undoc

8. EAP methods Name Publication Demand Status
EAP Arcot (16) - Vendor Undoc
Cisco LEAP (17) - Vendor Undoc
EAP RAS (22) - Vendor Undoc
EAP 3Com (24) - Vendor Undoc
EAP Microsoft (26) - Vendor Undoc
EAP CryptoCrd (28) - Vendor Undoc

9. EAP methods Name Publication Demand Status
EAP DynamID (30) - Vendor Undoc
EAP Rob (31) - Vendor Undoc
EAP Centrinet (34) - Vendor Undoc
EAP Actiontec (35) - Vendor Undoc
EAP Biometrics (36) - Vendor Undoc
EAP AirFortress (37) - Vendor Undoc

10. EAP methods Name Publication Demand Status
EAP Digest (38) - Vendor Undoc
EAP SecureSuite (39)- Vendor Undoc
EAP DevConn (40) - Vendor Undoc
EAP MOBAC (42) - Vendor Undoc
EAP ZoneLabs (44) - Vendor Undoc
EAP RSA PKA (9) - Vendor Undoc

11. Some observations A lot of methods, very few in RFCs
Not good!
Original, old EAP methods no longer suitable in wireless environment
Undocumented methods proliferate, IETF submissions delayed as long as four years
A lot of methods with similar intents
E.g. tunneling -- not good either!
A lot of methods with vendor background, a lot of expired methods
Status unknown

12. Technical Requirements
“Does not break EAP” (RFC 3748)
Security documentation must exist
Mechanism
Key hierarchy
Security claims
Vulnerabilities
See also RFC 4017 for requirements

13. Security Claims for EAP methods
Protected ciphersuite negotation
Mutual authentication
Integrity protection, replay protection, confidentiality
Key derivation, key strength
Dictionary attack resistance
Fast reconnect
Cryptographic binding
Session independence
Channel binding

14. EAP WG Process for New Method Type Codes
Either an official WG item or …
… an individual submission
All the usual rules for these RFCs apply
Also need to pass “expert review” that the technical requirements are satisfied and sufficient documentation exists
… a vendor-specific method

15. Need for New EAP Methods
Undocumented and vendor-specific methods is not a good sign for openness and interoperability of a major interface
EAP widely implemented and available, actual usage… not that big
But with WLAN phones, some 3G features, etc. the expectation is that a very large number of hosts will be using it
Currently there is NO method that can be made mandatory to implement
External SDO requirements (e.g. IEEE, TCG)

16. Some Interesting New EAP Methods
An update of RFC 2617 (EAP-TLS) to bring it to standards track and take care of nits & observations gathered over the years
A method that supports preshared secrets and generates keys (MD5 does not do the latter) -- e.g., EAP-PAX/PSK/IKEv2
Or a method that supports passwords
Better support for channel bindings
AP -> VPN GW attack is currently possible

17. Some Concluding Thoughts
It may be too late -- the IETF has been refusing to do this in various ways since the 1990’s
OTOH, there is now interest, demands from SDOs, and new EAP usage => we can still have an effect, if done now
The network access protocol stack is very important -- the IETF should worry about having an open, high-quality protocol set for this
But don’t open the flood gates -- focus on limited number of methods (1-3)
Integration of IETF auth frameworks is important, but network access application needs action now, not later