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

[Yoshihiro Ohba (yohba]

I have the same concern as Dan regarding "unless it has been derived
with a key-derivation function" part in Section 5.1.  

Why do we need this relaxing text?

Yoshihiro Ohba


On Sun, Nov 11, 2007 at 11:27:12AM +0200, Jari Arkko wrote:
> 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.
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>