eap Mailing List: RE: Re: EAP Key Binding

[Bernard Aboba (aboba]

> To honor this requirement, the identity
> delivered to the NAS is not necessarily the authenticated identity
> directly, but rather a function of the authenticated identity, something
> derived from the authenticated identity that can be made public without
> violating the EAP Peer's privacy.

The key management framework defines the Peer and Server identities
utilized by existing methods.  We can mention that this information needs
to be passed up along with the Key Name and exported keys.  On the peer
side this information can be passed down to the lower layer to
do the required computation.  On the AAA server side, the required
computation can be sent to the NAS in an attribute.

The question in my mind is whether this is an existing attribute (e.g.
User-Name), a proposed attribute (CUI), or something new altogether.
If the function of the peerID includes the Challenge it could qualify
for inclusion in the CUI attribute which is supposed to not allow
tracking.  I don't think User-Name will work since some AAA servers
might just send the peer-ID with no hiding.  However, I'm not sure if
the content of CUI can be constrained this way.

> You may respond that some sort of multi-factor authentication may be
> used, and that several identities will be asserted during
> authentication. Fine. Let's define some standard way to concatenate them
> and compute a function of them. And that is the right thing to do, too,
> because all of the identities collectively are what the Server verified
> by EAP authentication.

I think that it is sufficient to require the EAP method to define and pass
up the peer-ID.  Whatever the method passes up is what is included in the
computation.

> A further requirement on what identifier gets returned to the NAS is it
> must be something the EAP Peer can reassert to the NAS during any
> subsequent handshakes that put the key in place. It is the job of things
> like 802.11r to structure their protocols so that the Peer will reassert
> its identity to the NAS, so the NAS knows the key is being used in the
> context asserted to by the EAP Server.

Right.

> This realization is
> an important step forward in the conversation, and I don't remember it
> being made before.

Actually, it was discussed in the EAP WG 18 months ago as part of the
channel binding issue.  However at the time there was no request from IEEE
802.11 for that functionality.

> The identity of the NAS the Server (and the Peer) would be required to
> use has to be the one the Server uses to name the NAS. This is the NAS
> ID. This says that if 802.11r or some other link discipline wants its
> key usage to be properly bound, it will have to arrange for its NASes to
> advertise their NAS IDs to their EAP Peers, so that the Peers can verify
> the Server's assertion of the NAS indirectly through key derivation.

This is also required so that the peer can understand the scope of
the key that it has derived.  Including it in the AAA-Key calculation
would ensure that the key was not used outside its scope (e.g. the NAS to
which the AAA server sent the key).

> [Walker, Jesse] If you recall, I prepared a requirements document
> 11-04-1498 that we discussed at the November 2004 IEEE 802 meeting in
> San Antonio. At the time you indicated you did not think it was
> necessary for IEEE to forward such a document to IETF.

My understanding was that IEEE 802.11 did not vote to approve the
requirements document, so that it had no official status.

> For the record,
> now are you asking 802.11 to update and adopt this or some similar
> document as requirements and then forward the result to IETF?

Yes, if there is consensus on such a set of requirements that would be
helpful.  Note that I'm not just talking about requirements for the 802.11
handshake;  I'm talking about 802.11 requirements for the system (which
would include any functionality required from EAP or AAA).