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

[Dan Harkins (dharkins]

  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.