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 / ws-sp usecases example draft
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/23821/ws-securitypolicy-1.2-spec-cs.pdf
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/24008/ws-sp-usecases-examples-draft-14-02.doc
Artifact: spec / schema / use cases doc
Type:
design
Title:
Support for more stringent security implementation in WS-SP as per requirements in WS-SP Usecases document
Description:
WS-SP Use cases
doc states
Lines <968-969>
"Line (M046) contains the Nonce
element and Line (M047)
contains a timestamp. These two elements should also be included in the
PasswordText case for better security"
The UsernameToken assertion in
Security Policy supports only <NoPassword>, and
<HashPassowrd> assertion.
UseCase:
According to the use case
document, Nonce, and Creation timestamp should be sent even for plain
text passwords for better security which is a very valid requirement
IMO. However, present security policy, and the schema(?) supports only
HashPassword, which can indicate to the requestor, the provider's
requirement for sending Password Digest, Nonce, and Created.
If <HashPassword> is not
present (assuming it is not <NoPassword>), it tells the
requestor, that only Username, and clear text Password is mandatory.
This no way indicates that the service may need a Nonce as well.
So what it essentially means is
that, service provider is actually offering a choice to the requestor:
1.) Send a plaintext password
without Nonce/Created. (Less secure) - Acceptable to service
2.) Send a plaintext password WITH Nonce/Created. (More Secure) - - Acceptable to service
Obviously any requestor will
take the less secure route to access to service.
What should have happened is:
Service provider unambiguously declaring its intention to check for
Nonce/Created irrespective of PasswordType, and rejecting any messages
which then do not conform to its policy. This leaves the requestor with
only the more secure route to take.
Related Issues:
None.
Proposed Resolution:
I propose that for
service provider to indicate its requirement for these elements, the TC
should consider adding assertions like
<sp:NonceAssertion>, and <sp:CreatedAssertion>. The policy
would look something like:
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:CreatedAssertion/>
<sp:NonceAssertion/>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
The WS-SecurityPolicy
schema should also be updated for the same.
Thanks
Aditya Athalye