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

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, December 23, 2003 5:03 PM
> To: eap [at] frascone.com
> Cc: mankin [at] psg.com
> 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 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.  

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