Subject: [eap] Re: Clarifications on "Domino Effect"

From: Bernard Aboba <[email-masked]>
Date: Sun, 31 Jul 2005 10:58:05 -0700 (PDT)

> "Compromise of a single authenticator cannot compromise any other
> part of the system, including session keys and long-term secrets."

> In some sense it is too broad. It disallows NAS to provide any keys to
> NAS ports (which may be hosted on separate nodes). In the lack of
> clarification, I read some people even take this as "no keys shall ever
> be passed around". I really think this part deserves further
> clarification.

If an authenticator is compromised, we have to assume that the attacker
obtains the MSK/AAA-Key.  Since the TSKs are derived from (IEEE 802.11i)
or at least protected by (IEEE 802.16e) the MSK, the attacker will then
obtain the TSKs as well.  In any case, if the attacker has compromised the
NAS, the TSKs should probably be assumed compromised anyway.

So I think draft-housley must be talking about some other entity in the
phrase "part of the system".  For example, compromise of one authenticator
doesn't compromise *another* authenticator's session keys.  Obviously
compromising the authenticator session keys also compromises the EAP peer
session keys, since they are the same.  But that doesn't mean that the
long-term secrets are compromised.

Compromise of one NAS will yield the attacker access to traffic on that NAS,
ability to admit/deny usage, ability to launch online dictionary attacks
against the RADIUS server.  But I think that the "Domino Effect" paragraph
is trying to say that the attacker should not be able to gain control over
another entity, such as another NAS, a peer or a backend server.

Note that in practice, most NASes in a deployment run the same firmware,
and if the attacker gained control of one NAS through a vulnerability,
then it is likely that all the NASes are vulnerable to that same attack.

> And in other sense, I find the text a bit narrow. Why does it only focus
> on the "authenticator" if we are talking about domino affect? A
> compromised RADIUS relay yields a domino effect as well.

Right -- and a much worse one because this compromises not only
keys, but also the RADIUS shared secrets, allowing the attacker to forge
RADIUS packets at will to all the NASes associated with that RADIUS proxy.

> An EAP peer, for instance,
> is a part of "the system", and its traffic at least would be
> compromised if its authenticator got compromised.

Yes.

> Hmm, that's interesting. I never thought that way before. We definitely
> need a clarification on that as well.

Given the importance of draft-housley to the EAP Key Management Framework
document, I think we probably need to do a very detailed review so that we
can settle this and other issues.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Aug 2005 01:42:42 +0300

Yes.

Yes.

Yes.

>then it is likely that all the NASes are vulnerable to that same attack.
Well, yes, but I think the main reason for this requirement
is physical access. If you grab an access point from a coffee
shop wall, this should not lead to an uncontained compromise
of the whole system.

>RADIUS packets at will to all the NASes associated with that RADIUS proxy.
Yes. But its hard to do anything about this, so that may
be the reason we are not setting much requirements for
it...

>can settle this and other issues.
In the interest of getting a complete document, and for getting
an RFC with WG consensus behind it, it might be an idea
to define the issue in the keying framework itself. In this particular
case what we need to do is to go from a general statement "must
not compromise other nodes" to a set of more specific statements
that talk about what exact quantities in what exact other nodes
must not be compromised. While we are at it, we might also state
that we do not have a requirement on the compromise of the radius
server being recoverable...

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 31 Jul 2005 17:52:17 -0700 (PDT)

> shop wall, this should not lead to an uncontained compromise

This problem statement is somewhat more concrete (and easier to analyze).

For example, if you grab the access point off the wall, do you:

a. Obtain a RADIUS shared secret used by another AP?  If good RADIUS
secret hygene is being used, then  the answer is no.

b. Obtain keys useful in compromising another AP?  If the EAP method
provides "session independence" I think that obtaining one MSK provides
no useful information to compromise another MSK.  Also if the EMSK is
cryptographically independent from the MSK, you can't compromise the EMSK
if the MSK is compromised.

c. Obtain keys useful in compromisng an EAP peer or the backend server?

Assuming that the EAP method is sufficiently robust (e.g. satisfies the
RFC 4017 requirements) I think the answer is "no" to this one too.  For
example, the attacker can't do an offline or online dictionary attack,
can't do a brute force attack on the key (assuming the key strength is
sert high enough), etc.

> server being recoverable...

Yes, it would be good to have a plan for getting this (and other
requirements issues) settled.  The exact nature of the "domino effect"
requirement is important to a number of lower layer attempting to utilize
EAP.

And the EAP WG is probably as good a place to discuss this as anywhere...