- From: Nico Williams <nico@cryptonector.com>
- Date: Fri, 13 Jul 2012 16:53:10 -0500
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Jul 13, 2012 at 4:18 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote: > On Fri, Jul 13, 2012 at 5:04 PM, Nico Williams <nico@cryptonector.com> 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 --
Received on Friday, 13 July 2012 21:53:34 UTC