Subject: GSS Usage [Was: RE: Planning for DC IETF CAT session]

From: "Linn, John" <[email-masked]>
Date: Fri, 31 Oct 1997 10:06:26 -0500

Mike Swift writes:

> 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.
> 
These are important concerns.  First, I think it would be useful to
establish common understanding of where GSS-API has been applied within
the IETF; I'm aware of the following:

FTP security
SASL (and, through SASL, IMAP (and other SASL consumers?))
ONC-RPC
IPsec (as of a working draft for isakmp-oakley-05, currently being
discussed on ipsec list)

This is a modest list.  Mike raises two possible reasons for this fact:

1) perceived complexity of interface: as Mike suggests, this may be an
educational issue.  Would anyone be interested and in a position to
enhance or contribute to the set of available GSS-API sample/example
code, to demonstrate workability?

2) unavailability (actual or perceived) of suitable mechanisms to
satisfy prospective callers' requirements; this is a matter not only of
the mechanism specifications which are deliverables of the WG per se but
also of implementation availability for those mechanisms.  Would anyone
be interested and in a position to contribute significantly towards
definition and implementation of additional mechanisms, and/or to
maintain a cross-mechanism catalog of available implementations?

and I'll add the following additional candidates:

3) consideration by protocol designers that it's most appropriate in
their environments to specify and incorporate security facilities
directly rather than by incurring a dependency on separate providers
(whether via GSS-API or otherwise)

4) technical incompatibilities between GSS-defined services and specific
caller requirements (e.g., non-orientation to protection of
"byte-at-a-time" protocols) ; is anyone aware of ongoing protocol
definition activities which would be likely GSS integrator candidates if
such issues were to be addressed, and (if so) what the gating issues are
for those cases?

--jl

John Linn ([email-masked]), writing as an individual from
RSA Laboratories East, Bedford, MA, USA