Open Stack

Please see below:

On Thu, Apr 25, 2013 at 9: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.

Fair enough!

>> 2. Do we need some terminator between MetaData and Message during -
>> "Signature = HMAC(SignKey, (Version || MetaData || Message))"?
>
> No.

Cool. Was trying to figure out how the verification steps would work,
guess they concat the same way the original signing did. What threw me
off was the null terminated Version

>> 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.

Yes, that's the same in xml-dsig, DigestValue is the MAC there as well.

>> 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.

Dropping the counter/nonce for the first cut sounds good to me.

>> 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.

ISO8601 here is not for human consumption. In my environment, we make
sure all components are synced using NTPD and we like adding code to
reject messages outside of a time window.

>> 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



-- 
Davanum Srinivas :: http://davanum.wordpress.com