eap Mailing List: Re: EAP Key Binding

[Bernard Aboba (aboba]

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

Presumably, the verification would include the entire key context, which
would include key-lifetime, Peer-ID, NAS-ID and restrictions on key usage:

NAS --> EAP Peer:  Challenge, NAS-Id, Peer-ID, Lifetime, Authorizations
EAP Peer --> NAS:  f(AAA-Key, Challenge || Peer-ID || NAS-ID,
                   Lifetime, Authorizations)

If restrictions are placed on the use of the key (e.g. key lifetime,
Called-Station-Id/Calling-Station-Id restrictions, etc.) then all parties
need to be aware of the restrictions or the key has not been properly
bound to its context.

Note that in the above, the Peer-ID may not necessarily be the same as
what was provided by the EAP peer in the EAP-Response/Identity (e.g. in
the case where privacy is supported), or even the peer-ID used within the
EAP method (in the case where privacy is asserted and the AAA server does
not provide a User-Name attribute within the Access-Accept).

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

The issue is one of synchronizing the key context between the
parties.  Where the EAP peer supports privacy (e.g. it does not place its
userid within the NAI), then the peer-ID is provided to the NAS
in the Access-Accept, either via the User-Name or CUI attribute.  However,
the CUI is typically not provided to the peer so that in this case the
peer-ID may not be synchronized between the parties unless the Secure
Association Protocol handles this.

> 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 document does specify the peer/server-IDs to be passed up by methods,
but as noted above, this is not sufficient where privacy is supported.
My suggestion is that the Secure Association Protocol be modified to pass
the peer-ID to the peer, and verify it.

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

While EAP itself cannot deliver this information, the AAA protocol and
Secure Association Protocol can together deliver it.  For example, in
addition to the authorizations and AAA-Key the AAA server can provide one
or more Peer-tokens to the NAS.  This token could be transmitted to the
peer via the Secure Association Protocol, and could be encrypted and
authenticated using keys known only to the EAP server and peer, so that
it cannot be decrypted by the NAS or proxies.

This could provide an additional vehicle for synchronization of key state
and/or verification of channel bindings without requiring changes to EAP
methods.

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

Which "equipment" are you talking about?  Presumably the NAS and peer need
to change in order to support 802.11r anyway.  So presumably we are
talking about changes to the AAA-Server, correct?  Since this is
a new application, there is no backward compatibility issue - have the NAS
send an attribute requesting a different AAA-Key derivation, and if the
AAA-Server supports it, it will respond with the attribute in an
Access-Challenge, otherwise not.  You can therefore know before starting
the handshake whether the new scheme is supported by the AAA server.  If
not, you can use a backward compatible handshake instead (e.g. WPA2).

> 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.
>
> =20
>
> 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?

The original keying draft has now been split into two parts.  The first
part (the EAP Key Management Framework) is now only focussed on
documenting and analyzing existing uses (e.g. IEEE 802.11i).  The second
part (EAP Key Management extensions) will document additional uses.

While solutions to the key binding problem are appropriate for inclusion
in the extensions document, the goal there is to describe and analyze
complete proposals, including the EAP Key management and AAA extensions
that are required.

A key step toward that goal is for groups such as 802.11r to provide a set
of requirements.  Key binding seems like one of those requirements, but
there are presumably others, such as extensions to provide faster handoff.