March 2002
doc.: IEEE 802.1aa-02/XXX
EAP Update
Bernard Aboba
Microsoft
Submission
Slide 1
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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)
Submission
Slide 2
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 3
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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”
Submission
Slide 4
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 5
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 6
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 7
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
Allocated EAP Type#’s
Type
---1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Description
----------Identity
Notification
NAK (Response only)
MD5-Challenge
One Time Password (OTP)
Generic Token Card
Implemented?
-----------Yes
Yes
Yes
Yes
No
No
No
No
RSA Public Key Authentication
[Whelan]
No
DSS Unilateral
[Nace]
Yes
KEA
[Nace]
Yes
KEA-Validate
[Nace]
Yes
EAP-TLS
[Aboba]
Yes
Defender Token (AXENT)
[Roselli]
Yes
Windows 2000 EAP
[Asnes]
?
Arcot Systems EAP
[Jerdonek]
?
EAP-Cisco Wireless
[Norman]
Yes
Nokia IP smart card auth
[Haverinen]
?
SRP-SHA1 Part 1
[Carlson]
Yes
SRP-SHA1 Part 2
[Carlson]
No
EAP-TTLS
[Funk]
Yes
Remote Access Service
[Fields]
?
UMTS Auth and Key agreement
[Haverinen]
?
EAP-3Com Wireless
[Young]
Yes
PEAP
[Palekar]
Yes
MS-EAP-Authentication
[Palekar]
Yes
Mutual auth w/key exchange (MAKE) [Berrendonner]
?
CRYPTOCard
[Webb]
Yes
EAP-MSCHAP-V2
[Potter]
?
DynamID
[Merlin]
?
Rob EAP
[Ullah]
?
Submission
Reference
--------[RFC2284]
[RFC2284]
[RFC2284]
[RFC2284]
[RFC2284]
[RFC2284]
Slide 8
Spec Available?
--------------RFC 2284
RFC 2284
RFC 2284
RFC 2284
RFC 2284
RFC 2284
No
No
Expired
I-D?
I-D?
I-D?
RFC 2716
No
No
No
No
No
I-D
I-D
I-D
No
?
No
I-D
No
No
No
I-D
No
No
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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!
Submission
Slide 9
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 10
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
Vendor-Specific Support
• Draft-aboba-pppext-vendor-01.txt
• Method Type 255 reserved for (optional) VendorSpecific 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
Submission
Slide 11
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 12
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
EAP Lower Layer Assumptions
•
One to one conversation
–
–
PPP (only two parties)
IEEE 802 (not supported on shared media w/o cryptographic protection)
•
•
Known MTU
–
–
•
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 does not support fragmentation, but individual methods do
Framed-MTU attribute provided by NAS to AAA server to prevent fragmentation
Unreliable lower layer
–
–
–
•
Non-forwardable multicast destination can be used to locate endpoints, after which unicast is used
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)
Submission
Slide 13
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
“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?
– No alternate indication of Success
• Result: If Success or Failure are lost: Timeout or worse!
Submission
Slide 14
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 15
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 16
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 17
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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 AccessRequests to AAA server
– If done in the middle of EAP conversation, can cause problems on AAA server
Submission
Slide 18
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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!
Submission
Slide 19
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 20
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
EAP Type Multiplexing
Foo
Method
Layer
EAP
APIs
Type= Identity, Notification
Code =Success, Failure
Type=
NAK
Type=
Bar
EAP
Layer
Type=
Foo
Driver
APIs
PPP
Submission
802.3
802.5
Slide 21
802.11
Media
Layer
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 22
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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?
Submission
Slide 23
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 24
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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)
Submission
Slide 25
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 26
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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?
Submission
Slide 27
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
EAP Architecture?
AKA/SIM
TLS
SRP
GSS
Protection
Layer
Protection Layer
EAP
APIs
EAP
Layer
Driver
APIs
PPP
Submission
802.3
802.5
Slide 28
802.11
Media
Layer
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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)
•
•
•
•
Submission
Vendor-Specific, Type Expansion
ACK’d Success/Failure
Method negotiation
EAP State Machine
Slide 29
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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
Submission
Slide 30
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
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.
Submission
Slide 31
Bernard Aboba, Microsoft
March 2002
doc.: IEEE 802.1aa-02/XXX
Feedback?
Submission
Slide 32
Bernard Aboba, Microsoft