[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue i141 (i137): Support for more stringent security implementation in WS-SP - cloned to Issue i141
The problem with this is that my reading
of SP currently is that if HashPassword is specified, Nonce and Created are
required, but currently not specified. Thus situation is this for the 4 types
of password. 1. clear password – provide nonce and
created only if SP requires 2. hash password – provide nonce and
created whether specified in policy or not 3. no password – do not provide nonce
and created regardless of policy 4. Derived key – do not provide nonce
and created regardless of policy, but always provide salt and iteration This strikes me as confusing. If we want
it to work this way, we should add text saying so explicit. In general I am
wary of schemas where there are a bunch of elements which can be used, but the
semantics of some of the combinations are not spelled out. Hal From: Rich Levinson [mailto:rich.levinson@oracle.com] Proposed resolution for issue 141: 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]
Re: today's call. I think i141 should be assigned to
Hal instead of me. According to the 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] Issue i137. 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 / 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 "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 Obviously
any requestor will take the less secure route to access to service. What
should have happened is: 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 <wsp:Policy> <sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient"> <wsp:Policy>
<sp:CreatedAssertion/> <sp:WssUsernameToken10/> </wsp:Policy>
</sp:UsernameToken> </wsp:Policy> The
WS-SecurityPolicy schema should also be updated for the same. Thanks Aditya Athalye |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]