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

[Dan Harkins (dharkins]

  Hi Jari,

  I have some issues with the proposed changes to section 5.1.
You add an exception to key sharing permitting it if "it has
been derived with a key-derivation function." What are the
properties such a function has that would make sharing of keys
it derives acceptable?

  Do you mean to say that it's output is "indistinguishable from
random by an adversary"? That would certainly be a very important
property for such a function as it would prevent an EAP
authenticator from determining a root key used to derive the key
it was distributed. Certainly such a property is necessary but
it is clearly not sufficient.

  I say that "indistinguishable from random" is not sufficient
because the problem of the "domino effect" still remains. An
authenticator that is using a key-derivation function to
derive keys which it then shares with other authenticators will
be a very attractive target. Compromise keying material on that
authenticator and it enables compromise on a slew of other
authenticators.

  It is also not sufficient because the EAP peer has no way
of knowing when compromise has happened. Keys in his key
hierarchy just pop up on the network and he is expected to
just _assume_ everything is fine.

  EAP is a 2 party protocol. In practice it looks like there
are 3 parties because there's an EAP peer, and EAP authenticator
and an EAP server but, as I am repeatedly told, the EAP server
and EAP authenticator are logically one and any division between
the two is solely for scaling and performance. And in any event
channel binding can bind the NAS-Id of the authenticator into
the key derived by the EAP peer and EAP server to address any
issues arising from the introduction of a virtual 3rd party.

  If you want to start sharing keys between authenticators
then you REALLY have a 3 party protocol: 1) EAP peer; 2) EAP
server-cum-authenticator running a key derivation function;
and 3) another authenticator being the recipient of the output
of the key derivation function. There's no way to fudge that
into 2 parties. The EAP peer has no relationship with this new
authenticator (in the language of section 1.5 it does not "know"
that authenticator). Allowing distribution of keys to that new
authenticator would severely, and in my opinion deleteriously,
affect the security of EAP.

  If a 3 party key distribution protocol is the answer to some
problem then a true 3 party protocol MUST be used. I really
don't think easing the requirements on the security of EAP, a
2 party protocol, is the right thing to do.

  regards,

  Dan.