Subject: SOAP/XML Protocol and filtering, etc.

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 May 2001 00:03:05 -0700

The W3C's XML Protocol WG [1], which is chartered with developing
XML-based messaging based on SOAP [2], has been debating the merits
of the SOAPAction header in SOAP's HTTP binding. I've taken it upon
myself (with some misgivings ;) to solicit comments on the designs
being discussed.

Briefly, SOAPAction is intended to identify a service being accessed,
independently from its URL. For example, if you're accessing a
StockQuote service, you might put a URI which identifies this type of
service in the SOAPAction header.

The primary motivation of this is to allow firewall and filtering
proxies to identify SOAP messages in HTTP and act appropriately.

Some implementations and/or applications of SOAP also use SOAPAction
for dispatch, but that's out of scope for this discussion.

The three major designs being proposed are:
  - allow any arbitrary URI to be placed in the SOAPAction header [3]
  - force the content of the SOAPAction header to be the same as the
    top-level XML namespace in the message body, thereby identifying
    what kind of message it is (making this information available in
    the header removes the requirement that the intermediary parse
    the XML) [4]
  - removing SOAPAction and requiring that only one service be
    associated with any particular URI [5]

I feel that if we're going to design something to satisfy an external
requirement ("make SOAP play nice with firewalls, so they don't just
block all SOAP messages"), we should consult with the affected
communities. 

So, I would very much appreciate:
  - constructive comments as to the designs 
  - pointers to mailing lists, etc. of communities that would be
    interested in these issues (firewall admins, etc.)
  - discussion of whether any such hints will be helpful for the
    target audience
  - pointers to filtering/access control techniques already used,
    with particular emphasis on whether or not any current
    implementations can identify HTTP headers and act upon them.

Kind regards,

[1] http://www.w3.org/2000/xp/Group/
[2] http://www.w3.org/TR/SOAP
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0142.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0026.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0055.html

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 May 2001 15:12:08 -0400

The last thing that HTTP needs is yet another tag with which to 
de-multiplex incoming traffic.  Adding application-specific 
request or response headers just increases the problems that 
already exist due to a lack of clean layering in HTTP.  So I'd 
strongly recommend against defining any new SOAP-specific headers.

As for demultiplexing, my recommendation would be to do whatever 
SOAP-specific demultiplexing either entirely within the URL of the 
request, or entirely within the HTTP payload.   (and SOAP should
choose one of these, not make it a per-service option). If the 
latter is chosen, the separation between the SOAP payload and the 
tag used for demultiplexing could be done either using XML framing 
or with MIME multipart/something.  This ensures the maximum 
compatibility with existing servers, server-side APIs, proxies, 
and client APIs.  It also keeps HTTP servers from having to know
specifically whether a particular URI corresponds with a SOAP 
request (in which case it might have to look at the SOAPAction header 
in order to know how to handle it) or not (in which case the SOAPAction
header should be ignored).

The name of the SOAP service should *not* be inferred from the XML 
namespace used to describe the request.  This would make it impossible 
to have multiple services that accept identically formatted requests.

Keith

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 May 2001 12:59:36 -0700

> header should be ignored).

Yep; seems to me that Content-Type ss more appropriate for dispatch,
if doing it in a header is desireable.

> to have multiple services that accept identically formatted requests.

The idea is that the identity (i.e., "this is a stockquote service")
is implied by the namespace, and therefore is useful for firewall
admins, etc., so they can work at the granularity of a service type.
The location of the service is still carried in the HTTP
request-line. SOAPAction isn't intended to uniquely name services.

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 May 2001 17:46:16 -0400

> if doing it in a header is desireable.

ugh.  only if you must.  the URL is *far* better for this purpose.
 
> request-line. SOAPAction isn't intended to uniquely name services.

I can see why you might want firewalls to be able to filter certain
kinds of data - having everything tagged in XML might allow firewalls
to prevent inadvertent leakage of data of types known to be 'sensitive'
via any of several protocols. But I don't think you really want to 
conflate the name of the data structure with the name of the service, 
and probably not even with the 'type' of the service.  The type of 
the service and the type of data presented to the service should be 
kept separately.

Keith

