eap Mailing List: Re: Re: [802.1] Re: 802.1X interface variable

[Bernard Aboba (aboba]

> I still wonder about the protected result indications part and to which
> extent current and proposed methods comply with that. For instance, is
> EAP Archie's exchange considered a protected result indication, even if
> it is performed as a part of the authentication exchange and not as a
> separate "result exchange".

Key derivation protocols typically do not have a separate "result
exchange" yet somehow both sides are kept in sync as to the authentication
state.  If the parties mutually authenticate and prove possession of the
key then the only reason parties could be out of sync with respect to the
state is if one or both of them is not authorized.  If the protocol
supports error messages, then the use of an error message is a
failure "result exchange" and the completion of the protocol without an
error message (e.g. FINISHED message) is a success "result exchange".

Looking at the EAP Archie security claims, EAP-Archie provides mutual
authentication and key derivation but does not claim to provide protected
result indications.  Even though EAP-Archie has an Archie-FINISHED
message, it does not support any error messages, so that lack of
authorization cannot be signaled.  It would therefore appear that there
is no way for a server or client to send an error indicating that the
protocol has failed.  This will result in long time outs and possible
synchronization problems between the client and the server.  This seems
like a flaw in the protocol that needs to be fixed.

> What about EAP AKA, does that satisfy the requirement?

EAP AKA has support for client error messages: AKA-Client-Error.  However,
it would appear that there is no support for server error messages, and
that the EAP-Failure packet is used instead.  If an attacker spoofs an
EAP Failure packet after mutual authentication, does the client have to
accept it?

> It seems that the peer's response to an authenticated
> authentication request from the network can be considered to be a
> protected result indication, but I'm not sure if the reverse direction
> can be said to be indicated at the moment.

Yes, I think that is a correct assessment -- unless mutual authentication
*always* implies that the server will authorize the client and vice versa.

> More generally, on a shared secret-based method, how could the
> non-success of authentication be indicated so that the indication is
> still authenticated? If you found out that the shared secrets did not
> match, we can hardly authenticate the indication either... Or is it
> enough that you just show mutual possession of the shared secret?

Proving mutual possession of the shared secret is enough to provide mutual
authentication.  However, there is a separate issue of authorization -- if
mutual authentication occurs, is this enough for both sides to know that
they are authorized?  For this an authorization error message is required.
Since authentication has occurred, this can be MAC'd. If such a message is
supported and is not sent, then the client can know that the server will
eventually signal Success and can silently discard EAP Failure packets.