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

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:
> > draft-ietf-eap-keying-01 already states this:
> >
> >    EAP key derivation takes place between the EAP peer
> >    and EAP server, and methods supporting key derivation MUST also
> >    support mutual authentication.
> >
> > (Perhaps this is one of the keyword statements that should already
> > have been moved to 2284bis...)
>
> This statement is already in Section 7.10.

Ah, yes.

> > The reverse requirement (mutual auth => key derivation) seems sensible
> > to me as well. I do not have a comment on the protected result indiciations
> > part, I have to think about that some more.
>
> I've added both statements in the proposed resolution of Issue 207 (posted
> previously).  Let me know what you think.

The key deriv => MUST mutual auth part seems now consistent, thanks.

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". What about EAP AKA, does that satisfy the
requirement? 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. More generally, on a
shared secret-based method, how could the non-success of authenticated
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?

--Jari