Subject: [eap] Issue 165: Applicability statement

From: [email-masked] (Bernard Aboba)
Date: Sat, 2 Aug 2003 20:08:58 -0700 (PDT)

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.

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.

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

---

From: [email-masked] (Jari Arkko)
Date: Sun, 03 Aug 2003 11:08:27 +0300

> appropriate and inappropriate to use it.

Right. Thanks for the text!

> EAP methods may provide this support.

Looks good.

> than the EAP MTU will need to be modified in order to provide

Yes.

> [RFC2743] running over transports such as UDP, TCP or SCTP.

Hmm... I generally agree with the direction of this, but I do
have problems with some of the details. In particular:

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

   Question: how widely is SASL supported? Is it reasonable to
   recommend it as an alternative?

- How would the suggested applicability statement relate
   to PANA and IKEv2 use of EAP? For PANA, one could argue
   that there's no IP access in any real sense before you
   authenticate. But for IKEv2, we most certainly do have
   IP access.

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

- I suspect there might be other reasons beyond fragmentation
   that relate to the applicability of EAP. For instance, while
   the use of different credentials for network access
   is widespread, I sense that there is some level of desire
   in the IETF to control the true application layer authentication
   mechanisms to a smaller set of techniques, such as certs
   and passwords.

   Again, I'm not sure how to formulate this in text ;-(

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 3 Aug 2003 09:41:22 -0700 (PDT)

>    TLS [ref] or IKE [ref] or an alternate authentication framework

Sounds good.

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

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

---

From: [email-masked] (Alper Yegin)
Date: Sun, 03 Aug 2003 15:54:16 -0700

> access authentication in situations where IP connectivity is unavailable.

I'm not sure if we can really come to this generalized conclusion. As I
understand, this is driven by the fragmentation issue. For PANA, (limited)
IP connectivity is available but that does not mean that fragmentation
results in additional round-trips. Peer and authenticator are on the same
IP-link, and the link MTU is known to both. IP can take care of
fragmentation and reassembly that is transparent to EAP. Hence, IP
connectivity does not mean additional round-trips.

> [RFC2743] running over transports such as UDP, TCP or SCTP.

Alper

---

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

Thanks for doing this - a few comments below -

> than the EAP MTU will need to be modified in order to provide
Excellent point.  This assumes there is no feedback to the method of the 
desired MTU. I think this might be a good idea.

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

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