Subject: Re: [eap] Issue 165: Applicability statement

From: John Vollbrecht <[email-masked]>
Date: Mon, 04 Aug 2003 15:33:55 -0400

Thanks for doing this - a few comments below -

--On Saturday, August 2, 2003 8:08 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> Issue 165: Applicability Statement
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: 8/2/2003
> Reference:
> Document: RFC2284bis
> Comment type: T
> Priority: S
> Section: 1.4
> Rationale/Explanation of issue:
>
> EAP needs an applicability statement so that it is clear when it is
> appropriate and inappropriate to use it.
>
> Insert the following section:
>
> 1.4 Applicability
>
> EAP is an authentication framework for use in situations, such as network
> access, in which the IP layer connectivity may not be available.
> Since the goal of EAP is to support authentication without requiring
> IP connectivity, it provides just enough support for the
> reliable transport of authentication protocols, and no more. While EAP
> provides support for retransmission, it assumes ordering guarantees
> provided by the lower layer, so that out of order reception is not
> supported. EAP itself does not support fragmentation; however,
> EAP methods may provide this support.
>
> Since EAP does not support fragmentation as in IP, or an efficient
> reliable transport service as in TCP [RFC793] or SCTP [RFC2960],
> an authentication protocol will typically require more round-trips
> when run over EAP than when run over IP. Since EAP does not
> support fragmentation, authentication protocols generating payloads larger
> than the EAP MTU will need to be modified in order to provide
> fragmentation support.
>
Excellent point.  This assumes there is no feedback to the method of the 
desired MTU. I think this might be a good idea.

> As a result of these limitations, EAP is primarily applicable to network
> access authentication in situations where IP connectivity is unavailable.
> Where IP connectivity is available, it is advisable to choose an
> alternate authentication framework such as SASL [RFC2222] or GSS-API
> [RFC2743] running over transports such as UDP, TCP or SCTP.
>
The concept of no IP seems problematic.  PANA uses IP, IPSECv2 (over IP) 
uses EAP.  I think much of what is said is correct, but I am not sure how 
the above cases fit.  Seems that EAP is used also to provided a "generic" 
authentication method where other methods could be used but don't fit the 
existing infrastructure.  I am not sure this is correct - are there other 
thoughts?

> [RFC2743]
> Linn, J., "Generic Security Service Application Program Interface, Version
> 2", RFC 2743, January 2000.
>
> [RFC2222]
> Myers, J., "Simple Authentication and Security Layer (SASL)",
> RFC 2222, October 1997.
> _______________________________________________
> 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: "Joseph Salowey" <[email-masked]>
Date: Tue, 12 Aug 2003 16:03:13 -0700

<Snip>
> > - If you need authentication, you might not always need an
> >    authentication framework. For instance, if you need 
> authentication
> >    for application X, you might do well with TLS, even we wouldn't
> >    normally call TLS an authentication framework.
> >
> >    Therefore, I would suggest the following text modification:
> >    "... advisable to choose other security mechanisms such as
> >    TLS [ref] or IKE [ref] or an alternate authentication framework
> >    such as SASL ..."
> 
> Sounds good.
> 
> >    Question: how widely is SASL supported? Is it reasonable to
> >    recommend it as an alternative?
> 
> SASL is pretty widely supported in directories and email 
> systems, at least.  GSS-API is reasonably widely supported as 
> well, though Kerberos is by far the most widely used 
> mechanism.  I think it's fair to say that neither is as 
> popular as EAP, though.
> 

[Joe] EAP provides you with several things that GSSAPI and SASL do not.
It provides a formal description of the operation of a passthrough
authenticator and it provides a means to access session keys.  One can
argue about whether these are a good idea or not, but it has proven
useful in present EAP applications.

> >    I'm not really sure how to fix this. Perhaps the applicability
> >    of EAP is related more to network access "application" rather
> >    than the availability of IP?
> 
> EAP is sometimes used over IP (such as in Ethernet or PPP 
> tunneling) in situations where a link layer is being 
> simulated over IP.  However, whenever EAP is run over IP 
> there can be a large perforance penalty when EAP 
> fragmentation occurs and there are lots of round trips.  For 
> example, in an EAP method with 20 round trips and a 100 ms 
> RTT, the result is a 2 second latency when the same protocol 
> run over TCP might require only 4 RTT or 400 ms.  To some 
> extent the problem can be avoided by presenting a large MTU 
> to EAP and doing fragmentation within IP rather than within EAP.
> 
> The other issue is EAP server-initiation, which can add a 
> round-trip in situations where client-initiation is more 
> appropriate.  Both GSS-API and SASL are client-initiated.
>