W3C home > Mailing lists > Public > www-tag@w3.org > March 2005

RE: RFC 2616 (rfc2616) - Hypertext Transfer Protocol -- HTTP/1.1Re: Minutes of the Web Services Addressing / TAG joint meeting

From: Paul Cotton <pcotton@microsoft.com>
Date: Mon, 14 Mar 2005 19:23:33 -0800
Message-ID: <33D970235519324D988AFFDE7EA2E24C056F8489@RED-MSG-41.redmond.corp.microsoft.com>
To: "Rice, Ed \(HP.com\)" <ed.rice@hp.com>, "Rich Salz" <rsalz@datapower.com>
Cc: <public-ws-addressing@w3.org>, <www-tag@w3.org>

> What I
> 'Believe' your talking about with a SOAP intermediary is another
company
> or process that sits between the sender and the receiver who may open
the
> package, read the package and then route it appropriately (not sure if
> your suggesting they should also be able to add content).

I mean exactly what the SOAP processing rules for intermediaries defines
[1].

> This type of security would require that the
> entire SOAP package be encoded or that 'parts' or the soap package
would
> be encoded so that you could tell what had changed and what wouldn't

If you want to guard against "man in the middle" kinds of attack then
you can use WS-Security [2] to provide "message level security" as an
alternative to using SSL.  See also [3] for a description of how to use
either SSL or WS-Security as countermeasures for many threats to SOAP
messaging. 

/paulc

[1] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#relaysoapmsg 
[2]
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-sec
urity-1.0 
[3]
http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf 

Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 
mailto:pcotton@microsoft.com

  

> -----Original Message-----
> From: Rice, Ed (HP.com) [mailto:ed.rice@hp.com]
> Sent: March 14, 2005 5:38 AM
> To: Paul Cotton; Rich Salz
> Cc: public-ws-addressing@w3.org; www-tag@w3.org
> Subject: RE: RFC 2616 (rfc2616) - Hypertext Transfer Protocol --
> HTTP/1.1Re: Minutes of the Web Services Addressing / TAG joint meeting
> 
> I think your mixing your types of transfers (mixed metaphors).
> 
> A SOAP transfer using SSL is the same as any SSL transfer, you still
don't
> 'trust' the routers and the package transfer through securely.  What I
> 'Believe' your talking about with a SOAP intermediary is another
company
> or process that sits between the sender and the receiver who may open
the
> package, read the package and then route it appropriately (not sure if
> your suggesting they should also be able to add content).
> 
> Clearly, this is an issue if you're looking for end-to-end security if
> your going to use SOAP.  This type of security would require that the
> entire SOAP package be encoded or that 'parts' or the soap package
would
> be encoded so that you could tell what had changed and what wouldn't.
> 
> This is less a limitation of SOAP than a limitation of XML.
> 
> -Ed
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Paul Cotton [mailto:pcotton@microsoft.com]
> Sent: Monday, March 07, 2005 5:33 PM
> To: Rich Salz; Rice, Ed (HP.com)
> Cc: public-ws-addressing@w3.org; www-tag@w3.org
> Subject: RE: RFC 2616 (rfc2616) - Hypertext Transfer Protocol --
> HTTP/1.1Re: Minutes of the Web Services Addressing / TAG joint meeting
> 
> > I want end-to-end security, not hop-by-hop.  I'm not alone. :)
> 
> +1
> 
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Nepean, Ontario K2E 6A3
> Tel: (613) 225-5445 Fax: (425) 936-7329
> mailto:pcotton@microsoft.com
> 
> 
> 
> > -----Original Message-----
> > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On
Behalf
> Of
> > Rich Salz
> > Sent: March 7, 2005 8:18 PM
> > To: Rice, Ed (HP.com)
> > Cc: public-ws-addressing@w3.org; www-tag@w3.org
> > Subject: RE: RFC 2616 (rfc2616) - Hypertext Transfer Protocol --
> > HTTP/1.1Re: Minutes of the Web Services Addressing / TAG joint
meeting
> >
> >
> > > I guess it depends on the content.  Normally when you use a SOAP
> > > intermediary you would have your SSL connection with the
> intermediary if
> > > your concerned about the validity of the content.  That way the
> > > intermediary becomes a trusted source (and it in-turn would have
to
> have
> > > a trust relationship with the up-stream author of the content).
> >
> > That strikes me as turning an architectural limitation into a
feature.
> > If I sign my content, I don't have to trust a SOAP intermediary to
do
> > anything more than it's business.  If that intermediary gets
> > compromised, *my* content won't get screwed up.  (Choicepoint,
> anyone?)
> >
> > You don't trust every router that might touch your TCP packets, do
> you?
> > Of course not -- that's why you use SSL.  Why is the SOAP situation
> > any different?
> >
> > I want end-to-end security, not hop-by-hop.  I'm not alone. :)
> >         /r$
> >
> > --
> > Rich Salz                  Chief Security Architect
> > DataPower Technology       http://www.datapower.com
> > XS40 XML Security Gateway
http://www.datapower.com/products/xs40.html
> >
Received on Tuesday, 15 March 2005 03:23:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:33 GMT