Page Comparison

The following sections describe replay attacks and expand on how timestamps can be used to mitigate these attacks in WS-Security.

How replay attacks can be harmful?

...

<wsu:timestamp wsu:id="...">  
	<wsu:created valuetype="...">...</wsu:created>  
	<wsu:expires valuetype="...">...</wsu:expires>  
	...  
</wsu:timestamp>

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.
• The specification does not mention any mechanism for synchronizing the time between the sender and recipient. However, it specifies that this should be addressed.
• The Timestamp element should be signed in order to prevent it being forged.
• Another sub-element that may present in Timestamp element is wsu:received that can be included by an intermediary.
• Only one global timestamp element can be present in one security header.

The following is an actual Timestamp element extracted from a secured message.

<wsu:timestamp wsu:id="Timestamp-1" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">  
     <wsu:created>2011-09-24T12:11:41.331Z</wsu:created>  
     <wsu:expires>2011-09-24T12:16:41.331Z</wsu:expires>  
</wsu:timestamp>

The sections in this topic are related to Timestamp as defined in the specification. The following sections discuss how it is being utilized and processed in an actual implementation by referring to Rampart and WSS4J.

Rampart and WSS4J

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

The following are the rampart configuration parameters that allows you to configure and control Timestamp handling in Rampart and WSS4J (applies to Rampart 1.6.2 or above).

<rampart:rampartconfig xmlns:rampart="http://ws.apache.org/rampart/policy">  
      ...  
      <rampart:timestampprecisioninmilliseconds>true  
      </rampart:timestampprecisioninmilliseconds>  
      <rampart:timestampttl>300</rampart:timestampttl>  
      <rampart:timestampmaxskew>300</rampart:timestampmaxskew>  
      <rampart:timestampstrict>false</rampart:timestampstrict>  
      ...  
</rampart:rampartconfig>

• timestampprecisioninmilliseconds: This decides whether the precision of the timestamp reference is in milliseconds. This is a configuration parameter passed to WSS4J, when creating WSSConfig.
• timestampttl: This is the validity period of the message as decided by the sender of the message. This is used in Rampart level to calculate the "expires" time reference. Default value is 300 seconds.
• timestampmaxskew: Specifies the maximum tolerance limit for the clock skewed between the sender and recipient. As specified by the WS-Security specification, it should be taken into consideration that the sender and recipient may not have synchronized clocks and proper measures should be taken to avoid it. This is a rampart level configuration parameter and the default value is 300 seconds.
• timestampstrict: This instructs rampart whether to enable timestamp validation at WSS4J level or not. This is set to false by default. Timestamp validation happens in PolicyBasedResultsValidator of Rampart.

How Timestamp is created

RampartSender is the handler introduced by Rampart for security processing of the outflow of Axis2. In the process of securing the outgoing message according to the defined security policy, BindingBuilder adds the Timestamp element to the security header.

The 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 verifies the 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 expires, the validation at the WSS4J is disabled by default with timestampstrict set to false.

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)

This means replay attacks made during that period are not detected if any other mechanism is not adopted to detect and avoid replay attacks. Some other mechanisms to avoid replay attacks are:

• Using session keys
• Using one time passwords
• Using nonce value