From: Aditya Athalye
Sent: Thursday, June 07, 2007 1:23 AM
Cc: Marc Goodner
Subject: [ws-sx] New Issue: Support for more stringent security
implementation in WS-SP
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
Artifact: spec / schema / use cases doc
Support for more stringent security implementation in WS-SP as per requirements in WS-SP Usecases document
WS-SP Use cases doc states
"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>
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
Obviously any requestor will
take the less secure route to access to service.
What should have happened
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.
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:
WS-SecurityPolicy schema should also be updated for the same.