eap Mailing List: The end of the keying hierarchy...

[Bernard Aboba (bernard_aboba]

Jari Arkko said:

"My e-mail was a response to the discussion you and Joe had about Joe's 
comments to 2.6. I agree that we want to keep eap-keying as small as 
possible. But I think the practical alternatives are saying that the key 
hierarchy ends at EMSK (and leave rest of keying-extns) or that the 
hieararchy ends at AMSK (and leave all applications of AMSKs to 
keying-extns). I'd prefer the latter, but I could be persuaded to go for the 
former, too."

The EAP key hierarchy "ends" with the keying material passed to the lower 
layer.  One attraction of passing the EMSK to the lower layer is that this 
implies that the calculation of AMSKs is purely a lower layer issue, and not 
something that the EAP layer needs to be concerned about.   However, 
allowing the EMSK to be passed to the lower layer in some circumstances 
(stand-alone) but not in others (pass-through) violates the principle of 
Mode independence, so I don't think we can allow this.

Of course, the transformation of the Method-ID => Session-ID and EMSK => 
AMSK within the EAP layer does imply functionality within the EAP layer that 
is not envisaged in RFC 3748, so we need to think this over a bit.  
Essentially we are saying that the EAP layer is shielding EAP methods from 
writing into each other's Session-ID space, guarding against compromise of 
the EMSK by lower layers,
and in general becoming something of a "security policeman" for EAP.

Joe said:

"My concern with the above is that you may not want all of the authenticator 
to have access to the EMSK.  You would probably want it to remain with the 
part of the authenticator that hosts the EAP server."

In the case where EAP runs standalone, the EAP authenticator *is* the EAP 
server.  In the case of passthrough, the EAP authenticator doesn't host the 
EAP server, although it is co-resident with the AAA client.  So I guess I'm 
not understanding your comment.

Maybe this has to do with the flow of keying material/attributes in the 
standalone case?  In order to preserve mode independence, I think that the 
keying material needs to be processed the same way it would be if EAP were 
being run standalone.