← Back to team overview

openstack team mailing list archive

[Metering] signing messages, was Re: Agent configuration mechanism

 

Starting a new thread...

On Wed, Jun 6, 2012 at 5:43 AM, Nick Barcet <nick.barcet@xxxxxxxxxxxxx>wrote:

> On 06/05/2012 09:03 PM, Doug Hellmann wrote:
> >
> >
> > On Tue, Jun 5, 2012 at 12:59 PM, Nick Barcet <nick.barcet@xxxxxxxxxxxxx
> > <mailto:nick.barcet@xxxxxxxxxxxxx>> wrote:
> >
> >     On 06/05/2012 04:44 PM, Doug Hellmann wrote:
> >     > On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann
> >     > <doug.hellmann@xxxxxxxxxxxxx <mailto:doug.hellmann@xxxxxxxxxxxxx>
> >     <mailto:doug.hellmann@xxxxxxxxxxxxx
> >     <mailto:doug.hellmann@xxxxxxxxxxxxx>>> wrote:
> >     >     On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet
> >     >     <nick.barcet@xxxxxxxxxxxxx <mailto:nick.barcet@xxxxxxxxxxxxx>
> >     <mailto:nick.barcet@xxxxxxxxxxxxx
> >     <mailto:nick.barcet@xxxxxxxxxxxxx>>> 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.



>   I was
> envisioning a scenario that would allow both:
>
> 1. each agent instance generate a keypair
> 2. pub key is added to collector as in a trusted agent list
> 3. message are signed by agent using priv key and each message emitted
> carries a sequence number
> 4. collector checks signature using the pub key
>
> As a result, individual agents are authenticated, their signature is
> unique so they can be traced and you can't fool the system through a
> replay since the sequencing would be off.
>
> Nick
>
>
>

Follow ups