Open Stack

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?

Nick



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120607/fafa1248/attachment.sig>