EAP WG IETF 55 Atlanta, GA

EAP WG Meeting Monday, Salon II Preliminaries (10 minutes) –Bluesheets, minutes –Document Status RFC 2284 Bis EAP Design Team Report, Jari Arkko (5 minutes) IEEE 802.1aa D4 reconciliation, Paul Congdon (5 minutes) username: p8021, password: go_wildcats RFC 2284bis Open issues, Bernard Aboba (15 minutes) EAP state machine, Bryan Payne & Nick Petroni (10 minutes) EAP state machine, John Vollbrecht (10 minutes)

Monday agenda, continued EAP TLV method, Glen Zorn (5 minutes) EAP IANA considerations, Bernard Aboba (10 minutes) 02.txt EAP Security EAP Binding Problem, V. Lortz (10 minutes) 00.txt EAP Binding Problem, H. Haverinen (10 minutes) EAP Binding Problem, H. Krawczyk (10 minutes)

EAP WG Meeting Tuesday, Salon B EAP keying problem, Bernard Aboba (10 minutes) EAP Methods EAP security claims, Glen Zorn (10 minutes) Smart card support, Pascal Urien (5 minutes) EAP SIM, Henry Haverinen (5 minutes) EAP AKA, Henry Haverinen (5 minutes) EAP GSS, Bernard Aboba (5 minutes) EAP Roadmap EAP Roadmap Discussion (10 minutes)

Document Status WG work items –RFC 2284bis draft-ietf-pppext-rfc2284bis-07.txt draft-ietf-eap-otp-00.txt –Eap StatE machinE dEsign teaM (ESTEEM) Draft-ietf-eap-esteem-00.txt Individual submissions –EAP Keying Problem draft-aboba-pppext-key-problem-03.txt

Goals and Milestones Dec 02 RFC 2284bis submitted for publication as Proposed Standard RFC –IANA considerations –State machine –Security considerations –Type space expansion –OTP, GTC Jun 03 EAP Keying problem doc submitted for publication as Informational RFC.

RFC 2284bis

Goals for RFC 2284bis Understanding behavior of current implementations –EAP Implementation Survey Documenting features of EAP implementations –Interoperability testing Documenting interoperation of each feature by at least 2 independent implementations Recycling RFC 2284 at Proposed Standard –Clarifying interoperability issues within the specification –Recognizing support for multiple media PPP, IEEE 802, PIC (EAP over UDP) –Describing the EAP operational model –Security considerations –IANA considerations

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

Interoperability Testing Opportunities CIUG –Results of past EAP interoperability tests? –Plans for additional tests? Interop –Testing of IEEE 802.1X on the “Interop net”

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

Implications for RFC 2284bis Generic token card, OTP EAP methods now documented in separate draft –Draft-ietf-eap-otp-00.txt –Given no implementations, OTP & GTC will remain at proposed standard RFC 2284bis may need to cut additional features –We’ll cross that bridge once we come to it

RFC 2284bis Issues

RFC 2284bis Issues Process Issues represent a request for a specific change to the RFC 2284bis document. –Not just a “question” –Not just a description of the problem – but text for a solution! Issues sent to in the following –Description of issue Submitter name: Your_Name_Here Submitter address: Your_ _Address_Here Date first submitted: Insert_Date_Here Reference: URL to describing problem, if available Document: Document Requiring change [RFC2284bis, RFC 2869bis, Keying Framework] Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal Issues list kept at: –

Issues Report 42 Issues raised so far RFC 2284bis (37) –20 resolved –3 rejected –14 still open RFC 2869bis (2) –2 resolved EAP keying framework (2) –2 still open EAP state machine (1) –1 still open

Observations Closed/still open ratio is not very good Open 6 months or more: Issues 2,7,10,14,23,25,26,32 Relatively little discussion on posted RFC 2284bis issues If this continues, EAP WG will miss milestones by a considerable margin Have to pick up the pace!

RFC 2284bis Open Issues Alternative indications (#2) Authentication sequences (#7) Acknowledged Success/Failure (#10) Identifier usage (#13) EAP Transport behavior (#14) Identifier behavior (#18) Identity Request Payload (#23) Spoofing and duplicate detection (#25) Unprotected success and failure (#26) Keying confirmation (#32) Language negotiation (#38) Man-in-the-middle attacks (#40) NAK of Vendor-specific (#41) EAP enhancements (#42)

Alternate Indications (#2) 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.” –Result: If Success or Failure are lost: Timeout or worse! Lower layers have different “alternate indications” –PPP LCP-Terminate, carrier loss an alternate indication of Failure NCP an alternate indication of success –IEEE 802 Carrier sense an alternate indication of Failure No alternate indication of Success –IEEE Disassociate, Deauthenticate, EAPOL-Logoff an alternate indication of Failure Association/Reassociation response an alternate indication of success

EAP Transport Behavior (#14) 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

Identifier Behavior (#18) 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 conversation? 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!

Identity Request Payload (#23) RFC 2284 does not define what is included in the Identity Request payload EAP peer typically obtains information about the available networks out of band –PPP: via dialup client –802.11: via Beacon, Probe Responses –PANA: via CAR? Does the peer need additional hints in the Identity Request? –If so, what? –Can the information be provided in other ways? Example: SSID OID proposed in EAP TLS cert profile

Duplicate Detection (#25) 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

EAP Type Multiplexing 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

EAP Type MultiplexingEAPLayer MethodLayer MediaLayer MethodPrimitives PPP Type= Identity, Notification Code =Success, Failure Type=Foo FooFoo Type=Bar Type=NAK

IANA Considerations

Allocated EAP Type#’s Type Description Reference Implemented? Spec Available? Identity [RFC2284] Yes RFC Notification [RFC2284] Yes RFC NAK (Response only) [RFC2284] Yes RFC MD5-Challenge [RFC2284] Yes RFC One Time Password (OTP) [RFC2284] No RFC Generic Token Card [RFC2284] No RFC 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 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 32SecurID EAP [Josefsson] Yes I-D 33EAP TLV [Palekar] Yes I-D 34SentriNet [Kelleher] Yes No 35Actiontec Wireless [Chang] ? No 36Congent Systems Biometric [Xiong] ? No

Some Observations Rate of Method Type allocation is increasing –36 Type values allocated since March 1998 –4 Type values allocated in the last 3 months 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!

Proposed IANA Considerations Included in RFC 2284bis –Separated out in draft-aboba-pppext-eap-iana-02.txt Packet Codes –Codes 1-4 described in RFC 2284 –Codes allocated by Standards Action Method Types –Method Types 1-36 already allocated by IANA –Method Types allocated via Designated Expert w/specification required –Method Types reserved; allocation requires Standards Action –Method 255 for Vendor-Specific extensions when no interoperability is deemed useful –More than one type code at a time requires IETF Consensus

Vendor-Specific Support 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

Questions Should IANA considerations be kept within RFC 2284bis or progressed separately? –Separation might enable more rapid implementation of IANA considerations What should method allocation be?