Subject: [eap] Re: issue 121: failed auth & succeeded authz?

From: [email-masked] ([email-masked])
Date: Fri, 6 Jun 2003 10:15:31 +0300

Alper Yegin wrote:

>> But yes, it's a big unclear. Maybe this one would be better?
>>=20
>> "On the peer, once the method completes unsuccessfully, the link
>> is disabled and the EAP conversation is terminated (and any
>> Success and Failure packets are silently discarded).
>=20
> Why do we need to talk about what happens to the link?=20
> Shouldn't we let the consumer of EAP decide what to do with=20
> the EAP results. Secondly, this assumption of enabling/disabling=20
> links do not apply to other carriers of EAP, such as PANA and IKEv2.

By "disabling the link", I meant "terminating the connection
instead of doing whatever would have followed if everything
had succeeded". So, in IKEv2 this would mean aborting the=20
IKEv2 exchange instead of proceeding to "phase 2".

> > "If the authenticator has not verified the peer's identity,
> > it MUST send an EAP Failure packet. If the authenticator
> > uses a security policy that may, in some circumstances,
> > allow (possibly limited) access to the peer even when
> > the authenticator has not verified who the peer is, this
> > must be supported by the lower layer outside EAP. In this
> > case, the EAP Success/Failure packet does not completely
> > determine the access control decision, since access may be
> > granted  even when EAP Failure is sent. The lower layer
> > must then  have some means of signalling that "no, although
> > I sent an EAP Failure, it didn't really mean it.""
> >=20
> > (And no, I don't think this is a good idea, since it complicates
> > the lower layers
>=20
> Why does it complicate the lower layers? It might require=20
> additional changes  to the existing lower layers, I agree.

Ok, maybe it does not really complicate the lower layers much,
but it sure breaks existing lower layers, which IMHO is a=20
good enough reason not to do it..

> > , and breaks connection between RADIUS
> > Accept/Reject packets.
>=20
> I didn't understand this either. Could you please elaborate=20
> which breakage is this.

Current we're trying to say the RADIUS Access-Accept must contain
an EAP Success packet. This would break it: Access-Accept could
contain an EAP Failure, too.=20

(That is, I think we should stick with the principle that an=20
EAP Success packet means "access granted", and an EAP Failure=20
packet means "access denied".)

Best regards,
Pasi