eap Mailing List: Re: [Fwd: Re: hopefully final changes fordraft-ietf-eap-keying]

[Yoshihiro Ohba (yohba]

On Wed, Nov 14, 2007 at 12:48:13PM -0800, Bernard_Aboba [at] hotmail.com wrote:
> >  So if the draft we're discussing wishes to make an exception on the
> > key sharing prohibition when "[the key] has been derived with a
> > key-derivation function" then it has to explain what property of this
> > "key-derivation function" allows it to still conform to RFC4962. Well,
> > that's what my argument is. Why is that argument not valid?
> 
> If RFC 4962 covers this topic, what text do we need in the EKMF document? 
>  Is deleting the sentence in question (and saying nothing) acceptable? 

Yes, it is acceptable to me, as long as the EKMF draft has a citation
to the specific text on the requirement on "Prevent the Domino effect"
in RFC 4962.

Yoshihiro Ohba



> For example, would the following text (from -22) work? 
> 
> "Some of the implications of the requirement are as follows:
> 
> Key Sharing
>      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.  EAP lower layer specifications such as
>      [IEEE-802.11], [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306] and
>      PPP [RFC1661] do not involve key sharing.
> 
> AAA Credential Sharing
>      AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
>      keys or certificates) MUST NOT be shared between AAA clients, since
>      if one AAA client were compromised, this would enable an attacker
>      to impersonate other AAA clients to the backend authentication
>      server, or even to impersonate a backend authentication server to
>      other AAA clients.
> 
> Compromise of Long-Term Credentials
>      An attacker obtaining keying material (such as TSKs, TEKs or the
>      MSK) MUST NOT be able to obtain long-term user credentials such as
>      pre-shared keys, passwords or private-keys without breaking a
>      fundamental cryptographic assumption.  The mandatory requirements
>      of [RFC4017] Section 2.2 include generation of EAP keying material,
>      capability to generate EAP keying material with 128-bits of
>      effective strength, resistance to dictionary attacks, shared state
>      equivalence and protection against man-in-the-middle attacks." 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>