eap Mailing List: Re: hopefully final changes for draft-ietf-eap-keying

[Lakshminath Dondeti (ldondeti]

I have stayed out of this discussion so far, but I have a few 
observations in resolving Sam's Discuss.

Sam suggests in part:

"I think it would be
much more clear what is going on if the document made it clear that
while EAP keying material cannot be exported, keys derived from EAP
keying material may be exported within appropriate key scopes. "

It appears that he wants to facilitate 11r design (and perhaps other 
designs too) where the authenticator uses the MSK (EAP keying material) 
or a portion thereof as the root of a local key hierarchy and 
distributes derived keys.

I don't disagree.  The answer I think is already in the text that Sam 
chose to quote.  It may need a bit of tweaking.

">An EAP authenticator MUST NOT share any keying material with
>another EAP authenticator, since if one EAP authenticator were
>compromised, this would enable the compromise of keying material on
>another authenticator.  "

Perhaps the tweak might be that we should use "SHOULD NOT" instead of 
"MUST NOT."   The exception (to be documented) is the case where the 
threat that we cite can be mitigated otherwise.  So, the claim might be 
that keys or derived keys may be shared as long as compromise of the 
authenticator is made difficult.  Obviously the notion of derived keys 
protects from compromise of the receiving entities and the presumption 
is that it is easier to compromise the entity that receives keys than 
the one that derives the keys.

regards,
Lakshminath