RE: Problems with the SOAP binding

 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Rich Salz
> Sent: 03 January 2005 20:36
> To: Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: Re: Problems with the SOAP binding
> 
> 
> Jonathan Marsh wrote:
> > Like I said, I'm not a security expert, but I'm not aware 
> of anything in
> > WSS that implies that all security features must be 
> expressed through
> > WSS.  Do you have a reference to the part of WSS that 
> you're concerned
> > about?
> 
> If you read Section 5 of the WSS spec it's not unreasonable to assume 
> that everything related to message security belong inside WSS.  It is 
> clearly open to interpretation, which is why I asked Gudge 
> for his opinion.

OK, I'm back from vacation. Having read quickly through this thread, I
don't think it's unreasonable for ds:Signature elements to appear
outside of a wsse:Security header. In fact, given that for the scenario
you specify, it's the EPR issuer who wants to ensure that the RefPs are
exactly what was issued, it seems reasonable that a ds:Signature element
containing a wss:SecurityTokenReference that refered to an 'external'
token ( i.e. one that is NOT present in the message that contains the
STR ) would be an ideal way to deal with this. Such a ds:Signature could
be subordinate to a RefP or be a RefP in its own right.

> 
> More explicitly, the WS-I basic security profile says (R3207 
> in section 
> 9.1.2), that all xenc:EncryptedKeys must be a child of the WSS header.
> So if a server wants to "statelessly" encrypt a refP so that it can 
> decrypt it later, if has to put some information into the WSS header. 
> I.e., encrypted refP's imply tight coupling to WSS.

It seems to me that in such a case, the EPR issuer could put the key (or
reference thereto) in another RefP...

> 
> > Expanding on my earlier post, to statelessly secure a refP against
> > modification, one could:
> > - insert within the refP itself the security measures such as 
> >   a DSig that enable the service to verify that the refP hasn't 
> >   been changed since issued, or
> > - insert a second refP containing security measures and pointing to
> >   the header (or headers) to be secured.
> 
> In previous email I've tried to show that it's not as simple as that, 
> and requires some pretty close coupling between the WSS, WS-Addr, and 
> client or server application layers.  I can dig up links to those 
> messages if necessary.  But my overall comment is that making 
> sure that 
> the server gets back unmodified refP's isn't enough.  You 
> have to make 
> sure that the client doesn't get fooled into sending things 
> it shouldn't 
> (adversary modifies the EPR before client gets it), 

I agree that the recipient of an EPR needs to be able to satisfy itself
that the EPR has not been modified.

>and that 
> the server 
> gets only, and exactly, the refP's that it should.

I'm not exactly sure what this means. If I issue an EPR with RefPs A and
B and those are the only headers I know about, then if someone sends me
a message containing A and C then C will not get processed. And the
message may not get processed at all because B is missing... But someone
to whom I have not given an EPR, could, perhaps, upon reading
documentation for my service, construct a message to me containing
headers A and B...

If I really want to ensure that the headers were indeed 'issued' by me (
or someone I trust ) as an EPR, then I think the signature approach
works fine.

> 
> > This is similar to statelessly securing HTTP cookies.  The cookie
> > transfer mechanism is defined in a general spec but how 
> cookies ensure
> > clients don't modify their contents is out-of-scope.  Just 
> as you don't
> > use TLS to prevent clients from altering cookies you don't 
> use WSS to
> > prevent clients from altering headers.
> 
> I don't think the analogy is accurate.  A server concerned about 
> interception and modification of cookies can just send base64 blob of 
> data that, when it gets it back and decrypts it, can include 
> a digest. 
> For refP's, the goal is that the headers *not* be a binary blob, in 
> order to leverage the SOAP header processing model.  If you 
> want to do 
> the equivalent of an encrypted cookie, then WSS WS-I say to use XML 
> Encryption and WSS, no?
> 
> There's another problem, if the refP includes headers that 
> are targeted 
> *to intermediaries,* then securing them requires their own signature, 
> and they cna't be bundled into the signature that covers the refP's 
> intended for the ultimate recipient.

Agreed. If RefPs are targetted at multiple roles, and the recipients of
those RefPs want/need to know they were actually issued as part of an
EPR, then multiple signatures will be required. Note that I'm not
certain the 'need to know they were issued as part of an EPR' is a
requirement.

> 
> I don't think this is at all out of scope.  We must at least document 
> the security considerations.

I agree we should document the security considerations.

> 
> > ID attribute collisions seem indeed to be a problem, regardless of
> > whether refPs are wrapped or not - this is a general problem when
> > combining chunks of XML.  We should look at this more 
> closely, but on a
> > practical level I might try to make sure any ID values I stuck in my
> > refPs were unlikely to cause conflicts, e.g. something like 
> an embedded
> > GUID value xml:id="guid-1234-1234-1234-12345678".
> 
> Yes.  But again, we also need to document the potential 
> conflict problem.

Yes, we should call out that if people put ID based attributes on there
RefPs then they should use some mechanism for making uniqueness highly
likely.

Gudge

> 
> 	/r$
> 
> -- 
> Rich Salz, Chief Security Architect
> DataPower Technology                           
> http://www.datapower.com
> XS40 XML Security Gateway   
> http://www.datapower.com/products/xs40.html
> XML Security Overview  
> http://www.datapower.com/xmldev/xmlsecurity.html
> 
>

Received on Wednesday, 5 January 2005 12:17:58 UTC