Open Stack

On Thu, 2013-04-25 at 13:48 -0400, Eric Windisch wrote:
> > I don't think it is acceptable. Shared private keys aren't private.
> Sometimes I should read what I write before I send it. I realize this
> is probably not the right response. First, none of the keys in this
> architecture are private anyway. I used the wrong terminology here.
> 
> If each host has a shared AES key with the server, and their key is
> paired to their service-group, it is irrelevant if the service-group's
> key is shared.  You could even reject requests for unattested origin
> hosts, regardless of their service-group, based on their individual
> AES key.

Precisely :)

> The important factors we have are:
> 
> 1) Verify the sender's message signature
> 2) Prevent replay attacks
> 
> We can do #1 with a shared key-per-service, because we know the
> origin, even if we don't know the destination. It does seem to imply
> that any scheduler, if compromised, could replay messages to other
> schedulers until key cache timeouts occurred, even if revocation
> occurred. Unless, of course, a centralized replay-prevention-service
> to maintain state was deployed...

A compromised scheduler can simply go ahead and send commands to nodes,
an attacker has no reason to play with replays in this case unless there
is a specific reason for which a node would reject messages from a
specific scheduler but not another.

This is the reason why I think sharing keys between a single service
group is just fine.

> We can't do #2 without maintaining state somewhere. It is easiest and
> most scalable to maintain state in each endpoint, than centrally for
> each service group. The matchmaker is what lets us send messages to
> independent endpoints such that message history can be maintained. A
> nounce in the message makes them unique. The signature itself is what
> you cache and lookup against for replays.

You don't even need a nounce, timestamp + source name is already a
unique combination, assuming the source does not reuse timestamps (same
check you need in place to avoid reusing nonunces)

Simo.

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