Re: [ws-sx] Issue i141 (i137): Support for more stringent securityimple

Given the advisory text added to the examples document for issue 137 I think 141 can be closed with no action.

From: Rich Levinson [mailto:rich.levinson@oracle.com]
Sent: Wednesday, August 22, 2007 7:45 AM
To: Hal Lockhart
Cc: Greg Carpenter; Aditya Athalye; ws-sx@lists.oasis-open.org
Subject: Re: [ws-sx] Issue i137: Support for more stringent security implementation in WS-SP - cloned to Issue i141

Re: today's call. I think i141 should be assigned to Hal instead of me. According to the
June 27 minutes:

    http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/200706/msg00069.html

it was Hal that recommended the deferred state:

"i137 - Support for more stringent security implementation in WS-SP as per requirements in WS-SP Usecases document Hal believes this is an enhancement request and proposes to defer it to a future release of SP (see: http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/200706/msg00057.html). Issue inappropriately references both SP and the Examples document. AI: Greg will clone issue i37. The current i137 will reference only the examples doc. The cloned issue will reference only SP. The cloned SP issue will be given deferred status per Hal's proposal above. Issue i137b remains active."

And as we have discussed i137 has been in review and closed. The clone of i137 mentioned above became i141.
Note, I don't believe there was an open issue 141 email sent out so that's why I am responding to i137 here.

    Thanks,
    Rich

Hal Lockhart wrote:

On the last call I asked to defer action on this issue. Now that I have looked at it, I see that fundamentally it is an enhancement request for WS-SP.

Since WS-SP 1.2 is currently in ballot as an OASIS Standard, I propose this issue be deferred until such time this TC (or a successor TC) proposes to publish a further version of WS-SP.

Hal

From: Greg Carpenter [mailto:gregcarp@microsoft.com]
Sent: Friday, June 08, 2007 1:08 PM
To: Aditya Athalye; ws-sx@lists.oasis-open.org
Subject: [ws-sx] Issue i137: Support for more stringent security implementation in WS-SP

Issue i137.

From: Aditya Athalye [mailto:aditya.athalye@oracle.com]
Sent: Thursday, June 07, 2007 1:23 AM
To: ws-sx@lists.oasis-open.org
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

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

ws-sx message