eap Mailing List: Re: Basic facts about EAP

[Nicolas Williams (Nicolas.Williams]

On Mon, May 02, 2005 at 09:23:33PM -0700, Salowey, Joe wrote:
> > Some EAP methods may require a third party, and sometimes 
> > that third party may be "collocated" with one of the EAP 
> > parties.  But that would be a feature of the method, not of 
> > the framework (even if all EAP methods work that way in practice).
> >
> 
> [Joe] With standard EAP this is true.  When the discussion shifts to EAP
> channel bindings, AAA servers as trusted third parties, etc. the
> discussion is a bit muddled since these schemes expect the EAP-Peer to
> have knowledge of both the EAP-Authenticator and EAP-Server.  This is a
> feature of the method since not all EAP methods would support this
> (requires authentication of the EAP-Server and some sort of channel
> binding), but it seems it involves entities in the EAP-Framework.  

Your description of EAP channel bindings, to me, goes hand in hand with
thinking of the EAP authenticator in passthrough methods as part of the
network infrastructure.

> > Much like the Kerberos V GSS-API mechanism is a three-party 
> > mechanism that fits in a two-party framework (the GSS-API).  
> > A variant which allowed for proxying of AS and TGS exchanges 
> > by a GSS acceptor would be very similar to the world of EAP.
> > 
> 
> [Joe] This variant would work well in the standard EAP world.  Note
> though that things may not be implemented quite that simply. For example
> one might expect EAP-TLS to be implemented with the EAP-Authenticator
> and EAP-Server as one logical and physical unit.  This is often not the
> case and the EAP-Server is located away from the authenticator on a AAA
> server.  This is like having the GSS-API tokens that encapsulate the
> KRB-AP message exchange between the client and the AAA server.  In all
> cases the basic exchange is still a two party exchange.  

Yeah, I see that.  Thanks.

> > I find it very useful to think of EAP this way as it allows 
> > me to impose, in my mind, a GSS-like abstract API on EAP methods.
> > 
> > Please correct me if this is wrong.
> > 
> 
> [Joe] I think this is a useful way to think of things.  There is
> additional complexity when the EAP-Peer is expected to have knowledge of
> the EAP-Authenticator and EAP-Server, however I don't think there is
> agreement in the working group on how (or if) this is supported.  

I don't see why it shouldn't be supported.  It just has to be properly
abstracted (and the methods properly built).  Thanks.