1 / 17

SECMECH BOF EAP Methods

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.

geordi
Télécharger la présentation

SECMECH BOF EAP Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SECMECH BOFEAP 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 2716 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 • 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. 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. 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 • 802.11 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

More Related