Subject: [eap] RFC 2284bis issues

From: [email-masked] (Bernard Aboba)
Date: Wed, 20 Feb 2002 07:53:46 -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?

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 20 Feb 2002 11:50:27 -0500

Some comments in line-

>       take the pressure off the Type space.

This seems a very good idea.

>       review might be required).

This is also a good idea - some review seems reasonable, especially if we have a
Vendor specific type

> you are in the midst of doing Y?"

Also a good idea.

> has become a point of confusion.

Here I think there is some conceptual conversation that needs to take place.
There are different ways to think about EAP.  One is to see it as a decision
making protocol for Access control.  Another is as a protocol between two end
points that use it to make decisions AND possibly other things, and not just for
access control applications.

> complete, so this is broken.

or the client should not accept a "success" from the server if it is doing
mutual authentication.  I must decide for itself if the other side has
successfully authenticated

> up the interface and SHOULD disconnect. Comments?

This needs clarification as you say.  Again I think it is the clients job (or
802.11 or 802.1x)'s job to spell out what the client must do.

> fact up? Can the peer ignore the EAP Failure?

I agree

> the alternative indication.

seems a state machine could help here

> authentication and encryption of the entire EAP conversation. Comments?

I think the success message needs to be talked about more.  It is used to
indicate a successful completion of a method as far as one end of the method is
concerned.  It also is used to signal the end of the EAP session.  I would like
to talk about how to concatenate EAP methods - for example to do anuthentication
with one method (e.g. TLS) and negotiating a QOS with another method, before
terminating the EAPsession.

-  John

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 20 Feb 2002 08:39:02 -0800 (PST)

> This seems a very good idea.

Look for some initial ideas on how to do this in:
http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-vendor-00.txt
http://www.ietf.org/internet-drafts/draft-aboba-pppext-eap-iana-00.txt

> access control applications.

Want to stake out a position?

> successfully authenticated

If the client does not accept a "success" how does it know when the server
has granted access to the network? It seems like the "ok to get on the
network" state is reached as a result of two things where there is mutual
auth:
   1. Server authenticates itself to client (method specific) 
   2. Client authenticates itself to server (indicated by EAP Success)

Note that in RFC 2284bis there is an open issue as to whether a client can
send an EAP Success to a server. 

> 802.11 or 802.1x)'s job to spell out what the client must do.

Surely this doesn't depend on the underlying media, does it? Shouldn't
the "access granted" state be defined within the EAP state machine as
opposed to in the PPP/802.1X/802.11 state machines?

> > fact up? Can the peer ignore the EAP Failure?

This presumes that there is an "authenticating state" in which EAP
Failures are accepted, and that these packets can be thrown away in other
client states. 

> seems a state machine could help here

Yes -- the trick is that if it is an EAP state machine, it has to include
support for L2 triggers. In some media such triggers exist, and in other
media they do not. For example, in PPP we have LCP-Terminate, in 802.11 we
have Disassociate as alternative failure indications. In generic IEEE 802
we do not have an equivalent. Similarly, in terms of success in PPP we
have NCP, but I don't think there is an equivalent in 802.11 or generic
802. 

> terminating the EAPsession.

