Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications

From: <[email-masked]>
Date: Wed, 7 Jan 2004 11:36:55 +0200

Bernard Aboba wrote:
> 
> In Section 7.2.1, change:
> [...]
> To:
> 
> "Protected result indications The ability within a method for
> the authenticator to indicate to the peer whether it has
> successfully authenticated to it, and for the peer to
> acknowledge receipt of that indication as well as indicating
> to the authenticator whether it has successfully authenticated
> to the peer.  This claim requires implication of a
> method-specific result exchange that is authenticated,
> integrity and replay protected on a per-packet basis.  Since
> this requires a key, methods making this claim need only
> protect result indications sent after a key has been
> derived. See Section 7.16 for details."

Some methods may derive keys first (using e.g. Diffie-Hellman),
and authenticate them later in the exchange. Before this second
part has succeeded, the parties don't know who they are sharing 
the key with, so MAC'ing a packet with that key doesn't 
really provide per-packet authentication.

Since protecting these result indications seems quite complex
(and in many cases, impossible), I'd suggest we switch back
to "acknowledged result indications", defined something like this:

  Acknowledged result indications: A method provides
  acknowledged result indications if after the method has
  finished (1) the peer knows whether the authenticator will 
  grant access (that is, whether it will send an EAP Success or
  Failure packet), and (2) if the authenticator decides to grant
  access, it knows whether the peer will accept it.

  Acknowledged result indications are intented to improve
  resilience to packet loss; see Section 4.2 for discussion.
  Depending on the method and circumstances, these result
  indications could be spoofable by an attacker.

(This definition tries to take into account also "implicit" 
result indications where there really isn't anything that
could be called a "result exchange").

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Jan 2004 07:14:12 -0800 (PST)

> > to the peer.  This claim requires a

Agreed.

> to "acknowledged result indications", defined something like this:

The original change was made in part because without protection,
result indications only address the timeout issue.

> could be called a "result exchange").

How about combining them?

"Protected result indications:  A method provides
result indications if after the method has finished (1) the
peer knows whether the authenticator will grant access (that is,
whether it will send an EAP Success or Failure packet), and
(2) if the authenticator decides to grant access, it knows
whether the peer will accept it.  Result indications improve
resilience to packet loss; see Section 4.2 for discussion.

Depending on the method and circumstances, result indications
can be spoofable by an attacker.  Result indications are
said to be protected if they are authenticated, integrity and
replay protected.  Since this requires a key, it is only
possible to provide protection once mutual
authentication and key derivation are complete."