Subject: Re: [eap] Basic facts about EAP

From: Jari Arkko <[email-masked]>
Date: Mon, 02 May 2005 10:14:11 +0300

Artur Hecker wrote:

> Perhaps we could talk about a "service access control system" instead. 
> The service might be a network link with

This is a good name, and so is "user" and "service providing entity".

Note: right now EAP is used for network access, and even most
of the new applications of EAP can be thought of as network network
access or at least being network access related, such as IKEv2 VPNs,
mobility services, or DHCP. Some prior ideas for non-network access
related issues such as EAP in HTTP were abandoned. But we
also have some ongoing discussions to extend the use of EAP,
mainly in SNMP.

> Historically, AAA is just a convenient way to centralize the 
> administration of the dispersed NASes :-)

Yes.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 May 2005 16:01:19 -0500

On Thu, Apr 28, 2005 at 11:21:25AM -0700, Glen Zorn (gwz) wrote:
> [email-masked] <> 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
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 May 2005 16:11:21 -0500

On Fri, Apr 29, 2005 at 02:06:37PM +0300, Jari Arkko wrote:
> I tend to agree with Pasi here. Even if EAP is a two-party
> protocol, the complete system consisting of AAA and some
> features of EAP have more than two entities. For instance,
> EAP channel bindings specified in RFC 3748 help the system
> to protect against compromise of individual NASes through
> the system being aware of 3 entities, the information about
> the NAS being in part communicated over EAP.

But note that the GSS-API also has a similar (bear with me) concept of
channel bindings, yet the GSS-API itself is a two-party framework
(though its mechanisms are free to involve additional parties).

I think imposing some formal structure and abstraction on EAP would go a
long way to making these threads unnecessary :)

Nico