doc.: IEEE 802.11-00/382 Bernard Aboba Microsoft November 2000 March 2002 EAP Update Bernard Aboba Microsoft Bernard Aboba, Microsoft David Halasz, Cisco

Original Goals for RFC 2284bis March 2002 Original Goals for RFC 2284bis Advancing EAP to IETF Draft Standard EAP Implementation Survey Documenting features of EAP implementations Interoperability testing Documenting interoperation of each feature by at least 2 independent implementations Clarifying interoperability issues within the specification Recognizing support for multiple media PPP, IEEE 802, PIC (EAP over UDP) Bernard Aboba, Microsoft

Non-Goals Re-writing EAP from scratch March 2002 Non-Goals Re-writing EAP from scratch This is not EAPng! Making non-backward compatible changes to EAP Revising RADIUS RFC2869bis is needed, but not part of this effort Revising IEEE 802.1X IEEE 802.1X revision PAR (aa) in progress Bernard Aboba, Microsoft

Interoperability Testing Opportunities March 2002 Interoperability Testing Opportunities CIUG Results of past EAP interoperability tests? Plans for additional tests? Interop Las Vegas, May 2002 Will be testing IEEE 802.1X on the “Interop net” Bernard Aboba, Microsoft

March 2002 EAP Survey Results Survey requests sent out to PPPEXT, IEEE 802.1X mailing lists in early June 2001 Implementations covered in responses: 2 PPP 2 IEEE 802.3 1 IEEE 802.11 Many “implementations in progress” not ready to fill out survey yet IEEE 802: 802.3, 802.11 implementations Other: PIC Other potential uses of EAP: Hiperlan2, Bluetooth Will resend survey request Features not implemented: EAP OTP, Generic Token card Default retransmission timer of 6 seconds Allowing for loss of EAP Success and Failure packets via alternative indications Display of Notification to user and use to indicate invalid authentication attempt Bernard Aboba, Microsoft

Implications for RFC 2284bis March 2002 Implications for RFC 2284bis Generic token card, OTP EAP methods now documented in separate draft Draft-ietf-pppext-otp-01.txt Given no implementations, will remain at proposed standard, while RFC2284bis advances RFC 2284bis may need to cut additional features We’ll cross that bridge once we come to it Bernard Aboba, Microsoft

Areas for Clarification March 2002 Areas for Clarification IANA considerations Lower layer assumptions Method negotiation Transport assumptions Duplicate detection Identifier clarifications “Novel” uses of EAP messages Security issues Cryptographic protection of EAP Bernard Aboba, Microsoft

Allocated EAP Type#’s March 2002 Bernard Aboba, Microsoft Type Description Reference Implemented? Spec Available? ---- ----------- --------- ------------ --------------- 1 Identity [RFC2284] Yes RFC 2284 2 Notification [RFC2284] Yes RFC 2284 3 NAK (Response only) [RFC2284] Yes RFC 2284 4 MD5-Challenge [RFC2284] Yes RFC 2284 5 One Time Password (OTP) [RFC2284] No RFC 2284 6 Generic Token Card [RFC2284] No RFC 2284 7 No No 8 No No 9 RSA Public Key Authentication [Whelan] No Expired 10 DSS Unilateral [Nace] Yes I-D? 11 KEA [Nace] Yes I-D? 12 KEA-Validate [Nace] Yes I-D? 13 EAP-TLS [Aboba] Yes RFC 2716 14 Defender Token (AXENT) [Roselli] Yes No 15 Windows 2000 EAP [Asnes] ? No 16 Arcot Systems EAP [Jerdonek] ? No 17 EAP-Cisco Wireless [Norman] Yes No 18 Nokia IP smart card auth [Haverinen] ? No 19 SRP-SHA1 Part 1 [Carlson] Yes I-D 20 SRP-SHA1 Part 2 [Carlson] No I-D 21 EAP-TTLS [Funk] Yes I-D 22 Remote Access Service [Fields] ? No 23 UMTS Auth and Key agreement [Haverinen] ? ? 24 EAP-3Com Wireless [Young] Yes No 25 PEAP [Palekar] Yes I-D 26 MS-EAP-Authentication [Palekar] Yes No 27 Mutual auth w/key exchange (MAKE) [Berrendonner] ? No 28 CRYPTOCard [Webb] Yes No 29 EAP-MSCHAP-V2 [Potter] ? I-D 30 DynamID [Merlin] ? No 31 Rob EAP [Ullah] ? No Bernard Aboba, Microsoft

