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

[Bernard Aboba (bernard_aboba]

From: Charlie Kaufman <charliek [at] exchange.microsoft.com
To: "iesg [at] ietf.org" <iesg [at] ietf.org, "secdir [at] mit.edu" <secdir 
[at] mit.edu,
   Bernard Aboba <bernarda [at] windows.microsoft.com,        Dan
Simon<dansimon [at] microsoft.com,        "Pasi.Eronen [at] nokia.com"
<Pasi.Eronen [at] nokia.com,        "henrik [at] levkowetz.com"
<henrik [at] levkowetz.com
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