Subject: RE: low-infrastructure GSS mechanisms?

From: Paul Leach <[email-masked]>
Date: Mon, 21 Dec 1998 18:25:39 -0800

The other beef I have heard is about the complexity of using GSS in general,
and of implementing a GSS mechanism.

On the using side, I think it would be possible to make some "convenience"
GSS APIs that
a) given an open socket descriptor and a mechanism name, would do all the
lower level GSS calls, returning when authentication had been completed, and
negotiate privacy and integrity
b) are plugin (near) replacements for send() and recv() that do the gss_wrap
if needed, with the right privacy/integrity flags.

This would make it quite easy to use GSS in an application protocol, and
eliminate that beef.

> -----Original Message-----
> From: Theodore Y. Ts'o [mailto:[email-masked]]
> Sent: Monday, December 21, 1998 5:58 PM
> To: Paul Leach
> Cc: 'Theodore Y. Ts'o'; Richard B. Ward (Exchange); 'Linn, John';
> 'CAT-WG List'
> Subject: Re: low-infrastructure GSS mechanisms?
> 
> 
>    From: Paul Leach <[email-masked]>
>    Date: Mon, 21 Dec 1998 17:39:04 -0800
> 
>    I know that the people who want SASL think that SSL and 
> Kerberos are too
>    heavyweight (big implementations) -- they have resisted 
> making those
>    mandatory-to-implement (MTI) in LDAP WG and other WGs on 
> that basis. Hence,
>    I predict that a DH based scheme would also be judged too 
> heavyweight for
>    the general purpose "eliminate plaintext passwords MTI" scheme. 
> 
> If the folks who didn't like SSL didn't like it merely because of "big
> implementations", there's no reason that a D-H scheme has to 
> be all that
> large.  So if it's just that, all that should be needed to make their
> resistence go away is for someone to implement a small, 
> no-nonsense D-H
> and make it available as freeware for folks to put into the their
> products.
> 
> There are of course other definitions of "heavyweight" that 
> people might
> be complaining about:
> 
> 	* Infrastructure requiring (Kerberos and SSL if you're doing
> 		client certs)
> 	* Hard to implement (which we can trump with a good Open Source
> 		reference implementation)
> 	* Time to authenticate (SSL)
> 
> We can't do much about the authentication time --- that's 
> inherent in PK
> based solutions.  But for many applications, this shouldn't 
> be an issue,
> since the context establishment is only done at the start of the
> connection.  There are exceptions of course, such as badly designed
> protocols like HTTP --- a lot of the hair in SSL is 
> performance hacks to
> get around that the fact that you need to make repeated TCP 
> connections,
> and thus mitigate the cryptographic (but not the TCP slow start)
> implications of such a bad design choice.
> 
> I was assuming a simple D-H scheme that didn't make such 
> accomodations,
> which should be much easier to make to be lightweight.
> 
> 						- Ted
> 
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 21 Dec 1998 23:49:36 -0500

From: Paul Leach <[email-masked]>
   Date: Mon, 21 Dec 1998 18:25:39 -0800

I agree.  I suspect one of the reasons why the apps folks like SASL is
that there are various libraries and code fragments floating around
which provide code they can reuse to make it easier to add GSSAPI to an
application program.  (Yes, SASL supports some other authentication
mechanisms not supported by GSSAPI, so it isn't the only reason for its
popularity, but I think this is a major reason why they like SASL; they
have code which makes it easy for them to add GSSAPI support to
application protocols which use GSSAPI in a SASL framework.)

One caveat with specifying convenience API's is that they tend to be
extremely OS specific --- for example, passing in an open socket
descriptor assumes a BSD Sockets or Winsock style interface.  We could
standardize such an interface, but it would not be useful on certain
platforms, such as MacOS.

My guess is that specifying convenience API's as a formal standard isn't
as important as making sure there are reference implementations
available to application programers.

							- Ted