Open Stack

GET requests can be multiple, idempotent.
Your nonce would help to prevent DOS type attacks, stemming from rapid fire re-requests.
Typically POST requests will alert the user in WEB-UIs at least "do you really want to re-submit" .. such as ordering withdrawing another chunk from the same account!
If you have multiple servers in an HA cluster, they could have separate nonce generators, very unlikely that the same request will come from two separate servers with the same nonce and as you say, it is safe, the request will be re-submitted if genuine. I am guessing this why you concluded that you do not need any locking and global counter etc.

Regards
Malini

-----Original Message-----
From: Simo Sorce [mailto:simo at redhat.com] 
Sent: Thursday, April 25, 2013 2:57 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova][keystone] Message Queue Security

On Thu, 2013-04-25 at 17:26 -0400, Eric Windisch wrote:
> >  
> > 2. A random number can repeat but it is very unlikely that will 
> > happen if you have a good random generator that has uniform distribution.
> >  
> > I think you mean 2, because the chance we get out of the hat 2 
> > identical numbers chosen at random within the same hundredth of a 
> > second on the same machine if the numbers are big enough, say 2^64, 
> > are very, very low, so we might decide to ignore that it may happen.
> >  
> > However, how bad is it is it *does* happen ?
> I mean the latter and I believe this is sufficient. I believe worst 
> case is that a message is rejected by the endpoint as a potential 
> replay. In theory, we should be pretty resistant to lost messages, 
> especially at the very low rate of occurrence we'd expect it.

Well actually thinking about it the chance are infinitesimally smaller than I previously thought because if we are going to use the signature to check for replays not only the timestamp and nonce must match, but the message being sent must be a repeat and exactly identical to othe previous.

Honestly unless there are condition where it is legit to resend the exact same message multiple times we should probably just forget about the nonce, which is why I didn't care for it in the first place.
However base don my last formulation we have a good way to avoid interprocess locking too.

So given a few people requested it, and to account for the weirdest possible use of messages where a service decides to send 2 identical messages in rapid succession I will leave the nonce in.

> I gag any time we mention interprocess locking, global counters, or 
> state. I recognize might need to compromise here, especially in regard 
> to multiple services on a remote machine receiving the same message, 
> although I'd be careful about how we implement that.  The 
> implementation details will be vastly different for AMQP, versus 
> ZeroMQ.

I am not sure this difference will matter from the signing point of view.

> For instance, the ZeroMQ driver could do first-pass replay detection 
> in the ZmqProxy, which is a machine-global process. We'd still want to 
> verify signatures in the consuming services, but as all messages pass 
> through the ZmqProxy, it can outright reject duplicates. (This won't 
> stop someone from killing the ZmqProxy and doing a MITM to allow 
> replays - not but outright injection - but if that happens, the server 
> is likely compromised already…)

Are you going to check the signature in ZmqProxy ?

> The AMQP drivers won't be able to filter their replays centrally on 
> the host unless it added a per-host consumer and local distribution 
> pattern like we use in ZeroMQ. Without that, we'd need a local 
> datastore with all the locking issues that brings with it.

I am not sure I am following you here ...

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