OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue: replay attacks & timestamp


On the F2F I took the action to take a closer look at signatures, timestamps and replay attacks.
After we have moved the Timestamp element down to the Security header element, this timestamp is to be taken for the expiration of the security header.

In the core specification, section 13 "Security Considerations" it is suggested to use timestamps, sequence Numbers, Expirations, Message Correlations and unique nonces to protect against replay attacks.

Now let's assume the following scenario: A client creates a SOAP message and signs the body; the signature over the body is semantically interpreted by the server as an authentication. To prevent replays, the following elements may be added to the signature:

1)	Timestamps & Expirations

	Timestamps may be added to the wsse:Security header to indicate the freshness of the message, and it is up to the server to reject the message after a certain time; or - when the client specifies an expiration time - the message should not be processed by the server after the expiration time. However, within the expiration time a message may still be replayed to a different server.


2)	Nonces 

	Nonces may be added to make the signature unique - and the server should not accept a signature with the same nonce form the same recipient twice; However, a message may still be replayed to a different server.

3)	Sequence Numbers

	Similar to nonces, a message can still be replayed to a different server

4)	Message Correlations

	For the first request, message correlations cannot yet be applied, and thus offer no additional protection for replay attacks.

Proposal
=======

In order to prevent replay attacks, the following is proposed:

		*	The signature adds an (optional) reference to the SOAP Role. As XML DSIG does not allow for signing attributes, an element specifying the SOAP Role is added. 
		*	The processing rules are changed to reflect this change:

				If the signature references a different SOAP Role, the validation of the signature shall fail.

Regards,

Martijn de Boer



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]