On Mon, April 9, 2007 6:38 pm, hartmans-ietf(_at_)mit(_dot_)edu wrote:
"Charles" == Charles Clancy <clancy(_at_)cs(_dot_)umd(_dot_)edu> writes:
Charles> Sam Hartman wrote:
>>>>>>> "Charles" == Charles Clancy <clancy(_at_)cs(_dot_)umd(_dot_)edu>
writes:
>>
Charles> I don't think I'm convinced that EAP channel bindings are
Charles> doing this binding to the L2 channel. The identity used
Charles> in an EAP channel binding must be bound to the AAA
Charles> security association between the authenticator and the
Charles> peer in order for everything to work, so it would be more
>> I'm not sure I'd describe the association between the peer and
>> authenticator as an AAA association. I agree with the rest.
Charles> Ah, I mistyped. I meant AAA security association between
Charles> the authenticator and EAP server.
I'd define the EAP channel binding problem as follows. There are two
sets of identities that the peer and authenticator use: one at the EAP
layer and one at a lower layer. There is an additional identity that
the authenticator may use to authenticate to the AAA server. The
channel binding problem is to make sure that the EAP server authorizes
the authenticator's use of the lower layer identity to the peer and
the peer's use of a given lower layer identity.
In performing this authorization the EAP server must authorize that
the authenticator is actually allowed to claim the lower layer
identity it wants to claim.
I think this is implicit -- you gave the MSK to an authenticator,
therefore that authenticator's lower layer (regardless of its identity)
is authorized to use that key. Of course, this assumes an authenticator
has a single lower layers. I'm not sure the case of multiple lower
layers been addressed. EAP could simply forbid it (i.e. one lower layer
per authenticator), or say that giving a key to an authenticator
authorizes it for all lower layers.
> In doing that it will have to make an
authorization decision about whether the identity the authenticator
uses to authenticate to the AAA server is authorized to claim the
given lower layer identity.
Currently there's no AAA mechanism for an authenticator to "claim" a
lower-layer identity to an EAP server. Lower layer identities would
have to be statically provided to the EAP server if the EAP server is
going to use them for channel bindings.
However that identity--between the NAS
and the AAA server doesn't inherently appear anywhere else. It sounds
like 802.11R does plan to expose that identity, but that's a design
decision for that lower layer.
I guess the point of all my commentary is that the SAP needs to be
involved in your discussion of EAP channel bindings. Most
cryptographically binds an L2 identities to an EAP key, and some new
ones (11r) even bind AAA identities to an EAP key. If EAP channel
bindings could include AAA identities, then the peer would actually have
enough information to start doing identity comparisons and catch lying
NASes.
--
t. charles clancy, ph.d. <> tcc(_at_)umd(_dot_)edu <> www.cs.umd.edu/~clancy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf