Subject: RE: [eap] Proposed Resolution to Issue 209: Applicability statement

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Jan 2004 11:59:50 -0800 (PST)

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

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

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

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

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

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 7 Jan 2004 12:04:09 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, January 07, 2004 12:00 PM
> To: Joseph Salowey
> Cc: [email-masked]; [email-masked]
> 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.
> > >
> > 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.  

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

> 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.
> 
[Joe] No, but it should be used with a security layer. Perhaps that is a
layer of physical security.

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 8 Jan 2004 14:43:33 -0800

How about:

"EAP was designed for the use in network access authentication, where IP
layer connectivity may not be available.  EAP does not provide a means
for protecting bulk data transfer and must be used in conjunction with a
bulk data protection mechanism, such as layer 2 encryption, if such a
facility is required.  It is NOT RECOMMENDED that EAP be used in
scenarios where bulk data protection is required and not provided
through some mechanism. EAP may provide keying material for the bulk
data protection mechanism. Since not all EAP mechanism provide a channel
binding facility it is NOT RECOMMENDED that EAP be used with bulk data
protection that does not use keying material from EAP unless the
resulting man-in-the-middle threats can be mitigated.  The use of EAP
itself for bulk data transport is NOT RECOMMENDED."    

[email-masked] wrote:
>> Subject: RE: [eap] Proposed Resolution to Issue 209: Applicability
>> statement 
>> 
>> 
>>>> EAP was designed for use in network access authentication, where IP
>>> 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. 
>> 
> [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.
> 
> 
> [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.
> 
> 
> 
>>> "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.
>> 
> [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
>>> EAP may provide keying material for this external security layer. It
> [Joe] No, but it should be used with a security layer.
> Perhaps that is a layer of physical security.
>

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 7 Jan 2004 11:16:10 -0800

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, December 23, 2003 5:03 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [eap] Proposed Resolution to Issue 209: 
> Applicability statement
> 
> 
> The text of Issue 209 is enclosed below.  The proposed 
> resolution is as
> follows:
> 
> "1.3 Applicability
> 

"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.  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.  The use of EAP for bulk data transport is also NOT
RECOMMENDED."  

> Since EAP does not require IP connectivity, it provides just 
> enough support for the reliable transport of authentication 
> protocols, and no more.
> 
> EAP is a lock-step protocol which only supports a single 
> packet in flight. As a result EAP cannot efficiently 
> transport large quantities of data, unlike transport 
> protocols such as TCP [RFC793] or SCTP [RFC2960].
> 
> While EAP provides support for retransmission, it assumes 
> ordering guarantees provided by the lower layer, so that out 
> of order reception is not supported.
> 
> Since EAP does not support fragmentation and reassembly,
> EAP authentication methods generating payloads larger than
> the minimum EAP MTU need to provide fragmentation support.
> 
> While authentication methods such as EAP-TLS [RFC2716]
> provide support for fragmentation and reassembly, the EAP 
> methods defined in this document do not. As a result, if the 
> EAP packet size exceeds the EAP MTU of the link, these 
> methods will encounter difficulties.
> 
> EAP authentication is initiated by the server 
> (authenticator), whereas many authentication protocols are 
> initiated by the client (peer). As a result, it may be 
> necessary for an authentication algorithm to add one or two 
> additional messages (at most one roundtrip) in order to run over EAP.
> 
> Where certificate-based authentication is supported, the 
> number of additional roundtrips may be much larger due to 
> fragmentation of certificate chains. In general, a fragmented 
> EAP packet will require as many round-trips to send as there 
> are fragments. For example, a certificate chain 14960 octets 
> in size would require ten round-trips to send with a 1496 
> octet EAP MTU.
> 
> Where EAP runs over a lower layer in which significant packet 
> loss is experienced, or where the connection between the 
> authenticator and authentication server experiences 
> significant packet loss, EAP methods requiring many 
> round-trips can experience difficulties. In these situations, 
> use of EAP methods with fewer roundtrips is advisable."
> 
> --------------------------------------------------------------
> ---------
> Issue 209: Applicability statement
> Submitter name: Allison Mankin
> Submitter email address: [email-masked]
> Date first submitted: 12/17/2003
> Reference:
> Document:  RFC 2284bis-07
> Comment type: E
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> 
> I think there are many virtues to this spec, but it needs 
> more attention to the applicability description. The problem 
> is epitomized by comments such
> as:
> 
>    Where transport efficiency is a consideration, and IP transport is
>    available, it may be preferable to expose an artificially high EAP
>    MTU to EAP and allow fragmentation to take place in IP.
>    Alternatively, it is possible to choose other security mechanisms
>    such as TLS [RFC2246] or IKE [RFC2409] or an alternative
>    authentication framework such as SASL [RFC2222] or GSS-API 
> [RFC2743].
> 
> How could the same application use GSS-API or SASL if it 
> intended to use EAP
> 
> They seem to have very different domains of applicability.  
> It would be good to discuss the ways that EAP is very 
> applicable and ways in which it can be kind of wedged into 
> use, with results that may be only just satisfactory.
>