Re: HTTP2 Expression of Interest

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