SOAP/XML Protocol and filtering, etc.

[Mark Nottingham]

[This was originally posted to the main IETF list for comments, and
it was suggested that this list might give good feedback. Apologies
if you've seen it before]

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)

-
[To unsubscribe, send mail to majo...@lists.gnac.net with
"unsubscribe firewalls" in the body of the message.]

[Jeffery...@minnesotamutual.com]

Mark,

Maybe I am missing something here but I thought that the whole point
of developing SOAP was so that application developers could do stuff
without having to bother the pesky firewall administrator. I block SOAP
and I probably will continue to do so regardless of the identification
placed in the SOAP header. HTTP is bad enough without making the transport
protocol for everything else under the sun. The SOAPAction header sounds
nice but I think that most firewall administers will just block SOAP until
they are ordered not to.

Regards,
Jeffery Gieser

[Rusty]

I, for one, will always block SOAP because it was spawned by Mickeysoft and I have
never seen anything "secure" from that bunch.

Rusty

Bill_...@pch.gc.ca wrote:

> SOAP is an attempt to formulate a better structure for client-server exchanges
> than the present grapbag of CGI scripting.
> If SOAP is such a problem, why not also block anything with a CGI request in it
> or POST altogether?
> What is impoortant is to have a syntax for client-server exchanges that can be
> parsed unequivocally so that intermediate filters such as firewalls or web
> proxies do not interpretet the meaning differently from each other, the server
> or the client.
> If the SOAPaction verb in HTTP allows us to be clearer, it can only help
> firewalls.
> Unfortunately, SOAP is coming along a little late in the game. Most systems
> will always need to support CGI and other scripting so SOAP adds to the
> complexity rather than replaces it by a better paradigm.
>
> Jeffery...@minnesotamutual.com on 05/07/2001 09:47:16 AM
>
>
>
> To: Mark Nottingham <mn...@akamai.com>
>
> cc: fire...@Lists.GNAC.NET(bcc: Bill
> Royds/HullOttawa/PCH/CA)
>
>
>
> Subject: Re: SOAP/XML Protocol and filtering, etc.

> ------------------------------------------------------------------------
> Name: att1.eml
> att1.eml Type: Internet E-Mail Message (message/rfc822)
> Encoding: base64

--
"If Democrats wanted Gore to be president so bad,
they should have voted to convict."

[Bill_...@pch.gc.ca]

I hope you never use PPP to dial up. It is a Microsoft protocol so you need to
use SLIP.
Just because Microsoft was involved doesn't mean it is insecure.

Rusty <iri...@gci.net> on 05/07/2001 07:51:43 PM



To: Bill Royds/HullOttawa/PCH/CA@PCH,
"Fire...@lists.gnac.net"
<Fire...@lists.gnac.net>

cc:

Subject: Re: SOAP/XML Protocol and filtering, etc.

[bar...@groupit.com]

I would not say that SOAP is designed to circumvent firewalls--it is
intended as a standard for data representation and function calls to
programatically access remote services. For it's intended purpose, it is a
good standard.

For most purposes, though, it is not the sort of thing you would want to be
wide open. If you have SOAP services on one of you DMZ servers, you may
only want specific outsiders to access them.

Of course, if your firewall passes SSL it would be possible to send
encrypted SOAP and the firwall admin would not be able to filter it. This
is not a problem with SOAP, you could really pass anything this way.

CB

[Jose Nazario]

On Mon, 7 May 2001, Rusty wrote:

> I, for one, will always block SOAP because it was spawned by
> Mickeysoft and I have never seen anything "secure" from that bunch.

that alone shouldn't be enough to dismiss anything. let's face it, nearly
every company turns out crap, and if we applied that logic (they've turned
out crap before, they can't do it right) we'd be stuck going nowhere.

instead, evaluate it based on its merits.

SOAP is based on RPC and HTTP, two protocols which, alone, lack any decent
security measures. together, its a mess. from section 8 in the draft
standard (version 1.1, available at http://www.w3.org/TR/SOAP/):

8. Security Considerations

Not described in this document are methods for integrity and
privacy protection. Such issues will be addressed more fully in a
future version(s) of this document.

that's certainly not good. however, the whole thing is extendable enough
that stronger authentication mesures could be placed in there. they're
just not yet there.

bear in mind that SOAP was designed to get around those pesky firewalls
and bastard administrators who want to limit your productivity (under the
guise of 'protecting the infrastructure'). bahh! who needs that? (sarcasm,
folks, sarcasm ...)

again, we're in the quandry: facile communication balanced with security
concerns.

____________________________
jose nazario jo...@cwru.edu
PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80
PGP key ID 0xFD37F4E5 (pgp.mit.edu)

[D. Clyde Williamson]

The PPP RFC(1661) was written by a Network Working Group (In fact, The
Point-to-Point Protocol Working Group of The IETF), chaired by Fred
Baker, who was with Advanced Computer Communications. It was edited by
William Simpson, who worked for Computer Systems Consulting Services.

There is no mention of Microsoft anywhere in the RFC

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1661.html

[Johannes Kloos]

On Mon, May 07, 2001 at 12:11:41PM -0400, Bill_...@pch.gc.ca wrote:
> I hope you never use PPP to dial up. It is a Microsoft protocol so you need to
> use SLIP.
> Just because Microsoft was involved doesn't mean it is insecure.

Hmmm.
RFC 1134 (the first RFC about PPP) doesn't mention Microsoft anywhere in
it.
Can you further proof your claim?

--
Johannes Kloos
"Seems I can't get me 'ead down these days without rescuin' people or
foilin' robbers or sunnink."
-- It's a wonder dog's life (Terry Pratchett, Moving Pictures)

[Bernd Eckenfels]

On Sun, May 06, 2001 at 10:52:03PM -0700, Mark Nottingham wrote:
> - 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]

Actually a Firewall whis is relying on this fact is by default broken.
Terefore a Firewall needs to parse the content of the SOAP Request anyway.
Therefore checking the additional SOAPAction is not needed.

Greetings
Bernd
--
(OO) -- Bernd_E...@Wendelinusstrasse39.76646Bruchsal.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!