Re: [http-state] [apps-discuss] HTTP MAC Authentication Scheme

[Nico Williams <[e-mail]>]

On Fri, May 20, 2011 at 4:18 PM, Eran Hammer-Lahav <[e-mail]> wrote:
>> Additional comments:
>>
>>  - Using nonces for replay protection is heavy-duty.  It is difficult to
>> implement a reliable, secure, high-performance replay cache.  (It is easy to
>> implement just a high-performance replay cache: use
>> memcache.)
>>
>>    I recommend an option to use sequence numbers at the server's choice,
>> understanding, of course, that requests will not be received in sequence.
>> The use of a sliding sequence number window makes it possible to do at
>> least as well as when using nonce, and probably faster while still being
>> secure.
>
> We switched to use time since credentials were issued. This should be pretty easy to implement if you really need reply protection by using a small window (clock sync is no longer a problem, just the delay in getting the credentials to the client, which should be a small window).

Kerberos has had an option to use time or sequence numbers for a long
time.  We've learned a few things from this experience.

For a memcache-type implementation, timestamps are probably best
because maintaining a sequence number window in memcache,
synchronized, would be a pain, if not impossible.

Other replay cache implementations would likely do better using
sequence numbers, especially when they have a small sequence number
window per-session.

And, of course, memcache isn't going to be durable (but probably it
will be good enough in many cases).  If you set a skew window to be
tight on the future side, then you can compensate for this if you can
detect loss of replay data (hmmm, not likely with memcache, eh?).

One big gotcha to be aware of:

 - Some clocks have lousy resolution, leading to easily repeated
values in high-rate environments.  One fix is to add resolution on the
wire and use random numbers for the unused precision bits.  Another
solution is to not use time.

My advice is that you allow the server to select which of timestamps
or sequence numbers to use.

Also, I strongly recommend that you specify replay cache semantics in
some detail.  Think of the Kerberos V5 replay cache semantics.

>>  - In an open wifi environment active attacks may not be very difficult, thus
>> an option to secure more than just a handful of bits from the request, would
>> be nice (all of the request and all of the response, say).  The hard part is how
>> to decide when to use one or the other.  Ideally browsers can request more
>> protection when the network is reconfigured such that there's one or more
>> clear wifi interfaces.
>
> There is just no easy way to do that. If you need more, use TLS.

But even then you need to know when to use TLS.  TLS doesn't solve the
problem when you're trying to solve problems without introducing TLS
in the first place.  This is a serious problem.  You think you're
fixing one problem (cookie theft by passive attackers on open
networks) and you're very likely only making things somewhat harder
for the attacker -- we need to be very careful that the attacker can't
just automate active attacks and still win.

Nico
--