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, it becomes necessary to secure the communication. General requirements of secure message communication are authentication, integrity, confidentiality and non-repudiation. These requirements can be achieved through transport level security or message level security mechanisms such as security tokens, signature and encryption. Even though you adopt these mechanisms to secure a message, a secure message can be intercepted on the wire and the message can be resent repeatedly to the same endpoint and cause severe damage, unless there is a mechanism to verify the validity/originality of the message.

For an example:

• A user logs into an online banking application and performs a transaction.
• An attacker traces the messages exchanged during the process.
• The attacker resends the sequence of messages involved with a login step, to login and steal money from the bank account.

Timestamp in WS-Security

Due to replay attacks, 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; the Timestamp element defined there helps verifying the message validity in terms of time.

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

The following is the schema of Timestamp element.

<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).