Subject: RE: Planning for DC IETF CAT session

From: "Mike Swift (NT)" <[email-masked]>
Date: Thu, 30 Oct 1997 18:37:07 -0800

At the last IETF meeting there was a BOF for designing a new authentication
protocol/ interface because GSS-API was seen as too difficult to use. TLS
doesn't use GSSAPI. IPSEC similarly is developing authentication protocols /
key exchange protocols without using GSSAPI. While there are many protocols
that do use GSSAPI (IMAP, SASL) for example there is still a widespread
perception that it is too hard and cumbersome to use. Perhaps there is a
need for some simple non-ASN.1 authentication mechanisms that are more
usable, such as a simple challenge-response protocol, or a set of good
examples of how to correctly call GSS-API.

- Mike Swift

> -----Original Message-----
> From:	Dennis Glatting [SMTP:[email-masked]]
> Sent:	Thursday, October 30, 1997 6:22 PM
> To:	Mike Swift (NT)
> Cc:	Linn, John; 'CAT-WG List'
> Subject:	Re: Planning for DC IETF CAT session
> 
> 
> From: "Mike Swift (NT)" <[email-masked]>
> Date: Thu, 30 Oct 1997 11:35:58 -0800
> 
> > There are far too many groups that are inventing their own
> > authentication and security negotation mechanisms and I
> > believe the CAT group should either do more evangelizing of its
> > current technologies or really look at why what it has today
> > doesn't work and come up with some plans to address their
> > issues.
> >
> 
> Such as...?
> 
> 
> -dpg

---

From: Dennis Glatting <[email-masked]>
Date: Fri, 31 Oct 97 07:43:49 -0800

From: "Mike Swift (NT)" <[email-masked]>
Date: Thu, 30 Oct 1997 18:37:07 -0800

> At the last IETF meeting there was a BOF for designing a new
> authentication protocol/interface because GSS-API was seen
> as too difficult to use. TLS doesn't use GSSAPI. IPSEC
> similarly is developing authentication protocols / key
> exchange protocols without using GSSAPI. While there are many
> protocols that do use GSSAPI (IMAP, SASL) for example there is
> still a widespread perception that it is too hard and
> cumbersome to use. Perhaps there is a need for some simple
> non-ASN.1 authentication mechanisms that are more usable,
> such as a simple challenge-response protocol, or a set of good

I couldn't attend the last IETF but speaking as an author of
multiple GSS-API implementations and as an integrator it is my
belief the GSS-API is not a "one size fits all" kind of API and
making the GSS-API simpler or more complex doesn't fix
anything.

The GSS-API is an attempt to apply--what I have called--a layer
of peanut butter over complex security mechanisms. The
GSS-API, like peanut butter, can become a sticky and gooey
mess. For example, (note: I have not read the latest documents)
if an application of the GSS-API is not simple--perhaps the
client pieces and their communication with a server is simple
but the service side is quite complex--the GSS-API is often
subverted to perform low-level mechanism-specific and/or
implementation-specific tasks, such as a multi-threaded
server managing individual Kerberos credential caches
specific to authenticated clients which are later accessed by
other applications. Another example is a layered service
where authentication is performed at a high level using the
GSS-API but the shared key material must be extracted from the
context and fed into a legacy lower layer. These examples are
quite different from the GSS-API is too complex perspective.
Here it is too simple. On the other hand I have long been told the
GSS-API was too complex and, to be frank, for most of that time I
just didn't get it. Now I do, me thinks. :)

The problem is one of abstraction complexity and simplicity.
In my complex server example more capability is needed to
influence mechanism and/or vendor-implementation specific
behavior but the problem is to create a useful and
understandable abstraction to handle all possibilities. Not
possible, IMHO. On the simplistic side the abstraction can be
too simple thereby not providing flexibility, such as
eliminating the QOP parameter from gss_wrap().

Some years ago I developed C++ bindings for the GSS-API. With
overloaded functions, anonymous types, and other
language-specific features I believed I achieved a more
simplistic GSS API. One could pass as many or as few parameters
as they wished and instantiate a GSSInitiate class or import a
name to a GSSName class, for example. Often the overloaded
functions and constructors were simply a peanut butter layer
on top of a complex one. That seemed like a simple interface to me
but the number of overloaded functions and constructors made
the classes appear complex. Sigh.

So what am I saying? Perhaps the IETF should stick to protocols
and avoid APIs and, from my own personal perspective, I see the
GSS-API as something to learn from, not a "one size fits all."
When you get down to the brass knuckles facts, what is the
GSS-API anyway? Well, it's not just an API. It is also a
protocol. Perhaps we should dispense with the API and focus on
the protocol? That would certainly simplify things. Better
yet, we could standardize an API for each IETF secure protocol
thus eliminating most of the current abstraction goo. We could
also develop boiler plate API specifications, such as a
standard manner and form for setting and testing parameters,
buffer management, managing multi-level error information,
and multi-thread considerations. Work groups could elect to
develop an API themselves from the API boiler plate
specifications or, preferably, pass that task to another
group whose speciality is security APIs--the CAT group, for
example.

Just my $0.02.

-dpg