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

[Dan Harkins (dharkins]

  In Section 5.1, change

  My apologies to the list. My initial post was rejected because I
wasn't a member. This last post of mine is somewhat lacking in context
so these are Jari's suggested changes I was referring to from his
post on 11 Nov:

"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."

  regards,

  Dan.

On Mon, November 12, 2007 10:49 am, Dan Harkins wrote:
>
>   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.
>
>
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap
>