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

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> > 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.
>  
Perhaps this discrepancy can be explained by considering
that we are talking of both physical objects (a box) and
logical objects (a layer or a module). It isn't clear to me
that in an integrated case the "NAS" module gets all
the information that the "EAP method" module has...

> > [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.
>  
I like Joe's "exported context" term.

> 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.
>  
Works for me. This is at least the most general approach,
and the framework needs to support that, even if we
decide to have just one direction in an actual method
enhancement.

> 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.
>  
Perhaps you can make this optional in the figure.
I still haven't figured out whether you really need
this or not in the actual methods. You could rely on
access-reject if its the server that verifies (even if
you get less info on why you didn't get in).

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

--Jari