Open Stack

On 25/04/2013 14:51, Simo Sorce 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.

I think you should differentiate between the code that implements 
different algorithms, and the mechanism that is used to choose between 
algorithms. The initial implementation should not be hard coded with any 
specific algorithm, but should have the mechanism for choosing between 
algorithms built into it from the start, even if the initial 
implementation only supports one algorithm. It then becomes relatively 
straight forward to plug in new algorithms.

regards

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