Timestamp in WS-Security to mitigate replay attacks

How replay attacks can be harmful:
When sensitive information is exchanged or critical transactions are performed over the network, we need to secure the communication.

General requirements of secure message communication are authentication, integrity, confidentiality and non-repudiation.

One can achieve above requirements through transport level security or message level security mechanisms such as security tokens, signature and encryption. 

Even though you adopt above mechanisms alone, to secure a message, one can intercept a secured message on the wire and resend the message repeatedly to the same endpoint and cause damages - unless there is a mechanism to verify the validity/originality of the message.

For an example:
- user logs into online banking and performs a transaction.
- an attacker traces the messages exchanged during the process.
- attacker resends the sequence of messages involved with login step, to login and steal money from the bank account.

Timestamp in WS-Security:

Therefore, it is important to validate the freshness of a message before performing any operation that the message invokes. This validation can be performed either in the business logic or security processing layer of the platform in a generic manner.

If your soap message processing engine supports WS-Security to achieve message level security; Timestamp element defined there helps verifying the message validity in terms of time.

(WS-Security is a spec that defines a framework to enable security related information -as specified by mechanisms such as XML security, XML signature etc- be embedded in the SOAP message.)

Timestamp element allows the sender to express the creation and expiration times of the security semantics of the message - using which recipient can validate the freshness of the security semantics of the message to mitigate replay attacks.

Following is the schema of Timestamp element.

 ...
 ...
 ...

Few points to be noted are:

• Time references must be in UTC time.
• Time references are recommended to be in xsd:dateTime format, if in any other format is used, it should be specified in ValueType attribute.
• Spec doesn't mention any mechanism for synchronizing the time between sender and recipient - but specifies that this should be addressed.
• Timestamp element should be signed in order to prevent it being forged.
• Another sub element that may present in Timestamp element is "wsu:received"  which can be included by an intermediary.
• Only one global timestamp element can be present in one security header.

Following is an actual Timestamp element extracted from a secured message:

     2011-09-24T12:11:41.331Z
     2011-09-24T12:16:41.331Z

Above what we discussed is the theory part related to Timestamp as defined in the spec. Now lets see how it is being utilized and processed in an actual implementation - by referring to Rampart and WSS4J.
 

Rampart & WSS4J:

Rampart is the Axis2 module which introduces security processing handlers to inflow and out flow of the Axis2 SOAP processing engine. Rampart internally utilizes WSS4J which implements the support for WS-Security.

Following are the rampart configuration parameters which allows user to configure and control Timestamp handling in Rampart and WSS4J. (Applies to Rampart 1.6.2 or above)

      ...
      true
      
      300
      300
      false
      ...

• timestampprecisioninmilliseconds : whether the precession of timestamp reference is in milliseconds. This is a configuration parameter passed to WSS4J, when creating WSSConfig.

• timestampttl : Validity period of the message as decided by the sender of the message. This is used in Rampart level to calculate "expires" time reference. Default value is 300 seconds. 

• timestampmaxskew : Specifies the maximum tolerance limit for the clock skew between sender and recipient. As specified by WS-Security spec, it should be taken into consideration that renders and recipients clocks may not be in synchronized and proper measures should be taken to avoid it. This is a rampart level config parameter and the default value is 300 seconds.

• timestampstrict :  This instructs rampart whether to enable timestamp validation at WSS4J level or not. By default - this is set to false. i.e: Timestamp validation happens in PolicyBasedResultsValidator of Rampart.

How Timestamp is created:
RampartSender is the handler introduced by Rampart for security processing of the out flow of Axis2.

In the process of securing the outgoing message according to the defined security policy, BindingBuilder adds Timestamp element to the security header.

Following is how 'created' and 'expires' time references of Timestamp are derived:

• created = current time
• expires = created(in millis) + timestampttl*1000

How Timestamp is validated:

RampartReceiver is the handler introduced by Rampart for security processing of the inflow of Axis2.

In the process of validating the security of the incoming message, both WSSecurityEngine(in WSS4J) and PolicyBasedResultsValidator(in Rampart) validates Timestamp in the security header.

WSS4J only checks whether the 'expires' time reference is before the current time of the receiver, to validate timestamp.

Rampart - on the other hand verifies timestamp taking timestampmaxskew also into consideration and validates against both 'created' and 'expires' time references.

Timestamp is invalid if:

• current time < [created - (timestampmaxskew*1000)]  (in millis)
• current time > [created + (timestampmaxskew*1000)] (in millis)

Because of the consistent way timestamp is verified in Rampart level considering both created and expired, the validation at the WSS4J is disabled by default with timestampstrict set to false - which was introduced with the fix for the issue RAMPART-357.

Other ways to avoid replay attacks:

According to the above logic of validating Timestamp, it is considered valid during the time period:
from (created - timestampskew) to (expires + timestampskew)
- which means replay attacks made during that period is not detected if any other mechanism is not adopted to detect and avoid replay attacks.

Some other mechanisms to avoid replay attacks are:
1. Using session keys.
2. Using one time passwords.
3. Using nonce value.

References:

• Understanding WS-Security http://msdn.microsoft.com/en-us/library/ms977327.aspx