Subject: [eap] Proposed Resolution of Issue 108: Downgrade attack

From: [email-masked] (Bernard Aboba)
Date: Tue, 29 Apr 2003 11:42:31 -0700 (PDT)

The text of Issue 108 is included below. I would like to propose that the
changes described in this issue be accepted. Any objections?

----------------------------------------------------------
Issue 108: Downgrade attacks on lower layer ciphersuite negotiation
Submitter name: Benoit de Boursetty
Submitter email address: [email-masked]
Date first submitted: April 25th, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-April/001045.html
Document: EAP-01
Comment type: T
Priority: 1
Section: 7.1 and 7.11
Rationale/Explanation of issue:

In section 3.1 on lower layer requirements, requirement 2 indicates a
need for physically insecure links to be used with per-packet integrity,
authentication and replay protection.

Although the problem of downgrading attack on EAP method negotiation is
identified in 7.8, I cannot find word about the issue of downgrading
attacks on ciphersuite negotiation for the lower layer ciphersuite.
However there is mention of weak lower-layer ciphersuites being a threat
to security, at least in section 7.1 #8 and in section 7.11.

I understand that in actual cases deployed now, there is no or little
lower layer ciphersuite negotiation. But to take an example,
self-admittedly PPP's MPPE is currently vulnerable to downgrading
attacks (cf. par. 2, section 9 of RFC 3078) and there is no proposed
workaround (apart from explicit client configuration).

Another way to function is that parts of the keying material resulting
from EAP can be used by the link layer to authenticate a negotiation
handshake afterwards (I would have thought Auth-RECV-Key and
Auth-SEND-Key, but according to the new Keying Framework draft I'm not
so sure).

In the short term, I suggest mentioning the issue in the Security
Considerations section, as well as the workaround of using EAP-provided
keying material to enable negotiation integrity protection ex-post.

In the longer term, it could be desirable that the lower-layer
handshakes be integrity-verified during EAP authentication, as a
"handshake integrity checking service" offered by some EAP methods --
just as they can provide now mutual authentication, keying material
generation etc. This is left to the consideration of the EAP charter.

In the meantime:

Suggested changes:

Section 7.1: adding point 9 following point 8:
"[9]. An attacker may attempt to perform downgrading attacks on
link-level ciphersuite negotiation in order to ensure that a weaker
ciphersuite is used subsequently to EAP authentication."

Section 7.11: adding following paragraph at the end of the section:
"Additionally, if the lower layer performs ciphersuite negotiation, it
should be understood that EAP does not provide by itself integrity
protection of that negotiation. Therefore, in order to avoid downgrading
attacks which would lead to weaker ciphersuites being used, clients
implementing lower layer ciphersuite negotiation SHOULD protect against
negotiation downgrading.

This can be done by enabling users to configure which are the acceptable
ciphersuites as a matter of security policy; or, the ciphersuite
negotiation MAY be authenticated using keying material derived from the
EAP authentication and a MAC algorithm agreed upon in advance by
lower-layer peers."