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

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Nov 2007 10:49:50 -0800 (PST)

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

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Nov 2007 11:22:22 -0800 (PST)

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.

---

From: <[email-masked]>
Date: Mon, 12 Nov 2007 12:02:40 -0800

>> issues arising from the introduction of a virtual 3rd party.

Section 1.6.1 (Mode Independence) goes into this.  From the point of
view of the EAP peer, it has no idea whether the EAP authenticator is
operating in "pass through" mode or not, and it does not care --
since only the identity of the EAP server matters.

>> of the key derivation function.

Sharing EAP keying material does indeed change the EAP model from that of a 
2
party protocol to 3 (or more) parties.    This is prohibited by the
text in Section 2:

   EAP keying material provided to a lower layer MUST NOT be transported
   to another entity.  For example, EAP keying material passed down to
   the EAP peer lower layer MUST NOT leave the peer;  EAP keying
   material passed down or transported to the EAP authenticator lower
   layer MUST NOT leave the authenticator.

With respect to sharing of Transient Session Keys (TSKs), here is what 
Section 1.5 says:

   The goal of the EAP conversation is to derive fresh session keys
   between the EAP peer and authenticator that are known only to those
   parties, and for both the EAP peer and authenticator to demonstrate
   that they are authorized to perform their roles either by each other
   or by a trusted third party (the backend authentication server).

If TSKs are shared, clearly they will not be known only by the peer and 
authenticator.

So I think that the document is relatively clear about sharing of EAP keying 
material and
TSKs in other places.   So the question is about sharing of keys 
intermediate between
the EAP keying material (MSK/EMSK) and TSKs.

RFC 4962 Section 3, which is quoted in this section, contains quite a bit of 
text relating to this issue.
As I read it, it does not provide a blanket exemption from requirements 
based on use of a key
derivation function;  there are implementations and uses of key derivation 
functions that would
meet the requirements (such as IEEE 802.11r) and there are others that will 
not.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Nov 2007 23:33:16 +0200

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.

    >> properties such a function has that would make sharing of keys

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

This decision belongs within the charter of hokey.  To the extent it
is not already decided, please discuss it there.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 14 Nov 2007 07:30:06 -0800 (PST)

Hi Jari,

  Thanks for forwarding this.

  Sam, comments below.

> 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

  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.

> We had a discussion during RFC 4962's last call about whether the peer
> needed to be notified when keys were distributed.

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.

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

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

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

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 15 Nov 2007 11:32:03 -0800 (PST)

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:
>> I saw no support besides your comments for your position that peers
>> needed
>> to be notified.
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Nov 2007 22:37:06 +0200

No apology needed, I didn't even realize you were critizing
me! We need you and everyone else reacting on proposals
and issues; this is much appreciated -- thanks.

The window on changes is closed for new issues unless
they are truly dramatic problems. I would also not like
to re-open discussions that were held either earlier in
the WG and closed, or discussions that were resolved in
RFC 4962 publication process. Talking to Sam I understood
that the derived key issue had been discussed there
as well.

But the WG definitely needs to be OK with changes that
we are doing for the sake of resolving Discusses. That being
said, I would strongly encourage the working group to attempt
to move forward in a way that does not lead to a deadlock.
This particular document has been in the process for
over four years. There is a good chance that if it will not
get done now, it will never be done. There are things
that we could improve in the document, but I think the
world is a better place with this document published
than without.

So, with regards to Sam's Discuss we still need to resolve it.
Are we closer to agreement now, and what do you Dan think
is needed?

Jari

---

From: <[email-masked]>
Date: Thu, 15 Nov 2007 13:12:41 -0800

