Open Stack

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.

> 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