Open Stack

On Thu, 2013-04-25 at 13:27 -0400, Eric Windisch wrote:
> > 
> > I don't think he was advocating a matchmaker requirement. In fact, we
> > spoke about this specifically. The idea is what in cases when we're
> > sending a specific service+host, the key used reflects that. In the
> > case where we're sending to any one of a specific service, the key is
> > service-wide. Is that acceptable? Maybe. We have to look at when each
> > case is used.
> 
> 
> I don't think it is acceptable. Shared private keys aren't private.

They are shared, not private indeed, you just need to decide if the
bounding set of actors that have access to a shared key is acceptable.
I think it is for short term keys.

After all if you want to do encryption at any point you'll have exactly
the same problem with a public key infrastructure, only worse as you
have to share a long term key then!

> Also, you eliminate the ability to prevent replay attacks if the peer
> is not known in advance.

How do you prevent replay attacks with public key crypto ?

>  Despite what I said earlier, this does mean that for PKI, if strict
> replay attack prevention is enforced, one will need to use the
> matchmaker for signing.

If you have to use the matchmaker you are back to square zero and both
solutions are again on equal foot on this detail.

>  However, at least then, that is a soft-requirement, something a
> deployer can choose: risk of replay versus performance.

No, there is no versus here. You can choose to ignore replay attacks
with both solutions, the threat posed by a replay attack does not depend
on the scheme used. Either you care for it or not.

> Having individual keying allows for things like tying your keyserver
> into remote attestation. Hosts that cannot attest can be removed from
> the pool automatically.

I am not sure I understand what you mean here, care to elaborate ?

> You want one compromised scheduler to remove them all?

No, how would the scheme I proposed imply that ?

>  If using some plugin to Quantum that required a fanout to all
> compute, should one compromised compute machine disable them all?
> 
Compute nodes obviously should not be allowed to share keys.
But the thing is that you shouldn't probably do fanout to all compute
nodes in the first place.

One way to address broadcast type issues in quantum then, is perhaps to
establish that compute nodes should not trust information sent out that
way, and consider any broadcast messaging as a 'please call home as soon
as you can and grab a new value for X'. Broadcast messages would be
unsigned. Then each compute node can decide if they are interested in
the information and if they are, they actually go and contact the
service to get the information directly.

Incidentally this scheme may also give some protection from a single
compromised service, as its broadcasts will not be implicitly trusted.

If you have many instances of the service then only a subset of nodes
will end up contacting the compromised one as the nodes will evenly
spread their requests among the various copies of the service and reduce
the success of a broadcast attack.
> 
> > In nova, the case that we're *most* concerned about is anything
> > involving compute nodes. In the case of compute, we're almost always
> > talking directly to a specific compute node. There's one case where we
> > broadcast to all computes, but I think we can probably re-engineer that
> > case.
> 
> What about Quantum? Cinder? Ceilometer?

What you want signing for is mostly to avoid an anonymous attacker from
sending fake messages around posing as one of the legit services.
Signing is not a way to protect nodes from services that have legit
keys.
I see each of these services as a single trust entity, the fact there
are multiple instances is necessary to scale better but that's just
incidental. If any of the copy of the services is compromised this copy
can attack all other endpoints that 'believe' them. The fact they might
share a short term key makes absolutely no difference as a compute node
will trust scheduler.compromised or quantum.compromised as much as they
trust any other. 

> Quantum seems to require agents on all compute nodes. Several plugins
> perform fanout calls to those agents. Yes, seriously. That might not
> be a good design, but they do it.


> > A service-wide example would be scheduler. We're not nearly as
> > concerned about the scheduler, so a key for scheduler.* is probably
> > acceptable.
> > 
> 
> I disagree. 

Can you please substantiate a threat model ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York