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

[Jari Arkko (jari.arkko]

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.

It seems like hokey could easily specify such requirements within its charter.
    >> 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.

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.

    >>
    >> 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.  Some of the things hokey is doing are very clearly three 
or more party.
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.