Subject: Re: [eap] [secdir] secdir review of draft-ietf-eap-keying-18.txt (part 4)

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 05 Oct 2007 17:36:58 -0700

From: Charlie Kaufman <[email-masked]
To: "[email-masked]" <[email-masked], "[email-masked]" <[email-masked],
    Bernard Aboba <[email-masked],        Dan
Simon<[email-masked],        "[email-masked]"
<[email-masked],        "[email-masked]"
<[email-masked]
Subject: [secdir] secdir review of draft-ietf-eap-keying-18.txt
Date: Sun, 25 Feb 2007 18:55:23 -0800

P45 5.1 "No Key Sharing" talks about the "identity of the EAP
authenticator". I suspect this is another term for "NAS-Identifier", but
I'm not sure.

[BA] Yes.  Propose that this be changed to "the identity of the EAP
authenticator (NAS-Identifier)"

P45 5.2: Given that EAP methods can be negotiated, one possible way to
implement negotiation of cryptographic algorithms is to define a new EAP
method which is identical to the old one except that it uses different
cryptographic algorithms. It's not obvious why you say the ability to
negotiate KDFs is not required. Does that mean the ability to negotiate the
others is required? Why exempt KDFs? Just because a number of existing
protocols made that mistake? This section seems to be placing requirements
(or at least recommendations) on future protocols, in which case
negotiation of KDFs seems like a really good idea.

[BA] The text on page 45 section 5.2 originated in "Guidance for
Authentication, Authorization, and Accounting (AAA) Key Management",
RFC 4962/BCP 132 Section 3.  To make this clear, I would propose that
all the RFC 4962 requirements be explicitly called out and referenced.

In terms of the ability to negotiate KDFs, EAP methods based on TLS
will typically inherit the KDF-negotiation capability of TLS 1.2, so
that implementations of these methods are likely to support KDF
negotiation eventually.  However, KDF negotiation is less frequently
supported in methods not based on TLS (such as EAP-IKEv2).

Although RFC 4962 was being conservative, I think your point is
well taken.  Existing EAP methods frequently depend on SHA-1 and
if that algorithm were to be deprecated by NIST, this would not
only affect EAP methods utilizing SHA-1, but also EAP lower layer
(such as IEEE 802.11i) that don't support KDF negotiation and
utilize SHA-1.  So it would be appropriate to point out
the issue and provide guidance.

The ability to negotiate other cryptographic algorithms
is one of the mandatory security claims in [RFC4017] and is also
required in RFC 4962 Section 3, so I think that we're covered
there.

I propose to change the text in Section 5.2 from:

"   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:
"  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.  Since TLS v1.2 [I-D.ietf-tls-rfc4346-bis] supports
   negotiation of Key Distribution Functions (KDFs),  EAP methods
   based on TLS will, if properly designed, inherit this capability.
   However, negotiation of KDFs is not required by RFC 4962 [RFC4962],
   and EAP methods not based on TLS typically do not support KDF
   negotiation.

   Diameter [RFC3588] provides support for cryptographic algorithm
   negotiation via use of IPsec [RFC4301] or TLS [RFC4346].  Since
   IKEv2 [RFC4306] does not support KDF negotiation, support for
   KDF negotiation is only available when Diameter runs over TLS v1.2.
   RADIUS [RFC3579] does not support cryptographic algorithm negotiation
   and relies on MD5 for integrity protection, authentication and
   confidentiality.  Given the known weaknesses in MD5 [MD5Collision]
   this is undesirable, and can be addressed via use of RADIUS over
   IPsec, as described in [RFC3579] Section 4.2.

   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 well as KDF negotiation.
   As described in [RFC1968], PPP ECP does not support secure ciphersuite
   negotiation.  While [IEEE 802.16e] and [IEEE-802.11] support ciphersuite
   negotiation 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."

[Charliek]

Some typos:

P10: "Initiatlization" - "Initialization"

P16: "material needs to be" - "material be"

P17: "material and material" - "material"

P28: "derived from a portion" - "derived solely from a portion"

P31: "card hold holding" - "card holding"

P40: "is not longer able" - "is no longer able"

P45: "algorithms resilience" - "algorithms provides resilience"

P46: "EAP methods satisfying this" - "EAP methods to satisfy this"

P46: "EAP methods may not enable" - "EAP methods are not required to
enable"

P46: "Key Distribution Function" - "Key Derivation Function" (twice)

P46: "algorithm MUST be selected" - "algorithms MUST be selected"

       --Charlie

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

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