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

[Yoshihiro Ohba (yohba]

Hi Vidya,

I am ok with either hardcoding a mandatory KDF in a specification or
allow for KDF negotiation.  But regardless of it, some negotiation
might be needed for Channel Binding if Channel Binding is an optional
functionality.  For MSK branch Channel Binding is optional, but I am
not sure whether Channel Binding is mandatory or optional for EMSK
branch.

Yoshihiro Ohba


On Fri, Mar 17, 2006 at 01:02:55PM -0800, Narayanan, Vidya wrote:
> 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
> > 
> 
>