eap Mailing List: RE: EAP Key Binding Discussion

[Salowey, Joe (jsalowey]

> -----Original Message-----
>       From: Walker, Jesse [mailto:jesse.walker [at] intel.com] 
>       Sent: Saturday, April 16, 2005 4:41 AM
>       To: eap [at] frascone.com
>       Cc: Paul Funk; Henry Ptasinski; Steve Emeott; Russ 
> Housley; Nancy Winget
>       Subject: [eap] EAP Key Binding Discussion
>       

<snip>

> 
>                   TMS
> 
>                    |
> 
>               +----+----+
> 
>               |         |
> 
>              MSK       EMSK
> 
>               |
> 
>               |
> 
>            AAA-Key
> 
>        
> 
>       The TMS is an EAP method specific "session key" 
> constructed between the EAP Peer and the EAP Server. From 
> this the MSK and EMSK are derived, again in an EAP method 
> specific manner. The AAA-Key is derived from the MSK and 
> delivered to the NAS. The AAA-Key is then used as the session 
> key between the EAP Peer and the NAS.
> 
>        
> 
>       The issue has always been how to bind the AAA-Key to 
> this NAS and this EAP Peer for this session. The NAS needs to 
> know that this AAA-Key is for this <NAS, EAP Peer> pair for 
> this session, and the EAP Peer likewise needs to know the 
> same thing. The only party that is in a position to inform 
> both parties of this binding is the EAP Server. The EAP Peer 
> can trust the EAP Server to make this assertion, because it 
> has authenticated the EAP Server (at least in the case where 
> the EAP method provides mutual authentication), and the NAS 
> can trust the EAP server to make this assertion, because it 
> has some channel with the EAP server presumed to be secure.
> 
>

[Joe] We need to be a little careful here so we don't load too much
application specific knowledge into EAP methods.  In this description
there should be an application independent portion of the EAP server and
an application aware portion of the EAP server (may be the AAA logic).  
         
> 
>       I think everyone agrees this issue is solved for the 
> NAS, as mechanisms exist to allow the EAP Server to attest to 
> the binding. It could, for instance, deliver the EAP Peer's 
> authenticated identity Peer-ID to the NAS with the AAA-Key 
> along with the EAP Success message; abstractly:
> 
>        
> 
>             EAP Server --> NAS:  EAP-Success || AAA-Key || Peer-ID
> 
>

[Joe] In this scheme what is the Peer-ID?  I'm not sure that the Peer-ID
in this protocol is the same as the Peer-ID that is the authenticated
name.  If it is not then this mechanisms may run into problems.   Also
is it the identity that is important?  Perhaps it would be possible to
use a scoping or an authorization attribute instead.
         
> 
>       The NAS can then check whether it is talking with the 
> right EAP Peer using a protocol that would require the EAP Peer to
assert its identity:
> 
>        
> 
>             NAS --> EAP Peer:  Challenge
> 
>             EAP Peer --> NAS:  f(AAA-Key, Challenge || Peer-ID)
> 
>             etc.
> 
>        
> 
>       The function f used in this protocol would be selected 
> so that it would becomputationally infeasible for the EAP Peer to
produce 
> the right response without knowing the AAA-Key, the Challenge 
> value, and the Peer-ID value. And if exposure of the Peer-ID 
> to the NAS is deemed onerous, then we can certainly replace 
> it in the above with another session specific function of 
> Peer-ID, e.g.,
> 
>        
> 
>            g(TMS, Peer-ID)
>
>        
> 
>       for some suitable function g. The EAP keying draft 
> could specify that delivery of (a function of) the Peer-ID 
> with the session key is a requirement, and we would be done 
> with the key binding for the NAS.
> 

[Joe] This type of value is not exported by EAP right now and I'm not
sure it should be.  If the Peer-ID is the identity authenticated by EAP
then it may be possible.  IF not then I don't think this is a good
construct since it requires application specific knowledge in the EAP
method better to use a key derived from the EMSK hierarchy.  

<snip>

>        
> 
>       Of course life is never that simple, because the key 
> hierarchy above is already in place, and doesn't include the 
> derivation AAA-Key := kdf(MSK, NAS-ID). Therefore, we would 
> have to do something else, in order to avoid breaking already 
> deployed equipment. A candidate might be the EMSK, which is 
> currently unused. We could define something like
> 
>        
> 
>            Bound-AAA-Key := kdf(EMSK, "bound EAP session key 
> || SID || NAS-ID)
> 
>        
> 
>       where SID is the EAP session identifier, and deliver 
> the Bound-AAA-Key to the NAS along with the AAA-Key. 

[Joe] Its not currently clear to me that you need to include the binding
in the key derivation. Why can't the server just send the NAS-ID to the
peer? I need to think about it more.  
  

> We could 
> deliver this with a session specific EAP Peer identity
> 
>        
> 
>            Peer-Session-ID := hash(SID || Peer-ID)
> 
>        
> 
>       And we could fix kdf and hash for all EAP methods, 
> e.g., take hash to be the first 96 bits of SHA-256, and kdf 
> as TLS-PRF. The Bound-AAA-Key id would then be NAS-ID || 
> Peer-Session-ID. We don't, of course, have to use the EMSK 
> for this function, but I have used it for concreteness.
> 

[Joe] I had a proposal for a KDF for EAP EMSK derivation that was merged
into the EAP keying framework and then removed.  I expect we could issue
a new companion draft (EAP-keying extensions) soon if that would help
add clarity to this issue.  I think the the peer-session-ID is an
application specific thing (802.11).  
         
> 
>       This mechanism requires that a NAS find some way to 
> advertise its NAS-ID to EAP peers, and it requires a few new 
> attributes exchanged between the NAS and EAP Server. It 
> leaves the existing key hierarchies intact, but provides a 
> bound key for new applications that desire a bound key. It 
> seems to put to rest the security issues with the existing 
> key hierarchy, by giving the EAP Server some way to attest to 
> the EAP Peer the NAS which should possess the key.
>        
> 
>       What do people thing? Would this be a productive 
> addition to the EAP keying draft?
> 
[Joe] I expect that some of this would go into the EAP-Keying extensions
draft. 

>        
> 
>       -- Jesse
> 
>