<div dir="ltr"><div style>As for utilizing a key manager, we had a couple sessions about that at the summit, including:</div><div style><br></div><div style>  <a href="http://openstacksummitapril2013.sched.org/event/886118ad75e16dae1da91d9ca9866ca7#.UXlOASuDQ1I">http://openstacksummitapril2013.sched.org/event/886118ad75e16dae1da91d9ca9866ca7#.UXlOASuDQ1I</a></div>
<br><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 25, 2013 at 8:51 AM, Simo Sorce <span dir="ltr"><<a href="mailto:simo@redhat.com" target="_blank">simo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Thu, 2013-04-25 at 09:20 -0400, Davanum Srinivas wrote:<br>
> Simo,<br>
><br>
> Nice! feedback after a quick browse and compare with xml-dsig<br>
><br>
> 1. Can we please allow additional algorithms? (see DigestMethod in<br>
> [1]). HMAC-SHA-256 can definitely be the default<br>
<br>
</div>Well as a principle I like keeping security code *simple* and well<br>
defined, at least for an initial implementation. We might add additional<br>
metadata in the future to specify different algorithms, but I would see<br>
that as an additional feature to allow in the future.<br>
<div class="im"><br>
> 2. Do we need some terminator between MetaData and Message during -<br>
> "Signature = HMAC(SignKey, (Version || MetaData || Message))"?<br>
<br>
</div>No.<br>
<div class="im"><br>
> 3. Assuming that _SIGNATURE_KEY maps to DigestValue in [1] right?<br>
<br>
</div>No, XML signatures are a mess, we are not doing anything like that, we<br>
just use version as a string, and message and metadata are also srings<br>
(JSON dumps). So _SIGNATURE_KEY is literally a MAC on a blob of data<br>
composed of 3 concatenated strings.<br>
<div class="im"><br>
> 4. I am assuming the counter is to prevent replay attacks. can we<br>
> please use a nonce instead?<br>
<br>
</div>Yes replay attacks.<br>
What is the advantage of a nonce ?<br>
<br>
The counter can be used to make sure older messages are simply discarded<br>
w/o the need to keep track of them. The 2 advantages are:<br>
a) no need to save all the messages (or at least the nonces) seen during<br>
the validity interval of the keys, you just need to store a counter.<br>
b) allows to have some protection against replay attacks also when<br>
multiple targets are allowed to use the same key. For example sending<br>
message signed with the 'common' scheduler.* key. With nonces the only<br>
way to do any replay attack detection would be to have a shared cache<br>
between all schedulers. With a counter at least you can automatically<br>
discard any 'old' value if any specific scheduler have already seen a<br>
newer counter even if no shared database exists.<br>
<br>
I do not actually like either the counter or the nonce approach, and we<br>
technically do not require either. We could just use the timestamp, so I<br>
may end up proposing we drop the counter completely.<br>
<div class="im"><br>
> 5. Can we please use ISO 8601 timestamps instead of unixtime?<br>
<br>
</div>At the moment I am experimenting with python time.time() values that<br>
have sub-second resolution. ISO8601 timestamp do not really make sense<br>
here, This timestamp is not for human consumption, and having to parse<br>
it back and forth is unnecessary. Also ISO 8601 does not have sub-second<br>
resolution, while we may want to use it so that we can also drop the<br>
counter as the chance of 2 message being sent to the same target to end<br>
up with the same timestamp are low, and we can make it 0 by simply<br>
keeping around the old timestamp and increasing it by 1 if the new one<br>
matches exactly.<br></blockquote><div><br></div><div style>ISO 8601 supports subsecond resolution; we use it in keystone and pushed support back to oslo's timeutils during grizzly.</div><div style><br></div><div style>
<a href="http://www.w3.org/TR/NOTE-datetime">http://www.w3.org/TR/NOTE-datetime</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im"><br>
> I'll take a deeper look at the encryption later when i get a chance.<br>
<br>
</div>Thanks for the feedback so far, you raised excellent points!<br>
<span class=""><font color="#888888"><br>
Simo.<br>
</font></span><div class=""><div class="h5"><br>
> thanks,<br>
> dims<br>
><br>
> [1] <a href="http://www.w3.org/TR/xmldsig-core/" target="_blank">http://www.w3.org/TR/xmldsig-core/</a><br>
><br>
> On Thu, Apr 25, 2013 at 8:37 AM, Simo Sorce <<a href="mailto:simo@redhat.com">simo@redhat.com</a>> wrote:<br>
> > Hello list,<br>
> > at the Summit we had a very interesting and productive discussion about<br>
> > Message Signing/Encryption for RPC Messages sent via the Message Queue.<br>
> ><br>
> > I would like to present a proposal that uses symmetric keys and a<br>
> > central key server to address the problem:<br>
> ><br>
> > <a href="https://wiki.openstack.org/wiki/MessageSecurity" target="_blank">https://wiki.openstack.org/wiki/MessageSecurity</a><br>
> ><br>
> > I would really like to get feedback on the proposal, especially if there<br>
> > are corner cases I have not considered.<br>
> ><br>
> > Simo.<br>
> ><br>
> > --<br>
> > Simo Sorce * Red Hat, Inc * New York<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
<br>
<br>
--<br>
Simo Sorce * Red Hat, Inc * New York<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>