eap Mailing List: Re: About use of EMSK

[Yoshihiro Ohba (yohba]

One thing we might discuss is whether (a) and (b) provide the same
level of security or not.  Since (b) is not end-to-end, negotiation
bidding down attack may be possible by passthrough authenticator.

Yoshihiro Ohba


On Mon, Mar 06, 2006 at 11:36:24AM +0200, Jari Arkko wrote:
> 
> 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.
> 
> 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.
> 
>       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.
> 
> Based on this my current preference is (b). I'd be willing
> to accept (a), too.
> 
> 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.
> 
> Based on this my current preference is (1). But its a close
> call.
> 
> --Jari
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>