Subject: [eap] RE: Potential Resolution to Issue 121: Potential meaning of successful authentication

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

Bernard Aboba wrote:

> >    [2] Unconditional success: The authenticator has indicated that
> >        it will allow access to the peer, and the peer wishes
> >        to use this access.
> >
> >        The peer SHOULD, in the event that an EAP Success is not
> >        received, conclude that the EAP Success packet was lost
> >        and enable the link. Failure packets MUST be silently
> >        discarded by the peer.
> >
> >    [3] Conditional success: The peer wishes to use the access,
> >        but it does not know if the authenticator will allow access
> >        or not.
> >
> >        The peer MAY, in the event that an EAP Success is not
> >        received, conclude that the EAP Success packet was lost
> >        and enable the link. Failure packets MAY be silently
> >        discarded, but this can result in lengthy timeouts unless
> >        a lower layer failure indication is provided."
>=20
> In the event that an EAP Success is not received, what is the=20
> difference between 2 and 3?  Doesn't the peer *always* enable=20
> its link based on whether it authenticated the authenticator=20
> within the method? If so, then it would seem like the last=20
> sentence would apply to #2 as well, no?

In case of timeout or Success packet, there's no difference=20
between 2 and 3 (the peer should enable the link).=20

The difference is that in 2, the server won't ever send a=20
Failure packet, and thus if we receive one, it was sent by=20
someone else (and can be discarded).=20

In case 3, the peer can make a trade-off if it receives
a Failure: either it can process it (disable the link and=20
end the conversation immediately), or silently discard it=20
(in which case it will have to wait for a timeout,
then enable the link, and timeout again to find out
that the link doesn't work). The latter approach could
offer some protection against an attacker who spoofs=20
a Failure message.

Do you mean that the peer should always enable the link=20
when it is authenticated the authenticator, even when=20
the authenticator signals it won't give access?

Best regards,
Pasi

---

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

> Do you mean that the peer should always enable the link
> when it is authenticated the authenticator, even when

I'm asking what the state machine does in this circumstance. From the
point of view of the peer, it is satisfied in a mutually authenticating
method where it successfully authenticates the authenticator. It is also
satisfied in a one-way method, since in that case the authenticator is
only authenticating the peer; the peer assumes that the authenticator is
authentic.

I had thought that the state machine model was that each side makes
its own decision. Of course where the peer is satisfied, but the
authenticator is not, there are drawbacks to having the peer enable the
link. The peer will attempt DHCP, and if the authenticator has disabled
its side of the link, no response will be received and the peer will
then assign a linklocal address instead, and might not check again for
5 minutes.

So I'm asking what happens in each case, and what the decision is based
on:

a. One-way method. Peer fails to authenticate to the authenticator and the
authenticator sends an EAP failure. Does the Peer process the EAP Failure
and disable its side of the link? Why or why not?

b. Mutually authenticating method. Peer successfully authenticates the
authenticator. Does the peer accept a subsequent EAP Failure? Why or why
not?

c. Mutually authenticating method. Peer unsuccessfully authenticates the
authenticator. Does it accept a subsequent EAP Success? Why or why not?

---

From: [email-masked] (Alper Yegin)
Date: Fri, 09 May 2003 11:32:11 -0700

I think the answer to your below questions depend on this:

- Does EAP success mean peer is authorized for network access or just
authenticated?

I understand EAP methods may signal their own authentication result or
authorization result. But what should EAP result mean?

Alper

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