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

From: [email-masked] ([email-masked])
Date: Fri, 9 May 2003 11:31:56 +0300

Bernard Aboba wrote:

> This isn't a RADIUS issue -- the problem can also occur in any AAA
> protocol, including Diameter.
>=20
> Typically the problem occurs because the implementation applies policy
> after the authentication/authorization decision is made, and=20
> therefore the result of the EAP method/EAP Success or Failure=20
> message/AAA result may not agree.
>=20
> The question is whether this is just an implementation issue --=20
> and therefore whether the implementations should be fixed so that=20
> it doesn't occur. That was the judgement of IEEE 802.1aa, and=20
> that is what is reflected in RFC 2869bis.

I very much agree with you on this. Making the authorization=20
decision *is* IMHO same as applying policy, and an=20
implementation should behave consistently in this. If=20
the implementation signals (using some EAP method internal=20
mechanism) that "yes, I give you access", then it must
not change that decision later and send an EAP Failure.

(From implementation point of view, if the policy is stored
in some "RADIUS server or EAP mux module", then the "EAP method=20
module" has to communicate with this module. But this is purely=20
an implementation issue; the behavior observable to outside
has to be consistent).

However, this should not be confused with the peer knowing
that "yes, the authenticator has verified who I am" message.
In this case, either authorization decision is consistent
behavior for the server, and I think that it is reasonable=20
to make the authorization decision (apply the policy)=20
after verifying who the peer is (which may be before an
EAP method has concluded, or after!).

It seems that EAP methods that can signal the authorization=20
decision have one "extra round" in them: before sending
the last Request, the server has already made its decision
whether to allow access or not.

In many methods, the server won't make the final decision until
it has received the last Response from the peer; and in those
methods, the only way to signal the authorizion decision
is an EAP Success/Failure message (and thus the server
can freely choose either of them).

Best regards,
Pasi

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 9 May 2003 06:03:43 -0700 (PDT)

> It seems that EAP methods that can signal the authorization

In a mutually authenticating method, the peer authenticates the
authenticator. In addition, the authenticator may indicate to the peer
whether the peer has successfully authenticated to it, and the peer may
provide a similar indication to the authenticator of whether the
authenticator has successfully authenticated to it.

The question is when the peer enables its side of the link. Is this purely
based on whether it authenticates the authenticator? Or in a method that
provides for protected result indications, does this occur only when it
authenticates the authenticator *and* the authenticator provides a
positive result indication? If there is no explicit positive result from
the authenticator, only say, the absence of an error message or alert,
is this sufficient for the peer to enable its side of the link? Once the
peer enables its side of the link, is an EAP Failure accepted? And once
the link is enabled, does the peer wait for an EAP Success or can it
conclude that the Success has been lost if it is not received?

In a one-way method, the authenticator authenticates the peer, but the
peer doesn't authenticate the authenticator, and there is no
method-specific result indication in either direction.

Here, does the peer always enable its side of the link? Or does this occur
only when it receives an EAP Success from the authenticator? If the
latter, then it would seem that a timeout will occur if an EAP Success is
not received.

> can freely choose either of them).

The question is whether the peer will accept either one of these messages
in the case where it has authenticated the peer. Do you agree that if the
peer cannot successfully authenticate the peer, then it should disable the
link so the Success/Failure message is irrelevant to it and it need not
wait to receive it?