[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What Does SOAP/WS Do that A REST System Can't?

• To: Joe Gregorio <joe.gregorio@g...>
• Subject: Re: What Does SOAP/WS Do that A REST System Can't?
• From: Rich Salz <rsalz@d...>
• Date: Thu, 31 Mar 2005 00:09:07 -0500 (EST)
• Cc: "xml-dev@l..." <xml-dev@l...>
• In-reply-to: <3f1451f505033019364dd99ebd@m...>

> > Note that I'm not talking about transactions, rollback, etc., I just
> > want to know if the damn message got there and what the answer was.
> > I'd also like to avoid message replay.
>
> I believe POE fulfills that requirement:
>
>    http://www.mnot.net/blog/2005/03/21/poe

Unfortunately, no.  If a reply is lost, according to the POE draft
you're supposed to do a GET.  How does the server prevent someone
else from doing the GET?  Since a GET has no request body, there's
no way to put any real authentication in there.  Also, how long
does the server have to keep the GET'able response around for?
Mark proposed this same kind of trick in the WS-Addressing WG and
I raised the same objections.

> > HTTP has no way to provide end-to-end security of the Request URI.
> > That means you can't do a GET and have any cryptographically based
> > way to be sure that (a) the URI wasn't modified in-flight; and (b)
> > that nobody else will see it (i.e., signing and encryption).
> > is only hop-by-hop.  If there are any proxies or loadbalancers in the
> > path, at least some of them will get the plaintext.
>
> As far as (a) is concerned, doesn't Digest include the URI in the hash?

Digest requires the client and server to have a shared secret.
That means O(n**2) vs O(n), and we've all heard how bad that is. :)
Seriously, it means that every possible pair of communicating
entities have to have a shared password.  That, in turn, means that
if you get something signed with Digest you have no idea which side
signed it.  That doesn't tend to make the business folks very happy.

> As far as (b) is concerned, isn't the SLL certificate tied to the IP address
> of the server being accessed?

That's assuming the client has direct IP connectivity to the real
server being accessed.  It's rarely that way -- as I said, there's
often loadbalancers, content-aware networking, etc., in the way.
In addition, many organizations have a policy that SSL from the
outside world *must* terminate in the DMZ.  They *will not* let an
incoming SSL connection connect directly to internal services.

I'd rather not have to trust every single piece of network equipment
to not mess anything up, especially when I don't have to.

        /r$

-- 
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html

• Follow-Ups:
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Joe Gregorio <joe.gregorio@g...>

• References:
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Joe Gregorio <joe.gregorio@g...>

• Prev by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Previous by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Index(es):
  • Date
  • Thread