RE: [wss] Issue: replay attacks & timestamp

["De Boer, Martijn" <martijn.de.boer@sap.com>]

Hi Christopher,

the intention was to add a URI for an receiver as a unique identifier describing the receiver; when accepting a signature, a recipient should also check to whom the signature was addressed. 

Using a SOAP role will not work when defined roles as ultimateReceiver etc. are being used; is this case WS-Addressing might be a better and more general alternative. This would require to support multiple <wsa:To/> elements in the header (or as children of the Security-header). What are the plans for standardizing WS Addressing?

Regards,
Martijn

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Freitag, 13. Juni 2003 13:08
To: wss@lists.oasis-open.org
Subject: Re: [wss] Issue: replay attacks & timestamp


Martijn,

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

e.g.
        http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver
        http://www.w3.org/2003/05/soap-envelope/role/next

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

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/

Cheers,

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 
AM:

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


You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php