Subject: [eap] Issue 111: Lower Layer Requirements

From: [email-masked] (Bernard Aboba)
Date: Sat, 26 Apr 2003 14:15:06 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 25th, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: 3.1
Rationale/Explanation of issue:

This section says that a a lower layer CRC or checksum is not necessary,
but if it is absent there will be problems. Rewrite the section to the
following:

"3.1 Lower layer requirements

EAP makes the following assumptions about lower layers:

[1] Unreliable transport. In EAP, the authenticator
retransmits Requests that have not yet received Responses, so
that EAP does not assume that lower layers are reliable. Since
EAP defines it own retransmission behavior, when run over a
reliable lower layer, it is possible (though undesirable) for
retransmission to occur both in the lower layer and the EAP
layer.

Note that EAP Success and Failure packets are not retransmitted.
Without a reliable lower layer, and a non-negligible
error rate, these packets can be lost, resulting in timeouts.
It is therefore desirable for implementations to improve
their resilience to loss of EAP Success or Failure packets,
as described in Section 4.2.

[2] Lower layer error detection. While EAP does not assume that the
lower layer is reliable, it does rely on lower layer
error detection. EAP methods may not include a MIC, or if they
do, it may not be run over all the fields in the EAP packet,
such as the Code, Identifier, Length or Type fields. As a result,
without lower layer error detection, undetected errors could
creep into the EAP layer header or EAP method header fields,
resulting in authentication failures.

For example, EAP TLS [RFC2716], which computes its MIC
only over the Type-Data field, regards MIC validation failures
as a fatal error. Without lower layer error detection, this
method and others like it will not perform reliably.

[3] Lower layer security. EAP assumes that lower layers either
provide physical security for data (e.g. wired PPP or IEEE
802 links) or support per-packet authentication, integrity
and replay protection. EAP SHOULD NOT be used on physically
insecure links (e.g. wireless) where per-packet authentication,
integrity and replay protection is unavailable.

After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order
to provide assurance that the peer transmitting data is the
same entity that successfully completed EAP
authentication, the lower layer needs to bind per-packet
integrity, authentication and replay protection to the
original EAP authentication, using keys derived during EAP
authentication. Alternatively, the lower layer needs to be
physically secure. Otherwise it is possible for
subsequent data traffic to be hijacked, or replayed.

Where keying material for the lower layer ciphersuite is itself
provided by EAP, typically the lower layer ciphersuite cannot be
enabled until late in the EAP conversation, after key derivation
has completed. Thus it may only be possible to use the lower
layer ciphersuite to protect a portion of the EAP conversation,
such as the EAP Success or Failure packet.

[4] MTU known a-priori. The EAP layer does not support fragmentation and
reassembly. However, EAP methods SHOULD be capable of handling
fragmentation and reassembly. As a result, EAP is capable of
functioning across a range of MTU sizes, as long as the MTU is
known a-priori. EAP does not support path MTU discovery.

[5] Possible duplication. Where the lower layer is reliable, it will
provide the EAP layer with a non-duplicated stream of packets.
However, while it is desirable that lower layers provide for
non-duplication, this is not a requirement. The Identifier field
provides both the peer and authenticator with the ability to
detect duplicates.

[6] Ordering guarantees. EAP does not require the Identifier to be
monotonically increasing, and so is reliant on lower layer
ordering guarantees for correct operation. EAP was
originally defined to run on PPP, and [RFC1661] Section 1 has an
ordering requirement:

"The Point-to-Point Protocol is designed for simple links which
transport packets between two peers. These links provide full-
duplex simultaneous bi-directional operation, and are assumed to
deliver packets in order."

Lower lower transports for EAP MUST preserve ordering between a
source and destination, at a given priority level (the
ordering guarantee provided by [IEEE.802.1990])."

---

From: [email-masked] (Jari Arkko)
Date: Sun, 27 Apr 2003 21:07:49 +0300

Ok. --Jari

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

---

From: [email-masked] (Henrik Levkowetz)
Date: Mon, 28 Apr 2003 15:23:17 +0200

On Sun, 27 Apr 2003 21:07:49 +0300
Jari Arkko <[email-masked]> wrote:

Yes, looks fine, except 1 possible query made separately.

	Henrik

> > ordering guarantee provided by [IEEE.802.1990])."

	Henrik

-- 
  Certainly the game is rigged. Don't let that stop you; if you don't
  bet, you can't win.