- From: Nico Williams <nico@cryptonector.com>
- Date: Fri, 13 Jul 2012 14:28:06 -0500
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: Paul Hoffman <paul.hoffman@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Fri, Jul 13, 2012 at 12:40 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote: > On Fri, Jul 13, 2012 at 1:24 PM, Nico Williams <nico@cryptonector.com> wrote: >> On Fri, Jul 13, 2012 at 12:37 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote: >>> I really dislike the idea of having a platform inside a platform >>> >>> TLS is way too big for comfort. GSSAPI has mechanism on mechanism. >> >> I'm not sure I understand. The GSS-API is just an API. > > Which makes it a non-starter as HTTP is a protocol. How does a > protocol interact with an API? GSS-API is an API to a protocol. The protocol is the selected GSS-API *mechanism*. "Mechanism" here means: Kerberos, ABFAB, whatever -- that which defines the format of authentication messages. GSS is *not* a mechanism, just an interface to them. Just two[*] GSS-API functions are enough to implement a REST-GSS client: GSS_Import_name() and GSS_Init_sec_context(). It's *really* easy to write a simple GSS client application. Moreover, because the GSS-API comes with an *abstract* API it's also easy to specify an application protocol that uses GSS in a very precise (and therefore more likely to interop) way. [*] four when you add the two corresponding destructors, six altogether when you add the ability to select a client credential from among several. >> It defines a >> tiny bit of protocol. To give you an idea of just how little >> "mechanism on mechanism" the GSS-API has just consider the fact that >> SSPI is teh interface to TLS on Windows, and that the GSI TLS >> mechanism for GSS is wire-compatible with TLS even though it's being >> invoked from the GSS-API! > > I have no way to parse or make sense of what you are trying to say. > > A protocol and an API are two different things. The GSS-API is an API to a protocol where the *form* of the protocol is the same for all mechanisms but the *specific details* of each mechanism are specified by the mechanisms themselves. The *form* of the protocol is trivial: first there's an exchange of "security context tokens" that authenticate the peers and exchange session keys, then there's "per-message" tokens that the application can use in any way it wants to provide confidentiality and/or integrity protection to the application's data. The per-message token choices are quite rich in semantics, allowing for applications that want octet streams and applications that want datagrams. The GSS-API specifies a tiny bit of on-the-wire bits: optional token headers that *standard* mechanisms must have but that others need not. > If its not bits on the wire or describing the state at either end then > it isn't a protocol and if it isn't a protocol it has no place in HTTP > spec. See above. >> I think we need protocols that work with the types of credentials that >> people have *already* deployed, whether those be smartcards, >> passwords, OTPs, two-factor, or whether the infrastructures be based >> on RADIUS, Kerberos, ... >> >> There are large investments in these things already made. > > Nowhere near as large as the investment in HTTP and we are proposing > to change that. Apples and oranges. HTTP on the web mostly doesn't do anything for authentication. There's no investment there to protect. But there *is* authentication elsewhere (in HTTP on corporate networks, and above HTTP on the web), and that investment is really a great deal of inertia. There is also an enormous investment in HTTP, but I challenge you to show me how my proposal fails to be orthogonal to it. Nico --
Received on Friday, 13 July 2012 19:28:29 UTC