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

[Bernard Aboba (aboba]

> [Joe] I need some help with terminology here.  Isn't it that EAP is
> spoken between the EAP peer and authenticator unless the authenticator
> is running in pass-through mode in which case it is spoken between the
> EAP peer and an EAP server?   If this is the case then we probably have
> to adjust some of the terminology used below.

As defined in RFC 3748, the term "EAP server" applies in both the
pass-through and non-pass-through cases.  Where there is no pass-through,
the "EAP server" and "EAP authenticator" are the same entity.

> [Joe] I have been thinking that the EAP-Server itself just contains
> enough information to get the authentication done.  I don't think of the
> EAP Server knowing about authorization to services for specific
> identities, I thought this would be handled by the entity hosting an
> EAP-Server which understood services.  I would expect the same for a
> peer.

While it is possible for an EAP method to support authorization exchanges,
most methods don't do this.  So typically this is a lower
layer function (AAA can be considered a lower layer of EAP).

Here I'm assuming that "authorizations" refers to something different from
Channel Bindings or Key Context.

> [Joe] I think we want to limit the discussion of the EMSK to the
> extensions document.  Currently in this document the EMSK serves no
> purpose.

I think the document says that the MSK, EMSK and (optionally) the IV are
generated and passed down to the lower layer by the EAP peer and server.
AMSKs are generated within the lower layer based on the exported keying
material.

>From the perspective of the Principle of Equivalence, this creates an
interesting issue.  In the non-passthrough case, it can be assumed that
both the EAP peer and authenticator lower layers obtain the MSK and
EMSK.  As a result, both lower layers can calculate AMSKs.

In the pass-through case, AAA does not fulfill the "Principle of
Equivalence" in that only a portion of the key hierarchy present on the
EAP server is replicated to the authenticator.  For example, in RADIUS/EAP
and Diameter/EAP only the MSK is replicated.  In EAP extensions, other
portions of the key hierarchy may be replicated, such as the AMSK and
possibly the MSK as well.

So we have a situation where the key hierarchy may be partially
replicated and the EAP peer needs to understand what has occurred so
that it can know how to calculate the TSKs.  This seems like information
that needs to be securely synchronized between the EAP peer, authenticator
and server, but this is not something that can be accomplished within EAP
itself.  It is therefore an obligation of the EAP lower layer - to make
it clear to the authenticator and peer how the TSKs are to be
calculated, and of AAA, to replicate the required portion of the key
hierarchy between the EAP server and authenticator.

> [Joe] Instead of key hierarchy I look at this as an exported context
> which contains keys as well as other info.  The exported context would
> include MSK (leave EMSK exportation, if necessary, to extensions),
> Peer-ID, Server-ID, Method-ID, and Authenticated attributes.
> Authenticated attributes are data that is exchanged during the method
> such as EAP Channel-Bindings.  They are not evaluated by the method, but
> are part of the context. Note that the means to export this context data
> is outside EAP.

Perhaps Key Hierarchy is not the right term here.  The EMSK is mentioned
as one of the exports because RFC 3748 says that it is generated (though
it doesn't describe usage).  I agree that Channel Bindings need to be
added.

> [Joe] Remove the AAA server terminology and say the the EAP method may
> export authenticated attributes (or channel binding parameters) as an
> opaque blob which is part of the context.  Also does the method actually
> receive confirmation of whether parameters match?

Yes, removing the AAA server terminology will improve clarity.  I think we
need to  say that the EAP method may export or import Channel Bindings as
an opaque blob.

For example, in some cases it appears that Channel Bindings are passed to
the EAP method layer from the lower layer (e.g. on the EAP peer) and in
some cases, they may be passed from the EAP method layer to the lower
layer (e.g. on the EAP server).  However, the discussion relating to the
Service Authentication draft disclosed some uncertainty on exactly how
this works.  Perhaps we could fudge it for now by including a
bi-directional arrow for Channel Bindings.

As to confirmation, I think that on the side where the bindings are
verified, the lower layer passes to the EAP method a confirmation
on whether they were verified or not.  Presumably the EAP method
communicates this to the other side.  So if the Channel Bindings
are sent by the peer to the server for verification, then the server
sends the peer an indication of whether they matched.

I'll work on modifying the figures and text to describe this.