The RFC 2284bis text suggests that since EAP Success ends the conversation
(if only because it cannot be ACK'd), that this only be sent after all the
methods have completed. So if you want multiple methods, after a method
succeeds, instead of sending EAP Success, you just start the new
method. So you could do:

EAP Identity Request/Response
EAP Type=Foo Request/Responses
[EAP Identity Request/Response]
EAP Type=Bar Request/Responses
[EAP Identity Request/Response]
EAP Type=Gump Request/Response
EAP Success

This presumes that EAP Types Foo, Bar and Gump all suceeded.

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 20 Feb 2002 13:37:29 -0500

> Want to stake out a position?

sure - I would argue that EAP should be the basis for a conversation between end
points.   In 802.1X  terms this would be the STA and AS.  Converstion between the STA
and AP should be outside this.

The problem that arises is that the AP and STA have "side" EAP conversations that get
confused with the conversation between STA and AS.  Unconfusing this would be a
priority for me in the revised EAP doc.

>    2. Client authenticates itself to server (indicated by EAP Success)

I would argue that granting access to the net is the APs job, not the AS.  The AS is
having the EAP conversation.
Initiating access is different than authenticating.

Success could be used to say I am happy with the conversation so far, but not to say
"start access"

> send an EAP Success to a server.

yes - this needs conversation as well, but I would argue that the client should be
able to send a Success.

> opposed to in the PPP/802.1X/802.11 state machines?

Well I think that the AS can decide that access is ok, but it is the APs job to make
it happen.  APs may have different ways of initiating stuff.  Certainly a 802.1x
ethernet switch supporting EAP/MD5 may not require a session key, while an 802.11AP
will require a session key.

> Failures are accepted, and that these packets can be thrown away in other

hmm - is this a state machine issue?  I think there is an authenticating state where
Success and Failure mean something.  An EAP failure out of the blue should not be
taken seriously.

> have NCP, but I don't think there is an equivalent in 802.11 or generic

This is why I would like to get EAP and the L2 triggers separated.  802.11 has used
EAPOL to do two things, and I am think it has made for a lot of confusion.

Do you know what EAP/SIP does this way?

> This presumes that EAP Types Foo, Bar and Gump all suceeded.

If you want to ping pong methods (have a client initiate a method) one would like to
know that the other end is happy so far before starting the next method.   My reading
is that this (client start of method) is not possible now, but I would be curious if
this seems useful to others.  It could allow each end to do different authentication
of the other.

John

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 20 Feb 2002 10:35:00 -0800 (PST)

> priority for me in the revised EAP doc.

Are you referring to the EAP Identity exchange?

>From a technical point of view, the AS communicates that it wishes the
NAS/AP to "grant access" through the AAA message, *not* via the
encapsulated EAP frame if there is one. 

So you can have:

1.     Access-Accept + EAP-Message/EAP-Failure
2.     Access-Reject + EAP-Message/EAP-Success
3.     Access-Accept + no EAP-Message attribute
4.     Access-Reject + no EAP-Message attribute

Note that in case 1, if the EAP frame is decapsulated and sent, the client
can think that it failed authentication, whereas access can be granted by
the NAS/AP. In case 2, the client thinks it succeeded, but the NAS/AP
denies access. 

In case 3, the NAS/AP grants access, but the client never finds out what
the result is. In case 4, the NAS/AP denies access, but the client doesn't
get a result. 

You can argue that this is where "alternative indications of
success/failure" come in. Or you can argue (as 802.1X did) that the NAS/AP
should "manufacture" the appropriate Success/Failure packet based on the
Accept/Reject result to make sure that things are always consistent. 

> yes - this needs conversation as well, but I would argue that the client should be

What would such as Success mean to the NAS/AP? Does this serve as an ACK
of the Success sent by the NAS/AP?

> will require a session key.

So you're saying that the definition of the "authenticated" state is
media-dependent?

> Success and Failure mean something.  An EAP failure out of the blue should not be

Yes, I think this is a state machine issue. Same with an EAP Success,
presumably. 

> This is why I would like to get EAP and the L2 triggers separated.  

The RFC 2284 text that refers to L2 triggers is the "alternative
indication" text. That text was put in there presumably because the
Success and Failure messages are not ACK'd. Is this the only reason that
L2 triggers need to be taken into account within the EAP state machine? 

> this seems useful to others.  It could allow each end to do different authentication

Yes, RFC 2284 seems to imply that the additional methods must be server
initiated. This is perhaps another place where L2 triggers intervene. PPP
is inherently peer-to-peer. 802.1X (bless its pointy little head) is
not. So in PPP, the client could presumably turn around and start an
authentication conversation in the other direction. In 802.1X that would
require both implementation of dual roles on each peer (Supplicant and
Authenticator). 

I don't even want to think about what PIC
(draft-ietf-ipsra-pic-05.txt) does...

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 20 Feb 2002 14:38:18 -0500

> Are you referring to the EAP Identity exchange?

yes, and the Success from the AP to the STA, which is independent of what the AS to AP EAP
message (in an Access Accept) is.

> Accept/Reject result to make sure that things are always consistent.

I would argue that the EAP message in an Access Accept should be forwarded to the STA by
the AP.  It tells the STA wheter  the AS is happy with the authentication dialog.  Using
the EAP Success to indicate session initiation creates a situation where the STA doesn't
know if it is talking to the AS or the AP.

> So you're saying that the definition of the "authenticated" state is

no I'm arguing that what one does as a result of an authentication is different for
different applications.

> (draft-ietf-ipsra-pic-05.txt) does...

A state machine would be very helpful here.

---

From: [email-masked] (Jacques Caron)
Date: Thu, 21 Feb 2002 00:23:14 +0100

>Want to stake out a position?

I vote in favor of "can do other things". The great thing about EAP is that:
- it occurs before an actual session starts (whatever that session is)
- it is transmitted transparently, end-to-end, between the client and an 
AAA server, across the NAS/AP/whatever [note: it might be a good idea to 
finally come up with a generic term that means any of those -- might be a 
GAS, like Generic Access Server ;-)]

