OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[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 securityimplementation in WS-SP - cloned to Issue i141


I realize my previous comment was not particularly helpful (apology),
and have given the situation as Hal described a little more thought.

The phrase that threw me was "if we want it to work this way",
which I don't know the answer to, but it sounds like on balance
that Hal's suggestion is that: if that is the case, then his recommendation
would improve the current proposal by making it more specific to
the "clear password" case only so that users will not have to wonder
if there is something that needs to be done with the other cases
as well.

With that in mind, I suggest modifying the proposal to be the
following:

Add following text after line 815 (between sp:HashPassword and sp:RequireDerivedKeys:

/sp:UsernameToken/wsp:Policy/sp:Created
This optional element is a policy assertion that MAY be used only with the default cleartext password
case, and, if present,
indicates that the wsse:Created element MUST be present in the Username token.

/sp:UsernameToken/wsp:Policy/sp:Nonce
This optional element is a policy assertion that MAY be used only with the default cleartext password
case, and, if present,
that indicates that the wsse:Nonce element MUST be present in the Username token.


This is still a bit awkward, because the cleartext case only exists as a default and is
not explicitly defined, so we end up applying attributes to a phantom token type.

    Thanks,
    Rich


Rich Levinson wrote:
475F0E3F.8020806@oracle.com" type="cite"> The purpose of this change is to remove ambiguity, and thus enhance
interoperability, and specifically to fill a gap created in the spec by
the way sp:HashPassword was defined.

With WS-SP left as is, then for sp:HashPassword, Created and Nonce
are required by the WS-SP spec to be included, even though in the
Username Token Profile PasswordDigest they are optional.

However, by requiring them in one token type, but not another, an
imbalance has been created, resulting in ambiguity. i.e. with one
Token type it is now clear what to do with these, but in the others
we are left with no way to address the question of whether to include
them or not: i.e. ambiguity, confusion, frustration, and time wasted.

By specifying these elements as optional, we fill the gap created by
requiring them in the sp:HashPassword and remove the ambiguity
and the other problems mentioned.

    Thanks,
    Rich

Hal Lockhart wrote:
2E22E42D2E71B845B67F093A02B962DB018320DF@repbex01.amer.bea.com" type="cite">

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]
Sent: Wednesday, November 28, 2007 9:48 AM
To: Marc Goodner
Cc: Hal Lockhart; Greg Carpenter; Aditya Athalye; ws-sx@lists.oasis-open.org
Subject: Re: [ws-sx] Issue i141 (i137): Support for more stringent security implementation in WS-SP - cloned to Issue i141

 

Proposed resolution for issue 141:

Add following text after line 815 (between sp:HashPassword and sp:RequireDerivedKeys:

/sp:UsernameToken/wsp:Policy/sp:Created
This optional element is a policy assertion that indicates that the wsse:Created element MUST
be present in the Username token.

/sp:UsernameToken/wsp:Policy/sp:Nonce
This optional element is a policy assertion that indicates that the wsse:Nonce element MUST
be present in the Username token.


    Thanks,
    Rich

Marc Goodner wrote:

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]