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

[Dan Harkins (dharkins]

  I would like to apologize to anyone who thinks I was unfairly
criticizing Jari. I wasn't and did not mean to make it sound like
I was. I think I understand what's going on. I appreciate the
effort he made to address other people's concerns and hope that
the window on changes is not closed.

  regards,

  Dan.

On Wed, November 14, 2007 7:30 am, Dan Harkins wrote:
>
>   Hi Jari,
>
>   Thanks for forwarding this.
>
>   Sam, comments below.
>
> 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.
>
>   I don't understand how this is "future work". There was a proposal that
> adding "if it was been derived with a key-derivation function" would
> make it OK to share keys. I think it's incumbent upon the one making such
> an assertion to say what the properties this function has that make it
> OK to now share a key.
>
>   This isn't adding work items to the scope of this document only asking
> for an explanation of what this function does that makes sharing keys
> acceptable.
>
>> It seems like hokey could easily specify such requirements within its
>> charter.
>
>   This is a proposal to weaken the security properties of EAP by referring
> to a function that imparts some feature but whose properties are not
> specified. Hokey can specify any requirements it wants but if EAP is
> saying that it's OK to share _a pairwise_ key then it has to say why and
> under what circumstances it is OK.
>
>   Otherwise this is a magic function that sprinkles pixie dust on keys
> that makes them "sharable". It's not correct to say that some other group
> has to define the magic.
>
>>     >> 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.
>
> My comment was that a peer has no idea whether a key hierarchy was
> compromised or not. Is that not a true statement?
>
> You may say that you don't think that's a problem but then just say you
> don't think that's a problem. It's somewhat red herring-ish to rehash an
> old argument that may only be tangentially related. Many other points
> were raised in that discussion. But I think it's most efficient right now
> to stick to the discussion at hand.
>
>> There is support for a lesser requirement: that entities receiving
>> keys be authorized to do so.  However this authorization does not need
>> to be tied back directly to the peer.
>
> Yes, I know. Because it's easy to just throw keys around hither-and-yon.
> It is frequently argued that possession of a key implies authorization to
> hold that key but it is never argued why (except via the "why not?"
> non-argument argument).
>
>>     >>
>>     >> 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.
>
>   So what's the 3 party protocol then? If you want to share an EAP key
> then you need a 3 party protocol. A nebulous function that generates
> keys may, as I stated, be necessary but it's not sufficient.
>
>>                      Some of the things hokey is doing are very clearly
>> three or more party.
>
> 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.
>
>   This is a proposal to modify the EAP keying draft. It seems like the
> EAP working group's mailing list, and not hokey, is an entirely
> appropriate
> place to discuss it.
>
>   Obviously you want to enable hokey to share EAP keys. If you want to
> do that then I think the procedure is to do a RFC4962bis that removes
> the "prevent the domino effect" requirement, which acceptable AAA
> solutions
> MUST comply with. Then EAP can relax its requirements to say it's OK,
> but I still think it has to ascribe properties to functions that it is
> using. And then hokey can start saying how it's going to share keys.
>
>   I don't think it's right to cram through nebulous language into a
> document
> discussing security. And I say "cram" because of your statement, "To
> the extent it is not already decided". This doesn't smell right.
>
>   Dan.
>
>
>
>