From: Charlie Kaufman <charliek exchange.microsoft.com
To: "iesgietf.org" <iesgietf.org,
"secdirmit.edu" <secdirmit.edu,
Bernard Aboba <bernardawindows.microsoft.com,
Dan
Simon<dansimonmicrosoft.com,
"Pasi.Eronennokia.com"
<Pasi.Eronennokia.com, "henriklevkowetz.com"
<henriklevkowetz.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
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