I would also ask the question whether the WG is ok with the text in -22
(which is different from Jari's original proposal).  

--------------------------------------------------
From: "Jari Arkko" <[email-masked]>
Sent: Thursday, November 15, 2007 12:37 PM
To: "Dan Harkins" <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>; "eap-WG" <[email-masked]>
Subject: Re: [eap] hopefully final changes for draft-ietf-eap-keying

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 16 Nov 2007 23:27:29 -0800 (PST)

Hi Jari,

  What I think is needed is to not make an exception on key sharing
when a key is derived with a key-derivation function.

  That does seem to put us at a logger-heads with Sam though. Apparently
Sam's discuss related to enabling 11r but, as I said in a separate post,
what 11r stated it wanted from the IETF when it removed a secure 3 party
protocol from its draft was not a relaxation on key sharing but a secure
3 party protocol.

  So I would respectfully ask Sam to find a home for the task of defining
a secure 3 party protocol. That seems to me to be the proper way forward.

  regards,

  Dan.

---

From: <[email-masked]>
Date: Sat, 17 Nov 2007 22:05:00 -0800

Dan Harkins said:

> As I said in a separate post, what 11r stated it wanted from the IETF when
> it removed a secure 3 party protocol from its draft was not a relaxation 
> on
> key sharing but a secure 3 party protocol.

Did 11r ever send a liaison to this effect?

I do recall a discussion on this, but I don't think that the letter was ever 
sent.

The typical way to move forward in such as case would be to publish the 11r 
3rd party
protocol design.   That is what we did with RFC 4017, which was judged to be
outside the realm of IEEE 802.11i, since it dealt with EAP.

Since the development of the EKMF was coordinated quite closely with IEEE 
802.11
(EAP WG even had a joint interim meeting with 11), it should not be 
surprising
that the EKMF and 11r are generally in sync.  However, it took a while for 
11r to
get into sponsor ballot, so that it was not possible to include examples 
from it within the
EKMF document.   At this point, fixing that would require too many changes. 
In any case,
the 11r document is largely self-explanatory.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 18 Nov 2007 01:14:12 -0800

I have stayed out of this discussion so far, but I have a few 
observations in resolving Sam's Discuss.

Sam suggests in part:

"I think it would be
much more clear what is going on if the document made it clear that
while EAP keying material cannot be exported, keys derived from EAP
keying material may be exported within appropriate key scopes. "

It appears that he wants to facilitate 11r design (and perhaps other 
designs too) where the authenticator uses the MSK (EAP keying material) 
or a portion thereof as the root of a local key hierarchy and 
distributes derived keys.

I don't disagree.  The answer I think is already in the text that Sam 
chose to quote.  It may need a bit of tweaking.

">An EAP authenticator MUST NOT share any keying material with
 >another authenticator.  "

Perhaps the tweak might be that we should use "SHOULD NOT" instead of 
"MUST NOT."   The exception (to be documented) is the case where the 
threat that we cite can be mitigated otherwise.  So, the claim might be 
that keys or derived keys may be shared as long as compromise of the 
authenticator is made difficult.  Obviously the notion of derived keys 
protects from compromise of the receiving entities and the presumption 
is that it is easier to compromise the entity that receives keys than 
the one that derives the keys.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 18 Nov 2007 11:57:24 -0500

Lakshminath,

As I commented in a previous email, 802.11r key hierarchy is defined
within a single distributed authenticator and there is no key sharing
between different authenticators.  So there is no need to use of
"SHOULD NOT" instead of "MUST NOT".

Also, use of "SHOULD NOT" instead of "MUST NOT" is going against the
following requirement of RFC 4962:

"Likewise, compromise of a single authenticator MUST NOT compromise
keying held by any other authenticator within the system."

Yoshihiro Ohba

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 18 Nov 2007 22:34:04 -0800 (PST)

Dunno. Did they ever send a letter that said, "we are violating your
precepts; will you please change them for us?"?

  Dan.

---

From: <[email-masked]>
Date: Sun, 18 Nov 2007 23:06:54 -0800

> precepts; will you please change them for us?"?

No, in fact just the opposite.  Many of the security requirements in
the EKMF were in fact written by people who were active in 11r.
Early on, for example, we incorporated material on requirements
contributed by Jesse Walker.

Rather than questioning the requirements,  active 11r
participants authored many of them and overall the document
is fairly diligent about addressing the deficiencies in 11i that are pointed
out in the EKMF.