Re: Misconceptions about the GSS-API

[Nico Williams <[e-mail]>]

On Fri, Jul 13, 2012 at 4:18 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> On Fri, Jul 13, 2012 at 5:04 PM, Nico Williams <[e-mail]> wrote:
>> 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.
>
> And intend to remain so unless you can identify the small subset that
> 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 :)

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

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

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

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

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

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.

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