This could be used for negotiation of quite a number of things (related to 
AAA's second A). John seems to think QoS parameters. I think presentation 
of cost to the user. There might be more.

However, moving EAP from a single-method-then-success to a 
multiple-method-then-success model might have some implications for 
backwards compatibility.

>send an EAP Success to a server.

I think one big issue with Sucess and Failure comes from the fact they're 
not ACK'd, and hence cannot be NACK'd. In some cases, a client might want 
to refuse a connection to go further (which in some contexts would mean 
"start pumping cash out of my account") unless something else happened to 
the satisfaction of the client.

>we do not have an equivalent

I would get that most of the 802 media that support 802.1x (and hence are 
port-based) have a "link down" (or whatever the fancy name for that is in 
IEEE lingo) event?

>. Similarly, in terms of success in PPP we

Back to ACK'ing success/failure :-) Back to backwards compatibility issues :-(

Jacques.

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

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 20 Feb 2002 15:50:22 -0800

>This seems a very good idea.

I think if this is not done carefully then it can cause all sorts of 
interoperability problems.  I would rather first see what vendor specific 
issues need to be addressed and address them in a standard way if possible.

>This is also a good idea - some review seems reasonable, especially if we 

I am in favor of some sort of review given my concern above.

> > you are in the midst of doing Y?"

agree

>access control applications.

I'm not sure I follow you here.  I see EAP as a protocol for carrying out 
authentication and thats it.  It is when we bring in other things such as 
access control that we have current problems because things become 
application specific.

>successfully authenticated

I'm not so sure about this either. I would like to see the server send some 
indication that it thinks the authentication is complete.  The client may 
have some processing left to do.  Also the completeness and success refers 
to the authentication not the access control.

>802.11 or 802.1x)'s job to spell out what the client must do.

I think applications that use EAP need to define what happens with 
different authentication results.  I do not think it is EAP's job to 
determine access control.

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

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 20 Feb 2002 15:55:02 -0800

>priority for me in the revised EAP doc.

  Okay, I'm confused.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 20 Feb 2002 17:13:35 -0800 (PST)

> port-based) have a "link down" (or whatever the fancy name for that is in 

Maybe. Most switches and NICs have carrier sense at this point, but then
there is Ethernet over ATM :(  Typically though, switches do not lower
carrier when there is an EAP Failure so this is not really an alternative
indication of failure. 

> Back to ACK'ing success/failure :-) Back to backwards compatibility issues :-(

All in all, whenever we've left out ACK'ing of messages, it always seems
to come back to bite us :(

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 20 Feb 2002 17:21:18 -0800 (PST)

> issues need to be addressed and address them in a standard way if possible.

Not sure why interoperability problems should result assuming that an EAP
Type is uniquely allocated for this purpose. If a client doesn't support
it, it will NAK the request. Or am I missing something? 

> I am in favor of some sort of review given my concern above.

Since the majority of IANA allocations to date are for protocols with no
specification, it isn't clear to me that requiring a spec and review is
viable without also enabling vendor-specific use. But if the vendor
community is willing to live with this, I won't object :)

> to the authentication not the access control.

That's enabled within RFC 2284 today. The client is not REQUIRED to start
accessing the network just because it gets an EAP Success. It could, for
example, decide to discard the EAP Success if mutual auth was not
complete.

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 20 Feb 2002 22:18:37 -0800

>it, it will NAK the request. Or am I missing something?

No you're not, my worry is a bit more subtle,  I don't think it will break 
existing things.  I do worry that if there is something that should be 
added to EAP that is generally applicable which is only addressed in a 
vendor specific way that this will lead to interoperability problems.

In general I support vendor specific extensions where the extension is 
vendor specific.  If it is more generally applicable then I would like to 
see it addressed in a general way if it makes sense to do so within EAP.  I 
don't want to see the vendor specific space become a catch all for things 
that should be in the spec (I don't want to see it become a catch all for 
things that shouldn't be either).

>community is willing to live with this, I won't object :)

I'm not sure of the feasibility of reviewing vendor specific extensions 
either,  that's why I'd like to see things that are generally applicable in 
the base spec.

>example, decide to discard the EAP Success if mutual auth was not

True,  I think what I was getting at here was that EAP-Success refers to 
the servers view of the state of authentication: it's done and doesn't 
expect anything more from the client. I also want to emphasize the 
distinction between authentication success or partial success and access 
control.  The two are usually related, but one does not imply the 
other.   What the client and server do with the knowledge that 
authentication has failed or succeeded should be outside of EAP.

Joe

---

From: [email-masked] (Jacques Caron)
Date: Thu, 21 Feb 2002 08:07:22 +0100

>example, decide to discard the EAP Success if mutual auth was not

But the EAP success usually means a successful auth, and the beginning of 
accounting. Maybe the client wants more before that is the case (see my 
example of cost advertisement somewhere else in the thread).

Jacques.

---

From: [email-masked] (David Halasz)
Date: Sat, 23 Feb 2002 15:48:17 -0500

One concern, of EAP and wireless, is anonymity. I don't have any ideas, of 
how to "hide" the user id, in the identity response. But, since it gets 
broadcast, in wireless, I have heard concerns.

         Dave H.

>authentication and encryption of the entire EAP conversation. Comments?

Dave Halasz
Cisco Systems, Inc.
320 Springside Drive
Akron, OH  44333

---

From: [email-masked] (Thomas Hardjono)
Date: Mon, 25 Feb 2002 18:54:49 -0500

Dave,

There are many levels of anonymity possible.  The easiest way
would be for a Pre-Paid card type model, where the identity
is tied to the card.

I would put anonymity at a lower priority as it tends to complicate
the security protocols.

thomas
------