eap Mailing List: Issue 393: Downgrade Attacks

[Bernard Aboba (bernard_aboba]

Issue 393: Downgrade Attacks
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: February 3, 2007
Reference:
Document: KEYING-17
Comment type: Technical
Priority: S
Section: 5.3
Rationale/Explanation of issue:

Section 5.3 makes statements that are not quite accurate about
cryptographic negotiation in existing protocols.
It needs to distinguish between negotiation of ciphersuites for
protection of data, and negotiation of cryptographic algorithms within
the key management protocol itself (such as MICs and KDFs).

The proposed resolution is to change Section 5.3 to the following:

"5.3. Downgrade Attacks

The ability to negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular
cryptographic algorithm. This is usually accomplished by including
an algorithm identifier in the protocol, and by specifying the
algorithm requirements in the protocol specification. In order to
prevent downgrade attacks, secure confirmation of the "best"
cryptographic algorithm is required.

EAP methods satisfying [RFC4017] requirements and AAA protocols
utilizing transmission layer security are capable of addressing
downgrade attacks. [RFC3748] Section 7.2.1 describes the "protected
ciphersuite negotiation" security claim that refers to the ability of
an EAP method to negotiate the ciphersuite used to protect the EAP
method conversation, as well as to integrity protect the ciphersuite
negotiation. [RFC4017] requires EAP methods satisfying this security
claim. However, EAP methods may not enable the negotiation of all
cryptographic algorithms, such as Key Distribution Functions (KDFs).

Diameter [RFC3588] provides support for cryptographic algorithm
negotiation via use of IPsec [RFC4301] or TLS [RFC4346]. RADIUS
[RFC3579] does not support the negotiation of cryptographic
algorithms, and relies on MD5 for integrity protection,
authentication and confidentiality, despite known weaknesses in the
algorithm [MD5Collision]. This issue can be addressed via use of
RADIUS over IPsec, as described in [RFC3579] Section 4.2. However,
TLS and IKEv2 currently do not enable negotiation of the Key
Distribution Function (KDF).

To ensure against downgrade attacks within lower layer protocols,
algorithm independence is REQUIRED with lower layers using EAP for
key derivation. For interoperability, at least one suite of
mandatory-to-implement algorithm MUST be selected. Lower layer
protocols supporting EAP for key derivation SHOULD also support
secure ciphersuite negotiation. As described in [RFC1968], PPP ECP
does not provide support for secure ciphersuite negotiation. While
[IEEE-802.16e] and [IEEE-802.11i] support selection of ciphersuites
for protection of data, they do not support negotiation of the
cryptographic primitives used within the Secure Association Protocol,
such as message integrity checks (MICs) and KDFs."