eap Mailing List: Re: About use of EMSK

[Jari Arkko (jari.arkko]

Salowey, Joe wrote:

> Jari,
>
> Thanks for putting this together, but I think there is more to it than
> you describe.
I am SURE there is :-)

> The approaches (1) and (2) have very different
> characteristics and do not provide equivalent protection for the EMSK.
>  
Agreed.

> 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.  
>  
Noted.

> > (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.  
>  
Well, I think we should do (1) too. But I'm not sure we can
rule out the use of EMSK for any other purpose even in (2). There's
a security difference, yes. There's an even bigger difference in
that I'm not at all sure how that would work with current AAA --
how would the AMSK get to whoever that needs it?
But perhaps that's solvable...

> > 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. 
>  
Right.

> >       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.
>  
I agree that the KDF affects other apps. Whether the KDF needs to be
known to these other apps is another question, I think. It could be
that the NAS that got the EMSK is deriving the AMSKs, so the other
parties would only get a plain key. But again, this is mostly speculation
because I have not seen a design where we both send the EMSK to the
NAS and use it for some other application than the lower layer in
question.

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

> > 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.
>  
Right.

> > Based on this my current preference is (1). But its a close
> > call.
> >    
> [Joe] I agree with (1) as the preference. 
>  
Noted.  Thanks for your comments!

--Jari