[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
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]