[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]