EAP Update
description
Transcript of EAP Update
March 2002
Bernard Aboba, MicrosoftSlide 1
doc.: IEEE 802.1aa-02/XXX
Submission
EAP Update
Bernard Aboba
Microsoft
March 2002
Bernard Aboba, MicrosoftSlide 2
doc.: IEEE 802.1aa-02/XXX
Submission
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)
March 2002
Bernard Aboba, MicrosoftSlide 3
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 4
doc.: IEEE 802.1aa-02/XXX
Submission
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â
March 2002
Bernard Aboba, MicrosoftSlide 5
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 6
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 7
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 8
doc.: IEEE 802.1aa-02/XXX
Submission
Allocated EAP Type#âsType Description Reference Implemented? Spec Available?---- ----------- --------- ------------ ---------------1 Identity [RFC2284] Yes RFC 22842 Notification [RFC2284] Yes RFC 22843 NAK (Response only) [RFC2284] Yes RFC 22844 MD5-Challenge [RFC2284] Yes RFC 22845 One Time Password (OTP) [RFC2284] No RFC 22846 Generic Token Card [RFC2284] No RFC 22847 No No8 No No9 RSA Public Key Authentication [Whelan] No Expired10 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 271614 Defender Token (AXENT) [Roselli] Yes No15 Windows 2000 EAP [Asnes] ? No16 Arcot Systems EAP [Jerdonek] ? No17 EAP-Cisco Wireless [Norman] Yes No18 Nokia IP smart card auth [Haverinen] ? No19 SRP-SHA1 Part 1 [Carlson] Yes I-D 20 SRP-SHA1 Part 2 [Carlson] No I-D21 EAP-TTLS [Funk] Yes I-D22 Remote Access Service [Fields] ? No23 UMTS Auth and Key agreement [Haverinen] ? ?24 EAP-3Com Wireless [Young] Yes No25 PEAP [Palekar] Yes I-D26 MS-EAP-Authentication [Palekar] Yes No27 Mutual auth w/key exchange (MAKE) [Berrendonner] ? No28 CRYPTOCard [Webb] Yes No29 EAP-MSCHAP-V2 [Potter] ? I-D30 DynamID [Merlin] ? No31 Rob EAP [Ullah] ? No
March 2002
Bernard Aboba, MicrosoftSlide 9
doc.: IEEE 802.1aa-02/XXX
Submission
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!
March 2002
Bernard Aboba, MicrosoftSlide 10
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 11
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 12
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 13
doc.: IEEE 802.1aa-02/XXX
Submission
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)
March 2002
Bernard Aboba, MicrosoftSlide 14
doc.: IEEE 802.1aa-02/XXX
Submission
â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!
March 2002
Bernard Aboba, MicrosoftSlide 15
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 16
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 17
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 18
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 19
doc.: IEEE 802.1aa-02/XXX
Submission
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!
March 2002
Bernard Aboba, MicrosoftSlide 20
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 21
doc.: IEEE 802.1aa-02/XXX
Submission
EAP Type Multiplexing
EAPEAPLayerLayer
MethodMethodLayerLayer
MediaMediaLayerLayer
DriverDriver
APIsAPIs
EAP EAP
APIsAPIs
PPPPPP 802.3802.3 802.5802.5 802.11802.11
Type= Identity, Notification Type= Identity, Notification
Code =Success, FailureCode =Success, Failure Type=Type=
FooFoo
FooFooFooFoo
Type=Type=
BarBarType=Type=
NAKNAK
March 2002
Bernard Aboba, MicrosoftSlide 22
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 23
doc.: IEEE 802.1aa-02/XXX
Submission
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?
March 2002
Bernard Aboba, MicrosoftSlide 24
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 25
doc.: IEEE 802.1aa-02/XXX
Submission
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)
March 2002
Bernard Aboba, MicrosoftSlide 26
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 27
doc.: IEEE 802.1aa-02/XXX
Submission
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?
March 2002
Bernard Aboba, MicrosoftSlide 28
doc.: IEEE 802.1aa-02/XXX
Submission
EAP Architecture?
EAPEAPLayerLayer
ProtectionProtectionLayerLayerTLSTLSTLSTLS
MediaMediaLayerLayer
DriverDriver
APIsAPIs
EAP EAP
APIsAPIs
PPPPPP 802.3802.3 802.5802.5 802.11802.11
Protection LayerProtection LayerProtection LayerProtection LayerSRPSRPSRPSRP
AKA/SIMAKA/SIMAKA/SIMAKA/SIM GSSGSSGSSGSS
March 2002
Bernard Aboba, MicrosoftSlide 29
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 30
doc.: IEEE 802.1aa-02/XXX
Submission
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
March 2002
Bernard Aboba, MicrosoftSlide 31
doc.: IEEE 802.1aa-02/XXX
Submission
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.
March 2002
Bernard Aboba, MicrosoftSlide 32
doc.: IEEE 802.1aa-02/XXX
Submission
Feedback?