Subject: [eap] RFC 2284bis issues

From: [email-masked] (Bernard Aboba)
Date: Sun, 17 Feb 2002 20:52:06 -0800 (PST)

Over the last few months, we've collected quite a few issues for
resolution in RFC 2284bis. Here are the list of issues that we have
collected, and how I would propose to resolve them. Comments welcome. 

1. IANA considerations. RFC 2284 does not include an IANA considerations
section, and RFC 2284bis needs one. Some thoughts on what might be in such
a section:

   a. Reservation of some of the Type space for future use. Should this be
      a single EAP method (255) or more of the space (e.g. 127-255)? 

   b. Statement that IANA should not allocate two Type codes for a single
      EAP method. 

   c. Statement about reclamation of unused Type allocations. It looks
     like several of the alllocated Type codes have never been used.

   d. Allocation of an EAP Type code for "Vendor Specific". I have in
      mind something like what RADIUS does with attribute 26. This could
      take the pressure off the Type space.

   e. Statement on allocation of EAP type codes. Should this be on
      request? By expert review? (e.g. by sending mail to the WG) By
      designated expert? Assuming that we have a vendor specific code,
      the criteria might be different, (e.g. a specification and expert
      review might be required). 

2. State machine issues. There are a lot of these. RFC 2284 has only a
short section describing in general terms what the protocol does. There 
is no detailed section describing the protocol exchange in more detail, 
or a formal state machine. These meaans that in many cases there is no
clear answer to the question "what do you do if you receive packet X when
you are in the midst of doing Y?" 

3.  Not allowing data traffic prior to completion of authentication. RFC
2284 doesn't state specifically that this is required, because it is
required by PPP -- so it probably seemed obvious and not worth
mentioning. But now that EAP can be used over a variety of media, this
has become a point of confusion. 

Proposed resolution is to indicate that an authentication conversation, once
initiated, must complete before data traffic can be sent.

4. EAP Success prior to mutual authentication. RFC 2284 does not
include a state machine, but it seems to imply that the peer should
consider authentication complete on receiving an EAP Success. Bill Arbaugh
has pointed out that a client requiring mutual authentication should not
consider itself "on the network" until that mutual authentication is
complete, so this is broken.

For example, if the peer is authenticating via a method supporting
mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator sends an EAP
Success in the middle, the recommendation is that the text of RFC 2284bis
be changed to note that the client SHOULD NOT bring
up the interface and SHOULD disconnect. Comments?

5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply that a peer
always considers themself disconnected when receiving an EAP Failure,
although it does indicate that "alternative indications of
success/failure" can be considered. What if an attacker spoofs an EAP
Failure outside of an authentication conversation? What if other traffic
is being received at the same time, indicating that the connection is in
fact up? Can the peer ignore the EAP Failure? 

My recommendation is that the text clarify the meaning of "alternative
indications" with respect to this scenario. I believe that 802.11 and PPP
both have such alternative indications -- in the case of PPP, we have LCP
Terminate, in 802.11 we have Disassociate or Deauthenticate. So typically
the EAP Failure will be followed by an alternative indication,
particularly if it occurs "out of the blue". I think that the EAP
indicator can be ignored (sometimes? all the time?) if it is at odds with
the alternative indication.

6. Authentication of the EAP Success. Bill suggests that an authenticator
be added to the EAP Success message. My inclination is not to accept this
suggestion since existing proposals (PEAP, TTLS) already support
authentication and encryption of the entire EAP conversation. Comments?