Subject: [eap] Issue 158: Miscellaneous Nits

From: [email-masked] (Bernard Aboba)
Date: Mon, 7 Jul 2003 20:42:58 -0700 (PDT)

Issue 158: Miscellaneous Nits
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: July 6, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-July/001430.html
Document: EAP-04
Comment type: E
Priority: S
Section: 3.1, 5, 7.2, 7.3, 7.5, A.1
Rationale/Explanation of issue:

In Section 3.1, move the following text to section 3.4:

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

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g., wired PPP
or IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided.

Where keying material for the lower layer ciphersuite is itself
provided by EAP, ciphersuite negotiation and key activation is
controlled by the lower layer. In PPP, ciphersuites are
negotiated within ECP so that it is not possible to use keys
derived from EAP authentication until the completion of ECP.
Therefore an initial EAP exchange cannot protected by a PPP
ciphersuite, although EAP re-authentication can be protected.

In IEEE 802 media, key activation also typically occurs after
completion of EAP authentication. Therefore an initial EAP
exchange typically cannot be protected by lower layer
ciphersuite, although an EAP re-authentication or
pre-authentication exchange can be protected."

In Section 3.1, indent the following paragraph:

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

In Section 5, change "MITM resistance:" to "Crypt. binding:" (Since we no
longer have a definition of Man-in-the-Middle resistance)

In Section 7.2, change "man-in-the-middle resistance" to "cryptographic
binding"

In Section 7.3, Change "Identity-Response" to "EAP-Response/Identity" (two
times)

Delete Section A.1, and change Section 7.5 to the following:

"7.5 Packet modification attacks

While EAP methods may support per-packet data origin authentication,
integrity and replay protection, support is not provided within the
EAP layer.

Since the Identifier is only a single octet, it is easy to guess,
allowing an attacker to successfully inject or replay EAP packets. An
attacker may also modify EAP headers (Code, Identifier, Length, Type)
within EAP packets where the header is unprotected. This could cause
packets to be inappropriately discarded or misinterpreted.

In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used.

Method-specific MICs may be used to provide protection.
If a per-packet MIC is employed within an EAP method, then peers,
authentication servers, and authenticators not operating in
pass-through mode MUST validate the MIC. MIC validation failures
SHOULD be logged. Whether a MIC validation failure is considered a
fatal error or not is determined by the EAP method specification.

Since EAP messages of Types Identity, Notification, and
Nak do not include their own MIC, it may be desirable for the EAP
method MIC to cover information contained within these messages, as
well as the header of each EAP message. For details, see Appendix A.

To provide protection, EAP also may be encapsulated within a
protected channel created by protocols such as ISAKMP [RFC2408] as is
done in [IKEv2] or within TLS [RFC2246]. However, as noted in Section
7.4, EAP tunneling may result in a man-in-the-middle vulnerability.

Existing EAP methods define message integrity checks (MICs)
that cover more than one EAP packet. For example, EAP-TLS [RFC2716]
defines a MIC over a TLS record that could be split into multiple
fragments; within the FINISHED message, the MIC is computed over
previous messages. Where the MIC covers more than one EAP packet, a
MIC validation failure is typically considered a fatal error.

Within EAP-TLS [RFC2716] a MIC validation failure is treated as a
fatal error, since that is what is specified in TLS [RFC2246].
However, it is also possible to develop EAP methods that support
per-packet MICs, and respond to verification failures by silently
discarding the offending packet.

In this document, descriptions of EAP message handling assume that
per-packet MIC validation, where it occurs, is effectively performed
as though it occurs before sending any responses or changing the
state of the host which received the packet."