eap Mailing List: RE: Re: EAP Key Binding

[Walker, Jesse (jesse.walker]

Hi Bernard,

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
> Behalf
Of
> Bernard Aboba
> Sent: Saturday, April 16, 2005 2:22 PM
> To: eap [at] frascone.com
> Subject: [eap] Re: EAP Key Binding
> 
> > 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.
[Walker, Jesse] Yes; of course. We must include all of the relevant
parameters.

That is not the point I am trying to make, however. The point I am
trying to make is we have a channel from the EAP Server to the NAS for
delivering whatever parameter we might need, and using it is merely
mechanical, it is merely a matter of communal will to insert whatever we
can all agree we need. The point is to focus on as aspect of the
algorithm that is important for key usage correctness.

>From a key usage correctness perspective, what the EAP Server must tell
(some function of) the authenticated identity of the EAP Peer. The EAP
Server must tell the NAS (some function of) the authenticated identity
of the EAP Peer, because that is what the EAP Server has verified during
authentication. It is the EAP Server that must make the assertion that
this identity goes with this key because (a) it is the entity that
performed the authentication and (b) it is the only entity involved in
the transaction that the NAS could trust to make such an assertion.

> 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).
[Walker, Jesse] The Peer-ID that the EAP Server delivers with the key to
the NAS has to be (some function of) the identity the EAP Server
authenticates, because that is the only identity the EAP Server has
validated.

The point of language like "some function of the authenticated identity"
is we may not want to report the authenticated identity directly in some
scenarios, such as when the EAP Peer is a subscriber of an organization
that controls the EAP Server and the NAS is controlled by a competitor
of the organization. Fine. To honor this requirement, the identity
delivered to the NAS is not necessarily the authenticated identity
directly, but rather a function of the authenticated identity, something
derived from the authenticated identity that can be made public without
violating the EAP Peer's privacy.

> 
> > 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.
[Walker, Jesse] Again, the requirement is the identifier of the peer
that is required for key usage correctness is (some function of) the
identity that the EAP Peer asserted when it authenticated, because this
is the only identity the EAP Server knows for the EAP Peer and is the
only one it has authenticated during this session.

You may respond that some sort of multi-factor authentication may be
used, and that several identities will be asserted during
authentication. Fine. Let's define some standard way to concatenate them
and compute a function of them. And that is the right thing to do, too,
because all of the identities collectively are what the Server verified
by EAP authentication.
 
A further requirement on what identifier gets returned to the NAS is it
must be something the EAP Peer can reassert to the NAS during any
subsequent handshakes that put the key in place. It is the job of things
like 802.11r to structure their protocols so that the Peer will reassert
its identity to the NAS, so the NAS knows the key is being used in the
context asserted to by the EAP Server.

-- snip --
> > 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.
[Walker, Jesse] The motivation for my original posting was the
realization that we do not need a single new protocol message between
the Peer and the Server to provide the Peer with the Server's assertion
of the proper NAS. We can obtain this assertion through the session key
construction. We can obtain the assertion by requiring the EAP Server to
derive the session key used from an identity the NAS will advertise to
the Peer. We might need new protocol messages for some other function,
but not for asserting the NAS identity to the Peer. This realization is
an important step forward in the conversation, and I don't remember it
being made before.

The identity of the NAS the Server (and the Peer) would be required to
use has to be the one the Server uses to name the NAS. This is the NAS
ID. This says that if 802.11r or some other link discipline wants its
key usage to be properly bound, it will have to arrange for its NASes to
advertise their NAS IDs to their EAP Peers, so that the Peers can verify
the Server's assertion of the NAS indirectly through key derivation.

-- 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.
> 
> 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).
[Walker, Jesse] We are already using keys constructed in a different way
in 802.11i, in L2TP tunnels, PPP, etc. The keys constructed for this
usage do not include the NAS ID in their derivation. We will always have
keys constructed in the old way, because old instantiations of old
protocols never go away in the real world.

> 
> > 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.
[Walker, Jesse] If you recall, I prepared a requirements document
11-04-1498 that we discussed at the November 2004 IEEE 802 meeting in
San Antonio. At the time you indicated you did not think it was
necessary for IEEE to forward such a document to IETF. For the record,
now are you asking 802.11 to update and adopt this or some similar
document as requirements and then forward the result to IETF?

-- Jesse