Some Observations Rate of Method Type allocation is increasing March 2002 Some Observations Rate of Method Type allocation is increasing 31 Type values allocated since March 1998 4 Type values allocated in the last month Two Method Type values allocated to the same Method EAP SRP-SHA1 Parts 1 and 2 Most allocations are for vendor-specific use with no specification Not all allocated Method Types are used At least 5 of the allocated types have not been implemented (~15 percent!) Conclusion At present rate of allocation, EAP Type space could be exhausted within a few years EAP Method Type space is a finite resource (255) - could probably be managed more effectively IANA considerations needed! Bernard Aboba, Microsoft

Proposed IANA Considerations March 2002 Proposed IANA Considerations draft-aboba-pppext-eap-iana-01.txt Packet Codes Codes 1-4 described in RFC 2284 Codes 5-255 allocated by Standards Action Method Types Method Types 1-31 already allocated by IANA Method Types 32-191 allocated via “Expert Review” with specification required Method Types 192-254 reserved; allocation requires Standards Action Bernard Aboba, Microsoft

Vendor-Specific Support March 2002 Vendor-Specific Support Draft-aboba-pppext-vendor-01.txt Method Type 255 reserved for (optional) Vendor-Specific use and Type expansion Goal is to push exhaustion of EAP Type space out several years Expanded Type space (256+) allocated after Types 32-191 are exhausted May require inclusion in a separate document, so RFC 2284bis can advance to Draft Standard Bernard Aboba, Microsoft

Method Negotiation NAK allows only one alternate method to be returned March 2002 Method Negotiation NAK allows only one alternate method to be returned If client supports several methods (some of which server doesn’t support), can result in a long negotiation Example Client supports MD5, SRP, AKA, TTLS Server supports MD5, SIM, LEAP S: SIM; C: NAK-SRP; S: LEAP, C: NAK-AKA; S: MD5 Can we allow multiple methods to be included in a NAK? Would this break existing implementations? Initial investigation: probably backward compatible Bernard Aboba, Microsoft

EAP Lower Layer Assumptions March 2002 EAP Lower Layer Assumptions One to one conversation PPP (only two parties) IEEE 802 (not supported on shared media w/o cryptographic protection) Non-forwardable multicast destination can be used to locate endpoints, after which unicast is used Known MTU EAP does not support fragmentation, but individual methods do Framed-MTU attribute provided by NAS to AAA server to prevent fragmentation Unreliable lower layer EAP handles retransmission Default retransmission timer of 6 seconds (typically set lower) No retransmission strategy specified (RTO not a function of RTT) Unordered delivery EAP is a “lockstep” protocol – only one packet in flight at a given time Identifier field often incremented Misordering can occur, but is detectable Limited non-duplication of packets EAP-Responses are not retransmitted Duplicate EAP-Responses are possible Implies that peers, authenticators must be capable of duplicate detection Implies that lower layer should provide a non-duplicated stream of packets (e.g. EAP over PIC) Bernard Aboba, Microsoft

“Alternate Indications” March 2002 “Alternate Indications” The most infamous lower layer assumption of RFC 2284 Success and Failure messages are not ACK’d: “Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. The peer can use a Network Protocol packet as an alternative indication of Success. Likewise, the receipt of a LCP Terminate-Request can be taken as a Failure.” Problems PPP specific – but not supported in existing PPP implementations! Will have to be deleted unless two interoperable implementations can be found (seems unlikely) Other lower layers do not have “alternate indications” IEEE 802 Carrier sense an alternate indication of Failure? No alternate indication of Success IEEE 802.11 Disassociate an alternate indication of Failure? Result: If Success or Failure are lost: Timeout or worse! Bernard Aboba, Microsoft

Possible Approaches Don’t worry, be happy “Remove” March 2002 Possible Approaches Don’t worry, be happy Assume EAP always implemented over highly reliable media, can live with occasional timeout IEEE 802: wired media with very low packet loss IP: TCP or UDP w/retransmission Document “alternate indications” such as they exist for various media “Remove” “Alternate indications” is not a useful concept for many media It isn’t implemented anyway, so it needs to be removed from RFC 2284bis Not necessary to ACK Success or Failure messages, so don’t need fix Bernard Aboba, Microsoft

