Subject: [AAA-WG]: Why NASREQ Key Distribution is insecure (fwd)

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Mar 2002 09:45:24 -0800 (PST)

This is followup documentation on the issue posted to the list
earlier. 

---------------------------------------------------------------------
From: Jesse Walker <[email-masked]>:
To:   [email-masked]

>Given that the AS and AP trust each other (assumed), why
>is a reasonable cryptographic protocol (such as CMS or even IPSec) is
>insufficient to protect the transfer of a STA-AP session key from the AS to
>the AP?

There has been in fact ample discussion around exactly these points. There
is, for instance, the whole key handoff discussion, of which AS-AP handoff
is a special case. As a second example, there is the flap around the
Arbaugh-Mishra 802.1X paper, which echos many of our key handoff
discussions, and which we have also discussed.

But even if we had never discussed these points before, we would be forced
to if the issue were raised; if someone perceives holes in our security,
then these have to be addressed, and making an appeal that this wasn't ever
an issue before doesn't help.

I don't buy the assumed trust argument, because it is not specific enough to
offer any useful insight. Let me respond to it by asking why should we
assume the AS and the AP trust each other, and, more to the point, for what
purpose should they trust each other? I think the correct assumptions are
something like

a. The AS and the AP share a key used for key distribution, and that both
parties can be trusted to use this key for no other purpose, and to expose
it to no other parties;

b. The AS can be trusted to distribute a fresh key whenever it distributes a
key.

Why should we assume substantially more about the AP-AS relationship? Each
assumption represents a new point of attack if compromised, so we would do
well to think about eliminating as many assumptions as possible.

Protocols exist that would allow us to reduce the number of assumptions we
make by incorporating explicit verification in place of trust assumptions.
It is feasible to add protocol state allowing the AS to verify that the key
distribution request really did originate with a legitimate station and not
as the result of a rogue AP or a rogue station. It is feasible for both the
AS and the station to verify that the key distribution is live, even though
they can't verify it is fresh (that's why we have to make the second trust
assumption). It is feasible for both the AP and the station to verify that
the AS intended to distribute this particular key to this particular <AP,
station> pair, i.e., that each is talking to the other intended recipient of
the key, and to no one else, and for the protocol to protect against either
the AP or the station cheating (except by exposing a key). The existing
method of throwing keys over the fence to the AP does not have any of these
guarantees built in, so we have to assume much more to use it. Each such
assumption may reasonable in a sufficiently constrained environment, but I
question whether together they are reasonable in a network as open as a
WLAN.

And I don't buy basing the security on mechanisms like IPsec. By definition,
IPsec provides bilateral security between the two parties sharing a security
association, and binds only the two together. A key distribution protocol of
the sort we are discussing is not a bilateral relationship. Key distribution
is a trilateral relationship among three parties--the AS, the AP, and the
station--and because of this will have to cryptographically bind the three
parties together somehow to be secure, i.e., to minimize points to attack.
You can replace IPsec by any other bilateral security protocol, and the same
argument obtains.

My position is that it would be prudent for us to look at adapting a key
distribution protocol that reduces our exposure by minimizing security
assumptions. I believe this because we are building systems that expose many
more attack points than in the past. Indeed, I think the burden of proof is
on the other foot: what leads us to think the special conditions and
circumstances and topologies that permitted security shortcuts in the past
are still applicable in the more fragile environments we are building today?
Why should the mechanisms that worked in more restricted environments still
be applicable unchanged when moved into new environments that, on the
surface at least, seem to violate many of the assumptions we made before?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Mar 2002 21:43:07 -0800 (PST)

Here is a paper by Bellare and Rogaway paper on provably 
secure 3 way key distribution which may relate to this issue.

http://www.drizzle.com/~aboba/AAA/3pkd.pdf