> Theo, paraphrased:
> > You just need the request parameters.
>
> No. This would work if resultsets only last for one
> response/request. However if I were to do a search, do a
> second search and then try to combine the resultsets from
> those two searches, the first would have already disappeared.

Who so? - neither result set should disappear unless there TTL values
have expired. If the TTL hasn't expired the server cannot delete them.
If the TTL has expired the server may have deleted them (and the
presence of a session id wouldn't change that behaviour)


> Yes, introducing a session id doesn't make it impossible to
> do, but it does make it exponentially more difficult.
> Difficult enough that an attack is unlikely to succeed,
> whereas without it it is very possible.
>
> Compare basic authentication of username and password.
> Guessing a username and password combination is much harder
> than guessing one of the two. And for large robust servers
> (the reason we're using SOAP right?) there will be a lot of
> users. Unless the server is designed with this sort of
> security in mind, the resultsets will probably just
> identified with an incrementing scheme rather than a random
> set of characters, so once a pattern has been found, the
> server is completely compromised.

And session ids would be generated how? If there is a good algorithm for
generating session ids which isn't guessable why can't we use it for
record set ids?

And in any case a guessing an session id and result set id combination
is only as difficult as guessing a result set id of the same length as
the session id + result set id.

And what about situations (not necessary in SRW) in which a result set
id isn't being used? Aren't they more vulnerable since guessing a
session id alone is exponentially easier than guessing a session
id/result set id combination?

> User/password authentication has served for many years, and
> will likely continue to do so for all but financially
> important traffic.

There's nothing to stop SRW being used with username/password
authentication passed in the SOAP-Env:Header (or any other
authentication token for that matter) if that particular requirement is
needed.

> Yes. But then you drastically limit the number of potential
> clients to those that support encrypted SOAP.

Most toolkits I know that support SOAP over HTTP also support SOAP over
HTTPS

> It also makes
> it more difficult to just throw together a server, I wouldn't
> bother... > Z39.50 is less complex and more functional.

Again most SOAP toolkits run on http servers which support https out of
the box. Moving a SRW service from HTTP to HTTPS is normally just a
configuration change to the web server - hardly substantial "more
difficult". On the other hand, if you want to run Z39.50 in a secure
manner you would want to run Z39.50 over SSL or similar anyway
(especially in medical or financial scenarios). It is a little hard to
modify a Z39.50 toolkit to use SSL (not much, but it can require a
little recoding and recompiling) or you could use a SSL tunnel. Both of
these seem somewhat trickier than enabling https in a web server (which
is often just checking a box in the config tool).

The same situation applies to current websites (which maintain state
either via cookies or ids embedding in URLs or POST requests). Those
that are concerned about interception run on https, those that run
application where the risk analysis is such that it doesn't matter if
sessions are intercepted use http. As for mounting DDOS attacks there
are much easier ways to do that than guessing session ids (or result set
ids) and intercepting sessions (and which Z39.50 is immune to).

Matthew





Matthew