1. 1 SECMECH BOF EAP Methods IETF-63 Jari Arkko

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

3. 3 EAP methods NamePublicationDemand Status MD5 (4)RFC2284bisExisting RFC OTP (5)RFC2284bisExisting RFC GTC (6)RFC2284bisExisting RFC EAP TLS (13)RFC 2716Existing RFC EAP SIM (18)draft-haverinen3GPP RFC-to-be EAP AKA (23)draft-arkko3GPP RFC-to-be

4. 4 EAP methods NamePublicationDemand Status EAP TTLS (21)draft-ietf-pppextVendor I-D PEAPv0/1/2 (25)draft-joseffson*Vendor I-D MSCHAPv2 (26)draft-kamathVendor Expired EAP SSC (-)draft-urienVendor I-D EAP GSS (-)draft-abobaVendor Expired EAP TLS SASL (-)draft-anderssonVendor Expired

5. 5 EAP methods NamePublicationDemand Status EAP MAKE (27)draft-berrendoVendor Expired EAP PSK (-)draft-bersaniVendor New I-D EAP FAST (43)draft-camVendor New I-D MD5 Tunneled (-)draft-funkVendor I-D EAP TLV (33)draft-josefsson*Vendor Expired EAP SRP-SHA1 (19)draft-ietf-pppextIETF Expired

6. 6 EAP methods NamePublicationDemand Status EAP SecurID (32)draft-josefssonVendor Expired EAP Archie (-)draft-jwalkerVendor Expired EAP Bluetooth (-)draft-kimVendor New I-D EAP LDAP (-)draft-manciniVendor Expired EAP SKE (-)draft-salgarelliVendor Expired EAP GPRS (-)draft-salkiVendor I-D

7. 7 EAP methods NamePublicationDemand Status EAP IKEv2 (-)draft-tschofenigVendor I-D EAP POTP (32)draft-nystromVendorI-D EAP KEA Valid. (12)-Vendor Undoc EAP Defender (14)-Vendor Undoc EAP SecurID (15)-Vendor Undoc EAP KEA (11)-Vendor Undoc

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

9. 9 EAP methods NamePublicationDemand 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. 10 EAP methods NamePublicationDemand Status EAP Digest (38)-Vendor Undoc EAP DevConn (40)-Vendor Undoc EAP MOBAC (42)-Vendor Undoc EAP ZoneLabs (44)-Vendor Undoc EAP SecureSuite (39)-Vendor Undoc EAP RSA PKA (9)-Vendor Undoc

11. 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 –Not good! 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. 12 Technical Requirements “Does not break EAP” (RFC 3748) Security documentation must exist –Mechanism –Key hierarchy –Security claims –Vulnerabilities See also RFC 4017 for 802.11 requirements

13. 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. 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. 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. 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 –802.11 AP -> VPN GW attack is currently possible

17. 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