eap Mailing List: hopefully final changes for draft-ietf-eap-keying

[Jari Arkko (jari.arkko]

All,

You've seen the new draft versions appear. The changes have
related to resolving issues from Charlie's secdir review and
Sam Hartman's Discuss. I believe the final changes needed to
clear Sam's Discuss are below. I hope to close the document
in the next couple of days, send mail if you see anything
alarming.

These changes relate to text alignment between RFC 4962
and this document, and how tough requirements we place on
distribution of derived keys for future applications.

In Section 1.5, change

OLD:
If the authenticator
uses a key derivation function to derive additional keying material,
the authenticator is trusted to distribute the derived keying
material only to the appropriate party that is known to the peer, and
no other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the
principles in this document, confirming that keys used to protect
data are to be known only by the peer and authenticator.
NEW:
If the authenticator or backend authentication server uses a key
derivation function to derive additional keying material, it is
trusted to distribute the derived keying material
only to the appropriate party that is known to the peer, and no
other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the
principles in RFC 4962, confirming that keys used to protect
data are to be known only by the peer and authenticator.

In Section 5.1, change

OLD:
An EAP authenticator MUST NOT share any keying material with
another EAP authenticator, since if one EAP authenticator were
compromised, this would enable the compromise of keying material on
another authenticator. In order to be able to determine whether
keying material has been shared, it is necessary for the identity
of the EAP authenticator (NAS-Identifier) to be defined and
understood by all parties that communicate with it. Similarly, an
EAP peer MUST NOT share any keying material with another EAP peer.
NEW:
An EAP authenticator MUST NOT share any keying material with
another EAP authenticator unless it has been derived with a
key-derivation function, since if one EAP authenticator were
compromised, this would enable the compromise of keying material on
another authenticator. In order to be able to determine whether
keying material has been shared, it is necessary for the identity
of the EAP authenticator (NAS-Identifier) to be defined and
understood by all parties that communicate with it. Similarly, an
EAP peer MUST NOT share any keying material with another EAP peer
unless it has been derived with a key-derivation function.

In Section 5.3, change:

OLD:
Authentication mechanisms MUST maintain the confidentiality of any
secret values used in the authentication process.
NEW:
Each party in the AAA key management protocol MUST be
authenticated to the other parties with whom they communicate.
Authentication mechanisms MUST maintain the confidentiality of
any secret values used in the authentication process.

In Section 5.5, change:

OLD:
Once the AAA key management
protocol exchanges are complete, all of these parties should hold
a common view of the authorizations associated the other parties.
NEW:
Once the AAA key management
protocol exchanges are complete, all of these parties should
hold a common view of the authorizations associated with the
other parties.

and also

OLD:
As described in [RFC3748]
Section 7.15, channel binding enables the peer to verify that the
authenticator claim of identity is both consistent and correct.
NEW:
As described in [RFC3748]
in Section 7.15, channel binding is required to enable the
peer to verify that the authenticator claim of identity is both
consistent and correct.