On Thu, Jun 7, 2012 at 4:15 AM, Nick Barcet <[email protected]>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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 06/05/2012 09:03 PM, Doug Hellmann wrote: > > > > > > > > > On Tue, Jun 5, 2012 at 12:59 PM, Nick Barcet > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> wrote: > > > > > > On 06/05/2012 04:44 PM, Doug Hellmann wrote: > > > > On Tue, Jun 5, 2012 at 10:41 AM, Doug Hellmann > > > > <[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>> > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>> wrote: > > > > On Tue, Jun 5, 2012 at 9:56 AM, Nick Barcet > > > > <[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>> 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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
