[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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] 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. 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]
Issue i132 From: Aditya Athalye [mailto: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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]