W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2000

Re: Web RPCs Considered Harmful

From: Eric Prud'hommeaux <eric@w3.org>
Date: Sun, 14 May 2000 05:24:43 -0400
To: "Anders W. Tell" <anderst@toolsmiths.se>
Cc: Henrik Frystyk Nielsen <frystyk@microsoft.com>, dick@8760.com, Dave Winer <dave@userland.com>, "Wesley M. Felter" <wesf@cs.utexas.edu>, Edd Dumbill <edd@usefulinc.com>, xml-dist-app@w3.org
Message-ID: <20000514052443.C3709@w3.org>
On Sat, May 13, 2000 at 09:58:44PM +0200, Anders W. Tell wrote:
> Henrik Frystyk Nielsen wrote:
> 
> > SOAP doesn't define *a* security policy because we expect that there is
> > need for multiple policies and even capability for negotiating which one
> > to use depending on the context (commerce, medical etc.) but that is not
> > for the base SOAP to do.
> 
> You mentions that SOAP defines [no] "security policy" but what is SOAPs relation
> to
> the much larger concept of Security Architecture which have  far reaching
> consequences regarding RPC/Messaging in general ?

It is easy to imaging a mapping of digital signatures into
standardized (conventionalized) SOAP headers. SOAP provides all the
boundries and identifiers you need to test a checksum over a range of
XML. A widely adopted header and schema would provide interoperable
security (allowing generic auth agents to provide security for an
opaque payload). I beleive that SOAP has the appropriate scope in not
natively addressing security/authentication.

As far as I know, the most famously vulnerable RPC mechanism has beens
Sun's RPC, not because it was hard to implement security within RPC,
but because the security functionality was added when there was
already a considerable multi-platform codebase. Retrofitting this code
provided many tedious security holes in critical protocols like NFS
which were originally writtne for a network of well-meaning geeks.

The lesson: I suspect the healthiest lesson is not to say "we need
authentication in the serialization layer", but instead "we need to
work out a good security model/API before deploying any critical
code." If you write an SOAP-based stock broker program and run it over
SSL for lack of a good auth module, you'd better think hard when
retrofitting it with the finally standardized SOAP-DSIG module.
Chances are that strapping in an auth module and complicating the
application interaction will expose some vulnerabilities.

(Encryption is a harder problem, but I think the work there comes in
defining the interaction between the decrypter and the parser.)

-- 
-eric

(eric@w3.org)
Received on Sunday, 14 May 2000 05:25:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:56 GMT