Subject: [eap] Proposed strawman Section 3: Link Layer behavior

From: [email-masked] (Bernard Aboba)
Date: Fri, 3 Jan 2003 10:53:27 -0800 (PST)

I'd like to propose the following revision of Section 3 on Link Layer
behavior. Comments welcome (please indicate substitute text if something
is unsatisfactory).

3.  Lower layer behavior

3.1.  Lower layer requirements

EAP makes the following assumptions about lower layers:

[1]  Link layer CRC or checksum. 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 its 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.

     If lower layers exhibit a high loss rate, then retransmissions are
     likely, and since EAP Success and Failure are not retransmitted,
     timeouts are also likely to result.  EAP methods such as EAP TLS
     [RFC2716] include a message integrity check (MIC) and regard MIC
     errors as fatal. Therefore if a checksum or CRC is not provided by
     the link layer, then some methods may not behave well.

[2]  Known MTU. The EAP layer does not support fragmentation and
     reassembly. However, individual EAP methods SHOULD NOT make
     assumptions about the minimum MTU size and 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.

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

[4]  Possible reordering. EAP provides its own mechanisms to detect
     reordering and so does not assume that the lower layer provides
     ordering guarantees.

3.2.  EAP usage within PPP

In order to establish communications over a point-to-point link, each
end of the PPP link must first send LCP packets to configure the data
link during Link Establishment phase.  After the link has been
established, PPP provides for an optional Authentication phase before
proceeding to the Network-Layer Protocol phase.

By default, authentication is not mandatory. If authentication of the
link is desired, an implementation MUST specify the Authentication-
Protocol Configuration Option during Link Establishment phase.

The server can use the identification of the connecting host or router
in the selection of options for network layer negotiations.

When implemented within PPP, EAP does not select a specific
authentication mechanism at PPP Link Control Phase, but rather postpones
this until the Authentication Phase.  This allows the authenticator to
request more information before determining the specific authentication
mechanism.  This also permits the use of a "back-end" server which
actually implements the various mechanisms while the PPP authenticator
merely passes through the authentication exchange.  The PPP Link
Establishment and Authentication phases, and the Authentication-Protocol
Configuration Option, are defined in The Point-to-Point Protocol (PPP)
[RFC1661].

3.2.1.  PPP Configuration Option Format

A summary of the PPP Authentication-Protocol Configuration Option format
to negotiate the EAP Authentication Protocol is shown below.  The fields
are transmitted from left to right.

Exactly one EAP packet is encapsulated in the Information field of a PPP
Data Link Layer frame where the protocol field indicates type hex C227
(PPP EAP).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Authentication-Protocol   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

   3

Length

   4

Authentication-Protocol

   C227 (Hex) for PPP Extensible Authentication Protocol (EAP)

3.3.  EAP usage within IEEE 802

The encapsulation of EAP over IEEE 802 link layers is defined in
[IEEE8021X].  The IEEE 802 encapsulation of EAP does not involve PPP,
and IEEE 802.1X does not include support for link or network layer
negotiations. As a result, within IEEE 802.1X it is not possible to
negotiate non-EAP authentication mechanisms, such as PAP or CHAP
[RFC1994].

3.4.  Link layer indications

The reliability and security of link layer indications is dependent on
the medium. Link layer failure indications accepted by the link layer
and provided to EAP MUST be processed. However, link layer success
indications MUST NOT result in an EAP implementation concluding that
authentication has succeeded, since these indications are typically
unauthenticated.

In PPP, link layer indications are not authenticated and are therefore
subject to spoofing, provided that the attacker can gain access to the
physical medium.  This includes LCP-Terminate (a link failure
indication), NCP (a link success indication), and "link down" (a link
failure indication).

In 802.11, control and management frames are not authenticated and an
attacker within range can gain access to the physical medium. Link layer
indications include Disassociate and Deauthenticate frames (link failure
indications), and Association and Reassociation Response frames (link
success indications).

In IEEE 802 wired networks, the IEEE 802.1X EAPOL-Start and EAPOL-Logoff
frames are not authenticated or integrity protected, whereas within
802.11, authentication and integrity protection is possible depending on
when they are sent and the ciphersuite that has been negotiated.

Therefore, depending on the circumstances, EAPOL-Start and EAPOL-Logoff
frames may or may not be subject to authenticated and integrity
protected.  In 802.11 a "link down" indication is an unreliable
indication of link failure, since wireless signal strength can come and
go and may be influenced by radio frequency interference generated by an
attacker.