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

Unless the Nonce is used as a part of hash or put under a signature, there is nothing to prevent its modification in transit.

IMO the use of a nonce is only practical when accompanied with a timestamp (also integrity protected.) Otherwise, it is necessary for the receiver to retain every nonce value it has ever received forever and continually check this ever growing list against every newly received value.

Your proposal brings to mind a very real risk associated inherent in the nature of WS-Security as a toolkit of security mechanisms. While the mechanisms of WS-Security can be utilized to provide useful security properties, they can also be combined in many ways which contain obvious or subtle weakness. In your case you immediately recognized the issue and proposed a remedy.

However In the more general case I would advise users of the WS-Security specifications to either stick with well understood scenarios, such as those used in the several interoperability tests at OASIS and WS-I or documented in the WS-SX Security Policy Usecases or to publish their proposed scheme widely so there is some chance that it will be thoroughly vetted.

It is easy for the most knowledgeable person to overlook flaws in any protection scheme. During the time that WS-Security 1.0 and 1.1 and BSP 1.0 and 1.1 were being developed we uncovered many unexpected weaknesses in plausible scenarios. These have been documented in the Security Considerations sections of these documents, but I am by no means convinced that we have found them all.

Hal

From: Aditya Athalye [mailto:aditya.athalye@oracle.com]
Sent: Monday, May 21, 2007 1:40 AM
To: Hal Lockhart
Cc: ws-sx@lists.oasis-open.org
Subject: Re: [ws-sx] : Issue i132: Absence of a Confirmation to Nonce

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

ws-sx message