EAP Usage Issues

1. EAP Usage Issues Feb 05 Jari Arkko

2. Typical EAP Usage • PPP authentication • Wireless LAN authentication • 802.1x and 802.11i • IKEv2 EAP authentication mode • Client side only, server authenticated with a cert • Universal Mobile Access technology will use this • PANA • Initial deployment is for DSL

3. Main EAP-related IETF WGs • EAP WG • AAA & RADEXT WGs • Transport of EAP over AAA • PANA WG • Defines the use of EAP in an IP-layer version of 802.1X • IPsec WG • Defined the use of EAP in IKEv2

4. Other EAP-related IETF WGs 1 • MIP6 WG • Problem to solve is “bootstrapping” • This is about how to (a) find a home agent and (b) set up a security association with it so that the mobile node can use the home agent’s services • Want to avoid deployment problem of yet another configuration and secret just because you want to be mobile • One approach is the integration of EAP in some form to the protocol • Another approach is the use of keying material derived by EAP • A third approach is to use IKEv2 • Zero-config solutions could perhaps be developed as well (e.g., based on SEND certificates or CGA)

5. Other EAP-related IETF WGs 2 • DHCP WG • ?

6. Other EAP-related IETF WGs 3 • NSIS WG • ?

7. Other EAP-related IETF WGs 4 • ISMS WG • ?

8. Other EAP-related IETF WGs 5 • SIP WG • Many years ago, suggested the use of EAP in application protocol • Decided to go for support of a legacy credential inside HTTP Digest instead (RFC 3310, Digest AKA) • Positive experience -- simple, clean • Others?

9. EAP Applicability Statement • EAP was created for network access • RFC 3748 has an applicability statement: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.

10. EAP Applicability Statement 2 Since EAP does not require IP connectivity, it provides just enough support for the reliable transport of authentication protocols, and no more. EAP is a lock-step protocol which only supports a single packet in flight. As a result, EAP cannot efficiently transport bulk data, unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960]. While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so out of order reception is not supported. Since EAP does not support fragmentation and reassembly, EAP authentication methods generating payloads larger than the minimum EAP MTU need to provide fragmentation support.

11. Deployment Problem • The crux in deploying security seems often to be configuration, or setting up the shared secrets and/or certificates • Much of this cost is in the people and physical transaction process, not equipment or software • Exercise 1: ask your corporate manager to deploy an additional per-user token or secret • Exercise 2: calculate the investment to change all SIM cards to better ones (which are available) • N = 1.5 * 10^9, cost per user perhaps 20 $

12. Deployment Problem 2 • Good solutions are solicited! • Making things zero-config is useful • In limited applications this has been possible • HIP, MULTI6, SEND • One-sided configuration • Web-server certs and TLS • SEND router certificates • Weaker bootstrap phase • SSH, SIP signaling end-to-end security • Sharing the same credentials

13. Deployment Problem 3 • Are the protocols sufficient & secure for you to actually share credentials with with some other purpose? • Need to look for some non-trivial issues, such as the binding problem • Need to think whether our solutions are secure in theory, or also in practise • Do the credentials that you shared with another purpose really exist for a large part of the user base?