| Re: Basic facts about EAP | <– Date –> <– Thread –> |
|
From: Yoshihiro Ohba (yohba |
|
| 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 >
- Re: Basic facts about EAP, (continued)
- Re: Basic facts about EAP Bernard Aboba, May 2 2005
- Re: Basic facts about EAP Yoshihiro Ohba, May 2 2005
- Re: Basic facts about EAP Yoshihiro Ohba, May 2 2005
- Re: Basic facts about EAP Jari Arkko, May 2 2005
- Re: Basic facts about EAP Yoshihiro Ohba, May 2 2005
- Approach to channel bindings (Was; Re: [eap] Basic facts about EAP) Jari Arkko, May 3 2005
- Re: Approach to channel bindings (Was; Re: [eap] Basic facts about EAP) Yoshihiro Ohba, May 3 2005
- RE: Basic facts about EAP Alper Yegin, May 2 2005
Results generated by Tiger Technologies using MHonArc.