Because this is an issue against WSS Username Token Profile, it
is out of scope of this TC. Therefore, I propose that we close this issue we no
action.
Thanks,
--Jan
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Tuesday, May 08, 2007 10:32 AM
To: Aditya Athalye; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] : Issue i132: Absence of a Confirmation to Nonce
Issue i132
From: Aditya Athalye
[mailto:aditya.athalye@oracle.com]
Sent: Thursday, May 03, 2007 12:45 AM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: [ws-sx] : NEW Issue: Absence of a Confirmation to Nonce
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
The issues coordinators will notify the list when that has occurred.
Protocol: ws-sc / ws-sp
http://docs.oasis-open.org/wss/v1.1/wss-v1.1-os-UsernameTokenProfile
Artifact: spec / schema /
Type:
design
Title:
Absence of a Confirmation to Nonce
Description:
Presuming that this is the right forum to post this suggestion.
The UsernameTokenProfile 1.1 talks about usage of <Nonce>, the semantics of which are as follows:
<wsse:UsernameToken wsu:Id="ID">
<wsse:Username> ... </wsse:Username>
<wsse:Password Type="..."> ... </wsse:Password>
<wsse:Nonce EncodingType="..."> ... </wsse:Nonce>
<wsu:Created> ... </wsu:Created>
</wsse:UsernameToken>
The <Nonce> here includes a random token generated by a requestor while accessing a service.
The spec says that this should be generated fresh, for service providers to detect relay attacks.
However, there is nothing which guarantees the requestor, that the response generated from the service
was actually for the Nonce sent by the requestor. What I mean is that, it is possible to substitute a different random value
of Nonce in transit(especially in case of plaintext password), and the service provider would not be able to
detect this. (Of course signing the token will integrity protect it).
Related Issues:
None.
Proposed Resolution:
There should be something like a <NonceConfirmation> which should be sent in the response from the service to the requestor.
It should have a @Value = <value of request Nonce>. This would ensure that the response was generated for the value of the
Nonce sent in the request. If this validation fails on the requestor side, the response can be rejected, and can help
requestors also detect replays. The semantics of this element can be on the lines of <wsse11:SignatureConfirmation>.
Thanks
Aditya Athalye