Bad request: Local clock incorrect?

Why do I see messages like this:

"Bad Request: Your browser sent a request that this server could not understand.
Authentication error, status = 600, WLS response issued in the future
(local clock incorrect?); issue time 20070830T070016Z

It's like this. If your server doesn't use HTTPS then Ucam-WebAuth authentication response messages can be snooped off the network and replayed by an attacker to pretend to be you. To help guard against this, the protocol applies a timeout when processing response messages. In many implementations, including mod_ucam_webauth, their default configuration makes this timeout very tight - mod_ucam_webauth expects to process them no less than zero and no more then 20 seconds after they were issued. This really only works if the Raven servers and the machine running mod_ucam_webauth are successfully using something like NTP to synchronise their clocks. The Raven servers do use NTP, so if you are seeing this message perhaps yous isn't or NTP is having trouble keeping your clock right.

Even if your web server is using NTP your clock may not always be sufficiently accurate. There can be various reasons for this, but most come down to the NTP configuration. We have observed that Macs often suffer from this problem, and suspect that the default Mac NTP configuration may be such that sub-second accuracy is not normally achieved.

You can compensate for this using mod_ucam_webauth's AAClockSkew and AAResponseTimeout configuration directives. The acceptance window is from -ClockSkew to ResponseTimeout+ClockSkey seconds, so you should set AAClockSkew to the maximum expected inaccuracy in your clock - in many cases one or two seconds will be sufficient.

The catch with setting ClockSkew large is that you widen the window of opportunity for replay of response messages, thus weakening the security of your server. Your call how far you take this, but clearly a few seconds is no big deal. Best advice is to ensure that your clock is kept as accurate as possible, preferably with NTP, and then to adjust ClockSkew to be slightly larger than the maximum possible error. Remember that this will rot over time if your clock drifts further.