eap Mailing List: Re: Proposed resolution of Issue 212: Protected Result Indications

[Jari Arkko (jari.arkko]

Hi Bernard,

I have a question...

> "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, only either an EAP-Success or EAP-Failure will be
> accepted, no more method specific messages are expected), 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 it supports result indications as well as the
> "integrity protection" and "replay protection" claims. A method
> claiming to support protected result indications MUST indicate which
> result indications are protected, and which are not. See
> Section 7.16 for details."

My example method is EAP AKA, which sends an authenticated challenge
from the server in its first message. Before this challenge is sent,
the server already knows the identity of the peer.

Here's the question: Lets assume the method specification required that
the challenge be sent if and only if authz check for the peer is
successful. Would this be sufficient for satisfying condition 1 above?
Can you see such practise on shared key methods as sensible?

--Jari