Re: Re: Clarifications on "Domino Effect"
From: Bernard Aboba (abobainternaut.com)
Date: Sun, 31 Jul 2005 20:52:23 -0400 (EDT)
> 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.

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.



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

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



Results generated by Tiger Technologies using MHonArc.