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

[Dan Harkins (dharkins]

  Hi Sam,

On Wed, November 14, 2007 11:26 am, Sam Hartman wrote:
>>>>>> "Dan" == Dan Harkins <dharkins [at] lounge.org> writes:
>
>     Dan>   Sam,
>
>     Dan>   Where in RFC4962 are the properties of a "key derivation
>     Dan> function" enumerated and where does it explain which of these
>     Dan> properties makes a derived key "sharable"?
>
> They are not.  You may have found a problem with RFC 4962.  I don't
> think that means we need to fix that now in order to bring this spec
> into alignment with RFC 4962.
>
> Alternatively one could argue (and I do) that RFC 4962 leaves the
> security analysis of the key derivation function up to the protocol
> defining that function.

  That may very well be but RFC4962 explicitly says that a solution that
is acceptable and conforms MUST meet the requirements in it. One of those
is that:

        "compromise of a single authenticator MUST NOT compromise
         keying material held by any other authenticator within the
         system."

If an authenticator runs a key derivation function on a key it obtained
from the AAA server and ships that derived key off to another
authenticator it will violate that requirement.

  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?

  Dan.