Open Stack

> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: 24 October 2012 10:34
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] Secure RPC
> 
> On Mon, Oct 22, 2012 at 11:13:19AM -0400, Eric Windisch wrote:
> >
> >
> > On Saturday, October 20, 2012 at 17:39 PM, Vipul Sabhaya wrote:
> >
> > > Hi,
> > >
> > > I'm a developer on the RedDwarf project.  I missed the session on
> > > Trusted RPC Messaging at the summit, and we are hoping to use this when
> it's available.
> > >  I had some implementation/scope questions that someone may be able to
> answer.
> > >
> > > 1.  Is encryption of the message also in scope? or is the plan to
> > > only sign at this point?
> >
> > The scope is to have trust between components. Signing is necessary
> > for that, but not encryption. Encryption will be a more substantial
> > change to the messaging format and will more heavily depend on a key
> management solution.
> > My thoughts are to do signing first, encryption later.
> 
> I have been working on designs for disk encryption in the libvirt driver for Nova,
> and one of the key requirements for this work is to get both encryption and
> signing of messages (to protect key material passed between services). So from
> my POV I think we need to bite the bullet and go straight for a solution that
> provides both signing & encryption. I also need to have quite fine grained
> identity management - eg not simply per-host certs, but per-(host,service) certs,
> so you can distinguish messages from a Nova 'compute' service vs the
> 'schedular' service vs the 'api' service.
> 
> Do you have any formal design document for what you are proposing for the
> RPC layer security ?  I'm 1/2 way through writing up a design document for what
> I was going to propose and should be able to share it towards the 2nd half of
> next week. I'd like to make sure we collaborate on secure messaging to get a
> solution that meets all our goals.
> 

> > > 2.  What is the solution around key management?
> >
> > Generally, certificate management will look a lot like SSL certificate
> > management. The pattern is well known. You generate a private key and
> > a CSR on each host. You send the CSR to a CA for signing. You get a
> > certificate back.  The main difference to public SSL is that you'll
> > want to run your own CA.
> >
> > Additionally, this will depend on a keyserver, like other session-less
> > PKI systems such as PGP / GPG. The system will be pluggable so that
> > various keyservers can be plumbed in. Some CA solutions include keyservers.
> >
> > There are existing CA solutions that one can deploy, such as Dogtag,
> > RHCA, EJBCA, SimpleCA, OpenCA, and NewPKI. This list is
> > non-exhaustive.  There is almost as long a list of dedicated keyserver
> > options. We don't need to reinvent the wheel. Distributions can choose
> > one, or even build one, and we can give examples. (I haven't deeply
> > evaluated all the above options… caveat emptor)
> >
> > Overall, I see this as a place for vendors to step up and provide solutions.
> 
> I've not examined the options either, but I had thought that it may well be
> desirable to have Keystone be the hub to provide the certificate management
> interfaces. One of my desires is that RPC encryption + signing be something that
> people are able to have enabled out of the box, with every single OpenStack
> install, possibly even going as far as making it a compulsory feature for all. Thus
> I'm somewhat wary of requiring that people deploy a significant piece of
> external infrastructure as a pre-requisite for OpenStack. By the same logic, it is
> important that use of secure messaging should not be imposing any significant
> ongoing administrative overhead. That said, it could well be pratical to have a
> simple defautl cert manager built into keystone, which is then optionally
> pluggable with 3rd party solutions if desired. All TBD of course.
> 
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
>


How many of the Nova API messages really need to be encrypted? If it's few then I'd suggest there are probably better approaches than encrypting everything. A big issue in nova is that various components have different attack surfaces, which makes them more or less likely to be compromised than other components. Having each component sign messages before transmission would deal with the most immediate threat: An attacker on your network can control _everything_ by watching the wire and injecting their own packets. 

The next step (that's really needed before encryption makes much sense) is to shoehorn some sort of RBAC into Nova so that when a component receives a signed message (signing proves it's from "X") it can check that "X" is in the right role to send that message. Once this is done we start having some pretty robust mechanisms for controlling data inside of Nova.

Of the two things I've mentioned so far, signing and RBAC, signing probably seems to be the easiest but you need to decide how you're going to sign and what crypto primitives we're going to use (this is relevant to the encryption discussion too). At the design summit someone suggested sending a X.509 public certificate along with a signed call - this is kind of crazy, there's no way we can send around 1.5kb of extra data for each message, you could send the public key lets assume we're using 2048bit RSA - that still means we're adding 256bytes to every message. In either case you'd need a way to check the public component was valid and not revoked. I think there are probably some smart things that can be done by just sending an X.509 fingerprint or a keyID and having centrally distributed, cryptographically verifiable local lookup caches - (this is also a neat way of sidestepping any CRL verification issues : if the cert isn't in your trust cache, it's not trusted).

At the summit there seemed to be lots of confusion over how this would actually work and a whole bunch of frankly quite worrying ideas were being thrown around. This is part of the reason that the OpenStack Security Group was formed, I can't wait to see your design document, I hope that it blows away all of the concerns I've listed above but if it doesn't perhaps you would be open to working with the OSSG to lock it down or even joining the OSSG if you're "security inclined" generally. The OSSG is a group of stackers who come from good security backgrounds and want to help developers get security right first time around by providing review, advice and consultation : https://launchpad.net/~openstack-ossg

Cheers
-Rob


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6190 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121024/76ac6041/attachment-0001.bin>