Controlling for Clock Skew
Message replay is an attack where a message is presented to a processor more than once in the hopes of fooling the processor into taking some action. One protection against message replay and other timing-based attacks is to have the sender timestamp messages. Security timestamps are only valid for a limited window of time, typically represented by a creation time and an expiration time. The processor may declare that messages have a limited lifetime, which can be checked by using the security timestamp.
For such a scheme to work though, the sender and receiver have to agree on what time means. Since the two sides don't share a common clock, they need to each have a clock and those clocks need to agree on the current time to a certain precision. It's impossible to make two clocks exactly agree and there's some threshold after which you have to assume that the clocks are measuring two different times. The difference between the clocks is called the skew and the threshold is called the maximum allowed clock skew.
When checking creation and expiration times, the maximum clock skew becomes a factor because it determines whether two times might be the same. Here are the interesting checks for a security timestamp.
- If the creation time is after the local time plus the maximum clock skew, then the creation date is actually in the future.
If the expiration time is before the local time minus the maximum clock skew, then the expiration date is actually in the past.
- If the creation time is before the local time minus the maximum clock skew and minus the message lifetime, then the message is too old and may be part of a replay attack.
This clock skew is a configurable setting on the SecurityBindingElement through the local client settings or local service settings. Changing that value changes the tolerance for comparing times. Since the default is several minutes, you don't normally need to worry about this unless your computer clock is quite unreliable.
Next time: Serialization and Types