[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Revised proposal #2 for i122 - i124
|
Let's focus in on one claim you
have made below. (all emphasis below mine) “There is NO impact on SecurityPolicy since our
proposal does not introduce a new STR to the WSS header.” This is not true. To quote your own proposal: “One OPTIONAL means of achieving this objective is
to include a security token using an additional
wsse:SecurityTokenReference element from WS-Security in the SOAP security
header of the message containing the CreateSequence element.” The presence of that additional STR is also present in
your message examples. So looking at this more carefully I now feel that your
proposal is particularly unsuited for use with current WSS implementations. The
use of an STR in root of the WSS header is unexpected per what is described in
WSS, see Appendix D of WSS 1.1 in particular. So I find your proposal to add
this STR to the WSS header to be something that most WSS processors today would
find unexpected and therefore the message would not be processed. I now see
this as one of the most serious flaws in your proposal. Regarding your claim that there is no impact on
SecurityPolicy, that is also incorrect. There is NO SecurityPolicy binding that
describes the presence of a STR in the root of the WSS header. Therefore you
could not today describe what you are proposing using SP. -----Original Message----- 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) >> > > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]