Open Stack

On Thu, Jun 7, 2012 at 4:15 AM, Nick Barcet <nick.barcet at canonical.com>wrote:

> On 06/06/2012 05:20 PM, Doug Hellmann wrote:
> > Starting a new thread...
> >
> > On Wed, Jun 6, 2012 at 5:43 AM, Nick Barcet <nick.barcet at canonical.com
> > <mailto:nick.barcet at canonical.com>> wrote:
> >
> >     On 06/05/2012 09:03 PM, Doug Hellmann wrote:
> >     >
> >     >
> >     > On Tue, Jun 5, 2012 at 12:59 PM, Nick Barcet
> >     <nick.barcet at canonical.com <mailto:nick.barcet at canonical.com>
> >     > <mailto:nick.barcet at canonical.com
> >     <mailto:nick.barcet at canonical.com>>> wrote:
> >     >
> >     >     On 06/05/2012 04:44 PM, Doug Hellmann wrote:
> >     >     > On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann
> >     >     > <doug.hellmann at dreamhost.com
> >     <mailto:doug.hellmann at dreamhost.com>
> >     <mailto:doug.hellmann at dreamhost.com
> >     <mailto:doug.hellmann at dreamhost.com>>
> >     >     <mailto:doug.hellmann at dreamhost.com
> >     <mailto:doug.hellmann at dreamhost.com>
> >     >     <mailto:doug.hellmann at dreamhost.com
> >     <mailto:doug.hellmann at dreamhost.com>>>> wrote:
> >     >     >     On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet
> >     >     >     <nick.barcet at canonical.com
> >     <mailto:nick.barcet at canonical.com> <mailto:nick.barcet at canonical.com
> >     <mailto:nick.barcet at canonical.com>>
> >     >     <mailto:nick.barcet at canonical.com
> >     <mailto:nick.barcet at canonical.com>
> >     >     <mailto:nick.barcet at canonical.com
> >     <mailto:nick.barcet at canonical.com>>>> wrote:
> >     >     >
> >     >     >     Have you given any thought to distributing the secret
> value
> >     >     used for
> >     >     >     signing incoming messages? A central configuration
> >     authority does
> >     >     >     not give us a secure way to deliver secrets like that.
> >     If anyone
> >     >     >     with access to the message queue can retrieve the key by
> >     >     sending RPC
> >     >     >     requests, we might as well not sign the messages.
> >     >
> >     >     Actually, the private key used to generate a signature should
> >     be unique
> >     >     to each host, if we want them to have any value at all,
> therefore
> >     >     distributing a common signature should NOT be part of this, or
> >     we would
> >     >     fall under the notion of a shared secret, which is, IMHO, not
> >     any better
> >     >     than having a global password.
> >     >
> >     >     I would recommend that, for the time being, we just generate a
> >     random
> >     >     key pair per host the first time the agent is run, allowing
> >     for someone
> >     >     with further requirement to eventually populate this value by
> >     another
> >     >     mean.
> >     >
> >     >     In any case, if we want to effectively check the signature,
> >     the public
> >     >     key does need to be accessible by the collector to check it
> >     and have yet
> >     >     to define a way to do so...  Proposals welcome, but again,
> >     while I think
> >     >     we should lay the ground for a great security experience, we
> >     certainly
> >     >     don't need to solve it all in v1.
> >     >
> >     >
> >     > The current implementation uses hmac message signatures, which use
> a
> >     > shared secret instead of public/private key pairs. We can have a
> >     > separate secret for each agent, but we still need the collector(s)
> to
> >     > have them all. I thought the point of signing the messages was to
> >     > prevent an arbitrary agent from signing on to the message queue and
> >     > sending bogus data. Do we need to be doing more than hmac for
> >     security?
> >
> >     As stated since the beginning of the project, purpose of the
> signature
> >     is non repudiability, not only authentication.  If I understand
> >     correctly, hmac signature will only provide authentication through a
> >     shared secret, shared secret which then should not be transmited on
> the
> >     wire to the agent, or else it would loose all purpose.
> >
> >
> > Yes, hmac uses a shared secret to produce a SHA-256 (in our case)
> > signature of the contents of the message. How that is interpreted is up
> > to the application. For ceilometer it seemed like hmac would be
> > sufficient for both ensuring that the agent was allowed to send messages
> > (because it knows the secret) and that the message contents had not been
> > modified in transit (because the signature is valid). We could have a
> > separate secret for each agent, but I don't see how a keypair is better
> > for this purpose. I'm no crypto expert, though. :-)
> >
> > To cover the non-repudiability requirement the message includes a UUID1
> > value, which includes the MAC of the sending host as well as time and
> > counter components. No two agents will produce the same UUID1 value at
> > the same time, and no two messages from the same agent will have the
> > same value.
>
> Not a crypto/security expert either, so I think that, for the time
> being, we could very well live with the scenario you describe.  As long
> at the signature and check function that we put in place are distinct
> from the rest of the code, we can assume that someone with stronger or
> different requirements should be able to patch and eventually submit,
> right?


Definitely. The signing function is
https://github.com/stackforge/ceilometer/blob/master/ceilometer/meter.py#L41and
the check function will probably go into the same module, when it is
written.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120607/c5029324/attachment.html>