Re: Basic facts about EAP
From: Yoshihiro Ohba (yohbatari.toshiba.com)
Date: Mon, 2 May 2005 16:45:54 -0400 (EDT)
On Mon, May 02, 2005 at 08:59:50PM +0300, Jari Arkko wrote:
> Yoshihiro Ohba wrote:
> 
> >Given that the channel binding parameters would have to be pretty well
> >specified between the EAP peer and authenticator, the authenticator
> >can send the opaque objects to the EAP server via a AAA protocol
> >(e.g., a channel-binding attribute/AVP).  The EAP server will be able
> >to calculate the AAA-Key without necessarily knowing the semantics of
> >the opaque objects.  What do you think?
> >  
> >
> Sure. In fact, we are mostly doing this already... almost all
> information that
> one can think of as being a channel property already has an associated
> AAA attribute.
> 
> But I was more worried about how the peer and the AAA server can be in
> sync about the parameters to be used. If they don't communicate over
> EAP, this leaves only full one-time specification as an option. If they
> communicate (as in various drafts that propose to do channel binding),
> then the set of parameters can evolve.

I don't really think that the peer and the AAA server need to be
syncronized about the exact parameters (that's why opaque blob can be
used for channel bindings), while I do think that the peer and the
authenticator (NAS) need to be synchronized about them.  

Also, I think that the peer and the authenticator need to be
synchronized about the parameters even in the case of stand-alone
authenticator (i.e., no AAA protocol) in order to avoid MiTM in
between.  In this case, the EAP lower-layer is surely able to bind the
AAA-Key to the parameters (binding based on using the parameters in
the key derivation algorithm) without carrying the parameters in the
EAP method.  I think we should use the same way of binding regardless
of whether there is a pass-through authenticator or not.  Otherwise,
if we use one channel binding method for the stand-alone authenticator
case and another channel binding method for the backend authenticator
case, it would not make the pass-through authenticator transparent to
the EAP peer.

Yoshihiro Ohba


> 
> --Jari
> 

Results generated by Tiger Technologies using MHonArc.