[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ws-sx] : Issue i132: Absence of a Confirmation to Nonce
+1 From: Jan Alexander [mailto:janalex@microsoft.com] 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: 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
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]