SECMECH BOF EAP Methods IETF-63 Jari Arkko

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

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 2716 Existing RFC EAP SIM (18) draft-haverinen 3GPP RFC-to-be EAP AKA (23) draft-arkko 3GPP RFC-to-be

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

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

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

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

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

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

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

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

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

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

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

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)

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

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