RE: [ws-rx] Revised proposal #2 for i122 - i124

["Raepple, Martin" <martin.raepple@sap.com>]

Marc,

the intension of our proposal was never to ADD anything in terms of new
security features etc. to the previous proposal, but to propose a better
architecture based on existing, standardized mechanisms.

Looking at the history of the discussion in this TC, the use of the STR
in the body has always been the main reason for the issues around
security in RM. So it is actually the core of our proposal to describe a
solution where the STR can remain in the security header by utilizing
the @Usage attribute of the STR which is described in the WSS 1.0 / 1.1
OASIS Standard.

Our proposal perfectly supports WS-SecureConversation/Security Context
Tokens (as yours does), since we both suggest to use a token-type
independent STR as a means to associate the sequence with (any possible)
token in the WSS header. Section 8 you are referring to in the current
WS-SecureConversation draft actually describes ONE possible way to
implement this association. As our proposal demonstrates, there are also
other ways to solve this, again, based on a generic mechanisms specified
in a widely adopted OASIS standard. As a voting member in the WS-SX TC,
I agree that the current WS-SecureConversation Editor Draft is well on
its way to become an OASIS Standard presumably in 2007, but as the
discussion in WS-SX stands now, it is possible that section 8 you
referred to in the current Editor Draft will change and be improved till
then (see
http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/200606
/msg00066.html).

Please see more detailed <MR>comments</MR> inline.

- Martin

>-----Original Message-----
>From: Marc Goodner [mailto:mgoodner@microsoft.com] 
>Sent: Dienstag, 11. Juli 2006 18:55
>To: Prateek Mishra
>Cc: ws-rx@lists.oasis-open.org; Gilbert Pilz; Patil, Sanjay
>Subject: RE: [ws-rx] Revised proposal #2 for i122 - i124
>
>Prateek, 
>
>I do not agree with this direction. Your proposal does not add anything
>that was not already in the previous proposal we made to the TC. All it
>does is move the STR from the body to the header. I don't understand
>this pursuit to purge RM of primitives from WSS (primitives 
>intended for
>such reuse) when no exception is taken to the extensive reuse of
>primitives from WS-Addressing. 
>
>This proposal is also inconsistent with the techniques to associate a
>specific token with a message described in WS-SecureConversation. You
>suggested that referencing such a technique from WS-SecureConversation
>rather than defining it from scratch would be preferable:
>"It would be much better if this text were to make reference to Section
>8 of WS-SC which describes this technique versus inventing it from
>scratch"
>http://lists.oasis-open.org/archives/ws-rx/200607/msg00019.html 
>Now you highlight as a virtue that RM should do exactly the 
>opposite and
>define primitive security patterns that other specifications should
>copy.
>
>I also do not believe that this proposal is consistent with
>SecurityPolicy, see text on point 4 below.
>
>More inline below.
>
>-----Original Message-----
>From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
>Sent: Monday, July 10, 2006 12:27 PM
>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.
>MG: Yes but now the security layer has to communicate those 
>artifacts to
>the RM layer at the RM layer's request, I fail to see the 
>improvement. I
>am not convinced that what you propose is more flexible, it seems to
>enforce a rigid implementation strategy on how the security contract
>must be shared between the RM and WSS layer that is not described in
>your proposal (or WSS). That is in contrast to a well understood
>mechanism for just that purpose.
>



<MR>
Our proposal does not require the security layer to communicate the STR
to the RM layer since it is not included in the CS message any more (as
opposed to your proposal). It actually avoids this tight coupling
between the layers by clearly separating the elements of each protocol.
Now the RM layer is not required to have any understanding of the STR
any more, and there is no need to communicate any security artifacts up
the stack from the security processor to the RM layer. The RM processor
is now able to manage the mapping between the sequence and the token
based on an abstract handle (an unique id or number) or (based on
architectural preferences and the flexibility our proposal provides) the
security processor does that for RM.
</MR>



>Why is it such a concern to reference WSS elements (esp. ones meant for
>reuse) as opposed to reusing WS-A primitives which we do throughout the
>RM specification?
>
>What you are proposing has also not been validated by implementation
>experience. The approach that we propose has been in a slightly lesser
>form in the contributed specs. For anyone who plans to support the
>contributed specs your approach therefore represents a complication in
>that it requires two implementation approaches rather than one. 
>


<MR>
I disagree with the fact that any private, vendor-centric
interoperability events are a valid argument to assume that the majority
of the implementations have already adopted your proposed approach. Many
vendors will wait at least for a first CS status of the SX specs, and
speaking for the companies behind our proposal, one should not assume
that our design is less unproven than yours. 
</MR>


>(2) Is based entirely on the OASIS WSS standard.
>MG: I don't see that as an advantage if it does not compose with other
>specifications such as SecurityPolicy, see below. I think ignoring the
>specs in the SX TC is a mistake.
>


<MR>
The fact that our proposal formally only relies on the WSS 1.0/1.1 OASIS
Standard does not mean that it will not compose with
WS-SecureConversation. The STR works perfectly well with
WS-SecureConversation and the Security Context Tokens. Regading
SecurityPolicy, please see my comment below.
</MR>


>(3) Provides a standard pattern which may be re-used for other
>application protocols as it is based upon profiling the STR usage
>attribute.
>MG: I do not believe, and you have asserted as well, that RM should not
>be defining security patterns for re-use by other applications. The
>pattern in our original proposal was described in 
>WS-SecureConversation.
>You had previously asked for a reference in the proposal to the
>techniques as described there (as noted above). Now you are asserting
>that the RM TC should attack a general reusable security pattern for
>other applications rather than reusing a common technique 
>described in a
>security specification.
>

<MR>
To clarify this: Our proposal describes the RM-specific application of a
reusable security pattern. The description of the generic pattern will
be subject to the discussion around issue 77 in WS-SX
(http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/20060
6/msg00066.html).
</MR>


>(4) Has no additional impact on SecurityPolicy beyond that found in the
>original proposal.
>MG: I disagree. Your proposal introduces a new STR in the WSS header.
>That needs to be described in the SP assertion. Please illustrate how
>you would do so, I do not believe there is an existing assertion that
>covers this unexpected use. If such an assertion existed in SP, use of
>the technique as you have described it would impact the SP 
>layer in that
>it would then need to be reflected. Therefore there would be two
>assertions, across RM and SP, that would be emitted that are tied
>together one not making sense without the other. With our original
>proposal the SequenceSTR assertion only indicates the presence 
>of an STR
>that will refer to the token to secure the message, nothing more. It
>would not affect what the contents of the SP assertion would be. SP
>completely defines the token to be referenced.


<MR>
There is NO impact on SecurityPolicy since our proposal does not
introduce a new STR to the WSS header. It only introduces a new URI
value for the STR @Usage attribute to unambiguously identify the STR
used to protect the RM Sequence. If you carefully read the example
message and the explanation given in our proposal you'll notice that
there is NO additional STR in the WSS header. Instead, the *existing*
STR that is already part of the XML Signature for the RM Sequence in the
WSS Header uses this URI value to identify the STR for the processor.
The WSS header actually looks (except for the @Usage attribute in one
STR) identical to your proposal. The most important difference is that
our proposal does no require to duplicate the STR (which is already
included in the WSS header) to the body of the message with all the
advantages described in Prateek's summary.
</MR>


>
>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)
>>
>
>