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

[Salowey, Joe (jsalowey]

> 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] This is a bit squishy interms of what a service is.  It would seem
that an EAP method would have to take "service" as an input.  

> > [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.
> 
[Joe] I don't think it was the original intent for the EMSK to reach the
lower layer.  In this case the EMSK becomes roughly equivalent to the
MSK, which is confusing at best.  

> 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} I think this is correct, but I need to think about it more.  

> > [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] OK then I would say the EMSK is exported from the method, but it's
use is undefined at this point so it stops there (doesn't propagate
throught the rest of the layers). 

> > [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.
> 

[Joe] Yes

> 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.
> 

[Joe] This seems to complicate things.  I wonder if it is really
necessary? This may add new requirements to EAP methods.