EAP Update

1
EAP Update

• Bernard Aboba
• Microsoft

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

3
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

4
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

5
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

6
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
• Well cross that bridge once we come to it

7
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

8
Allocated EAP Types

• Type Description
  Reference Implemented? Spec Available?
• ---- -----------
  --------- ------------ ---------------
• 1 Identity
  RFC2284 Yes RFC 2284
• 2 Notification
  RFC2284 Yes RFC 2284
• 3 NAK (Response only)
  RFC2284 Yes RFC 2284
• 4 MD5-Challenge
  RFC2284 Yes RFC 2284
• 5 One Time Password (OTP)
  RFC2284 No RFC 2284
• 6 Generic Token Card
  RFC2284 No RFC 2284
• 7
  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 2716
• 14 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

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

10
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

11
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

12
Method Negotiation

• NAK allows only one alternate method to be
  returned
• If client supports several methods (some of which
  server doesnt 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

13
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

14
Alternate Indications

• The most infamous lower layer assumption of RFC
  2284
• Success and Failure messages are not ACKd
• 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!

15
Possible Approaches

• Dont 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 isnt implemented anyway, so it needs to be
  removed from RFC 2284bis
• Not necessary to ACK Success or Failure messages,
  so dont need fix

16
Possible Approaches (contd)

• Remove and Fix
• UnACKd Success and Failure messages will
  eventually bite us
• Wireless networks w/fading
• Cryptographic protection of EAP
• Remove alternate indications text
• Add support for ACKd 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 NAKd by implementations that dont
  support it
• Would require documentation in separate draft if
  RFC 2284bis goes to Draft standard

17
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 ACKd nor retransmitted
• RADIUS server does not retransmit (NAS
  responsibility)
• But some methods assume RADIUS server
  retransmission, ACKing 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

18
Duplicate Detection

• EAP retransmission behavior
• NAS retransmits EAP-Requests
• Client never re-transmits EAP-Responses on its
  own
• NAS retransmission doesnt 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 doesnt 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

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

20
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 ACKd, 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

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

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

24
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

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

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

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

28
EAP Architecture?
AKA/SIM
GSS
Protection Layer
TLS
Protection Layer
SRP
EAP APIs

EAP Layer
Driver APIs
Media Layer
PPP
802.3
802.5
802.11
29
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
• ACKd Success/Failure
• Method negotiation
• EAP State Machine

30
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

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

32
Feedback?