[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [ws-rx] Revised proposal #2 for i122 - i124
Doug
I've just re-read this. I am definitely beginning to see the positives
of Close No Action. In particular I agree specifically with this point:
>rather than leaving it to
>the RM and Security implementations to decide who can send which message
>(be it a Create Sequence or not).
The more I look at the proposals and the discussion it seems that we are
going beyond what an RM spec should care about.
Paul
Doug Bunting wrote:
> All,
>
> I am not sure where we are on these proposals. From what I can see, the
> current suggestions are found in:
>
> 1. latest from Microsoft and IBM
> <http://lists.oasis-open.org/ws-rx/200607/msg00036.html>
> 2. latest from Oracle and SAP
> <http://lists.oasis-open.org/ws-rx/200607/msg00075.html>
> 3. latest from
> BEA <http://lists.oasis-open.org/ws-rx/200607/msg00070.html> (do
> we have actual words for the composition of this and (2)?)
> 4. recently-accepted i121 words all of the above are starting from
> <http://lists.oasis-open.org/ws-rx/200607/msg00049.html>
>
> I have a general problem with all of (1)-(3) in that they go past the
> threats described in (4) as well as beyond our agreed Charter. The use
> cases addressed using any of these approaches include those involving
> separate security contexts for authenticating the Create Sequence and
> for authenticating the ("in-band") Sequence Traffic messages. The text
> in (4) seems to specifically call such strategies out of scope.
>
> Both (1) and (2) make assumptions about how much the RM implementation
> knows or should know about Security and how much the Security
> implementation knows or should know about Reliable Messaging. Such
> assumptions may not be good to make at this time.
>
> Further, separating two security contexts seems to directly result in a
> need to normatively reference early-in-process specifications. I also
> believe we're describing an RM-specific trust hierarchy (allowing the
> Create Sequence receiver to delegate to the sender responsibility for
> authenticating the Sequence Traffic sender) rather than leaving it to
> the RM and Security implementations to decide who can send which message
> (be it a Create Sequence or not).
>
> I suggest we close i122 through i124 with no action. Our specification
> should rely on the existing strategies for disambiguating multiple
> signatures (if any) in the Create Sequence to determine what Subject is
> authenticating that message and limit Sequence Traffic messages to the
> life cycle of the same security context.
>
> thanx,
> doug
>
> On 13/07/06 07:56, Raepple, Martin wrote:
>
>> IMHO, RM and WSS somehow have to be aware of each other in any of the
>> proposals as the slides [1] show (e.g. in both proposals the Security
>> Processor has to know what portions of the message constitute an RM
>> sequence to sign it, see step 3/slide 2 and step 5/slide 5).
>>
>> The central question in this regard is: How tight is this coupling in
>> terms of interactions between these layers and knowledge of each
>> others arifacts? This is what our proposal is all about.
>>
>> - Martin
>>
>> [1]
>> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00067.html
>>
>> ------------------------------------------------------------------------
>> *From:* Anthony Nadalin [mailto:drsecure@us.ibm.com]
>> *Sent:* Donnerstag, 13. Juli 2006 14:52
>> *To:* Raepple, Martin
>> *Cc:* ws-rx@lists.oasis-open.org
>> *Subject:* RE: FW: [ws-rx] Revised proposal #2 for i122 - i124
>>
>> I don't know of any implementations of WSS that do that nor do I
>> see this in the processing rules for WSS, as WSS now has to know
>> that it has to keep handles for STRs. Also the RM processing is
>> now aware of WSS
>>
>> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>> Inactive hide details for "Raepple, Martin"
>> <martin.raepple@sap.com>"Raepple, Martin" <martin.raepple@sap.com>
>>
>>
>> *"Raepple, Martin" <martin.raepple@sap.com>*
>>
>> 07/13/2006 06:27 AM
>>
>>
>>
>> To
>>
>> Anthony Nadalin/Austin/IBM@IBMUS
>>
>> cc
>>
>> <ws-rx@lists.oasis-open.org>
>>
>> Subject
>>
>> RE: FW: [ws-rx] Revised proposal #2 for i122 - i124
>>
>>
>>
>>
>> I don't follow your concern here. Maybe the pseudo-code for step 5
>> / slide 3 is misleading. All it says is: RM processor asks the
>> Security Processor to return an abstract handle for the token that
>> is referenced by the STR with Usage attribute set to the value
>> ".../SequenceToken" in the WSS Header. IMHO, this simple operation
>> does not violate any of the WSS processing rules and non-normative
>> App. D in WSS is neutral wrt @Usage.
>>
>> - Martin
>>
>> ------------------------------------------------------------------------
>> *From:* Anthony Nadalin [mailto:drsecure@us.ibm.com] *
>> Sent:* Mittwoch, 12. Juli 2006 23:48*
>> To:* Raepple, Martin*
>> Cc:* ws-rx@lists.oasis-open.org*
>> Subject:* Re: FW: [ws-rx] Revised proposal #2 for i122 - i124
>>
>> You have seem to require changes in every WSS stack with step 5,
>> this is not acceptable.
>>
>> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>> Inactive hide details for "Raepple, Martin"
>> <martin.raepple@sap.com>"Raepple, Martin" <martin.raepple@sap.com>
>>
>> *"Raepple, Martin"
>> <martin.raepple@sap.com>*
>>
>>
>> 07/12/2006 02:24 PM
>>
>>
>> To
>>
>> <ws-rx@lists.oasis-open.org>
>> cc
>>
>> Subject
>>
>> FW: [ws-rx] Revised proposal #2 for i122 - i124
>>
>>
>>
>>
>> All,
>>
>> as an informal supplement to our proposal, please find a technical
>> analysis of the different processing models behind the current
>> proposals
>> wrt. issues 122 - 124.
>>
>> I'd also like to propose some time on the agenda of our call this week
>> to discuss these slides in the context of the security issues.
>>
>> Thanks and regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: Prateek Mishra [_mailto:prateek.mishra@oracle.com_]
>> Sent: Montag, 10. Juli 2006 21:27
>> To: Marc Goodner
>> Cc: ws-rx@lists.oasis-open.org; Gilbert Pilz; Patil, Sanjay
>> Subject: Re: [ws-rx] Revised proposal #2 for i122 - i124
>>
>> Marc,
>>
>> Attached to this message you will find an alternative solution
>> proposal
>> that meets the requirements for i122-i124. The proposal is co-authored
>> by SAP and Oracle. The proposal is expressed as a diff over your
>> original proposal.
>>
>> We believe that our proposal has certain advantages over the original
>> proposal. These include:
>>
>> (1) Supports a more flexible interaction model (architecture)
>> between RM
>>
>> and the Security layer; RM layer does not have to process or
>> communicate
>>
>> security artefacts such as STRs. All required STRs are found
>> within the
>> SOAP message security header.
>> (2) Is based entirely on the OASIS WSS standard.
>> (3) Provides a standard pattern which may be re-used for other
>> application protocols as it is based upon profiling the STR usage
>> attribute.
>> (4) Has no additional impact on SecurityPolicy beyond that found
>> in the
>> original proposal.
>>
>>
>> Thanks,
>> prateek mishra
>>
>> > This update is easy to understand but includes some important
>> tweeks
>> > that have been discussed on the list. Redlines are from the last
>> > revision of this proposal posted on June 21^st .
>> >
>> > _http://lists.oasis-open.org/archives/ws-rx/200606/msg00164.html_
>> >
>> > First the observation Sanjay made that the header does not make any
>> > sense as mU=false has been addressed, the header now must be
>> mU=true.
>> >
>> > _http://lists.oasis-open.org/archives/ws-rx/200606/msg00259.html_
>> >
>> > I also added a reference to the SC section (I used the contributed
>> > version rather than the SX TC editor draft) that describes the
>> use of
>> > an STR in a message body to address Prateek's concern that the
>> RX TC
>> > not invent new mechanisms. The concern Gil mentioned that there
>> should
>>
>> > be advice to favor a message independent reference over a local
>> > reference has also been added.
>> >
>> > _http://lists.oasis-open.org/archives/ws-rx/200607/msg00035.html_
>> >
>> > Other than that I corrected a few 2119 terms that were not in caps.
>> >
>> > (Sorry if this is a dupe, I forgot the subject line and the OASIS
>> > mailer said it bounced)
>> >
>>
>> [attachment "Processing models.ppt" deleted by Anthony
>> Nadalin/Austin/IBM]
>>
>>
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]