eap Mailing List: EAP Key Binding Discussion

[Walker, Jesse (jesse.walker]

On Friday we had a conference call to discuss 802.11r keying that included Tony Braskich, Nancy Cam-Winget, Steve Emmeot, Paul Funk, Russ Housley, Henry Ptasinski, Kapil Sood, and myself. An issue came up on the call regarding the EAP keying draft which should be discussed here. I don't know if everyone from the 802.11r group is on the EAP mailing list, so please reply to all.

 

The core problem has been discussed many times before. Let us begin by setting the context. One of the goals of the EAP keying draft is to deliver a session key that an EAP Peer and a NAS can use to secure a session between them. The EAP keying draft defines a key hierarchy expressly for this purpose. The details of the hierarchy are method specific, but for EAP-TLS it appears thusly:

 

            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.

 

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

 

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 be

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

 

The issue we have never been able to resolve successfully has been how to provide the same attestation by the EAP Server of the correct NAS to the EAP Peer, i.e., how does the EAP Server assert to the EAP Peer the correct NAS to which the session key AAA-Key is bound? There is no obvious channel within EAP itself for delivering this assertion.

 

The question from our conference call is whether that the assertion could come from the key derivation. In 802.11r, for instance, we could require the NAS to advertise its NAS-ID to the EAP Peer as part of the 802.11 discovery protocol:

 

     NAS --> *:  NAS-ID

 

Then the EAP Peer would know the NAS-ID being asserted by the NAS. The EAP Server also knows the NAS-ID associated with an EAP transaction through the normal instantiations of the EAP transport between the NAS and the EAP Server. The EAP Server could then make the assertion of NAS identity through the AAA-Key derivation:

 

     AAA-Key := kdf(MSK, NAS-ID)

 

where kdf is a suitable key derivation function. The EAP Peer would perform the same key derivation. If the EAP Server delivered the AAA-Key to some other NAS other than the one that advertised NAS-ID, then the EAP Peer could detect this, because its session would fail, as the EAP Server would have used the identifier NAS-ID' for that NAS instead.

 

On first blush it appears that this kind of mechanism would finally close the binding issues with EAP keying.

 

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

 

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?

 

-- Jesse