Subject: [eap] Issue: Downgrading attacks on lower-layer ciphersuite negotiation

From: [email-masked] (DE BOURSETTY Benoît FTRD/DTL/ISS)
Date: Fri, 25 Apr 2003 14:51:21 +0200

Hi, I'm not sure this comment bears on the latest version of the draft. =
Apologies if this point has been raised already.

Best,

Beno=EEt de Boursetty
France Telecom R&D
[email-masked] / +33-1-4529-5926

Downgrading attacks on lower-layer ciphersuite negotiation

Submitter name: Benoit de Boursetty
Submitter email address: [email-masked]
Date first submitted: April 25, 2003
Document: draft-ietf-eap-rfc2284bis-01.txt
Comment type: T
Priority: 1
Section: 7.1 and 7.11
Rationale/Explanation of issue:=20

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.=20

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:=20
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."