Subject: HTTP2 Expression of Interest

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Jul 2012 19:22:22 -0700

Greetings again. I am not an implementer or a deployer. I am making
this statement of interest as Just Some Person. Please take these
comments in that light relative to those from implementers and
deployers.

Given what we know about users inability to choose good passwords and
their lack of ability to use good passwords that are chosen for them,
it is incredibly important that a non-password authentication
mechanism be described for HTTP 2. Thus, I support HOBA or something
HOBA-like. The HOBA proposal as it stands has a lot of significant
issues, but the idea of portable origin-bound certificates for HTTP
clients is the correct way to do non-password authentication for HTTP.
draft-williams-rest-gss relies on GSSAPI, which has thin adoption even
after many years. draft-montenegro-httpbis-multilegged-auth is an
interesting way to get non-password authentication (and NTLM!) into
HTTP, but I suspect that not having a mandatory authentication
mechanism that is widely supported will mean that this document will
go unimplemented.

At least one password-based authentication mechanism should also be
standardized for HTTP 2. Of these, draft-oiwa-httpbis-mutualauth and
draft-oiwa-httpbis-auth-extension seem to solve more of the problems
with passwords than draft-melnikov-httpbis-scram-auth.

I am willing to contribute to and review proposals for non-password
authentication. I am willing to provide a bit of late review to a
password-based proposal.

--Paul Hoffman

---

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

On Thu, Jul 12, 2012 at 9:22 PM, Paul Hoffman <[email-masked]> wrote:
> after many years. [...]

If you consider that the SSPI is very similar to the GSS-API, and
wire-compatible with it anyways, then that assertion is quite clearly
incorrect.  SSPI is extremely widely used, both in proprietary
application protocols and standard ones (including TLS, since SSPI is
the interface to TLS in Windows).

The GSS-API has had a dearth of mechanisms for it deployed, but this
is beginning to change.  We now have all of these standardized and/or
deployed:

 - Kerberos (including IAKERB)
 - GSS-EAP (see ABFAB WG)
 - SCRAM
 - Microsoft's PKU2U (PKI, based on Kerberos w/ PKINIT)
 - the GSI mechanism that is really just TLS repackaged as GSS

   (See again how SSPI is the interface to TLS in Windows.
    It's also the interface to SASL.)

 - OAuth and SAML-based mechanisms are in the works as well.

It's easy enough to add new GSS-API mechanisms, but between GSS-EAP,
Kerberos (particularly with trust routing and bootstrapping
enhancements), PKU2U, OAuth, and SAML I think we have most needs
covered.  A ZKPP mechanism or three should be added, but unless that's
done in a way that federates then I think it's best to make sure that
GSS-EAP can use ZKPP EAP methods and Kerberos can use ZKPP
pre-authentication mechanisms.

The biggest Internet protocol users of the GSS-API are SSHv2 (yes,
really, SSHv2 w/ GSS and Kerberos is widely deployed in corporate
networks), LDAP (see again Windows), and NFS.  But also IMAP (see
Exchange), DNS (GSS-TSIG, see Active Directory and Windows) and
others.  There's also widely deployed non-Internet standards-track
protocols, such as SMB, as well as many proprietary protocols.  And
then there's HTTP/Negotiate -- how could I forget!  (though to be sure
I don't really like HTTP/Negotiate, otherwise I might just have
proposed that.)

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jul 2012 01:37:02 -0400

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 don't want a choice of fifty ways to authenticate. I want exactly
one mechanism to support each type of authentication. I certainly
don't want a choice of crypto protocols to verify passwords. In fact I
don't want passwords to be flowing over the net at all. The proper use
of a password is to unlock the user's credential on their
authentication device.

SAML and OAUTH and the rest already define an interaction with HTTP.
If we want to adopt those as mechanisms we should adopt them directly
into HTTP and not introduce a platform step.

But even there we should not accept the whole of either spec. Much of
the argument in SAML went into the design of a mechanism that could be
used with legacy Web browsers. Same for OAUTH. Now it will certainly
be necessary to consider how we transition to HTTP 2.0 but I would
want to jettison the entire transition structure once we get there.

But really we have a much smaller set of concerns. In particular we
should distinguish between the different things that are called
'authentication' and we should not incorporate any mechanism into the
spec that is incompletely specified. By which I mean relying on out of
band configuration or exchange of credentials.

Specifically we have the following activities that are all known as
'authentication':

CREDENTIAL-Authentication Is this the user claiming to be the owner of
account 'X' the same user who was issuedaccount 'X'

RE-Authentication: Is this the same user that authenticated previously?

FED-Authentication: Is the user claiming to be acct:[email-masked]
the same user that other sites accept as acct:[email-masked]

Now credential authentication is a strict subset of the federated case
so it may not be desirable to distinguish the two on an ongoing basis
but RE-Authentication is something rather different.

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

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Jul 2012 12:24:02 -0500

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

> one mechanism to support each type of authentication. I certainly

Good luck coming up with a single mechanism that works on an Internet
scale, on corporate networks, with BYOD, with IT-managed desktops, ..
and that meets the requirements of all those involved.  And as if that
were not hard enough, you'll have to come up with one mechanism that
manages to use the existing infrastructures that people already have
or else makes it real economic (read: *CHEAP*) to replace those.

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.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jul 2012 13:40:09 -0400

