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

[Dan Harkins (dharkins]

  Sam,

  Where in RFC4962 are the properties of a "key derivation function"
enumerated and where does it explain which of these properties makes
a derived key "sharable"?

  I see the following sentence in RFC4962:

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

Now if one takes that sentence out of context one may think that there
does exist a magical function that makes keys sharable. But the context
around that sentence includes this before:

   "The authenticator is trusted not to distribute keying material
    provided by the AAA server to any other parties."

and this after:

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

So how can one use a key derivation function to distribute keying material
to another party such that it meets all the principles in that document,
like "prevent the domino effect", such that only the peer and authenticator
know the keys? Well, if one parses the above 3 sentences with _session
keys_ in mind it is possible. The "appropriate party known to the peer" is
the entity engaging in the "secure association protocol". That entity is
not another authenticator.

  So there's a key that an authenticator uses with a key derivation
function to produce session keys which are then used to protect data.
There isn't a key that's used in a key derivation function by an
authenticator to derive another key that is distributed to and used by a
different authenticator that is then used (by this different
authenticator) with another key derivation function to produce session
keys.

  The "indistinguishable from random" property of a key derivation
function is necessary and sufficient if it's deriving session keys on
an authenticator to be used to protect sessions. But that is _not_ the
way it's being proposed to be used by this modification to the EAP
keying draft. If non session keys are being distributed then how does
it "meet all principles in [RFC4962]", including preventing the domino
effect?

  Dan.

On Wed, November 14, 2007 8:28 am, Sam Hartman wrote:
>>>>>> "Dan" == Dan Harkins <dharkins [at] lounge.org> writes:
>
>     Dan>   Hi Jari,
>
>     Dan>   Thanks for forwarding this.
>
>     Dan>   Sam, comments below.
>
>     Dan> On Tue, November 13, 2007 1:33 pm, Jari Arkko wrote:
>     >> Dan,
>     >>
>     >> Please find a reply from Sam Hartman on your issue below.
>     >>
>     >> ----
>     >>
>     >> Jari, I don't know where this was sent, so feel free to forward
>     >> my reply.
>     >>
>     dan> Dan Harkins kirjoitti:
>     >> >> 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?
>     >>
>     >> This sounds like an excellent area to focus future work.  I
>     >> don't think adding items to the scope of the eap keying
>     >> document is appropriate at this time.
>
>     Dan>   I don't understand how this is "future work". There was a
>     Dan> proposal that adding "if it was been derived with a
>     Dan> key-derivation function" would make it OK to share keys. I
>     Dan> think it's incumbent upon the one making such an assertion to
>     Dan> say what the properties this function has that make it OK to
>     Dan> now share a key.
>
> Ah.  I believe that we already enabled this in RFC 4962 and that this
> proposal is simply aligning eap-keying with 4962.  So, that's the
> sense in which I think it is future work.
>
>     >> >> 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.
>     >>
>     >> We had a discussion during RFC 4962's last call about whether
>     >> the peer needed to be notified when keys were distributed.  I
>     >> saw no support besides your comments for your position that
>     >> peers needed to be notified.
>
>     Dan> My comment was that a peer has no idea whether a key
>     Dan> hierarchy was compromised or not. Is that not a true
>     Dan> statement?
>
> That is a true statement.  However your comment went beyond making a
> statement about what peers know; by saying "this is not sufficient
> because," you make the claim that peers knowing whether the key
> hierarchy is compromised is a requirement.  I agree that peers will
> not know of a compromise.  I disagree that this is a requirement.
>
>
>     Dan> Yes, I know. Because it's easy to just throw keys around
>     Dan> hither-and-yon.  It is frequently argued that possession of a
>     Dan> key implies authorization to hold that key but it is never
>     Dan> argued why (except via the "why not?"  non-argument
>     Dan> argument).
>
> I think any spec that proposed to share keys would need to discuss how in
> that spec the keys were authorized.
>
>     >> >> >> 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.
>     >>
>     >> Absolutely correct.
>
>     Dan>   So what's the 3 party protocol then?
>
> To be implementable any spec that described a specific instance of
> sharing keys would need to describe what three-party protocol is used.
>
>     >> Some of the things hokey is doing are very clearly three or
>     >> more party.
>
>     Dan> I agree.
>
>     >> This document covers interactions that go beyond EAP.  RFC 4962
>     >> definitely does and may even have a broader scope.  >> 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
>     >>
>     >> This decision belongs within the charter of hokey.  To the
>     >> extent it is not already decided, please discuss it there.
>
>     Dan>   This is a proposal to modify the EAP keying draft. It seems
>     Dan> like the EAP working group's mailing list, and not hokey, is
>     Dan> an entirely appropriate place to discuss it.
>
>     Dan>   Obviously you want to enable hokey to share EAP keys. If
>     Dan> you want to do that then I think the procedure is to do a
>     Dan> RFC4962bis that removes the "prevent the domino effect"
>     Dan> requirement, which acceptable AAA solutions MUST comply
>     Dan> with. Then EAP can relax its requirements to say it's OK, but
>     Dan> I still think it has to ascribe properties to functions that
>     Dan> it is using. And then hokey can start saying how it's going
>     Dan> to share keys.
>
>     Dan>   I don't think it's right to cram through nebulous language
>     Dan> into a document discussing security. And I say "cram" because
>     Dan> of your statement, "To the extent it is not already
>     Dan> decided". This doesn't smell right.
>
>     Dan>   Dan.
>
>
>
>
>