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