eap Mailing List: RE: EAP-Keying draft issues

[Walker, Jesse (jesse.walker]

Alper:

-- snip --

I see two levels of binding in here:

1- binding user name and NAS id to the authentication session. This is
where we need AAA server's attestation.
2- binding MAC addresses (or, some other device identifiers) to the
authentication session. This is where we can get away without having to
get an attestation from AAA server.
[Walker, Jesse] This seems reasonable to me.

Eventually we need to bind the MAC addresses to the session. My point
is, we can get there in two steps too (not necessarily having to run the
MAC addresses via the AAA server).
[Walker, Jesse] I'm not sure we have to worry about step 2. Or rather, I
don't see (yet) why the Peer and the NAS cannot do the binding
themselves. If the AAA server attests that the identities are bound to
the MSK, then any exchange confirming possession of the key can also
confirm that the key holder (a) is using any address it claims it is
using and (b) that these are bound to the identifiers for the purpose of
this session. It is up to the consumers of the binding information (like
802.11) to do the right thing with it.

IKEv1 takes this tack and no one has raised a security issue. IKEv1
phase 1 verifies that the identities are bound to a key. IKEv1 phase 2
binds the IP addresses each endpoint wants to use to a particular IPsec
SA.

-- Jesse

-- snip --