EAP WG

IETF 55Atlanta, GA

EAP WG Meeting Monday, Salon II 1530-1730Preliminaries (10 minutes)

– Bluesheets, minutes– Document Status

RFC 2284 Bis

• EAP Design Team Report, Jari Arkko (5 minutes)http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt

• IEEE 802.1aa D4 reconciliation, Paul Congdon (5 minutes)http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdfusername: p8021, password: go_wildcats

• RFC 2284bis Open issues, Bernard Aboba (15 minutes)http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt

• EAP state machine, Bryan Payne & Nick Petroni (10 minutes)http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.{ps,txt}

• EAP state machine, John Vollbrecht (10 minutes)http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-00.txt

Monday agenda, continued• EAP TLV method, Glen Zorn (5 minutes)

http://www.ietf.org/internet-drafts/draft-hiller-eap-tlv-00.txt

• EAP IANA considerations, Bernard Aboba (10 minutes)http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-02.txt

EAP Security

• EAP Binding Problem, V. Lortz (10 minutes)http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt

• EAP Binding Problem, H. Haverinen (10 minutes)http://www.saunalahti.fi/~asokan/research/mitm.html

• EAP Binding Problem, H. Krawczyk (10 minutes)

EAP WG Meeting Tuesday, Salon B 1700-1800• EAP keying problem, Bernard Aboba (10 minutes)

http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-03.txt

EAP Methods

• EAP security claims, Glen Zorn (10 minutes)http://www.ietf.org/internet-drafts/draft-zorn-eap-eval-00.txt

• Smart card support, Pascal Urien (5 minutes)http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-00.txt

• EAP SIM, Henry Haverinen (5 minutes)http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-07.txt

• EAP AKA, Henry Haverinen (5 minutes)http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-aka-06.txt

• EAP GSS, Bernard Aboba (5 minutes)http://www.ietf.org/internet-drafts/draft-aboba-pppext-eapgss-12.txt

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

• 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 eap@frascone.com in the following format:– Description of issue

Submitter name: Your_Name_Here Submitter email address: Your_Email_Address_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail 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:– http://www.drizzle.com/~aboba/EAP/eapissues.html

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 802.11• 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 Multiplexing

EAPEAPLayerLayer

MethodMethodLayerLayer

MediaMediaLayerLayer

MethodMethod

PrimitivesPrimitives

PPPPPP 802.3802.3 802.5802.5 802.11802.11

Type= Identity, Notification Type= Identity, Notification Code =Success, FailureCode =Success, Failure Type=Type=

FooFoo

FooFoo

Type=Type=BarBarType=Type=

NAKNAK

IANA Considerations

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] ? No32 SecurID EAP [Josefsson] Yes I-D33 EAP TLV [Palekar] Yes I-D34 SentriNet [Kelleher] Yes No35 Actiontec Wireless [Chang] ? No36 Congent 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 5-255 allocated by Standards Action

• Method Types– Method Types 1-36 already allocated by IANA– Method Types 37-191 allocated via Designated Expert w/specification required– Method Types 192-254 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

32-191 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?