eap Mailing List: KDF Negotiation for AMSK derivation (was RE: [eap] About use of EMSK)

[Narayanan, Vidya (vidyan]

A higher level question here - why do we feel compelled to even allow
for KDF negotiation to derive an AMSK from the EMSK? It is a
yet-to-be-defined thing and the computation is only done by the EAP
server and peer - could we just not pick a KDF and mandate it? 

Regards,
Vidya

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba [at] tari.toshiba.com] 
> Sent: Friday, March 17, 2006 12:24 PM
> To: Jari Arkko
> Cc: eap [at] frascone.com; Bernard Aboba
> Subject: Re: [eap] About use of EMSK
> 
> 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
> > 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>