SECMECH BOF EAP Methods

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 -gt 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 1990s
• OTOH, there is now interest, demands from SDOs,
  and new EAP usage gt 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 dont 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