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: Re: [wss] Issue: replay attacks & timestamp


What if the SOAP role is one of the values defined in the spec?


I don't see how this proposal prevents a replay attack on a different 
These roles, and likely others to be defined, are abstract roles, not 

If the signature were signed over an endpointReference such as defined in
the WS-Addressing spec[1], (e.g. <wsa:To/>) then you might have something
that would ensure that a message could not be replayed (or even processed)
by an unintended recipient.

[1] http://www-106.ibm.com/developerworks/webservices/library/ws-add/


Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

"De Boer, Martijn" <martijn.de.boer@sap.com> wrote on 06/13/2003 02:24:51 

> 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 
> 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
> You may leave a Technical Committee at any time by visiting 
> org/apps/org/workgroup/wss/members/leave_workgroup.php

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