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

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Jan 2004 15:31:37 -0800 (PST)

> Hmm... on a second thought, actually (1) should be something
> like "(1) if the peer is willing to use the access provided
> by the authenticator, it knows whether the authenticator will
> grant access (that is, whether it will send an EAP Success
> or Failure packet), and..."
>
> (Is there some easier way to say that? The idea was that if the
> peer is not going to use the access, it doesn't have to know
> about the authenticator's decision.)

I think your suggestion is OK.

> I'd say that result indications are protected if they can't
> be spoofed, and unprotected otherwise (since if we don't have
> a "result exchange", speaking of integrity protecting is
> somewhat confusing).  It also seems the revised definition
> of "result indication" covers only things that occur after
> key derivation...

We already have "integrity protection" and "replay protection" claims
so perhaps it is easiest to piggyback on these.  I don't think we have to
specify exactly which result indications are protected and which aren't;
the method specification can clarify that.

So perhaps the right definition is:

"Protected result indications
A method provides result indications if after the method
has finished (1) if the peer is willing to use the access provided
by the authenticator, it 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. A method is said to provide protected
result indications if supports result indications as well as the
"integrity protection" and "replay protection" claims.
See Section 7.16 for details."

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

---

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

Bernard Aboba wrote:
>
> > 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:
> 
> The original change was made in part because without protection,
> result indications only address the timeout issue.

What other issue would require that the result indications 
are protected? (protecting the result indications is not likely
to make DoS any harder)

> >   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
> >   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").
> 
> 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

> 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."

Thus, if I'm getting this right, it seems that result indications 
are protected iff the following cases don't occur:

1. Peer is satisfied. Authenticator is also satisfied 
   (sends EAP Success), but attacker convinces the peer to 
   expect EAP Failure instead.
2. Peer is satisfied. Authenticator is not satisfied 
   (sends EAP Failure), but attacker convinces the peer to 
   expect EAP Success instead.
3. Peer is satisfied. Authenticator is satisfied, but 
   sends EAP Failure anyway because the attacker convinced it 
   the peer is not satisfied.
4. Peer is not satisfied. The authenticator is satisfied 
   and sends EAP Success because the attacker convinced it 
   the peer is satisfied.

(or did I get it right? ouch, my brain hurts :-)

Or, equivalently (?), one of the parties proceeds to four-way
handshake (or whatever comes after EAP) and the other one
doesn't because it had spoofed information about the other
party's intentions. (Note that the end result is still just 
a DoS, unless the attacker gets the session keys; and if he 
does, we have worse problems.)

Let's see how e.g. EAP-TLS handles these... it seems that
all cases can occur. Cases 1 and 3 could probably be 
prevented by rather simple cases (silently discard packets
with incorrect MAC instead of failing). Cases 2 and 4
might be prevented if TLS Alert messages were used in
a different way than shown in Section 3.8's sequence diagrams.

Best regards,
Pasi