Possible Approaches (cont’d) March 2002 Possible Approaches (cont’d) “Remove and Fix” UnACK’d Success and Failure messages will eventually bite us Wireless networks w/fading Cryptographic protection of EAP Remove “alternate indications” text Add support for ACK’d Success and Failure messages Can be implemented as new EAP Types EAP-Request/Success, EAP-Response/Success EAP-Request/Failure, EAP-Response/Failiure Used where support is likely Within EAP types known to support it Within media known to support it Can be NAK’d by implementations that don’t support it Would require documentation in separate draft if RFC 2284bis goes to Draft standard Bernard Aboba, Microsoft

Transport Assumptions March 2002 Transport Assumptions EAP is an ACK/NAK protocol Only one packet in flight at a time But some methods assume that additional Requests can be sent without a Response EAP is driven by the authenticator Responses cannot be retransmitted, only Requests Success/Failure not ACK’d nor retransmitted RADIUS server does not retransmit (NAS responsibility) But some methods assume RADIUS server retransmission, ACK’ing of Success/Failure EAP transport characteristics not defined in RFC 2284 RTO default = 6 seconds (for human interaction) No exponential backoff No defined retransmission strategy When running over IP, EAP retransmission can conflict with transport retransmissions Bernard Aboba, Microsoft

Duplicate Detection EAP retransmission behavior Interactions with AAA March 2002 Duplicate Detection EAP retransmission behavior NAS retransmits EAP-Requests Client never re-transmits EAP-Responses on its own NAS retransmission doesn’t take RTT into account Result NAS can retransmit before it is assured that EAP-Request has been lost Client can send duplicate EAP-Responses Interactions with AAA In RADIUS, NAS is responsible for retransmissions No AAA server-initiated messages AAA server does not retransmit If NAS doesn’t detect and discard duplicates, can send duplicate Access-Requests to AAA server If done in the middle of EAP conversation, can cause problems on AAA server Bernard Aboba, Microsoft

Identifier Clarifications March 2002 Identifier Clarifications Identifier is unique per port, not per NAS Ongoing authentications per NAS not limited to 256 Guidelines for Identifier selection Start from 1 or random selection? Can identifier wrap within a session? Is Identifier monotonically increasing or just unique within the maximum time to live? Example issue AAA server sends Accept with Reply-Message and EAP-Message attributes If Reply-Message translated to EAP-Notification, EAP authenticator needs to “create” an Identifier for it Assumption is that EAP-Request/EAP-Notification is sent, followed by receipt of EAP-Response/EAP-Notification, then EAP-Message attribute is decapsulated and sent But EAP-Message attribute already contains an Identifier! Bernard Aboba, Microsoft

Novel Uses of EAP Messages March 2002 Novel Uses of EAP Messages Proposed EAP methods use NAK and Notification in “novel” ways NAK used for version negotiation within the EAP method Notification used for Nonce exchange Some proposed methods have placed data in EAP Success/Failure Success/Failure are not ACK’d, so data may never arrive 802.1X “manufactures success/failure, so data, if present will be thrown away Not explicitly prohibited by RFC 2284, but unlikely to interoperate either Might work in a monolithic EAP implementation, but not in a layered one No description of EAP type multiplexing in RFC 2284 Bernard Aboba, Microsoft

EAP Type Multiplexing Method Layer Foo EAP Layer Media Layer Driver March 2002 EAP Type Multiplexing Method Layer Foo EAP APIs Type= Identity, Notification Code =Success, Failure EAP Layer Type= Bar Type= Foo Type= NAK Driver APIs Media Layer PPP 802.3 802.5 802.11 Bernard Aboba, Microsoft

March 2002 Security Issues Should mutual authentication be mandatory in some situations? Wireless Use over the Internet Mandatory to implement method (EAP-MD5) is one-way What happens if EAP Success is sent prior to completion of server authentication? In RFC 2716 client terminates the conversation if server fails authentication Client MUST NOT accept this message! Should IEEE 802.1X change the state machine to not always accept the Success? Denial of service attacks EAPOL-Logoff: needed in 802.11? EAPOL-Start: needed in 802.11? Identifier exhaustion: Identifier is per port, not per NAS Spoofing of EAP Failure or Success: solution is cryptographic protection Modification attacks EAP header modification: solution is cryptographic protection Modification of NAK or Notification: solution is cryptographic protection Bernard Aboba, Microsoft

Cryptographic Protection March 2002 Cryptographic Protection EAP originally created for use with wired link layers But now being applied to wireless, use over the Internet EAP vulnerable to attackers with media access Individual methods protect their exchanges, but… Some methods vulnerable to dictionary attack Basic EAP messages sent unprotected and in the clear: Identity exchange (Identity) Method negotiation (NAK) Error messages (Notification) Success/Failure indication Should cryptographic protection of EAP be mandated in some (many) situations? Bernard Aboba, Microsoft

