RE: Securing Z39.50 & SSL

>just a couple of quick comments on this; i was not at the discussion 
>at the recent ZIG and i'm just picking up on some recent comments on 
>the list, so excuse me if this has already been hashed through.

Some of this was hashed through - I originally wanted to point the list at
STunnel so that implementors could have something to play with - but fresh
insight into the discussion is always welcome.

> On the issue Bob W. raised, at least the way I think about it, 
> encrypting specifc records or fields of records seems like it ought 
> to be a function of the application. there's no reasonable way for 
> z39.50 itself to decide what records or fields in records ought to be 
> secure, and this ought to be up to the programs that use z39.50.

True, but as Bob realised on reconsideration there seems little advantage in
selectively secured parts of the conversation as opposed to securing all of
it (given that we are talking about preventing snooping and we already have
mechanisms - e.g. Access Control - for authentication)
 
> ssl type security is really more complicated than just encryption. it 
> also can carry authentication functions which are very useful -- 
> there are certs passed around (required at the server end, optional 
> at the client end, if i remember right).

Typically these are used to provide a public/private key pair used during
the handshake so that the client and server can securely exchange a key used
symmetric encryption during the rest of the session (the security of the
rest of the connection being dependent on this key being only know to that
client and server). Client and server certs can be used at this stage for
authentication purposes, but only at this handshaking stage (i.e. comparable
to the authentication which can be done in an Init as opposed to that in
Access Control).

> however, as i understand it 
> (and i am not an expert in this area), the IETF has re-done SSL for 
> general use (ie not just HTTP, but also SMTP and other protocols) via 
> something called TLS (Transport layer security). This does not 
> require the use of 2 ports, one for secure and one for unsecure, the 
> way that HTTP/HTTPS does, at least as I understand it, and I think 
> that the IETF thinking is to avoid 2 well-known ports for every 
> protocol.  I'd urge you to give a read through the RFCs on TLS before 
> making any decision about best practices .

The general decision was that encryption should be at the transport level
not the application level. SSL looked a good candidate since its already
available and would not involve much work to implement. Moreover, we could
later move to another encryption mechanism at the transport layer such as
IPSec or some of the Internet2 proposals without too much hassle (SSL would
be easy enough to implement that no-one would feel they have invested too
much time in implementing it and be reluctant to move from it). TLS wasn't
explicitly mentioned.

A quick look over the RFC's reveals that TLS is very close to SSL but not
interoperable (I think the main difference is that TLS supports more
encryption algorithms than SSL etc., but most of the protocol is almost
identical) - see RFC 2246 and compare with
http://home.netscape.com/eng/ssl3/3-SPEC.HTM. A concern here is to adopt
something that can be implemented today, as opposed to something coming in
the future (e.g. we can't wait for the inbuilt mechanisms planned for
Internet2) as some of us have a need to implement this sort of security now.
There are already some proven SSL toolkits (SSLeay, OpenSSL, STunnel)
available (both commercial and GNU source code license ones, on both
Unix/Linux and Windoze platforms). Does anyone know of similar for TLS
(that's a genuine question, not a rhetorical one)?

A quick look over the RFC's also reveals that the avoidance of two ports
(one for secure, one for insecure) is not part of TLS per se. Indeed RFC
2818 discusses how to use http over TLS using the two port method. What has
happened with SMTP, POP,IMAP, HTTP etc. is the addition of a new command to
the application protocol concerned requesting the connection switch to TLS.
The command is STARTTLS for SMTP, POP etc. (RFC 2487, 2595) and the Upgrade
HTTP response headers (RFC 2817) for HTTP 1.1, i.e. the initial connection
is made via the standard unencrypted method, and then either the client or
the server requests that the connection goes TLS (note HTTP 0.9 and 1.0 seem
to be limited to the two port approach only). It goes without saying that
this should occur before any authentication such as passwords are exchanged.
In theory this could work equally well with SSL or any other encryption
layer (e.g. SSH).

In Z39.50 terms, we probably need to add something to the Init
request/reponse to do this (but remember that this may be server initiated
as well as client initiated). However, this is a little different from most
normal negotiation in that if one side requests encryption but the other
doesn't accept this typically the connection should close rather than use no
encryption (as this would violate the security and run the risk of
man-in-the-middle attacks). Also an Init requesting TLS or SSL encryption
could not also include a username/usergroup/password since the encryption of
the session hasn't been established at that point. We'd either have to allow
a second Init to do this, or accept that we could only use Access Control in
this situation.

An advantage of the two port approach is we wouldn't have to make this sort
of change to the Z39.50 protocol at this stage, but could leave such things
until standards in this arena (and Internet2) had stabilised.

Matthew Dovey
R&D Manager
Oxford University Libraries Automation Service

Received on Monday, 14 August 2000 17:32:35 UTC