Issue 393: Downgrade Attacks

Issue 393: Downgrade Attacks
Submitter name: Bernard Aboba
Submitter email address: abobainternaut.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."


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap