Subject: [eap] Re: Issue 121: Document meaning of successful authentication

From: [email-masked] ([email-masked])
Date: Wed, 7 May 2003 13:46:01 +0300

Bernard Aboba wrote:

> However, if the AAA server didn't examine the policy until
> after the EAP method was complete, there can be trouble
> because the method presumably completed successfully. As a
> result, the changes indicated in Issue 116 would cause the EAP
> Failure to be silently discarded since it doesn't agree with
> the result of the EAP method authentication which was
> successful.
>
> One response to this problem is that the AAA server should
> examine the policy early on and appropriately terminate the
> method, so that it's not a protocol issue, but an implementation
> issue. I'm not sure I find this 100% convincing however, because
> in some methods (EAP TLS, for example), there may not be a
> method-specific error message that appropriately conveys an
> "authenticated but not authorized" error. So if we're going to
> go down this road, we probably need to add some advice in the
> method Appendix to make sure that those messages are available.

I think this problem appears only if we assume that the client
and the server have to have the same opinion about if the EAP
method succeeded or not (success being defined as "will allow
access to the other party").

I don't think this is the case with most EAP methods.

The current approach taken in the EAP state machine draft (-02)
is that some methods may have an internal mechanism for=20
communicating an "access allowed/denied" message=20
("confirmed success/failure") from the server to the client. =20
If the client gets an "access allowed" message (methodState=20
CON_ACC), then a Failure packet will be silently discarded=20
(and for methodState CON_REJ, Success packet will be discarded).

The end result (of the client) is an AND of the server's=20
decision and the client's own decision ("do I want to talk=20
to this server").

However, most methods do not have such a message, and they will
simply report "ordinary success" (their own decision, not the
server's). The server's decision is communicated using a=20
Success or Failure packet (both are allowed), and the end=20
result is again an AND of client's and server's decision.

I know this is a bit complicated, but it seems to capture a
reasonable set of behavior that applies to all EAP methods?
If it's actually what we want to happen, I think we should
include a discussion explaining it in 2284bis (perhaps
somewhere near where success and failure are explained).

(I can try to write something if you think this is
what we want to say)

Best regards,
Pasi

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 7 May 2003 06:23:53 -0700 (PDT)

> access to the other party").

It might be ok for the authenticator to be willing to grant access,
and the peer to be unwilling to use the link, because the peer would then
disconnect, which the authenticator could detect. However, I do not think
it is ok for the authenticator to refuse to grant access and the peer to
be unaware of this, because the peer will continue to attempt to use the
link, with no success, unaware of what it needs to do in order to
authenticate. For example, the peer will attempt to obtain an IP
address via DHCPv4, which will fail and as a result it will then obtain an
IPv4 linklocal address. Under draft-ietf-zeroconf-ipv4-linklocal, the host
might not check for the presence of a DHCP server for another 5 minutes.
The result is a very long period of frustration for the user, support
calls, etc.

This problem was encountered in IEEE 802.1X-2001 and resulted in a frustrating
user experience. As a result, we had to clarify RFC 2869bis so as to require
consistency between AAA messages and the embedded EAP messages.

> I don't think this is the case with most EAP methods.

It's not really an EAP method issue -- it's a basic protocol operation
issue.

> The end result (of the client) is an AND of the server's
> decision and the client's own decision ("do I want to talk
> to this server").

The problem with this is that both sides need to eventually become aware
of each other's state and in the authenticator failure/peer success case
this could take a considerable period of time and create an administrative
burden along the way.

> The server's decision is communicated using a
> Success or Failure packet (both are allowed)

The problem is that you previously indicated that this message was
silently discarded by the peer -- so how is it "communicated"?

> reasonable set of behavior that applies to all EAP methods?

Actually, I don't think that the behavior is all that reasonable -- it
appears to result in multi-minute timeouts, user frustration and
an expensive support burden.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 7 May 2003 06:34:49 -0700 (PDT)

> The result is a very long period of frustration for the user, support

BTW, one way to deal with this is to assume that the authenticator will
inform the peer of the state of authentication via a lower layer
mechanism. For example, if an Access Reject is received from the AAA
server, the authenticator will decapsulate the embedded EAP packet (EAP
Faliure) and send it to the peer. The peer might silently discard the EAP
Failure packet because the authenticator successfully authenticated to it
so that the method succeeded. However, we do say that the peer MUST act on
lower layer failure indications. So in PPP, the authenticator can send an
LCP terminate, and in IEEE 802.11 it can send a Disassociate or
Deauthenticate.

The problem is that in IEEE 802.11i they are now talking about silently
discarding the Disassociate or Deauthenticate messages too :(

My suggestion would be to add some additional discussion about this so as
to make clear what the authenticator needs to do in order to ensure
consistency.

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 07 May 2003 10:25:31 -0400

> disconnect, which the authenticator could detect. However, I do not think

If the authenticator can detect it I would think the peer could as well. Is 
this not the case?

> This problem was encountered in IEEE 802.1X-2001 and resulted in a
> frustrating user experience. As a result, we had to clarify RFC 2869bis
> so as to require consistency between AAA messages and the embedded EAP
> messages.
>

I agree it is a protocol not method issue.  if the Success/Failure message 
was acknowledged would this solve the protocol problem?

> an expensive support burden.

I think Pasi's description is quite good.  Seems to me the options actually 
open to us, without adding acknowledged ACK for success/Failure messages are

 1. always accept success and failure messages and accept the consequences 
of possible DOS attacks using them
 2. use method indication of where there is a confirmed success and not 
allow Failure.  This leave the possiblity a Failure sent would be ignored 
and the peer would hang thinking it had succeeded.

I think the second scenario allows the use of protected methods like PEAP 
and avoid DOS attacks. [ PEAP might want to define a protected 
Success/Failure that IS acknowledged within it self - might be worth 
looking at how to do that.]  The risk with the second method seems low if 
only used with protected methods.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 7 May 2003 09:03:15 -0700 (PDT)

> If the authenticator can detect it I would think the peer could as well. Is

It depends on whether lower layer indications are sent. For example, in
PPP the peer may send an LCP-Terminate if it wants to disconnect, but in
my experience that doesn't always happen. Similarly in IEEE 802.11 the
peer can wander off without sending a Disassociate. In both cases the
authenticator will typically time out the authentication state.

That just results in excess resource consumption but on the peer there may
be a human user who gets frustrated and makes support calls if she can't
authenticate. So the impact of an authenticator not sending a lower
layer indication is somewhat greater.

> was acknowledged would this solve the protocol problem?

I don't think so, becaue if we're going to silently discard the
Success/Failure indication on the peer, then the authenticator will just
retransmit it until it times out.

> only used with protected methods.

I'd suggest that a lower layer failure indication be recommended if we go
with #2.

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 07 May 2003 19:55:33 -0400

--On Wednesday, May 7, 2003 9:03 AM -0700 Bernard Aboba 
<[email-masked]> wrote:

> > If the authenticator can detect it I would think the peer could as
> > well. Is this not the case?
>
> > I agree it is a protocol not method issue.  if the Success/Failure
> > message was acknowledged would this solve the protocol problem?
>

true -
>
> > I think Pasi's description is quite good.  Seems to me the options
> > actually open to us, without adding acknowledged ACK for
> > success/Failure messages are
> >
> >  1. always accept success and failure messages and accept the
> >  consequences of possible DOS attacks using them
> > allow Failure.  This leave the possiblity a Failure sent would be
> > ignored and the peer would hang thinking it had succeeded.
> >
> > I think the second scenario allows the use of protected methods like
> > PEAP and avoid DOS attacks. [ PEAP might want to define a protected
> > looking at how to do that.]  The risk with the second method seems low
> > if only used with protected methods.
>
I agree - sounds right to me.

---

From: [email-masked] (Alper Yegin)
Date: Wed, 07 May 2003 18:06:21 -0700

How about relying on the EAP transport to signal the result of the
"authorization" and EAP and EAP method signal the result of
"authentication"? This way EAP result can always be same as the EAP method
result because it does not have to convey a different value (auth vs.
authz).

What is the problem with this approach?

Alper

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

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 07 May 2003 21:17:24 -0400

> What is the problem with this approach?
I think this is what Bernard is suggesting.  Am I missing something?
-- John

> >> PPP the peer may send an LCP-Terminate if it wants to disconnect, but
> >> in my experience that doesn't always happen. Similarly in IEEE 802.11
> >> the peer can wander off without sending a Disassociate. In both cases
> >> the authenticator will typically time out the authentication state.
> >>
> >> That just results in excess resource consumption but on the peer there
> >> may be a human user who gets frustrated and makes support calls if she
> >> can't authenticate. So the impact of an authenticator not sending a
> >> lower layer indication is somewhat greater.
> >>
> >> Success/Failure indication on the peer, then the authenticator will
> >> just retransmit it until it times out.
> >
> > true -
> >>
> >>>  2. use method indication of where there is a confirmed success and
> >>>  not allow Failure.  This leave the possiblity a Failure sent would be
> >> I'd suggest that a lower layer failure indication be recommended if we
> >> go with #2.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 7 May 2003 19:35:19 -0700

I think what the text suggested by Bernard means is:

o EAP Success/Failre indicates an authorization result (i.e., access
accepted or denied).

o Similar indication can also be carried in an authentication method
perhaps with acknowledged, but the indication must be consistent
with the result indicated by EAP Success/Failure.  This means that
method indication actually indicates an authorization result, too.

(For example, in PEAP, EAP-TLS, EAP-TTLS, it is possible to use TLS's
error alert "access_denied" to indicate a failure of authorization
even when authentication succeeds. Or in PEAP, it is also possible to
use Success/Failure EAP-TLV inside the PEAP method to indicate an
authorization result.  In PEAP, it might be also possible to return a
Success/Failre EAP-TLV and return a EAP-Success outside PEAP, even
when PEAP "authentication" fails, to be able to provide restricted
access for unauthenticated clients.)

o There is another indication, which is from link-layer.  When the
link-layer indication is used, it is assumed to be consistent with the
other indications.  This means that link-layer indication is an
authorization result, too.  Link-layer indication is not secure in
802.11, on the other hand, if link-layer indication is not used
there is some delay that might frustrate users.  (So there is a
pros-and-cons on using link-layer indications over 802.11.)

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 7 May 2003 20:47:35 -0700 (PDT)

> What is the problem with this approach?

The problem is that it creates numerous corner conditions. We have already
encountered this in AAA where if the AAA indication (Access/Reject) is not
consistent with the encapsulated EAP packet (Success/Failure) we can get
extended timeouts. We have addressed this in RFC 2869bis by strongly
discouraging contradictory indications.

We are encountering it again with the distinction between method result
indications and EAP Failure/Success. And here again the solution appears
to be restricting (or prohibiting) contradictory indications.

That's also why Section 3 of RFC 2284bis restricts the use of lower layer
indications substantially -- basically these can only be used to deny
access (e.g. PPP LCP-Terminate, 802.11 Disassociate/Deauthenticate), not
as success indications.

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 08 May 2003 13:03:48 -0400

> What is the problem with this approach?
I think I may have misinterpreted your suggestion on first reading.  I 
think I may understand what you are suggesting better now.

to check if I do understand what you are suggesting, here is what I think 
you are saying, a bit expanded -

 - have two results 1. [auth] authentication done by EAP methods
                    2. [authz] done by EAP policy

 1. would be signalled from the EAP method to the EAP mux and presumably 
signalled from authenticator to peer by the EAP Success/Failure message

2. would be determined by EAP policy and signalled to the supplicant with a 
level 2 signal.

----
If this is what you are saying, I think it is a very interesting idea, and 
one to talk about for futures.  It doesn't work for current version because

a) There is no positive way to signal an [auth] with EAP Success/Failure 
because they aren't ack'd
b) The intent of EAP as described now is to have the EAP dialog result be 
both authentication and authorization [separating them is the interesting 
idea]
c) There are positive ways to in existing lower layers to indicate failure, 
but not success.  That is one can do and 802.11 disassociate or EAPoL 
logoff to drop a link, but there is no indicator outside EAP to indicate 
success.

