eap Mailing List: RE: Proposed Resolution to Issue 209: Applicability statement

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Wednesday, January 07, 2004 12:00 PM
> To: Joseph Salowey
> Cc: eap [at] frascone.com; mankin [at] psg.com
> Subject: RE: [eap] Proposed Resolution to Issue 209: 
> Applicability statement
> 
> 
> > > EAP was designed for use in network access 
> authentication, where IP 
> > > layer connectivity may not be available. Use of EAP for other 
> > > purposes, such as application layer authentication, or bulk data 
> > > transport, is NOT RECOMMENDED.
> > >
> > [Joe] So why is EAP not recommended for application layer 
> > authentication?  I think it would be useful to state more 
> clearly why 
> > since many of the requirements for authentication would be 
> the same. 
> > The main difference  between EAP and something like SASL, 
> GSSAPI and 
> > TLS is that EAP does not provide security services or a security 
> > layer, it just provides a key material for an existing 
> security layer.
> 
> A major difference between GSS-API and EAP is that GSS-API 
> (with the exception of IAKERB) assumes that an initial 
> authentication has already occurred.  GSS-API also provides a 
> complete suite of security services, as you say.
> 
[Joe] This depends on the authenticaiton mechanism, not on GSSAPI or
EAP.  What you say is true of kerberos and may not be true of other
GSSAPI mechanisms. 


> SASL does not provide such a complete suite, and does not 
> assume initial authentication, so it is more analagous to 
> EAP.  However, it runs over reliable transport so it is more 
> efficient than EAP.  It also typically assumes that it is 
> running over a lower security layer (e.g. TLS) but does not 
> provide keys for that layer or even supporting crypto-binding 
> to it (enabling man-in-the-middle attacks).
> 
[Joe] SASL using Kerberos GSSAPI (or a raw kerberos mechanism) does not
assume initial authentication.  SASL mechanisms can provide an
encryption and integrity protection layer themselves, but you are
correct in that this is currently independent of any TLS security
because SASL does not have channel bindings or crypto-binding.  



> > I suggest change the above to something like:
> >
> > "EAP was designed for the use in network access 
> authentication, where 
> > IP layer connectivity may not be available.  EAP also assumes the 
> > existence of a security layer to provide on going data 
> protection such 
> > as layer 2 encryption.
> 
> Hmm.  Section 3.1 states that EAP does *not* assume existence 
> of lower layer security services.
> 
[Joe] So lower layer security might not be the correct term for what I
am describing.  EAP by itself does not provide a full set of security
services it must be used in conjunction with some additional mechanism
in order to provide this.  If it is not used with an external mechanism
then you will have vulnerability to man in the middle attacks which
compromise the data completely. It is possible that the additional
mechanism/layer is physical security (there's that term again).  


> > EAP may provide keying material for this external security 
> layer. It 
> > is NOT RECOMMENDED that EAP be used in scenarios where an external 
> > security layer is not provided such as most application layer 
> > protocols.
> 
> I don't think we want to probibit use of EAP in wired networks, do we?
> 
[Joe] No, but it should be used with a security layer. Perhaps that is a
layer of physical security.