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

[Yoshihiro Ohba (yohba]

Lakshminath,

As I commented in a previous email, 802.11r key hierarchy is defined
within a single distributed authenticator and there is no key sharing
between different authenticators.  So there is no need to use of
"SHOULD NOT" instead of "MUST NOT".

Also, use of "SHOULD NOT" instead of "MUST NOT" is going against the
following requirement of RFC 4962:

"Likewise, compromise of a single authenticator MUST NOT compromise
keying held by any other authenticator within the system."

Yoshihiro Ohba



On Sun, Nov 18, 2007 at 01:14:12AM -0800, Lakshminath Dondeti wrote:
> 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
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>