[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
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]
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]