Open Stack

As for utilizing a key manager, we had a couple sessions about that at the
summit, including:


http://openstacksummitapril2013.sched.org/event/886118ad75e16dae1da91d9ca9866ca7#.UXlOASuDQ1I

On Thu, Apr 25, 2013 at 8:51 AM, Simo Sorce <simo at redhat.com> wrote:

> On Thu, 2013-04-25 at 09:20 -0400, Davanum Srinivas wrote:
> > Simo,
> >
> > Nice! feedback after a quick browse and compare with xml-dsig
> >
> > 1. Can we please allow additional algorithms? (see DigestMethod in
> > [1]). HMAC-SHA-256 can definitely be the default
>
> Well as a principle I like keeping security code *simple* and well
> defined, at least for an initial implementation. We might add additional
> metadata in the future to specify different algorithms, but I would see
> that as an additional feature to allow in the future.
>
> > 2. Do we need some terminator between MetaData and Message during -
> > "Signature = HMAC(SignKey, (Version || MetaData || Message))"?
>
> No.
>
> > 3. Assuming that _SIGNATURE_KEY maps to DigestValue in [1] right?
>
> No, XML signatures are a mess, we are not doing anything like that, we
> just use version as a string, and message and metadata are also srings
> (JSON dumps). So _SIGNATURE_KEY is literally a MAC on a blob of data
> composed of 3 concatenated strings.
>
> > 4. I am assuming the counter is to prevent replay attacks. can we
> > please use a nonce instead?
>
> Yes replay attacks.
> What is the advantage of a nonce ?
>
> The counter can be used to make sure older messages are simply discarded
> w/o the need to keep track of them. The 2 advantages are:
> a) no need to save all the messages (or at least the nonces) seen during
> the validity interval of the keys, you just need to store a counter.
> b) allows to have some protection against replay attacks also when
> multiple targets are allowed to use the same key. For example sending
> message signed with the 'common' scheduler.* key. With nonces the only
> way to do any replay attack detection would be to have a shared cache
> between all schedulers. With a counter at least you can automatically
> discard any 'old' value if any specific scheduler have already seen a
> newer counter even if no shared database exists.
>
> I do not actually like either the counter or the nonce approach, and we
> technically do not require either. We could just use the timestamp, so I
> may end up proposing we drop the counter completely.
>
> > 5. Can we please use ISO 8601 timestamps instead of unixtime?
>
> At the moment I am experimenting with python time.time() values that
> have sub-second resolution. ISO8601 timestamp do not really make sense
> here, This timestamp is not for human consumption, and having to parse
> it back and forth is unnecessary. Also ISO 8601 does not have sub-second
> resolution, while we may want to use it so that we can also drop the
> counter as the chance of 2 message being sent to the same target to end
> up with the same timestamp are low, and we can make it 0 by simply
> keeping around the old timestamp and increasing it by 1 if the new one
> matches exactly.
>

ISO 8601 supports subsecond resolution; we use it in keystone and pushed
support back to oslo's timeutils during grizzly.

http://www.w3.org/TR/NOTE-datetime


>
> > I'll take a deeper look at the encryption later when i get a chance.
>
> Thanks for the feedback so far, you raised excellent points!
>
> Simo.
>
> > thanks,
> > dims
> >
> > [1] http://www.w3.org/TR/xmldsig-core/
> >
> > On Thu, Apr 25, 2013 at 8:37 AM, Simo Sorce <simo at redhat.com> wrote:
> > > Hello list,
> > > at the Summit we had a very interesting and productive discussion about
> > > Message Signing/Encryption for RPC Messages sent via the Message Queue.
> > >
> > > I would like to present a proposal that uses symmetric keys and a
> > > central key server to address the problem:
> > >
> > > https://wiki.openstack.org/wiki/MessageSecurity
> > >
> > > I would really like to get feedback on the proposal, especially if
> there
> > > are corner cases I have not considered.
> > >
> > > Simo.
> > >
> > > --
> > > Simo Sorce * Red Hat, Inc * New York
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
>
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130425/747a690a/attachment.html>