p.s. One thing that really concerns me about the SOAP approach is what I 
call firewall escalation - the chief justification for using HTTP as a 
substrate for SOAP is to allow it to operate through existing firewalls, 
but one of the consequences of SOAP is likely to be that firewalls become 
more complex (and more error-prone) due to a need to dig deeper into the 
HTTP payload.  This degrade service for all uses of HTTP.  So I think 
SOAP should be designed, to the extent possible, to avoid encouraging 
such escalation.  

And if it ends up requiring changes to HTTP after all, and/or changes
to existing firewalls, then it should be declared to be a different 
protocol, with a different default port, with a different URI prefix.  
That way, the firewall measures that get put in place for SOAP don't 
end up affecting use of ordinary HTTP.

---

From: [email-masked]
Date: Mon, 07 May 2001 00:01:07 -0400

> request-line. SOAPAction isn't intended to uniquely name services.

OK.. I've read section 6 of http://www.w3.org/TR/SOAP several times,
and I'm frankly dissapointed.

Unless you find a way to codify that the site has to tell the
truth in the SOAPAction, it's a non-starter.  Consider that
the user behind a firewall could, in conjunction with a site
that supported it, just tack onto the end of the URL a

&callit=whateverSoap

and the web site could just label it with SOAPAction=whateverSoap
will get through the firewall.

So what is this actually fixing?  The guy *inside* the firewall
presumably knows what will be allowed to pass, and can tell the
guy outside what to call it.  This sounds like a scene from a
James Bond movie - if he knows that the roadblock up ahead is
looking for a Jaguar with Swiss plates, he hits a button and
he's now driving a Jaguar with French plates.

This leaves us with 2 choices:

1) Require the SOAPAction to match the XML.  Since the firewall
has to poke around the XML then, it renders SOAPAction redundant
and useless.  It's also a protocol layering violation egregeous
enough to cause retching.

2) Accept that it's yet another broken protocol that confuses
authentication with authorization (in the worst way - it trusts
the value it's given).  I *have* to point out that 4 of the 8
authors work for a company which has historically had problems
in understanding that an attacker might <*gasp*> put incorrect
data into a header field....

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 May 2001 22:34:17 -0700

> will get through the firewall.

I don't read SOAPAction as trying to solve world hunger; it merely
provides information about the payload that may be useful in
identifying it. Of course someone can circumvent this, but that's a
problem that doesn't originate with SOAP, but the underlying transfer
protocol (HTTP in this case). 

I.e., if two parties can coordinate, and wish to get through a
firewall which allows HTTP to pass, they have a multitude of options.
SOAP is one of them, but they could build their own as well. All that
SOAPAction does is allow spec-abiding SOAP messages to be identified.

My original question was whether this behaviour was useful; although
firewalls can (and some undoubtably will) break open the XML to try
and figure out what's inside, SOAPAction gives those who merely wish
to have some reasonable control over what SOAP messages pass into and
out of their network.

I'll take it to the firewall lists pointed out, thanks.

---

From: "Melinda Shore" <[email-masked]>
Date: Mon, 7 May 2001 08:25:05 -0400

> HTTP payload.  This degrade service for all uses of HTTP.  

Note, as well, that any assumption that you can get
through a firewall by inspecting content implies that 
the firewall can read that content - in a very real
sense the use of stateful inspection firewalling works 
against securing applications.

Melinda

---

From: [email-masked]
Date: Mon, 07 May 2001 10:25:19 -0400

> My original question was whether this behaviour was useful; although

I don't think it is..

> to have some reasonable control over what SOAP messages pass into and

No, it doesn't provide reasonable control.  Since the whole *point* of
a firewall is to stop malicious packets, and since a packet can simply
label itself as "non-malicious", it leaks too much.

We *already* have too many networks out there run by people who think
that because they've installed a firewall, they're secure.  I'm going
to have to protest tooth-and-nail any proposal that will give even a
HINT to "the unwashed masses" that they can say "We installed a firewall
that implements SOAP, we dont have to worry about bad SOAP packets".

I have *NO* objections to implementing SOAPAction so that software can
use it as a "hint" for possible fast-pathing or special handling of some
sort (for instance, to flag it as SOAP-compliant so a SOAP handler can
be loaded, or to flag it as "priority" for expedited handling, or for
purposes similar to 'content-type:'.  If somebody comes across a good
way to use SOAPAction: headers to make the Akamai node across the hall
from me do even more cool caching things, I'll encourage that ;)

I only object to the implication that it's reasonable to use it for
yes/no decisions in a firewall or other security context.
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech