[
Lists Home |
Date Index |
Thread Index
]
> > 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
|
