[23] in WWW Security List Archive
Re: GSS API...
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Tue Aug 16 04:19:52 1994
To: John Ludeman <johnl@microsoft.com>
Cc: www-security@ns1.rutgers.edu
Date: Tue, 16 Aug 1994 01:45:37 EDT
From: Marc Horowitz <marc@MIT.EDU>
>> | 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?).
I listed five documents. The fifth was the FTP security extensions
draft. Here's the full list again:
ftp://ftp.internic.net/rfc/rfc1508.txt
ftp://ftp.internic.net/rfc/rfc1509.txt
ftp://ftp.internic.net/internet-drafts/draft-ietf-cat-kerb5gss-01.txt
ftp://ftp.internic.net/internet-drafts/draft-ietf-spkmgss-00.txt
ftp://ftp.internic.net/internet-drafts/draft-ietf-cat-ftpsec-05.txt
>> 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.
RFC 1509 as it currently stands isn't quite specific enough to
unambiguously define how a plug'n'play DLL should be written.
However, a proposal for how to do just this was floated last week on
the relevant IETF list (mail cat-ietf-request@mit.edu if you want on),
and it seems like mostly a no-brainer. (Basically, nail down the
opaque types to be a simple scalar or void *, and declare all pointers
to be FAR.)
>> If you can't encapsulate you're preferred flavor in the GSS APIs, then
>> please indicate where it is deficient.
Yes, please do! To me personally, if not the list, so I can pass the
comments on to the working group. We really do want to get this
right. Note that GSSAPI as it currently stands is intended for
real-time communications, it doesn't do store-and-forward semantics
yet.
>> A transaction from the client perspective may look like:
>> From a server perspective:
Actually, it's simpler than this. People have discussed implementing
a mechanism which isn't really a mechanism, but a wrapper around
existing mechanisms which will negotiate a satisfactory mechanism
between the client and server based on the mechanisms available to the
client and server, and the security requirements requested by the
application. The practical upshot of all this is that you get a lot
of portability and versatility without doing the hard work yourself.
>> 1) Need to add an API for advertising the services a GSS DLL provides
GSSAPI provides this already, in the form of the qop and related
flags.
>> 2) The above example is a simplified case. You should be able to use
>> one provider for authentication and another provider for encryption.
[GSSAPI terminology ahead:] I see no reason why you couldn't use
gss_seal() to sign the data with one context, then use gss_seal() to
encrypt it with another, should you so choose.
>> 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?
This is a real problem, especially if you want to provide negotiation.
>> 4) More detail needs to be added for exactly when the server/client
>> calls the GSS API.
Yup. The FTP spec is probably a good place to start as an example.
>> 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.
Amen :-)
Marc
