eap Mailing List: Re: Key derivation and the principle of equivalence

[Bernard Aboba (aboba]

> This seems true. Interestingly, it even seems true if
> one imagines a fast handoff scenario where you start
> off from a combined NAS-AAA device and handoff to
> another NAS.

Yes.

> But its also interesting to note what the text above
> does not say. I believe peers already can learn the
> identities of both the authenticator and the server,
> separately, and if channel bindings are provided peers
> can also learn of potential discrepancies among the
> properties claimed by the different parties. Of course,
> such discrepancies can be learned even if all of this
> is in the same box.

Yes.  The Server-ID is exported by the EAP method, while the lower layer
may expose the NAS-Identifier.  These two identifiers may not be the same,
even where the authenticator and server are on the same box.

For example, the Server-ID exported by the EAP method may refer to the
name of the EAP server, while the NAS-Identifier might refer to the MAC
address of the box.

Since the exported keying material and parameters are pushed down to the
lower layer, it is really the lower layer that defines how the key cache
operates, if one exists at all.  For that purpose, it is typically the
authenticator identity exposed by the lower layer that matters.

For example, as the result of an EAP conversation the peer can know that
it has derived keying material with the EAP server identified by the
Server-ID.  That could be a AAA server handling hundreds of NASes.

However, once the lower layer receives the keying material, it needs to
organize its key cache.  Typically they do this by associating the keying
material passed down to them with an Authenticator Identity as defined by
the lower layer.  But in principle I think that the lower layer could
also advertise the Server-ID.

> Secondly, the text does not say anything about
> fast handoffs (and this may well be right). But in
> fast handoffs peer would again be aware of changing
> identities of the authenticator (even though in this
> case you'd not really be running EAP again). And
> keys for this would be created slightly differently. But
> again, the peer has no real knowledge of whether
> he handed off to a new box or just a different part of
> the same box.

Right.  The lower layer is passed the keying material and parameters
(peer-ID, server-ID, method-ID, key-lifetime).  The lower layer can use
this information to organize its key cache in addition to any lower layer
information it might gather.

If there is no AAA server, fast handoff (e.g. authentication without EAP)
is still possible.  If the lower lower can identify a point of attachment
as being possessing keying material, then it can use the keying material
in the key cache to authenticate with it.