eap Mailing List: Re: Clarifications on "Domino Effect"

[Bernard Aboba (aboba]

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