---

From: [email-masked] (Alper Yegin)
Date: Thu, 08 May 2003 13:53:22 -0700

> signalled from authenticator to peer by the EAP Success/Failure message

Yes. So that EAP method result and EAP result are the same. And they only
mean authentication.

> 2. would be determined by EAP policy and signalled to the supplicant with a

Not necessarily "level 2 signal" if you mean "link-layer" here.

Between the authenticator and the authentication server, if you are running
Radius, access accept/reject can indicate the result of authorization. On
the last hop, this value is translated to, for example, PANA
success/failure. That way, authentication and authorization results can be
kept separate all the way to the peer.

> because they aren't ack'd

Sorry, I'm missing why this matters here...If we had EAP results ack'ed,
would we not have the problems we are facing when we want to separate auth
from authz?

> both authentication and authorization [separating them is the interesting

I thought the starting point of this thread was that people want to separate
and differentiate between two results. If they are always the same, how does
the peer know when it fails if it is due to authentication or authorization?
The result should not tell me I am not Alper@docomo just because I tried to
access a service before 5pm (too early).

> logoff to drop a link, but there is no indicator outside EAP to indicate

I guess this is a EAP lower layer problem, or limitation of existing ones.
If you look at PANA, we have both success and failure.

Alper

---

From: [email-masked] (Alper Yegin)
Date: Thu, 08 May 2003 14:26:09 -0700

> discouraging contradictory indications.

I think the problem is not with EAP, or AAA. The problem is with the EAP
lower layers, such as PPP and 802.1X. If they had a way to carry
authorization results, this problem wouldn't exist. In PANA, we carry PANA
result so this wouldn't be a problem.

> to be restricting (or prohibiting) contradictory indications.

Does this work? There are three pieces here:
1- (potentially) EAP authentication method result
2- EAP result
3- Radius result

I see rfc2869bis says (2) and (3) must agree. On the other hand, now we are
discovering that (1) and (2) must agree too. So, when an authentication
method succeeds, but authorization fails, should the authenticatin server go
back and flip the authentication method to "failed" so that the results are
all aligned?

We could make (1) and (2) the same, and keep (3) independent. But the
problem is there is no equivalent of (3) for the last hop when PPP or 802.1X
is used. 

Alper

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 8 May 2003 14:22:14 -0700 (PDT)

> kept separate all the way to the peer.

If the AAA Access/Reject agrees with the EAP Success/Failure as
recommended in RFC 2869bis, what is the value of a PANA Success/Failure?
Seems like this means that PANA is much more than an EAP transport -- it
actually changes the EAP state machine, which is problematic.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 8 May 2003 14:29:01 -0700 (PDT)

> result so this wouldn't be a problem.

802.1X considered, and rejected the carriage of authorization results. It
was simpler to just recommend that the AAA result and EAP results agree.

> discovering that (1) and (2) must agree too.

This is not a "discovery" -- it is an implication of the proposed state
machine.

> So, when an authentication

If the authentication method supports an authorization failure error
message, it can send that and there is no problem. Alternatively, the AAA
server can send a Reject/EAP Failure. If this does not agree with the EAP
method, which completed successfully, then the peer may silently discard
the EAP Failure. Again there is no issue, as long as the NAS sends a lower
layer failure indication such as an LCP-Terminate or 802.11
Deauthenticate/Disassociate.

Why doesn't this address the problem?

> problem is there is no equivalent of (3) for the last hop when PPP or 802.1X

That seems needlessly complex -- given that our goal is to improve
interoperability.

---

From: [email-masked] (Alper Yegin)
Date: Thu, 08 May 2003 16:50:43 -0700

> recommended in RFC 2869bis, what is the value of a PANA Success/Failure?

If the decision is to align the result codes across Radius, EAP and EAP
method, then you are right, PANA result code does not add much value when
the backend is Radius.

I have some questions regarding the aforementined condition (I'll respond to
your other message), and Radius is not the only backend for PANA. People can
use any proprietary solution, there is no reason to take away this
flexibility because Radius does it one way, imo.

> actually changes the EAP state machine, which is problematic.

Could you please elaborate how does this change the EAP state machine?
PANA does not touch EAP session, and EAP is only for authentication. PANA
result can change based on the EAP result, but not vice versa.

Alper

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 8 May 2003 16:50:31 -0700 (PDT)

> flexibility because Radius does it one way, imo.

This isn't a RADIUS issue -- the problem can also occur in any AAA
protocol, including Diameter.

Typically the problem occurs because the implementation applies policy
after the authentication/authorization decision is made, and therefore the
result of the EAP method/EAP Success or Failure message/AAA result may not
agree.

The question is whether this is just an implementation issue -- and
therefore whether the implementations should be fixed so that it doesn't
occur. That was the judgement of IEEE 802.1aa, and that is what is
reflected in RFC 2869bis.

Basically, this is a case of "Doctor, it hurts when I do this!" Since the
protocol messages in question don't appear to add much in the way of
new capabilities, the resolution was "don't do that!"

> result can change based on the EAP result, but not vice versa.

The problem is that the EAP result *isn't* just about authentication --
it's about whether the peer and authenticator enable their side of the
link. As noted earlier, if the authenticator fails to authenticate to
the peer, then the peer MUST NOT enable the link -- no matter what the
lower layer indications say.

As a result, the lower layer can only offer failure indications so as to
indicate that the link is disabled. It can't authorize access in
situations when EAP authentication has failed.

---

From: [email-masked] (Alper Yegin)
Date: Thu, 08 May 2003 17:43:05 -0700

> situations when EAP authentication has failed.

This sounds more like you are talking about a specific usage of EAP, such as
EAP over PPP or EAP over IEEE 802. rfc2284bis talks all about authentication
but not authorization, and what you imply above is authorization.

Does the spec say access service cannot be granted if EAP fails? I hope it
does not. For example, even if a visitor fails to authenticate himself, I
might choose to provide limited access service to him just because he is in
the shopping mall.

Alper

---

From: [email-masked] (Alper Yegin)
Date: Thu, 08 May 2003 17:45:22 -0700

> was simpler to just recommend that the AAA result and EAP results agree.

But is this a better approach?
Now, since AAA rules, if AAA disagrees with EAP and the authentication
method, the authentication server has to forcefully change the EAP and
authentication methods results. They were meant to be for "authentication",
but now they are overwritten by "authorization" results. Is this allowed
from EAP perspective, and practical?

> message, it can send that and there is no problem.

If the authentication method has its own result, wouldn't that be
"authentication failure/success"? I'd say it should not be "authorization
f/s".

> Alternatively, the AAA

This is meant to be an alternative to aligning all results same as AAA
result, right?

- this delivers authorization result in EAP result which is meant to be
authentication result.
- does this not open up a DoS attack? Those link-layer failures are not
protected. [you were asking what is the use of PANA results. Here it can
replace the lower-layer hints.. it can even be protected if method are
available]
- How about the opposite case: method fails but the peer is authorized to
have limited access to the network.

> That seems needlessly complex -- given that our goal is to improve

If you are referring to the required change on PPP and 802.1X, yes, this is
hard. 

Alper

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 8 May 2003 19:13:18 -0700 (PDT)

> might choose to provide limited access service to him just because he is in

Access can't be granted if an EAP Failure is sent. This is more than an
EAP issue -- RADIUS [RFC2865] says that an Access Reject means to deny access.
Since the EAP result and AAA result need to be aligned, that means you shouldn't
send an EAP Success inside a RADIUS Access Accept or an EAP Failure inside
a RADIUS Access Reject. These cases are a SHOULD NOT within RFC
2869bis.

Now that we only have a single EAP authentication mechanism, the current
discussion is over whether the EAP method result and EAP result have to be
the same. The big advantage to aligning them is that spoofing of EAP
Success and Failure is made much more difficult.

If AAA authorization for access is only provided when an EAP Success is
sent, and if an EAP Success is only sent after EAP authentication
succeeds, then access service can't be granted if EAP fails.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 8 May 2003 19:16:51 -0700 (PDT)

Oops. I meant an EAP Failure shouldn't be sent inside an Access Accept or
an EAP Success inside an Access Reject.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 8 May 2003 19:28:17 -0700 (PDT)

> from EAP perspective, and practical?

I think this is an implementation issue. Typically, EAP methods
provide an indication of success or failure on completion, and so the EAP
Failure or Success packet can be generated by the AAA server, which can
make sure that it is aligned with the AAA indication. So overall,
alignment of the AAA indication and EAP Success/Failure is not much of an
issue in practice. That's why RFC 2869bis is recommending consistency.

Consistency between the EAP method and the Success/Failure indication is a
bit trickier. If the method provides its own result indications, then the
AAA server will only learn of the EAP method result *after* those
indications are sent. At that point, it may be too late to change the
result indication if policy indicates that another result should occur.

The solution to this is for the policy to be checked earlier on, so that a
method-specific authorization error message can be sent. As has been
noted, such messages exist within EAP methods such as EAP-TLS [RFC2716].
If this is done then the EAP method result can be made consistent with the
Success/Failure indication and the AAA result.

The other way to do this is to use a method that doesn't do mutual
authentication. On the peer, such "one way" methods always conclude
successfully from the peer's perspective. Since the peer doesn't
authenticate the authenticator it is always ready to enable the link, no
matter what happens. Or at least, this is what I gather from the state
machine discussions.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 13 May 2003 21:18:51 -0400

I am not able to join the conversation tomorrow.  I am having a medical 
problem this week - hopefully I will be better by Thursday and getting 
email.  I am pretty happy with 2284 and 2869 bis and with the stqte 
machine.  I have one major concern with both 2284bis and with the state 
machine - and that is that tunnelled methods will not be able to do 
sequences of methods.

Another concern is that the keying material information be taken from 2284 
and put in its own section, if possible.  I think keying is not always 
necessqry so putting it in its own section is important.

Sorry I can't join you tomorrow --

John

--On Thursday, May 8, 2003 2:29 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> > authorization results, this problem wouldn't exist. In PANA, we carry
> > PANA result so this wouldn't be a problem.
>
> > I see rfc2869bis says (2) and (3) must agree. On the other hand, now we
> > are discovering that (1) and (2) must agree too.
>
> > method succeeds, but authorization fails, should the authenticatin
> > server go back and flip the authentication method to "failed" so that
> > the results are all aligned?
>
> > problem is there is no equivalent of (3) for the last hop when PPP or
> > 802.1X is used.
>

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 13 May 2003 21:41:09 -0400

John