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

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

Agreed on the point of one-way hash. However, to me there is no (should not be) restriction on usage of Nonce for a certain type of password only.
We have supported use-cases in our impl which accommodates a Nonce even for a clear text password. This may not seem very intuitive from the perspective of the specification, but a Nonce is IMO solely meant for replay detection, and should be usable even for plaintext password.
The fact that it is a part of a hashed password, is only increasing its utility for digested passwords.

The spec nowhere takes care of the scenario wherein a client is also interested in detecting replays (for UNToken case), hence the proposal.

However, I agree this TC is not the best place to post this issue, but I guess WSS TC is closed, hence this TC was the best possible shot :-)

T&R
Aditya

Hal Lockhart wrote:

This is not an issue. Although the document is not clear on this point, the Nonce is only intended to be used with a Password Digest. The one-way properties of the hash function provide a means to verify the Nonce.

 

Hal

 

---

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Tuesday, May 08, 2007 1:32 PM
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