Open Stack

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

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

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.

Basically, having peer-to-peer trust, rather than peer-to-service trust, would mean that we can prevent replay attacks without a centralized datastore / cache.

Regards,
Eric Windisch