Subject: Misconceptions about the GSS-API

From: Nico Williams <[email-masked]>
Date: Fri, 13 Jul 2012 14:58:55 -0500

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
--

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 20:37:49 +0000

In message <[email-masked]>
, Nico Williams writes:

>only a very small subset of the available GSS functions.

Just out of curiosity:

Does that really sound like good security engineering for a
narrow-scope protocol like HTTP/2 to you ?

It certainly sounds wrong to me.

It almost certainly IS wrong, if the goal is to get as many mediocre
programmers as possible to implement protection correctly.

One of the main reasons Varnish does not support HTTPS is the the
quality of the APIs available, and the elephantine amounts of
needless generality behind them.

I know crypto is never simple, but arguing that it comes with a lot
of complexity that most users don't need, is not a winning argument
in my book.

Crypto for HTTP/2.0 should be specified in a way which is very hard
to do wrong, not very hard to do right.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Jul 2012 16:04:41 -0500

> programmers as possible to implement protection correctly.

There are many enormous APIs out there where only a small subset is
necessary for common applications.  The functions that most GSS
applications don't need are not functions that you can shoot your feet
off with.  It sounds to me like you're not familiar with the GSS-API.

> needless generality behind them.

APIs like OpenSSL's are awful, I give you that.  If you used the
GSS-API as an interface to TLS you'd have a very trivial client,
particularly for anonymous clients.  You'd only need these functions:

 - GSS_Import_name(), which you'd call to get a NAME object
corresponding to the server's hostname
 - GSS_Init_sec_context(), which you'd call with that NAME object, the
mechanism OID for TLS, and all default arguments
 - GSS_Wrap() and GSS_Unwrap() to implement the application record layer
 - GSS_Release_name(), GSS_Deleset_sec_context(), and
GSS_Release_buffer() to release resources

That's *it* (oh, and GSS_Display_status() to get printable errors).
All the complexity of validating the server cert and ensuring that it
is good for the given hostname would be buried in the mechanism.  If
you need to specify different trust anchor sets for different hosts
that would require one more function (though the GSI TLS mechanism
doesn't support it, but I could make sure it gets added...).

> of complexity that most users don't need, is not a winning argument

It really pains me to see you say this about GSS -- you don't know,
you can't know, because you'd not say that if you knew it.  OpenSSL's
APIs are an utter usability disaster.  GSS' aren't.

> to do wrong, not very hard to do right.

I agree violently.

Nico
--

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 21:11:21 +0000

In message <[email-masked]>

>particularly for anonymous clients.  You'd only need these functions:

You seem to overlook half of my argument:  It is both a matter of
API design *AND* lugging around tons of unnecessary code.

>> to do wrong, not very hard to do right.

So lets start from there, if we ever get a chance.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jul 2012 17:18:57 -0400

> off with.  It sounds to me like you're not familiar with the GSS-API.

And intend to remain so unless you can identify the small subset that
is needed and separate it out from all the rest.

Oh and explain the whole project in terms of bits on the wire rather
than multi-tiered abstractions that mean something to people with
decades of experience of GSS-API but nothing to the rest of us.

I have been in the business of Web Security twenty years as of
September. In all that time the only people who have ever brought up
the issue of support for it have been GSS-API developers. I have never
once had a customer ask for it.

> corresponding to the server's hostname

You still don't get our point. How does this call relate to HTTP? What
data objects are produced? What do they look like on the wire? How
does it affect protocol state?

What you have there is not a protocol, it is an implementation.

> doesn't support it, but I could make sure it gets added...).

Assuming that we embed your library into all the clients and servers.

> APIs are an utter usability disaster.  GSS' aren't.

This is about the choice of a protocol, not an API.

-- 
Website: http://hallambaker.com/

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Jul 2012 16:20:44 -0500

> API design *AND* lugging around tons of unnecessary code.

Who said you have to?  You don't even need to use the GSS-API itself
to access GSS mechanisms.

I'm using the GSS-API in REST-GSS not because I expect apps to "lug
around" complete GSS implementations, but because it helps produce a
more formal specification.  I'm using the *abstract* API.
Implementors are free to not use the API at all yet still interop.

> So lets start from there, if we ever get a chance.

See the above.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Jul 2012 16:53:10 -0500

> is needed and separate it out from all the rest.

I can commit to writing an I-D in short order describing "profiles" of
the API, but I'd expect you to read it :)

> decades of experience of GSS-API but nothing to the rest of us.

Well, different audiences will want different points of view.  I could
try several approaches.

> once had a customer ask for it.

Did they ever ask for HTTP/Negotiate?  Did they ever ask for SSPI?

> does it affect protocol state?

See my I-D!  It has figures, with bits on the wire.  Textual bits on
the wire!  My examples use SCRAM, which is all-text, with only a tiny
bit of base-64 encoding of binary data.  Here:

http://tools.ietf.org/html/draft-williams-rest-gss-01#section-3

BTW, my classification I-D also has examples of what several possible
approaches might look like:

http://tools.ietf.org/html/draft-williams-httpbis-auth-classification-01#section-3.3

> What you have there is not a protocol, it is an implementation.

No.  It's a protocol.  The use of the API is strictly for
specification purposes.  Implementors can use or not use the API.

> Assuming that we embed your library into all the clients and servers.

Nope.  See my reply to Poul-Henning Kamp.  The API is NOT required for
implementing.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Jul 2012 17:10:00 -0500

Maybe we should rename the bloody thing...  One more misconception
seems to be that "API" means you must have a library and use _it_.
But GSS is an *abstract* API and there's no need to either have a
complete implementation, nor to have C or any other bindings of the
abstract API.  Microsoft, for example, has been using SSPI instead of
GSS for ages, yet interops on the wire.  Samba has implemented GSS
without using the API at all.  Those are existence proofs...

We created SASL/GS2 (which is what REST-GSS actually uses) in large
part to simplify things.  I should have called it REST-SASL..  Maybe I
still can!

Nico
--