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

From: [email-masked] ([email-masked])
Date: Tue, 3 Jun 2003 11:22:35 +0300

Jari Arkko wrote:

> > On the peer, once the method completes unsuccessfully (that=20
> > is, either the authenticator sends a method-specific failure=20
> > indication, or the peer decides that it does want to continue=20
> > talking to this authenticator), the link is disabled and the EAP=20
> > conversation is terminated (and any Success and Failure packets=20
> > are silently discarded).
>=20
> Ok. But shouldn't we mention mutual authentication failure in
> the above?

Oops, that should of course be "..., or the peer decides that it=20
does _NOT_ want to continue", and I intended that to cover
authentication failures, as well as all other possible reasons.

But yes, it's a big unclear. Maybe this one would be better?

  "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).
  unsuccessful completion of a method means that either the
  authenticator sends a method-specific failure indication, or the
  peer decides that it does not want to continue talking to this
  authenticator (for instance, in EAP-TLS, the certificate
  presented by the authenticator does not satisfy the peer's
  policy)."

(Note that this means that "unsuccessful completion" on the peer
can occur before the last message of the method. For instance,
in EAP-TLS, if the server's certificate does not satisfy the
peer's policy, there's no point in continuing the conversation.)

> > If the authenticator has sent a method-specific success indication,
> > the peer MUST silently discard Failure packets, and MAY, in=20
> the event
> > that an EAP Success is not received, conclude that the EAP Success
> > packet was lost and enable the link.  (Note that the peer does not
> > enable the link immediately after receiving the method-specific
> > success indication, since it may be necessary to retransmit the last
> > EAP Response packet.)
>=20
> Ok.
>=20
> > If the authenticator has not sent any method-specific result
> > indication, and the peer still wants to talk to this authenticator,
> > once the method completes the peer waits for a Success or Failure
> > packet (and cannot silently discard either of them). In the=20
> event that
> > neither a Success nor Failure packet is received, the peer SHOULD
> > disable the link to avoid lengthy timeouts in case the lost=20
> packet was
> > an EAP Failure."
>=20
> Ok.
>=20
> > I don't think it's necessary to explicitly forbid the case of
> > allowing access when the authenticator has not verified who the peer
> > is. In most methods, the peer can't tell the difference=20
> anyway: e.g.,
> > if in EAP-TLS the authenticator simply ignores the certificate given
> > by the peer, nobody will know.=20
>=20
> Your text looks good as such, but I still think that it should
> say something about "method authentication failure". Somebody
> will know, if the authentication failure confuses key generation
> somehow. And even if it does not, what use are the keys if they
> are not tied to the specific authentication? In short, there
> appears to be at least some worries in letting the process
> go forward after an authentication failure. And as discussed
> previously, there does not appear to be a specific reason to
> allow this.

Since we have forbidden sequences, I think we don't have to=20
differentiate between "method failures" and "EAP conversation=20
failures" anymore. It's probably easier to think that the=20
situation is a failure to a party if that party is unhappy=20
with the situation, and will not enable the link, regardless=20
of the other party's decision (and it does not matter why=20
the failure occured).

If we use this definition, then if the authenticator decides=20
to give (maybe some sort of limited) access to the peer, then=20
the situation is a "success" for the authenticator, even if it=20
does not exactly know who the peer is. (The same situation may,=20
of course, be a  "failure" for the peer).

I agree that in some methods (especially those based on=20
shared secrets), some sort of protocol mismatches will
result in lack of keys. But is this a protocol issue
or policy issue? After all, in some cases methods that don't=20
derive keys even when succesful are completely acceptable.=20
An authenticator could, of course, have a policy saying that=20
"allow very limited access, if we haven't verified the peer's=20
identity but have derived keys" (of course, the authenticator
does not then know who it shares the keys with, but this does
not mean they're useless).

If we absolutely do want to require that the authenticator=20
must never allow access if it hasn't verified the peer's
identity, then I think we should use some other word than=20
"method success" for that (I think Joe Salowey said something=20
like this in his recent mail, that using MUST NOTs around an=20
undefined term isn't a good idea). Maybe something like this=20
would do the job:

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

(And no, I don't think this is a good idea, since it complicates
the lower layers, and breaks connection between RADIUS
Accept/Reject packets. I think in this case, the authenticator=20
should be allowed to send an EAP Success inside RADIUS=20
Access-Accept that includes a Filter-Id AVP.)

Best regards,
Pasi

---

From: [email-masked] (Alper Yegin)
Date: Thu, 05 Jun 2003 17:09:49 -0700

Hi Pasi,

> Success and Failure packets are silently discarded).

Why do we need to talk about what happens to the link? Shouldn't we let the
consumer of EAP decide what to do with the EAP results. Secondly, this
assumption of enabling/disabling links do not apply to other carriers of
EAP, such as PANA and IKEv2.

> presented by the authenticator does not satisfy the peer's

...

> "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
> the lower layers

Why does it complicate the lower layers? It might require additional changes
to the existing lower layers, I agree.

> , and breaks connection between RADIUS
> Accept/Reject packets.

I didn't understand this either. Could you please elaborate which breakage
is this.

> I think in this case, the authenticator
> should be allowed to send an EAP Success inside RADIUS

Thanks.

Alper

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