Open Stack

On Thu, 2013-04-25 at 15:16 -0400, Eric Windisch wrote:
> One use-case I see this proposal failing to address is with cross-cell
> and cross-project messaging. 

At the moment it is not directly addressed, but I haven't seen
addressing handling certificate trust and revocation checking in the
public key scheme which has the same challenges.

> The cross-cell messaging is a legitimate concern and probably where
> some of this security is most desperately needed. Your present design
> seems to require a single, global service to drive communication and
> authority for all cells.

If I have to argue on the spot I can tell that cross-cell keys can be
easily handled through intra key server communication when the 2 peers
are in different cells.

If you look at how keys are generated only one peer key is used to do
derivation, so if the key is not on a specific server all you need is a
call to the trusted peer-key server to obtain the necessary keys and
hand them back to the client.

This is made up on the spot and will need more consideration but I do
not see it as an obstacle, and certainly not incompatible with the
current scheme, just an additional extension.

> Secondly, cross-project messaging is a concern for the Ceilometer
> team. This is presently contentious amongst the RPC users and
> maintainers, and a matter of active discussion.  However, should that
> we seek to support this, it should be considered. Presently, all
> projects communicate via AMQP through a single control_exchange.
> ZeroMQ messaging happen over a unique TCP port per project. The
> messaging is clearly delineated, split between the projects.
> 
> In our proposed PKI model, this isn't a huge deal, because we can have
> a keyserver per project, per cell, or per project per cell. There will
> be devils in the details of implementing it,

At least as hard as with the shared-secret solution.

You have the same problem of trust between clients and the key server
and inter-domain/project/cell/server trust between different key
servers. 

>  surely, but it isn't against the architectural design. If
> communicating to another project or cell, we can make the code reach
> into the right keyserver.

Same with a shared key solution, why do you think you can't there ?

>   However, your proposal requires a tight coupling of peers / services
> that introduces complexity around scale that is not presently
> addressed. 

I do not see a difference in the complexity, care to share some details
about why you think it is more complex ?

Simo.

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