eap Mailing List: RE: keying issue 221: EMSK usage guidelines

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Wednesday, March 03, 2004 4:15 PM
> To: Joseph Salowey
> Cc: eap [at] frascone.com
> Subject: Re: keying issue 221: EMSK usage guidelines
> 
> 
> Joseph Salowey wrote:
> 
> >>- "The application MUST NOT use the EMSK in any other way except to
> >>    derive Application Master Session Keys (AMSK) using the key
> >>    derivation specified in this document." This seems inconsistent
> >>    with the idea that applications should only know the AMSK, not
> >>    the EMSK.
> >>
> > 
> > [Joe] OK, would this be better?  "Applications MUST NOT use 
> the EMSK 
> > directly, instead they use Application Master Session Keys (AMSK) 
> > derived from the EMSK using the key derivation specified in this 
> > document."
> 
> Ok.
> 
> >>- Don't we need key names, too? Suggest branching a key naming
> >>   hierarchy from the EMSK before using it to branch AMSKs.
> >>
> > 
> > [Joe]  Yes we need key names, but I'm not sure it is a good idea to 
> > derive public names from secret keys.  I think this needs more 
> > security analysis.  I think it would be better to have the 
> EAP method 
> > export a name based on publically exchanged information.
> 
> Would this bring back the "must exchange nonces" requirement
> we had earlier?
> 

[Joe] I don't think so, I think that the basic requirement is that both
parties in the EAP exchange can derive the same key name and that the
name is unique.  I'm suggesting the methods derive the key name in their
own way.  This could make use of nonces, it could send the key name as
authenticated data in the exchange, and there are probably other
possibilities as well.  It might be OK to derive the key from the EMSK,
but a few people I mentioned this to disliked it.  In theory I suppose
it increases the chance that an attacker can precompute a partial
dictionary that will allow them to compromise some sessions on a network
(its difficult to attack a particular session, but it may increase the
possibility of compromising one arbitrary session out of many).  Perhaps
it is not a big deal, perhaps it is worse than I think it is.