Subject: [eap] A straw man for EAP BOG writeup

From: [email-masked] (Simon Blake-Wilson)
Date: Thu, 21 Feb 2002 11:56:53 -0500

I think review of EAP methods, and standardization of new methods should be part
of the proposal.

Best regards. Simon

John Vollbrecht <[email-masked]> on 02/20/2002 05:07:34 PM

To:   EAP <[email-masked]>
cc:    (bcc: Simon Blake-Wilson/Certicom)
Subject:  [eap] A straw man for EAP BOG writeup

Here is a first cut at a proposal for an EAP BOF writeup.  I am sure
there are other things to add, and that what is on here may need
clarification.
If we have till Friday there isn't much time.

There are a number of issues with EAP that may need to be cleaned up.
Many
of these issues are created because of the use of EAP with 802.1x in
802.11
wireless LAN authentication.   EAP work currently is being done in the
PPPext working group.  Since many issues are not PPP related, it seems
reasonable to consider having a wg that will deal with EAP specific
issues.

Some possible topics:

1. Clarify meaning of EAP success and failure message
2. Extend Method negotiation
3. Add Mutual authentication and Client initiated authentication
4. Recommended practices for AP/NAS - (rework EAP recommendations in
RADIUS
and extend to other possible protocols)
5. any special requirements for  Diameter, COPS, others
6. role of key creation and cyphersuite negotiation (especially for
802.11
algorithms) and EAP
7. Add state diagram for EAP and interactions with clients

some possible workitems for an EAP group

Clean up EAP 2284bis and publish
Revise RADIUS Ext 2869
Create EAP Recommended practices for Access Devices

Things not to be included in EAP group

Security Review of EAP algorithms  (although it might want to help
figure
out where this would be done)

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 21 Feb 2002 10:11:53 -0800 (PST)

> Specifically, since EAP-Success is not ACK'ed, how can it be relied upon to
> indicate things like "auth successful, go ahead and send packets"? 

Well, RFC 2284 states that "alternate indications of Success/Failure" are
to be used in case a Success or Failure indication does not arrive. This
is problematic, because while PPP might have the appropriate mechanisms
(like LCP-Terminate and NCP) not all media will have them. 802.11 has
Disassociate, but no alternative success indicator (unless you count
EAPOL-Key, which also isn't ACK'd). Generic IEEE 802 doesn't really have
an alternative failure indicator, except maybe if you count carrier sense. 
EAPOL-Key isn't sent for 802 wired, so we don't even have that straw to
grasp at. 

There seem to be two possible approaches to fixing this, neither of which
seem ideal:

a. Defining alternate success/failure indications for each media. 
b. Adding a client ACK (perhaps an EAP Success in the other direction). 

Approach a) seems hard to accomplish for all media.  

Approach b) may not work well with existing implementations. If an ACK is
to be useful, then the Server would need to retransmit if it is not
received. Yet legacy clients will never ACK so it is hard to see how
backward compatibility can be achieved. 

Maybe someone else has some better ideas.

> If I remember correctly, 802.1x makes a mistake like this and relies on
> EAP-Success being delivered successfully in several of the state machines.

Since IEEE 802.1X doesn't define alternative failure/success indicators,
they just use a timeout.

---

From: [email-masked] (Jacques Caron)
Date: Thu, 21 Feb 2002 19:58:59 +0100

>backward compatibility can be achieved.

There could be something earlier on in the conversation (e.g. a request for 
a specific method, or a change in response format) that would allow 
distinction between versions of EAP (i.e. the present one, and a new one). 
In the case of the present one (which we can suppose is mainly implemented 
in PPP clients, and some limited number of 802.1x clients for WLANs), 
traditional behavior would be expected. In the case of the new one, ACKs 
would be necessary.

Of course there's the issue that some part of the negotiation actually has 
an implication on the NAS/AP/switch itself. An alternative method would be 
to define a brand new encapsulation of EAP (i.e. with a different 
LCP/Ethernet frame type) to distinguish the two versions. The intent being 
to keep the AAA proxying and serving intact as much as possible.

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 21 Feb 2002 10:51:30 -0800 (PST)

Is someone willing to volunteer to create a problem statement and analyze
the pros and cons of various possible solutions to this issue? 

We've been asked to come up with an EAP BOF Agenda by tommorrow, and this
sounds like a useful topic to explore. 

Some other potential BOF agenda items:

1. EAP state machine [Bill Arbaugh]
2. EAP vulnerability assessment & security considerations [Bill Arbaugh]
3. IANA considerations [Bernard Aboba]
4. RFC 2284bis issues [John Vollbrecht]
5. RFC 2869bis issues [Bernard Aboba]

---

From: [email-masked] (John Vollbrecht)
Date: Fri, 22 Feb 2002 08:48:10 -0500

> I think review of EAP methods, and standardization of new methods should be part

My preference is to deal with EAP as a protocol.  This would include interactions
between EAP and the applications using EAP.  I don't think it appropriate for this
group to analyze SRP or Kerberos or SKE for strength of authentication or
vulnerability to replay attack etc., unless the way that EAP is used to carry that
method is the cause of the problem.

I do think there should be some review of EAP methods for conformance to good "EAP"
practice.  I also would agree that this is a grey area and it is not clear exactly
how or where to draw the line.
-- John