[ws-sx] : NEW Issue: Absence of a Confirmation to Nonce

[Aditya Athalye <aditya.athalye@oracle.com>]

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