eap Mailing List: RE: Basic facts about EAP

[Salowey, Joe (jsalowey]

<snip>

> > I'm not sure how that is material: EAP is (or should be, IMHO) as 
> > aware of things like RADIUS proxies or Diameter agents as 
> HTTP is of 
> > IP routers.
> 
> Right.  Let's not confuse EAP with EAP methods.
> 
> EAP is a two-party framework into which EAP methods fit.
>

[Joe] Yes.
 
> 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.  
 
> 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.  
  
> 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.  

> Cheers,
> 
> Nico
> --
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>