Misconceptions about the GSS-API

I wanted to clear up some misconceptions about the GSS-API I saw here
over the last 24 hours, and repeatedly elsewhere over the last decade.

0) The GSS-API is really just an abstract interface to authentication
protocols.  The authentication protocols are termed "mechanisms" in
GSS-API terminology.  The GSS-API does not specify a protocol so much
as a form of protocol that is really quite standard: first there's a
synchronous exchange of messages that provide authentication and/or
key exchange, then there's what TLS calls the application record
layer, but which GSS calls "per-message tokens".  GSS-API application
record semantics are richer still than DTLS' but easily supports octet
stream applications.

There are three parts to the GSS-API: an abstract API used for
describing the form of the protocols, an actual API specification
(with C, Java, other bindings) that need not be used, but is
convenient, and the concrete security mechanisms.  The last specify
the bits on the wire.  An application that uses the API can be written
such that it can use *any* mechanism, which makes the API *pluggable*,
which means that the choice of mechanism is not dictated by the IETF
but by users in the field and the authentication infrastructures that
they have already deployed.

1) The GSS-API is -in fact- widely deployed and used.  The SSPI is a
very similar API that provides access to GSS mechanisms.  The SSPI is
one of the most widely used security APIs ever.

2) Implementors need not implement the GSS-API in order to
use/implement GSS security mechanisms.  That's because the mechanisms
are the protocols, and the API is just an API.

3) The GSS-API is a very large API, yes, but typical applications use
only a very small subset of the available GSS functions.  A simple
client application can use as few as two functions (not counting
destructors).  Do not let the size of the API scare you.  It's large
because complete, not because complicated.  To be sure, it is possible
to design applications that can use large numbers of GSS-API
functions, but REST-GSS is designed to be quite a simple GSS
application.

Note by the way that REST-GSS uses SASL, not GSS, but it uses GSS
mechanisms through SASL/GS2.  SASL/GS2 is a trivial SASL layer above
GSS.  There's a reason for this: it's simpler for those implementors
who wish to use GSS security mechanisms without using the API, while
not really making implementation more difficult for those who have and
want to use a GSS-API implementation.

Nico
--

Received on Friday, 13 July 2012 19:59:18 UTC