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

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

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

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

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

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

> > 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.
>  
Yes. But its hard to do anything about this, so that may
be the reason we are not setting much requirements for
it...

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