Subject: [eap] Proposed Resolution to Issue 165: Applicability Statement

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Aug 2003 10:57:03 -0700 (PDT)

In going over the comments on this issue, it looks like I left out an
issue or too.  Here is a revised proposed resolution:\

"1.4 Applicability

EAP is an authentication framework primarily for use in situations
such as network access, in which 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.
EAP is a lock-step protocol and does not support an efficient
reliable transport service as in 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.

As noted in Section 3.1, EAP does not support fragmentation
and reassembly as in IP, although EAP methods may provide support
for this.  As a result, authentication protocols generating payloads
larger than the EAP MTU will need to be modified in order to provide
fragmentation support.

EAP authentication is initiated by the EAP server, whereas
many authentication protocols are initiated by the client (peer).  As a
result, it may be necessary for an algorithm to add 0.5 - 1 additional
roundtrip to run over EAP.

As a result, an authentication algorithm will typically
require more round-trips when run over EAP than when run over IP.
In particular, certificate-based authentication
algorithms using long certificate chains can result in many
round-trips due to fragmentation.

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 may
experience difficulties. In these situations, use of EAP
methods with fewer round trips is advisable.

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 an
alternative authentication framework such as SASL [RFC2222] or
GSS-API [RFC2743].

References (Informative)

[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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 06 Aug 2003 12:23:23 -0700

> roundtrip to run over EAP.

When the identity request is sent from the authenticator, the additional
0.5 round-trip is not the one between peer-to-AS, but between
peer-to-authenticator, which is considerably less. If we are going to
highlight this latency as an issue, maybe we should capture this as well.

> round-trips due to fragmentation.

I think the first sentence is referring to aforementioned round-trip delay.
The latter is another source of latency which needs a clarification, imo.
So, I'd propose:

  As a result, an authentication algorithm will typically
  require more round-trips when run over EAP than when run over IP.
  Additionally, certificate-based authentication
  algorithms using long certificate chains can result in many
  round-trips when the fragmentation is handled by the EAP method.

Also, it is not very clear what "running auth algorithm over IP" means.
Maybe mentioning an example helps. This should not be mixed with running EAP
over IP.

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Aug 2003 12:01:26 -0700 (PDT)

> Maybe mentioning an example helps. This should not be mixed with running EAP

OK.  How about this?

1.4 Applicability

As noted in Section 3.1, EAP does not support fragmentation
and reassembly as in IP, although EAP methods may provide support
for this. As a result, authentication protocols generating payloads larger
than the EAP MTU will need to be modified in order to provide
fragmentation support.

EAP authentication is initiated by the authenticator, whereas
many authentication protocols are initiated by the client (peer). As a
result, it may be necessary for an algorithm to add 0.5 - 1 additional
roundtrips between the client and authenticator in order to run over EAP.

require more round-trips when run over EAP than when run directly over IP.

References (Informative)

[RFC2743]

[RFC2222]

---

From: Alper Yegin <[email-masked]>
Date: Wed, 06 Aug 2003 13:00:44 -0700

> roundtrips between the client and authenticator in order to run over EAP.

OK.
 
> round-trips due to fragmentation.

I still think we need to be more clear here (like in my suggested text). Are
you referring to the amplified effects of fragmentation when coupled with
the lock-step nature of EAP? That's the only case where we can talk about
many additional round-trips. If the fragmentation is done by the EAP lower
layer, then there is no additional round-trip issue (just additional
in-flight packet issue).

Alper

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 06 Aug 2003 15:48:15 -0400

Folks (Bernard especially),

What's the expected life-time for MSK in the EAP key hierarchy?
Is it supposed to be discarded immediately after TSK's have been
derived? Is it supposed to be kept for the length of the current
EAP session (if so - for what purpose? Rekeying on TSK level?)?

And is session rekeying going to be considered/discussed?

Thanks!

Regards,
Uri.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Aug 2003 13:14:00 +0300

Bernard Aboba wrote:
> issue or too. 

> alternative authentication framework such as SASL [RFC2222] or

    "... to choose other security mechanisms such as
    TLS [ref] or IKE [ref] or an alternate authentication framework
    such as SASL ..."

> GSS-API [RFC2743].

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Aug 2003 13:03:09 +0300

--Jari