On Fri, Jul 13, 2012 at 1:24 PM, Nico Williams <[email-masked]> wrote:
> 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?

> It defines a

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.

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.

> or else makes it real economic (read: *CHEAP*) to replace those.

Been there, done that. I was editor of SAML 1.0. I think I know the
range of complexity out there.

But HTTP 2.0 should not be SAML either. We have an opportunity here to
address the central problems that SAML, OpenID and OAUTH have to work
around all the time.

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

---

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

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

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

> it isn't a protocol and if it isn't a protocol it has no place in HTTP

See above.

> Nowhere near as large as the investment in HTTP and we are proposing

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

---

From: Paul Leach <[email-masked]>
Date: Fri, 13 Jul 2012 19:31:29 +0000

I'd like to quibble a little with the description of the "authentication activities"; they all have the same flaw which can be illustrated by a proposed modification to the first one:

	CREDENTIAL-Authentication: Is this the user _who sent this HTTP request_ and claiming to be the owner of account 'X' the same user who was issued account 'X'?

Why is the change necessary? Because one of the biggest problems with current security mechanisms at the HTTP layer is that there is very little binding between the identity of the user making the connection and the request coming over the connection. None of the existing in use mechanisms except Digest even tries, and Digest usually only binds the request URI and method of the request to the authenticated identity. As a result, any MITM can almost completely change the request, so that knowledge of who sent the Authentication header is basically irrelevant if real security is needed.

As a further result, the only time that HTTP layer authentication has any real security value is when it is tunneled inside of TLS, and _has its channel bound_ to the authentication.

Note that Digest also (in a less-used feature) has a way to bind the request body and the response body to the identity of the requesting user. Unfortunately, it doesn't bind the rest of request and response headers; that's because proxy servers are allowed to rearrange them, and coming up with a canonical form that allowed for that seemed intractable. Also, Digest doesn't support chunked encoding, so that very large or indefinite length entity bodies are at best problematic. 

Also note that Digest has an "MD5-sess" mode that provides for the "RE-authentication" mode that Phillip defines.

(The biggest problem with Digest is that the construction of the keys it uses from the password does not specify how to handle any character set other than ASCII. I was clueless about that in those days.)

-----Original Message-----
From: Phillip Hallam-Baker [mailto:[email-masked]] 
Sent: Thursday, July 12, 2012 10:37 PM
To: Nico Williams
Cc: Paul Hoffman; [email-masked]
Subject: Re: HTTP2 Expression of Interest

I don't want a choice of fifty ways to authenticate. I want exactly one mechanism to support each type of authentication. I certainly don't want a choice of crypto protocols to verify passwords. In fact I don't want passwords to be flowing over the net at all. The proper use of a password is to unlock the user's credential on their authentication device.

SAML and OAUTH and the rest already define an interaction with HTTP.
If we want to adopt those as mechanisms we should adopt them directly into HTTP and not introduce a platform step.

But even there we should not accept the whole of either spec. Much of the argument in SAML went into the design of a mechanism that could be used with legacy Web browsers. Same for OAUTH. Now it will certainly be necessary to consider how we transition to HTTP 2.0 but I would want to jettison the entire transition structure once we get there.

But really we have a much smaller set of concerns. In particular we should distinguish between the different things that are called 'authentication' and we should not incorporate any mechanism into the spec that is incompletely specified. By which I mean relying on out of band configuration or exchange of credentials.

CREDENTIAL-Authentication Is this the user claiming to be the owner of account 'X' the same user who was issuedaccount 'X'

FED-Authentication: Is the user claiming to be acct:[email-masked] the same user that other sites accept as acct:[email-masked]

Now credential authentication is a strict subset of the federated case so it may not be desirable to distinguish the two on an ongoing basis but RE-Authentication is something rather different.

On Fri, Jul 13, 2012 at 1:16 AM, Nico Williams <[email-masked]> wrote:
>> draft-williams-rest-gss relies on GSSAPI, which has thin adoption 
>> even after many years. [...]
>

---

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

+1

Also note that the major constraint on the design of DIGEST was that
it had to be open and unencumbered which meant not using RSA or
Diffie-Hellman at the time.

We knew better at the time we made the original proposal. The problem
was that we could not do things the way we wanted.

The KGB has an interesting doctrine, every message has to be secured
by two independent mechanisms that have to independently provide for
complete protection of the message based on different principles. [As
a result they ended up killing a few dozen cipher clerks with ionizing
radiation generators in their enclosures prompting the defection of
one of their top crypto people. But that is another issue]

What I am saying is that adding security at the HTTP layer is really
orthogonal to the need for TLS or not. More to the point, even if we
got rid of TLS there would still be a need to authenticate servers and
thus a need for some form of open authentication infrastructure for
servers which means a CA-like entity.

If you want HTTP messages to tunnel through proxies then you are going
to need to be realistic about the practicality of securing headers. If
you don't need that capability (and I haven't used a proxy
intentionally for 15 years) then you can be more aggressive.

If we want to secure anything more than the content in HTTP 2.0 then
we probably need to think about ways to separate out headers that are
content metadata and thus should be inside the security envelope from
routing headers which ain't.