Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings

[Charles Clancy <clancy at cs.umd.edu>]

On Mon, April 9, 2007 6:38 pm, hartmans-ietf at mit.edu wrote:
> > > > > > "Charles" == Charles Clancy <clancy at cs.umd.edu> writes:
>
>     Charles> Sam Hartman wrote:
>     >>>>>>> "Charles" == Charles Clancy <clancy at cs.umd.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.edu  <>  www.cs.umd.edu/~clancy



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf