eap Mailing List: Re: Basic facts about EAP

[Nicolas Williams (Nicolas.Williams]

On Thu, Apr 28, 2005 at 11:21:25AM -0700, Glen Zorn (gwz) wrote:
> Pasi.Eronen [at] nokia.com <> supposedly scribbled:
> 
> > Bernard Aboba wrote:
> >> 
> >> I have received a request that the following basic facts about
> EAP be
> >> posted to the EAP WG mailing list.
> >> 
> >> a. EAP is a two party protocol, run between an EAP peer and
> server.
> >> Saying EAP is an N-party protocol is like saying that TCP is a
> >> N-party protocol because TCP packets pass through routers. 
> >> Forwarding an EAP packet without modification does not cause an
> >> entity to become a "participant" in an EAP conversation any more
> >> than forwarding an IP packet turns a router into a host.
> > 
> > I fully agree. EAP is a two-party protocol between two entities.
> > 
> > However, EAP is always used as a component or "sub-protocol" in a
> > system which includes several other (sub-)protocols and usually
> more
> > than two entities.  
> 
> 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.

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).

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.

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.

Cheers,

Nico
--