Subject: [eap] Issue 67: Lower layer security requirement?

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 09:41:34 -0800 (PST)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 11, 2003
Document: RFC 2284bis-08
Comment type: T
Priority: S
Section: 3.1
Rationale/Explanation of issue:

Does EAP also require security from the lower layer in some form, such as
physical security, or a lower layer ciphersuite? Given that the Nak,
Identity, Notification, EAP Success and Failure packets are not
protected, this seems reasonable.

Add the following to the lower layer requirements:

"[2] Lower layer security. Although EAP methods may support
method-specific message integrity checks (MICs), these MICs typically only
cover the Type-Data field within EAP Request and Response messages of a
single Type, such as in [RFC2716]. While it is possible for a
method-specific MIC to be calculated over the EAP header, as well as
previous EAP messages of Types Identity, Nak, and Notification, existing
methods do not support this. While Success and Failure messages also do
not include a MIC, it is possible for EAP methods to support
method-specific acknowledged and protected success and failure indications.
However, as discussed in Section 4.2.1, this cannot
provide complete protection against denial of service attacks.

In order to compensate for these weaknesses, EAP SHOULD be used only with
lower layers that are either physically secure (e.g. wired PPP or IEEE 802
links), or provide per-packet authentication and integrity protection via a lower
layer ciphersuite. Note that where keying material for the lower layer
ciphersuite is itself provided by EAP, the ciphersuite cannot be enabled until late in
the EAP conversation, after key derivation has completed. Thus, it may
only be possible to protect a portion of the EAP conversation, such as the
EAP Success or Failure packet."

---

From: [email-masked] (Jari Arkko)
Date: Sun, 12 Jan 2003 12:12:47 +0200

> provide complete protection against denial of service attacks.

Moreover, authentication is pretty useless without any sort of guarantee
that the subsequent payload come from the same source.

> EAP Success or Failure packet."

Ok.

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 12 Jan 2003 07:08:51 -0800 (PST)

> that the subsequent payload come from the same source.

Do you have some text to suggest?

---

From: [email-masked] (Jari Arkko)
Date: Sun, 12 Jan 2003 22:49:29 +0200

> Do you have some text to suggest?

Here's some:

   "[2] Lower layer security. Typically, the purpose of EAP
    authentication is to open a channel for the peer's traffic.
    In many cases, usage-based accounting is applied for the
    traffic passing through this channel. In order for the EAP
    authentication to be useful in allowing the service only
    to the right peers, there has to be some assurance that
    the authentication and the traffic comes from the same
    source. When EAP is used over links that are physically
    insecure and the link carrying the traffic is not
    cryptographically protected, it becomes possible for
    other parties to inject messages to the channel. The
    authentication run of a real user may also be diverted by
    a man-in-the-middle to another link, where some service
    may be acquired with it.

    Additionally, although EAP methods..."

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 13 Jan 2003 21:59:37 -0800 (PST)

OK. How about this?

[2] Lower layer security. After EAP authentication is
complete, the peer will typically wish to transmit data
to the network, through the authenticator.
In order to provide assurance that the peer transmitting
data is the one that successfully completed EAP
authentication, it is necessary for the lower
layer to either provide per-packet integrity and
authentication (using keys derived as a result of
EAP authentication) or for the lower layer to be
physically secure. Otherwise it is possible for
subsequent data traffic to be hijacked.

These requirements also serve to allow for the
protection of EAP traffic itself.
EAP methods may support
per-packet message integrity checks (MICs).
In existing methods such as EAP-TLS [RFC2716],
the MIC covers the Type-Data field
within EAP Request and Response messages of a
single Type. However, it is also possible for
a MIC defined within an EAP method
to include coverage of the EAP header
or even previous EAP messages, although
some EAP implementations may not support this.
Where the MIC defined within the EAP method
does not cover the EAP header and all messages
within the EAP conversation, tampering is possible.

While EAP Success and Failure messages do
not include a MIC, it is possible for EAP methods
to support their own acknowledged and protected
success and failure indications. However, as discussed
in Section 4.2.1, this cannot provide complete protection
against denial of service attacks.

As a result of these considerations,
EAP SHOULD be used only with lower layers that are either
physically secure (e.g. wired PPP or IEEE 802 links), or
provide per-packet authentication and integrity protection via a lower
layer ciphersuite. Note that where keying material for the lower layer
ciphersuite is itself provided by EAP, the ciphersuite cannot be enabled
until late in
the EAP conversation, after key derivation has completed. Thus, it may
only be possible to protect a portion of the EAP conversation, such as the
EAP Success or Failure packet.

---

From: [email-masked] (Jari Arkko)
Date: Tue, 14 Jan 2003 09:16:10 +0200

Looks good. Thanks.