Subject: [http-auth] My list of issues to be tackled in http auth framework

From: "Paul Leach" <[email-masked]>
Date: Wed, 31 Oct 2012 21:19:10 -0400

In this post I undertake to outline issues with which an authentication framework for HTTP needs to deal.

I do so by sketching the typical behavior of many authentication protocols in setting up and using secure sessions, then relating it to the HTTP context.

A typical authentication protocol initially exchanges a few messages between client and server, which securely identifies the requestor (and sometimes the server) and which arrives at a mutually agreed upon key for the session, after which the key is used to provide authentication and/or confidentiality for subsequent application protocol traffic on that session. The session also typically provides replay prevention. Some schemes provide optimized session re-establishment if the underlying transport connection is dropped.

HTTP issues

The key agreement phase requires that state be kept between messages, and the HTTP authentication framework [RFC 2617] provides no mechanism for associating requests with an authentication session. (Individual authentication schemes can provide their own, but this complicates addition of new schemes.) Since proxies may have more than one connection to an origin server, and may forward requests from a client along any of them, transport connections can not be used for this purpose. (And with multiplexing in HTTP/2.0, it doesn't even require a proxy to create this problem -- a single client-server connection can have it.)

After key agreement, the key and any information needed for replay prevention are session state, and present the same problem.

Even in the absence of proxies, transport connections may be dropped at any time. The effectiveness of optimized session re-establishment depends on the session being usually re-established on the same system as it was initially established.

There is no support for authenticating chunked entity bodies. Without chunking, long messages can't be authenticated until the whole message arrives. If the bodies are large, just buffering them can be problematic, and the inability to interleace reception and authentication adds to latency. If the bodies are indefinite length, authentication is not possible.

The mechanism for negotiating authentication schemes is not protected; this means that a MITM attacker can cause the client and server to select the weakest mutually supported authentication scheme. In principle, the weakest scheme should be strong enough, but in practice the desire for interoperability leads to overly weak schemes being offered.  

POST (and other) requests containing large entity bodies are problematic when the client doesn't know whether authentication will be required for the target resource. For performance reasons, they don't want to include the entity body with each authentication message, yet they can't omit the body in the initial request because authentication might not be required (in which case the request would succeed using the empty body).

The syntax for the content of authentication messages is scheme-specific and visible to the HTTP stack implementation. This makes addition of new authentication schemes more intrusive than it might be (contrast with SASL [RFC 4422], where they are encoded as a single opaque string).

HTTP is often carried over TLS, and can be leveraged to avoid all but the last two of the above issues (with proper channel binding [RFC5056, RFC5929] support). However, unless its use is mandatory for all client-authenticated connections, all the issues would still need to be dealt with.

Conclusion

I've tried to list all the issues I can think of with the HTTP authentication framework as currently specified.  Comments and additions are welcome.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 31 Oct 2012 21:30:14 -0400

Paul,

I have a few more....
http://tools.ietf.org/html/draft-hallambaker-httpauth-01

On the chunked thing, well we did actually consider putting per chunk
authentication in chunked. Problem is that a lot of the implementations
have turned out to be fubar and so using chunked attributes is now
deprecated.

On the key exchange, I am not sure that is something that has to happen
inside HTTP but the use of the established key certainly should. Reason for
that is that there are many ways to exchange and associate keys. If we are
doing a Web service we probably want to do it at the level of the Web
service. But what we can't avoid doing is the binding to HTTP messages.

One other point that I brought up in apps. I see a massive ice berg headed
our way labelled Javascript privacy lawsuits. The fact is that the big
holes in the Web security model are in the application layer and the parts
that IETF has generally not wanted to look at. Today Javascript is a cess
pit that enables a horror show of privacy violations.

Pretty soon we are going to see that become a regulatory concern and it
won't be pretty if we can't start fixing things.

If we are going to fix things we have to start putting proper support in
the browser for the types of feature that people use Javascript attrocities
for.

BTW, I just turned off Javascript by default earlier today, Web works a LOT
better.

On Wed, Oct 31, 2012 at 9:19 PM, Paul Leach <[email-masked]> wrote:

> I do so by sketching the typical behavior of many authentication protocols
> in setting up and using secure sessions, then relating it to the HTTP
> context.
>
> A typical authentication protocol initially exchanges a few messages
> between client and server, which securely identifies the requestor (and
> sometimes the server) and which arrives at a mutually agreed upon key for
> the session, after which the key is used to provide authentication and/or
> confidentiality for subsequent application protocol traffic on that
> session. The session also typically provides replay prevention. Some
> schemes provide optimized session re-establishment if the underlying
> transport connection is dropped.
>
> HTTP issues
>
> The key agreement phase requires that state be kept between messages, and
> the HTTP authentication framework [RFC 2617] provides no mechanism for
> associating requests with an authentication session. (Individual
> authentication schemes can provide their own, but this complicates addition
> of new schemes.) Since proxies may have more than one connection to an
> origin server, and may forward requests from a client along any of them,
> transport connections can not be used for this purpose. (And with
> multiplexing in HTTP/2.0, it doesn't even require a proxy to create this
> problem -- a single client-server connection can have it.)
>
> After key agreement, the key and any information needed for replay
> prevention are session state, and present the same problem.
>
> Even in the absence of proxies, transport connections may be dropped at
> any time. The effectiveness of optimized session re-establishment depends
> on the session being usually re-established on the same system as it was
> initially established.
>
> There is no support for authenticating chunked entity bodies. Without
> chunking, long messages can't be authenticated until the whole message
> arrives. If the bodies are large, just buffering them can be problematic,
> and the inability to interleace reception and authentication adds to
> latency. If the bodies are indefinite length, authentication is not
> possible.
>
> The mechanism for negotiating authentication schemes is not protected;
> this means that a MITM attacker can cause the client and server to select
> the weakest mutually supported authentication scheme. In principle, the
> weakest scheme should be strong enough, but in practice the desire for
> interoperability leads to overly weak schemes being offered.
>
> POST (and other) requests containing large entity bodies are problematic
> when the client doesn't know whether authentication will be required for
> the target resource. For performance reasons, they don't want to include
> the entity body with each authentication message, yet they can't omit the
> body in the initial request because authentication might not be required
> (in which case the request would succeed using the empty body).
>
> The syntax for the content of authentication messages is scheme-specific
> and visible to the HTTP stack implementation. This makes addition of new
> authentication schemes more intrusive than it might be (contrast with SASL
> [RFC 4422], where they are encoded as a single opaque string).
>
> HTTP is often carried over TLS, and can be leveraged to avoid all but the
> last two of the above issues (with proper channel binding [RFC5056,
> RFC5929] support). However, unless its use is mandatory for all
> client-authenticated connections, all the issues would still need to be
> dealt with.
>
> Conclusion
>
> I've tried to list all the issues I can think of with the HTTP
> authentication framework as currently specified.  Comments and additions
> are welcome.
>
>
>
>
>
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>
>

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

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 31 Oct 2012 21:58:13 -0400

Phil:

Maybe I should have been more abstract about “chunked”. The problem isn’t per-chunk authentication per-se; it’s that for big and indefinite length entity-bodies some form of incremental authentication of entity-bodies is needed.

I agree that my list assumed that account registration (which I have more commonly seen referred to as “provisioning”) had already happened, and that it omits consideration of collecting credentials from the user. One could say that my list just deals with what your draft calls “message authentication”, which, as you point out, is the only thing directly in the purview of HTTP.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 31 Oct 2012 22:15:55 -0400

I think that at this point with HTTP 2.0 in discussion, well we should
really revisit chunked.

I would like HTTP/2.0 to replace the ASCII framing with binary and handle
things like authentication and chunked properly in  that context.

Since we already have SSL in the mix it would make good sense for the HTTP
framing to follow the SSL approach which is  pretty easy to follow (well I
think so).

Some of the stuff we talked about at great length in HTTP-NG now seems to
me to be just silly. Like all the concern about allowing for word
alignment. While that might have been an issue in theory if the transport
really was a stream of octets, it is actually sliced up into packets. And
the sender can control the slices. So if quadword alignment was a real
issue it would be something the TCP/IP stack could address as an
optimization.

[Appols if I seem to dredge up old history but I have had to dredge through
rather a lot recently.]

On Wed, Oct 31, 2012 at 9:58 PM, Paul Leach <[email-masked]> wrote:

>   Phil:
>
> Maybe I should have been more abstract about “chunked”. The problem isn’t
> per-chunk authentication per-se; it’s that for big and indefinite length
> entity-bodies some form of incremental authentication of entity-bodies is
> needed.
>
> I agree that my list assumed that account registration (which I have more
> commonly seen referred to as “provisioning”) had already happened, and that
> it omits consideration of collecting credentials from the user. One could
> say that my list just deals with what your draft calls “message
> authentication”, which, as you point out, is the only thing directly in the
> purview of HTTP.
>