RE: Z39.50 and SSL

> 
> > Securing Z39.50 was discussed at the Belgium ZIG, and the 
> consensus was that
> > security should be at a different layer to Z39.50 rather 
> than built into the
> > standard. 

>   But I guess I have the same problem with this as with 
> authenticating in
> a Z39.50 init APDU (which I also support).  THe problem is 
> that on many
> servers you need different levels of security.

This is a little different, in that apart from supporting legacy clients,
there is no real advantage in not running over an encrypted layer - i.e.
there is no advantage in dropping to a clear-text (or in this case
clear-BER) encoded transport just because the particular record isn't
sensitive. (Any comments amount performance overheads are nit-picking since
these are almost insignificant). The only exception is in debugging
circumstances, but you wouldn't be doing this in a production environment
(hopefully?)

So a solution would be to run an SSL and an non-SSL server (on different
ports), the latter not returning the sensitive records (perhaps returning an
appropriate surrogate diagnostic).

The trend with SSL, IPSec and Internet2 etc. is that eventually no traffic
will be sent in an unencrypted form. SSL seems the easiest way at present to
add encryption to those services that need it now - adding SSL to existing
client and servers isn't too difficult and doesn't require any changes to
the existing Z39.50 standard so hopefully there won't be too many legacy
client/servers not supporting it - and in any case STunnel can add the
required functionality to them, albeit in a less tidy fashion.

Matthew

Received on Monday, 14 August 2000 11:02:36 UTC