Key Management Issues Draft-aboba-pppext-key-problem-01.txt March 2002 Key Management Issues Draft-aboba-pppext-key-problem-01.txt Questionable key management in proposed EAP methods Unproven techniques proposed for key management No description of key hierarchy Insufficient entropy for key generation Ciphersuite-specific key handling specified within EAP methods Lesson: Secure key management is hard to do correctly Solutions: Guidelines for key generation in EAP methods Just say no: EAP methods should not generate their own keys, should reuse well reviewed key generation techniques instead Bernard Aboba, Microsoft

Cryptographic Protection Approach March 2002 Cryptographic Protection Approach Create a secure channel within which EAP conversation can be transported Provides encryption, integrity protection of EAP messages Makes it harder to spoof or modify EAP conversation Lessens dictionary attack vulnerability Support for identity protection Provide a single, well reviewed method for key management Allows EAP methods to focus on authentication Support for “fast reconnect” Ability to re-authenticate without public key operations (no PFS) Support for fragmentation and reassembly No need for EAP method to handle this itself Can be backward compatible with 802.1X and EAP Implemented as a new EAP method Client can NAK if not supported Examples PIC (EAP protected in ISAKMP) EAP TTLS (EAP protected in TLS) PEAP (EAP protected in TLS) Bernard Aboba, Microsoft

Cryptographic Protection Issues March 2002 Cryptographic Protection Issues Goal of cryptographic protection is to protect the entire EAP exchange Identity, method negotiation (NAK), Notification, Success/Failure messages Messages within the individual EAP Methods, too Last message sent by AAA server is typically encrypted EAP Success encapsulated in Access Accept 802.1X Authenticators implementing “manufactured Success” will replace encrypted Success with cleartext Success Possible solutions Add ACK’d Success/Failure messages as new Types Send EAP-Request/Success within the encrypted channel Receive EAP-Response/Success Send cleartext EAP-Success as last message Adds a round-trip on every authentication (even fast reconnect!) Enables removal of requirement for “alternative indications” Require Authenticator to “pass through” final message Would save a round-trip per authentication, but would not allow removal of “alternative indications” Would require changes in 802.1X Bernard Aboba, Microsoft

March 2002 Questions to Ponder How do these cryptographic protection methods differ? What problems do they solve? Should the IETF standardize: None of them? One of them? More than one? Should some (many?) EAP methods be required to run over a “protection layer”? If so, which ones? When is this required? Bernard Aboba, Microsoft

EAP Architecture? Protection Layer TLS SRP Protection Layer EAP Layer March 2002 EAP Architecture? AKA/SIM GSS Protection Layer TLS SRP Protection Layer EAP APIs EAP Layer Driver APIs Media Layer PPP 802.3 802.5 802.11 Bernard Aboba, Microsoft

Next Steps Solicit additional implementation surveys March 2002 Next Steps Solicit additional implementation surveys Document bakeoff results Revisit goals for RFC 2284bis Still aimed at Draft Standard? If so, no room for feature addition Interoperability verification likely to take 18-24 months Clarifications may be needed sooner Candidates for separate draft (or inclusion in a recycled Proposed Standard) Vendor-Specific, Type Expansion ACK’d Success/Failure Method negotiation EAP State Machine Bernard Aboba, Microsoft

Proposed EAP WG Charter March 2002 Proposed EAP WG Charter The EAP working group will restrict itself to the following short-term work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations. 2. Threat model and security considerations. 3. EAP state machine. 4. Clarification and documentation of EAP keying issues 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. Interaction of EAP and AAA 8. Type space extension to support an expanded Type space. 9. EAP applicability statement Bernard Aboba, Microsoft

Goals and Milestones Jun 02 IANA considerations draft to RFC Editor. March 2002 Goals and Milestones Jun 02 IANA considerations draft to RFC Editor. Jun 02 EAP type extension section for RFC 2284bis. Jun 02 EAP Security considerations section for RFC 2284bis. Jun 02 EAP state machine section for RFC 2284bis. Sep 02 RFC 2869bis published as Proposed Standard RFC. Sep 02 RFC 2284bis published as Proposed Standard RFC. Sep 02 EAP applicability statement published as Informational RFC. Sep 02 EAP keying issues doc published as Informational RFC. Bernard Aboba, Microsoft

March 2002 Feedback? Bernard Aboba, Microsoft