Subject: RE: [eap] Basic facts about EAP

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 2 May 2005 20:31:16 -0700

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Monday, May 02, 2005 2:11 PM
> To: Jari Arkko
> Cc: Zorn, Glen; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [eap] Basic facts about EAP
> 
> 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).
> 

[Joe] The EAP concept of Channel Bindings may be slightly different than
GSS-API.  In GSS-API I think of channel bindings as being processed by
the method; each side presents data to the method and the method checks
to see if the data is the same.  In EAP I think of channel bindings as
an output from the method to be verified by the caller; each side
presents data to the method and the method returns the other parties
data to the caller.  In this sense the usage of the term "channel
bindings" in EAP is probably inappropriate (may be my fault for
introducing it).  The reason why it is better for the for the caller to
evaluate is that the EAP channel binding is more akin to authorization
data that is somewhat application specific.  For example determining
which ports are authorized to which authenticator can require more
complexity than a simple binary comparison. 

Since it is realy just protected data being sent EAP channel bingings
could be implemented as GSS-API wrapped data.  In some of the current
threads dealing with "trusted third parties" it gets a bit more complex
since a disctinction is being made between the the EAP-authenticator and
the EAP-server and the EAP-Peer is expected to rely upon some entity
hosting the EAP-Server to provide some authorization of the
EAP-Authenticator.  In this usage it seems to be important that the data
is protected between the EAP-Peer and an entity that can act as a
"trusted third party."  This concept is not core to EAP itself since a
peer typically is not expected to differentiate between a case where the
EAP-Authenticator and EAP-Server are co-located or in different physical
processes and not all methods are required to support EAP channel
bindings.  There is a draft,
draft-arkko-eap-service-identity-auth-01.txt, that discusses one
particular usage for EAP channel bindings, other usages have been
discussed. 

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

[Joe] Yes I agree that it would be helpful.  

> 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: "Salowey, Joe" <[email-masked]>
Date: Tue, 10 May 2005 17:28:23 -0700

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, May 02, 2005 10:46 PM
> To: Nicolas Williams
> Cc: Salowey, Joe; Zorn, Glen; [email-masked]; [email-masked]
> > 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.

[Joe] True, my explanation was bad.  I was trying to say the Peer needs
to determine the identity it authenticated as the EAP-Server is
associated with an entity that is trusted to provide or validate that
opaque information, additional knowledge about the entity hosting the
EAP authenticator is required in EAP.     

> 
> > 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.
> 
> 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.
> 
> > A variant which allowed for proxying of AS and TGS 
> exchanges by a GSS 
> > acceptor would be very similar to the world of EAP.
> 
> Such a method was specified, but never implemented (EAP-GSS).
>