When using Message level security with UserName credential in some WCF bindings, you might get into a situation where you start getting Message Authentication Failure(See my earlier post for more details) .
The reason for this is due to the fact that WCF frameworks implementation of WS-Security by default enables Message Replay Detection. 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.
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. The default clock skew value is 00:05:00.
Keep in mind that this message timestamp value is checked both ways i.e. from the client to the Service(checked at the service side) AND from the Service to the client (check on the client side).
There are two solutions to this:
- Make sure both the server and client clocks are synced with a standard time server. This approach may not be applicable when you don’t have control over the server or the client machines.
- Change the default values from the Service configuration by defining a custom binding. An example as as below.
<binding name="CustomDevWSHttpBinding"> <security authenticationMode=“UserNameOverTransport“ requireSecurityContextCancellation=“true“> <localservicesettings maxClockSkew=“00:10:00“ /> <localclientsettings maxClockSkew=“00:10:00“ /> <secureconversationbootstrap /> </security> <textmessageencoding /> <httpstransport /> </binding>
Note: For some reason, when I generate the client proxy’s configuration using SvcUtil, the clients ClockSkew value still default to 00:05:00 but you can manually change that to a suitable value.
Recently came to find out that the settings I mentioned above are going to be local to the service and the domain it operates in, hence the ClockSkew can be set on the service side to a suiable value or to turn it off set the maxClockSkew=“Infinite“.However the generated Client configuration will always default to 5 mins and will have to be changed manually if required.
