Subject: RE: [eap] Basic facts about EAP

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 2 May 2005 21:23:33 -0700

<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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 May 2005 23:46:25 -0500

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

> cases the basic exchange is still a two party exchange.  

Yeah, I see that.  Thanks.

> 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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 May 2005 22:46:03 -0700 (PDT)

> these schemes expect the EAP-Peer to have knowledge of both the
> EAP-Authenticator and EAP-Server.

I don't think this is necessarily true.  For example, if the sever lower
layer passes up opaque blobs to be transported via the method from the server to
the peer, and then pushed back down to the peer lower layer for
verification, then the method need have no knowledge of the media or of
the authenticator.

> thinking of the EAP authenticator in passthrough methods as part of the

In "pass-through" the EAP authenticator is no more a part of the EAP
conversation than a router is part of a TCP conversation between two
endpoints.

> by a GSS acceptor would be very similar to the world of EAP.

Such a method was specified, but never implemented (EAP-GSS).