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

2. 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

3. 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

4. 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

5. 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
Many “implementations in progress” not ready to fill out survey yet
IEEE 802: 802.3, 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

6. 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

7. 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

8. Allocated EAP Type#’s March 2002 Bernard Aboba, Microsoft
Type Description Reference Implemented? Spec Available?
Identity [RFC2284] Yes RFC 2284
Notification [RFC2284] Yes RFC 2284
NAK (Response only) [RFC2284] Yes RFC 2284
MD5-Challenge [RFC2284] Yes RFC 2284
One Time Password (OTP) [RFC2284] No RFC 2284
Generic Token Card [RFC2284] No RFC 2284
No No
No No
RSA Public Key Authentication [Whelan] No Expired
DSS Unilateral [Nace] Yes I-D?
KEA [Nace] Yes I-D?
KEA-Validate [Nace] Yes I-D?
EAP-TLS [Aboba] Yes RFC 2716
Defender Token (AXENT) [Roselli] Yes No
Windows 2000 EAP [Asnes] ? No
Arcot Systems EAP [Jerdonek] ? No
EAP-Cisco Wireless [Norman] Yes No
Nokia IP smart card auth [Haverinen] ? No
SRP-SHA1 Part [Carlson] Yes I-D
SRP-SHA1 Part [Carlson] No I-D
EAP-TTLS [Funk] Yes I-D
Remote Access Service [Fields] ? No
UMTS Auth and Key agreement [Haverinen] ? ?
EAP-3Com Wireless [Young] Yes No
PEAP [Palekar] Yes I-D
MS-EAP-Authentication [Palekar] Yes No
Mutual auth w/key exchange (MAKE) [Berrendonner] ? No
CRYPTOCard [Webb] Yes No
EAP-MSCHAP-V [Potter] ? I-D
DynamID [Merlin] ? No
Rob EAP [Ullah] ? No
Bernard Aboba, Microsoft

9. 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

10. 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 allocated by Standards Action
Method Types
Method Types 1-31 already allocated by IANA
Method Types allocated via “Expert Review” with specification required
Method Types reserved; allocation requires Standards Action
Bernard Aboba, Microsoft

11. 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 are exhausted
May require inclusion in a separate document, so RFC 2284bis can advance to Draft Standard
Bernard Aboba, Microsoft

12. 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

13. 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

14. “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
Disassociate an alternate indication of Failure?
Result: If Success or Failure are lost: Timeout or worse!
Bernard Aboba, Microsoft

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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 ?
EAPOL-Start: needed in ?
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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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 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

30. 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

31. 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

32. March 2002
Feedback?
Bernard Aboba, Microsoft