[20] in WWW Security List Archive
GSS API...
daemon@ATHENA.MIT.EDU (John Ludeman)
Mon Aug 15 19:54:35 1994
From: John Ludeman <johnl@microsoft.com>
To: www-security@ns1.rutgers.edu
Date: Mon, 15 Aug 94 13:15:45 TZ
----------
| From: Marc Horowitz <marc@MIT.EDU>
| To: <www-security@ns1.rutgers.edu>
| Subject: Re: Kerberos authentication for X-Mosaic 2.4 and NCSA HTTPD
| Date: Sunday, August 14, 1994 4:22PM
|
[...]
|
| Before you all go out and reinvent the wheel, I think it would be
| productive for people to go out and read the following documents:
|
| ftp://ftp.internic.net/rfc/rfc1508.txt
| ftp://ftp.internic.net/rfc/rfc1509.txt
In addition, there is an internet draft by IETF called "FTP Security
Extensions" detailing plans on the use of GSS in the FTP server (I only
have a local copy, can somebody provide a pointer to an Internet copy?).
At this point, people should understand there are two very different
issues that we are dealing with:
1) A model for pluggable security providers in Web servers and clients
2) The age old question of how to add support in HTTP (i.e.,
Secure-HTTP etc.) for any random provider.
The two are linked but I don't think they are tightly coupled (except
in one or two key spots).
I would like to propose using the GSS API (RFC 1508 and RFC 1509 (the
latter gives the C-Language spec for the API)) as the model for a
dynamic link library (DLL) interface that Web servers and Web clients
can use for plug'n'play authentication and encryption. It should be
obvious to everyone a multitude of known and unknown schemes will need
to be supported. With a runtime pluggable interface for both the
client and the server, distributing updated or new
authentication/encryption schemes is a matter of providing a 40k file
instead of a multi-megabyte file set. In addition, this may have the
added benefit of preventing a proliferation of somewhat compatible
servers/viewers because sites can customize the tools for their
particular requirements without having to munge the sources.
First, go read the GSS specs. They are well written and appear to
accurately reflect the various security schemes out there. If you
can't encapsulate you're preferred flavor in the GSS APIs, then please
indicate where it is deficient.
A transaction from the client perspective may look like:
1) The user starts the viewer which then checks which GSS DLLs are
available to it. The viewer loads the DLL entry points and queries
each DLL for an HTTP compatible string that will advertise its services.
2) The user opens a remote URL. The viewer builds the GET request and
includes the headers from the GSS APIs and puts it on the wire.
3) The server responds and includes the type of service (if any) it
would like to use. The viewer then selects the GSS DLL that advertised
the service for all further communication (this includes
authentication, sealing and signing).
From a server perspective:
1) The server starts and checks which GSS DLLs are available to it.
The server loads the DLL entry points and queries each DLL for an HTTP
compatible string indicating the services it provides.
2) The server receives a client request and looks through the available
auth./enc. services in the client request header (preferenced expressed
by ordering in the header). The server selects the most preferred
service that matches services available to it, builds a response with
this information and puts it on the wire. The server uses the GSS DLL
it selected for all further communication.
We should be able to get to the point where the same binary image can
be used on both the server and the client.
The open issues I've thought of off the top of my head include:
1) Need to add an API for advertising the services a GSS DLL provides
2) The above example is a simplified case. You should be able to use
one provider for authentication and another provider for encryption.
3) GSS defines a way to have several steps in the authentication
process between the client and server (as would be used in a client
connect->server challenge->client response scenario). Does Secure-HTTP
provide support for this?
4) More detail needs to be added for exactly when the server/client
calls the GSS API.
I realize this is perhaps more work in the short term then what people
may be willing to implement but in the long term we'll be better off if
we get this right.
So, what holes are there? Why won't this work? What needs to be
changed/added so this will work for your particular implementation?
