eap Mailing List: Issue: Downgrading attacks on lower-layer ciphersuite negotiation

[DE BOURSETTY Benoît FTRD/DTL/ISS (benoit.deboursetty]

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ît de Boursetty
France Telecom R&D
benoit.deboursetty [at] francetelecom.com / +33-1-4529-5926



Downgrading attacks on lower-layer ciphersuite negotiation

Submitter name: Benoit de Boursetty
Submitter email address: benoit.deboursetty [at] francetelecom.com
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: 

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