eap Mailing List: RE: About use of EMSK

[Salowey, Joe (jsalowey]

Jari,

Thanks for putting this together, but I think there is more to it than
you describe.  The approaches (1) and (2) have very different
characteristics and do not provide equivalent protection for the EMSK.
Passing the EMSK to the lower layer limits how it can be used because
now it has been exposed to the lower layer.  Therefore I think anything
based on 2 is unacceptable.  

More below 

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Monday, March 06, 2006 1:36 AM
> To: Bernard Aboba
> Cc: eap [at] frascone.com
> Subject: Re: [eap] About use of EMSK
> 
> 
> Here's some analysis of the server vs. lower-layer based
> EMSK processing approaches.
> 
> (1) In the server based approach we keep the
> EMSK in the server (perhaps just for a moment)
> and generate the AMSKs, which are given to the the
> different applications, such as fast handoff mechanisms.
> The use of these applications goes via AAA, e.g., some kind
> of key requests or fast re-auth requests can be sent from
> NASes to the server. The AMSKs are derived using a KDF
> which is decided either (a) by a default plus optional negotiation
> in methods or (b) by lower layer negotiation and having AAA
> tell the server which KDF to use.
> 
> (2) In the lower-layer based EMSK processing approach, the
> EMSK is delivered to the authenticator along with the MSK.
> KDF is selected either (a) by a default in EAP plus optional
> negotiation in methods, choice is communicated to the
> lower layer via AAA or (b) by lower layer negotiation alone.
> The lower layer is responsible for all use of the AMSKs
> in a local context. That is, no AAA key requests are needed
> or possible.
> 
[Joe] Also the EMSK cannot be used securely for any purpose outside of
the lower layer. I don't think (2) is a good choice.  


> Discussion about the chosen approach for EMSK use has
> so far appeared to assume 1a vs. 2b. Based on the above,
> it seems that the KDF negotiation may be a separate
> issue from who maintains the EMSK and calculates AMSKs.
> In the following I'll try to analyze these issues.
> 
> The KDF negotiation is indeed problematic almost no
> matter what we do. Requiring new funtionality in methods
> is in practice often a non-starter; while we can develop
> new methods and update old ones, it is expected that
> most of current usage will continue to use the existing
> methods. Having a default does not help much either,
> if the default becomes broken in the near future.
> But requiring new functionality in link layers it not
> always easy either. It would be easy when we are developing
> a new link layer and including some EMSK usage as a part
> of that. But if we were to use EMSK for some new function
> over 802.11, for instance, would there be enough incentive
> to extend 802.11 just to make this possible?
> 
> The choices and their implications are:
> 
>   (a) Specified default, optional negotiation in EAP methods.
> 
>        This implies an interface either from methods to the 
> AAA/EAP server
>        code (for solution 1) or AAA protocol extensions for 
> solution 2.
> 

[Joe] Note that there doesn't necessarily have to be negotiation in the
method.  The method could specify a default.  If the method does not
specify a default then a mechanism independent default would come into
play.  

>        Changes in peers, servers, methods, possibly AAA protocols.
> 
>   (b) Lower layer negotiation.
> 
>        If used together with solution 1, implies AAA protocol 
> extensions
>        to communicate the KDF. If used with solution 2, implies AAA
>        protocol extensions to carry the EMSK.
>       
>        Changes in lower layers, AAA protocol. No changes in 
> EAP or methods.
> 

[Joe] Another side effect is that the lower layer then chooses the KDF
for all other applications.  The method knows best how to choose a key
derivation method that is efficient and secure for its operation.  If
the method's key derivation scheme is not sufficient for an environment,
then it is likely the method itself will not be usable for reasons
beyond MSK derivation.  In addition here the KDF name space must be
coordinated.   

> Based on this my current preference is (b). I'd be willing
> to accept (a), too.
> 
[Joe] My choice would be (a)

> The choice between server or lower-layer based EMSK processing
> depends on security implications and ease of use for 
> different purposes.
> The choices are:
> 
>   (1) Derive AMSKs at the EAP/AAA server.
> 
>        Implies a AAA protocol extension to retrieve AMSKs.
> 
>        Changes at the EAP/AAA server, authenticator. New, stateful
>        nature of the EAP/AAA server.
> 
>   (2) Derive AMSKs at the lower layer.
> 
>        Implies a AAA protocol extension to carry EMSK to the
>        authenticator.
> 
>        Small changes at the EAP/AAA server, main functionality in
>        the authenticator.
> 
>        Hard to see how other nodes than the authenticator would
>        actually use the AMSKs. Traditionally, NAS -> NAS communication
>        has not been easy compared to NAS -> AAA communication.
> 
[Joe] Because the EMSK, and therefore all the AMSKs, are known to the
NAS the security properties of these two solutions are very different.  

> Based on this my current preference is (1). But its a close
> call.
[Joe] I agree with (1) as the preference. 
 
> --Jari
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>