Subject: Authentication over HTTP

From: M Stefan <[email-masked]>
Date: Mon, 15 Jul 2013 02:15:01 +0300

Hello,

As HTTP is fundamentally an old protocol, it has not kept up with
the more recent developments in cryptography and security. I believe
that a major change in the protocol version should also take into account
some security concerns.

Nowadays, the only serious way of providing secure communications over
HTTP is using HTTPS. Many web hosts are reluctant to using it because
of the extra computational burden and the necessity of buying
certificates. Some sites cannot afford being part of it or simply
do not agree with the idea of paying a certificate authority money.

Not every admin cares about security equally, and for those that,
for one reason or another, choose not to use HTTPS, there should be
some lighter alternative. It may not have the security guarantees of
HTTPS but would still be better than current approaches.

According to a very popular train of thought, concerns should be separated,
in that security protocols should be built at a lower layer (and 
therefore be
independent) from the HTTP protocol.
As tempting as it sounds to fragment components into smaller ones as much
as possible, I believe that a protocol that has the popularity of
HTTP must address this concerns itself. To find evidence of this fact,
you don't have to look very far. Simply observe how many websites currently
send your log in password as plain text. Even IMAP has STARTTLS.

As most websites allow users to sign up and log in, it becomes an
important question what can be done to have some security when HTTPS
is not affordable (as is currently the case for most of the web).

Websites these days typically receive your password as plain-text upon
sign up and log in. Upon log in, they provide you with an unique large
string (the session id cookie) which constitutes proof that you are indeed
logged in as a certain user. You then have to provide that proof in every
request you make.

This sounds very primitive. The fact that the password is
sent as plain-text both upon subscription and log in and the fact
that your proof string (the session id) is reusable are serious flaws
that I believe to be unacceptable for the most used protocol on the 
Internet.
One can argue that this should be the concern of the web developer, but one
would be wrong. It cannot be expected for every web developer to have 
the necessary
knowledge in security to implement a more secure authentication handshake.

One could also claim that there is no way to have a great deal of security
without the web host owning a trusted (signed) certificate. While this may
be true, some security guarantees can still be made even in the absence
of such a certificate. It makes no sense to believe that "some security" is
just as bad as "no security".

In general, there are three operations that need to be considered for 
web-sites
that allow users to authenticate themselves: sign up (rare), log in (often),
other requests (very often).

Using HTTPS with a signed certificate, all three operations are secure, and
relatively fast. In general, public-key cryptography is considered slow,
whereas computing hash functions and private-key cryptography is considered
fast.

In the HTTP plain-text setting, all three operations are insecure:
Sign up: the plain-text password can be intercepted
Log in: the plain-text password can be intercepted
Requests: the session id can be intercepted and reused as many times as 
desired

The obvious question is: how can most websites, with little overhead, 
benefit
from better security (authentication and/or encryption) without too much 
effort and
without requiring the web developer to have advanced knowledge about 
security?

For instance, an EKE (encrypted key exchange) mechanism could be 
embedded in HTTP2.0 for
allowing users to log in. Both the web host and the user share some 
common secret
that a third party does not have (a salted digest of the user's 
password). Using this
common secret, the host and the user can negotiate a shared key. After 
this login handshake
has finished, the server has the guarantee that the client knows the 
digest of the password.
The client also has the guarantee that the server knows his password's 
digest (so
this provides authentication both ways). On the other hand, a 
man-in-the-middle
cannot find the digest of the password from this handshake.

At this point, the host and the user share a secret key. This key can be 
used in every request
for the client to authenticate itself to the server and vice-versa. The 
shared key becomes the
"session id" that is commonly used nowadays. Except that instead of 
sending it directly as a cookie,
an efficient zero-knowledge interactive proof is mounted. If encryption 
is desired,
this shared key can also be used to encrypt communication.

This mechanism provides the following security for the three operations 
considered:
Sign up: provides no security against an active man-in-the-middle.
          security against a passive MITM can be achieved through 
schemes such as
          Diffie-Hellman
Login: if no active MITM was present during sign up, this procedure is 
secure
         this is because the server and the user both know the password 
of the user,
         but no attacker knows it. This shared information can be used 
to perform
         EKE and exchange a larger shared key.
Request: Same as for Login. If no active MITM interfered during Sign Up then
         no attacker can know the shared key. This means that the 
communication
         can be encrypted and authenticated with it. Random numbers (nonces)
         may be used to prevent replay attacks etc.

Therefore, using this technique, an attacker gets a single chance of 
attacking an user:
by taking action upon the user's sign up.
However, once the password digest has been provided to the server 
without anyone tampering with it,
there's little an attacker can do.

There's a significant difference between exposing yourself once and 
exposing yourself with every request.
Registrations are rare. Requests are very often.

Another technique worth considering is client-side certificates. These 
can be self-signed and allow
security during sign up, login and request.

It is about time we start providing alternatives for password-based 
authentication on the web.
I realize I'm dreaming big, but I believe that if HTTP provided 
client-side authentication
with certificates, browsers would gladly follow and we could get 
ourselves a bit further
away from the evilness behind passwords. Towards a world where we would 
need to protect
our private keys with various mechanisms, not remember huge different 
passwords for every
site.

I realize my points are very superficial and are mostly 
proof-of-concepts. Clearly, MITM
attacks with active adversary cannot be mitigated at sign up without 
signed certificates.
But I cannot stress this enough: once an user has been exposed once, 
there is no reason
to expose himself again.

In my opinion, a major release of HTTP is the right opportunity to 
address such issues.
Consider its popularity, as well as the fact that the vast majority of 
the websites
that need confidentiality and authentication also offer means of log-in. 
I believe
this would be a giant step towards a more secure Web. No modern 
protocols should
offer plain-text authentication as their main option any longer.

I look forward to hearing your thoughts on this matter.

Stefan

---

From: J Ross Nicoll <[email-masked]>
Date: Mon, 15 Jul 2013 00:51:55 +0100

Hello Stefan,

Most of this is a UI challenge, and therefore arguably beyond the remit 
of this group. The W3C Web Application Security Group ( 
http://www.w3.org/2011/webappsec/ ) is probably a more appropriate place 
for this. I do want to provide feedback, but I'm going to keep my 
response short, so apologies for abruptness.

StartSSL ( http://www.startssl.com/?app=1 ) will provide free 
certificates. It's been argued that processor overhead isn't a major 
concern at this point, although that's not something I've tested myself. 
Server Name Indication client support is limited, however, so the 
requirement for an IP address per certificate is essentially still in 
effect. That does limit adoption.

I'm not sure what your suggested shared secret approach would do that 
HTTP Digest Authentication (see http://tools.ietf.org/html/rfc2617 ) 
doesn't? Personally I also am not a fan of anything which requires the 
server to be able to retrieve the plaintext of the shared secret; 
inevitably it's a security hole, and given the rate at which systems are 
compromised it's difficult for me to accept it as reasonable.

By comparison, client certificate based authentication has significant 
advantages in terms of inability for phishing attacks to work (the 
original value is never transmitted) and in resistance to server-side 
compromises. However there are usability issues in terms of generating 
keys with appropriate certificates, managing when certificates are 
presented (such as not to make it incredibly easy to track users), and 
making certificate backup easy to use. Also in handling access when away 
from your normal desktop (for example in a cyber cafe).

Ross

On 15/07/2013 00:15, M Stefan wrote:
> Requests: the session id can be intercepted and reused as many times 
> as desired
>
> from better security (authentication and/or encryption) without too 
> much effort and
> At this point, the host and the user share a secret key. This key can 
> be used in every request
> for the client to authenticate itself to the server and vice-versa. 
> The shared key becomes the
> an efficient zero-knowledge interactive proof is mounted. If 
> encryption is desired,
> This mechanism provides the following security for the three 
> operations considered:
> away from the evilness behind passwords. Towards a world where we 
> would need to protect
> that need confidentiality and authentication also offer means of 
> log-in. I believe

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 15 Jul 2013 00:02:39 +0000

In message <[email-masked]>, M Stefan writes:

>of the extra computational burden [...]

I agree with you (if I understood your message right) that the
current HTTP/1.1 authentication/password stuff is fundamentally
useless and should not be carried into HTTP/2.0.

I think HTTP/2.0 should make partial protection possible, (See my
previous message :-) exactly so that the cost can be kept down.

But I think that it would be a big mistake to involved HTTP/2.0 in
the actual protection, to any extent further than to mark what needs
protection and what does not.

Authentication should happen either in the encrypting transport
which moves HTTP/2.0 across (as in certificates and assymetric crypto)
or in the application transported inside HTTP/2.0 (as in most web-site
login dialogs), but HTTP/2.0 itself should not get involved:  It
is the wrong layer.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 15 Jul 2013 06:51:40 +0000

> Hello,

Hi

> that a major change in the protocol version should also take into account

Basic and Digest are pretty outdated. There is a working group to deal with this: http://tools.ietf.org/wg/httpauth/

> do not agree with the idea of paying a certificate authority money.

Buying a certificate and turning on TLS is pretty cheap and easy, but only gets the website authenticated to the UA. Getting mutual authentication working requires distributing certificates to users, and that is beyond the means of most websites (exceptions being corporate/government agency VPNs, and sometimes banks, maybe a few others)

> HTTPS but would still be better than current approaches.

Encrypting stuff and then sending it to someone who may be the intended recipient or may be an attacker makes no sense. Good authentication is way more important than encryption. Unfortunately, it's also much harder.

> in that security protocols should be built at a lower layer (and therefore be

Yeah, IPsec is great, TLS is great. But assuming your application supplies different services to different users, the application has to be aware of the user identity. User identity is hard in both IPsec and TLS, so most application opt to do the authentication by themselves. The fact that this pretty much replicates the security properties of HTTP Basic notwithstanding.

> send your log in password as plain text. Even IMAP has STARTTLS.

They do that because a form gives the designers more control over the user experience than using any facilities within HTTP. That is something I'm afraid the http-auth working group will not be able to solve, regardless of all the cool crypto that they might add.

> is not affordable (as is currently the case for most of the web).

I disagree with the affordability claim. But TLS has a lot of ciphersuites, including some that are anonymous. So you can have encryption without authentication even with TLS (for all the good that will do you)

> logged in as a certain user. You then have to provide that proof in every

And that session id cookie was the target in the BEAST, CRIME and Lucky-13 attacks.

> that I believe to be unacceptable for the most used protocol on the Internet.
> would be wrong. It cannot be expected for every web developer to have the necessary

Totally agree.

Note also that form-based login can never be more secure than that. I've seen forms that use Javascript to encrypt the password with an RSA key from the server. But those forms are visually indistinguishable from forms that send the password in the clear. So unless we expect the users to read the javascript before entering their password, they will be duped by a look-alike form from an attacker.

> just as bad as "no security".

Disagree. Some security guarantees are not necessarily the security guarantees that matter, and to me it's far more important to know that I'm talking to the correct server than knowing that my traffic is encrypted en route.

> In general, there are three operations that need to be considered for web-sites

And thanks to TLS session resumption, public-key cryptography is very rare.

> Requests: the session id can be intercepted and reused as many times as desired

I've mentioned http-auth (in this message) and websec (just yesterday), so I won't do it again. The hard part is getting the web site owners to use the new technologies.

> The obvious question is: how can most websites, with little overhead, benefit
> from better security (authentication and/or encryption) without too much effort and
> without requiring the web developer to have advanced knowledge about security?

self-signed certificate + DANE + HTTPS ?  Most of this could be automated, but the infrastructure would have to be there (DNSSEC, registrars willing to enter DANE keys in the DNS)

> For instance, an EKE (encrypted key exchange) mechanism could be embedded in HTTP2.0 for
> allowing users to log in. Both the web host and the user share some common secret
> that a third party does not have (a salted digest of the user's password). Using this
> common secret, the host and the user can negotiate a shared key. After this login handshake
> has finished, the server has the guarantee that the client knows the digest of the password.
> The client also has the guarantee that the server knows his password's digest (so
> this provides authentication both ways). On the other hand, a man-in-the-middle

The only reason certificates exist at all is that symmetrical key management is really, really hard. Where do I get my secret key for GMail?

> At this point, the host and the user share a secret key. This key can be used in every request
> for the client to authenticate itself to the server and vice-versa. The shared key becomes the
> "session id" that is commonly used nowadays. Except that instead of sending it directly as a cookie,
> an efficient zero-knowledge interactive proof is mounted. If encryption is desired,
> This mechanism provides the following security for the three operations considered:
>         security against a passive MITM can be achieved through schemes such as
>         Diffie-Hellman
> Login: if no active MITM was present during sign up, this procedure is secure
>        this is because the server and the user both know the password of the user,
>        but no attacker knows it. This shared information can be used to perform
>        no attacker can know the shared key. This means that the communication
> Therefore, using this technique, an attacker gets a single chance of attacking an user:
> However, once the password digest has been provided to the server without anyone tampering with it,
> There's a significant difference between exposing yourself once and exposing yourself with every request.
> Another technique worth considering is client-side certificates. These can be self-signed and allow
> It is about time we start providing alternatives for password-based authentication on the web.
> I realize I'm dreaming big, but I believe that if HTTP provided client-side authentication
> with certificates, browsers would gladly follow and we could get ourselves a bit further
> away from the evilness behind passwords. Towards a world where we would need to protect
> our private keys with various mechanisms, not remember huge different passwords for every
> site.
> 
> I realize my points are very superficial and are mostly proof-of-concepts. Clearly, MITM
> attacks with active adversary cannot be mitigated at sign up without signed certificates.
> But I cannot stress this enough: once an user has been exposed once, there is no reason
> to expose himself again.
> 
> In my opinion, a major release of HTTP is the right opportunity to address such issues.
> Consider its popularity, as well as the fact that the vast majority of the websites
> that need confidentiality and authentication also offer means of log-in. I believe
> this would be a giant step towards a more secure Web. No modern protocols should

---

From: Henry Story <[email-masked]>
Date: Mon, 15 Jul 2013 10:32:31 +0200

> do not agree with the idea of paying a certificate authority money.

The problem of cost could be solved by deploying DANE in browsers
http://tools.ietf.org/html/rfc6698 
It would make the internet more secure all the way around.

Computational cost is no longer a problem. Google and Facebook provide
it with billions of connections a day.

Henry

Social Web Architect
http://bblfish.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 15 Jul 2013 08:37:39 +0000

In message <[email-masked]>, Henry Story writ

>it with billions of connections a day.

That's like saying "transportation is non-issue, because Bill Gates
have a private jet."

Not everybody has Google and FaceBook's globally distributed resources,
nor their laser-like focus on delivering web-content.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 15 Jul 2013 09:00:49 +0000

> nor their laser-like focus on delivering web-content.

Not so. A pretty low-end server, say 4 cores, can handle 250 full handshakes per second, and can easily saturate a 1Gbps link.

That's with a default Apache and OpenSSL installation. If your website needs more than this, then you may not be in the class of Google and Facebook, but you're way beyond the personal blog / local store crowd.

It is true that content delivery networks charge a premium for things protected by TLS. I think that has more to do with signaling than actual costs.

Yoav

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 15 Jul 2013 15:16:10 +0200

> login dialogs), but HTTP/2.0 itself should not get involved:  It

However, secret transport *is* HTTP/2.0 domain, and there are quite a lot
of parts of the spec that assume "simple" auth (intermediary auth comes to
mind). I'm quite sure straightening auth requires at least some protocol
adjustments.

Regards,

-- 
Nicolas Mailhot

---

From: "Ludin, Stephen" <[email-masked]>
Date: Mon, 15 Jul 2013 09:38:08 -0500

> It is true that content delivery networks charge a premium for things protected by TLS. I think that has more to do with signaling than actual costs.

And that premium comes directly from cost. 

There is still a big gap between "TLS is totally free" and what we have today. 250 handshakes a second is a big difference from the 2500 connection o more you can get without. The march to 2048 makes that worse, and luckily advances like ECC help bring it some of the way back. When you then consider the excess requirements of having sufficient resources to gracefully withstand a DDoS, the problem is compounded. 

All that said, you have not heard me preaching against the growing adoption of TLS. I think it is a "good thing" despite the pain associated with it. I firmly believe, however, that as long as there is some incremental cost with TLS there will be someone whose business wants to avoid that cost affecting their margins and will look for a non-TLS alternative. These discussions have been hashed and rehashed since SPDY was introduced, however, and I doubt there is much new to add to them at this point. 

-stephen

---

From: Henry Story <[email-masked]>
Date: Mon, 15 Jul 2013 18:35:46 +0200

> nor their laser-like focus on delivering web-content.

For those who don't have billions of hits a day, they have even less
of an issue, since they have more spare cycles. Computer power has massively
increased since 1998.

btw. one version of DANE is implemented in Chrome

Social Web Architect
http://bblfish.net/

---

From: J Ross Nicoll <[email-masked]>
Date: Tue, 16 Jul 2013 00:07:40 +0100

> of an issue, since they have more spare cycles. Computer power has massively
I think the point is that for someone with a $9/month hosting plan for 
their Wordpress blog, they only get a tiny slice of the resources on an 
already overstretched system they're probably sharing with a dozen or 
more other people. People aren't necessarily paying for the same 
proportion of computing power, instead we're seeing hosting become cheaper.

Ross

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 15 Jul 2013 23:20:52 +0000

for browser-based reverse proxy or serving I agree that current HTTP 
auth is next to useless.

However for forward proxying it is still useful and necessary.  And 
given we don't have TLS to proxy, then HTTP is the only possible layer 
for this.

Adrien

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Jul 2013 01:24:19 -0500

> Basic and Digest are pretty outdated. There is a working group to deal with this: http://tools.ietf.org/wg/httpauth/

+1.  Please look at the proposals at HTTPauth WG.

> Encrypting stuff and then sending it to someone who may be the intended recipient or may be an attacker makes no sense. Good authentication is way more important than encryption. Unfortunately, it'…

Well, it made sense to me when we pursued BTNS, with the express
purpose (for me anyways) of using it and RFC5660 to use for channel
binding to application-layer user/service authentication.

The lower in the stack one goes, the less relevant the layer's
identification and authentication capabilities are to the higher
layers.  Paradoxically, the lower in the stack one goes, the easier it
may be for hardware/firmware to provide session cryptography.  That
was the theory for IPsec channels and BTNS.  However, there was no
take-up.

> Yeah, IPsec is great, TLS is great. But assuming your application supplies different services to different users, the application has to be aware of the user identity. User identity is hard in both…

We have the following layers: application, HTTP, TLS, IPsec, IP, link, ...

The link layer doesn't help, and neither does IP.  IPsec doesn't
either in practice, though it could if by some miracle we got the
pieces in place to use it.

TLS is still too low a layer: there may be a world of caching and
routing proxies between the server-side end-point of the TLS
connection and the actual service, and the service might be spread
over many nodes.  At the very least we'd need to standardize how the
services and TLS are to interact.

That leaves two layers as useful for authentication: HTTP and the
application layer.  HTTP is closer to TLS in the architecture than to
the application layer, therefore we have roughly the same problems as
with TLS.

That leaves only the application layer as the best suited for
authentication of identities (and/or resolution to attributes) that
the service needs for authorization (or even in the other direction).
This, I know, is a bit of a controversial opinion.  My proposal is
here: http://tools.ietf.org/html/draft-williams-http-rest-auth-01
(ah, I need to submit the WG version).

> They do that because a form gives the designers more control over the user experience than using any facilities within HTTP. That is something I'm afraid the http-auth working group will not be abl…

My proposal (RESTauth) is not incompatible with application-defined
UIs, but it does constrain things a bit so that the application cannot
get access to raw credentials that it must not have access to.

> Note also that form-based login can never be more secure than that. I've seen forms that use Javascript to encrypt the password with an RSA key from the server. But those forms are visually indisti…

Right!

> Disagree. Some security guarantees are not necessarily the security guarantees that matter, and to me it's far more important to know that I'm talking to the correct server than knowing that my tra…

A zero-knowledge proof protocol can certainly get by without a server
certificate.

The problem with ZKPPs is that they don't scale: they require
pair-wise shared secrets.  The standard answer to this in the past has
been Kerberos, but now the new cool kids on the block are BrowserID
(roughly: an online CA that pre-authenticates users however it wishes,
and issues short-lived certs) and ABFAB (roughly: based on EAP +
RADIUS + SAML).

>> [...]

See http://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/

See also my comments above about scalability of ZKPPs.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Jul 2013 01:26:54 -0500

> login dialogs), but HTTP/2.0 itself should not get involved:  It

I agree.  Thus my proposal for RESTful authentication (with channel
binding to TLS where available).  I don't believe user authentication
in TLS will work out too well (it hasn't so far, and there are reasons
why it should prove difficult; see my reply to Yoav's reply to
Stefan).

Nico
--

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Jul 2013 09:13:37 +0200

> why it should prove difficult; see my reply to Yoav's reply to

RESTful authentication on the TLS level exists. We have been working for
it over the past 5 years, testing it over most well known languages, showing
how it works with distributed ACLs and distributed social networks. It's called 
WebID.

The latest draft are here:

 WebID overview: https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
 WebID over TLS: https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html
 a video is here: http://webid.info/

To try it out with WebAccess Control try
 
  https://github.com/stample/rww-play

Henry

Social Web Architect
http://bblfish.net/

---

From: Josh Howlett <[email-masked]>
Date: Tue, 16 Jul 2013 10:04:40 +0000

>(ah, I need to submit the WG version).

I agree with this analysis. No single mechanism will meet every need. It
is more important that HTTP has the agility to allow different mechanisms
on a per-application basis, while maintaining a consistent presentation to
users and application developers (as Nico's proposal allows). Binding
specific mechanisms to the protocol, as in HTTP/1.1, would be an error IMO.

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 17 Jul 2013 00:54:37 +1200

> specific mechanisms to the protocol, as in HTTP/1.1, would be an error IMO.

Binding what exactly? If you look through RFC 2616 there is no mention 
of authentication mechanism limits.

The mechanisms which we are all so familiar with today are defined in 
RFCs outside of the HTTP protocol spec and layered on top of HTTP 
headers. There is none of them which can be pointed at specifically and 
say "that is only possible with HTTP" or "HTTP only permits X, Y, Z 
mechanisms". HTTP simply defines some headers which are reserved for 
sending auth credentials per-hop or end-to-end, limiting to two sets of 
credentials concurrently on any hop. It is the application and 
implementations which determines which one is more appropriate to be 
used on any transaction and/or hop.

*Every single claim* that HTTP-auth is broken and needs re-designing 
seems to me to be based on the flawed assumption that HTTP-auth is not 
extensible and that the common existing schemes are the only ones HTTP 
permits. Or that somehow a user authenticating with N different and 
fragile mechanisms for one transaction is a good thing (I rather 
disagree, the UX on that would be tricky and implementation nightmares).

Amos

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 16 Jul 2013 15:36:50 +0200

>proportion of computing power, instead we're seeing hosting become cheaper.

(Indeed, a "$9/month hosting plan" would be ridiculously expensive.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Jul 2013 12:34:02 -0500

On Tue, Jul 16, 2013 at 7:54 AM, Amos Jeffries <[email-masked]> wrote:
> *Every single claim* that HTTP-auth is broken and needs re-designing seems
> to me to be based on the flawed assumption that HTTP-auth is not extensible
> and that the common existing schemes are the only ones HTTP permits. Or that
> somehow a user authenticating with N different and fragile mechanisms for
> one transaction is a good thing (I rather disagree, the UX on that would be
> tricky and implementation nightmares).

That's either a strawman or you misunderstood the arguments against
doing authentication in HTTP.  It's not that "HTTP auth is broken",
but that HTTP is the *wrong layer* -- that's not because HTTP or HTTP
auth is broken, but because properties of the stack of protocols
spoken make HTTP auth a problematic proposition.

BTW, I've not see any arguments about N different mechanisms (fragile
or not) being a problem.

Nico
--

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 17 Jul 2013 17:59:39 +1200

> BTW, I've not see any arguments about N different mechanisms (fragile

Maybe I have been misunderstanding some of them. But the auth proposals 
I've seen in the last few years all seem to fall into three brackets 
with regards to their claims about HTTP:

1) "HTTP auth is broken". Aka "do it all in payload entities and have 
HTTP endpoints interpret those" ... well so what? payload format is not 
HTTP. Good luck but go away and do it at a different layer.

2) "HTTP auth is broken". Aka the headers dont let me login user X to 
proxy A and proxy B at the same time, in the same chain, with different 
credentials all controlled by user X ... seem to be making a few wrong 
assumptions about how HTTP works there. Go away and do (1) instead the 
user-application ha sa lot more control over end-to-end pathways in 
application layer.

3) "HTTP auth is broken". Aka its missing a scheme to do mechanism Z ... 
and we do see these followed by specs to do Z in HTTP. But none of them 
are exactly replacing the existing HTTP mechanism design, just extending 
it as it was intended to be extended.

What am I missing?

Amos

---

From: David Morris <[email-masked]>
Date: Tue, 16 Jul 2013 23:33:22 -0700 (PDT)

On Wed, 17 Jul 2013, Amos Jeffries wrote:

> Maybe I have been misunderstanding some of them. But the auth proposals I've
> seen in the last few years all seem to fall into three brackets with regards
> to their claims about HTTP:
> 
> 1) "HTTP auth is broken". Aka "do it all in payload entities and have HTTP
> endpoints interpret those" ... well so what? payload format is not HTTP. Good
> luck but go away and do it at a different layer.
> 
> 2) "HTTP auth is broken". Aka the headers dont let me login user X to proxy A
> and proxy B at the same time, in the same chain, with different credentials
> all controlled by user X ... seem to be making a few wrong assumptions about
> how HTTP works there. Go away and do (1) instead the user-application ha sa
> lot more control over end-to-end pathways in application layer.
> 
> 3) "HTTP auth is broken". Aka its missing a scheme to do mechanism Z ... and
> we do see these followed by specs to do Z in HTTP. But none of them are
> exactly replacing the existing HTTP mechanism design, just extending it as it
> was intended to be extended.
> 
> What am I missing?

How about the user experience sucks because the authentication doesn't fit
into the style/face of the application and doesn't provide sufficient user
context for the prompts generated by the auth mechanicanism so the
application owners design and implement their own approach? Oh, and no
logout mechanism to cancel browser caching of credentials?

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 17 Jul 2013 18:50:18 +1200

On 17/07/2013 6:33 p.m., David Morris wrote:
>>> On Tue, Jul 16, 2013 at 7:54 AM, Amos Jeffries wrote:
> application owners design and implement their own approach?

  HTTP provides key=value parameters on the mechanism headers for that 
kind of thing. What can't be expresed as such comes under #1, 
application layer problem. For example, how in heck is HTTP or any 
protocol going to enforce "thou shalt have no password longer than S 
characters long" when the protocol never sees the password at all? or 
similar *GUI* restrictions.

>   Oh, and no

In the stateless HTTP "login" is done by delivering credentials or 
requesting them. But how *do* you "logout" in a stateless protocol? 
Nobody (self included) has produced anything like a good proposal spec 
for resolving that problem AFAIS.

Amos

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Jul 2013 07:01:41 +0000

> logout mechanism to cancel browser caching of credentials?

There is at least one attempt to address the user experience issue, by having an unauthenticated as well as an authenticated version of the page (presumably with the unauthenticated version pointing you at the credential entry box that is located in the chrome of the browser)

There's even a modified browser to demonstrate this:

https://www.rcis.aist.go.jp/special/MutualAuth/index-en.html

Yoav (who is in no way affiliated with this site, but is the chair of http-auth where their draft is discussed)

---

From: Albert Lunde <[email-masked]>
Date: Wed, 17 Jul 2013 06:04:51 -0500

One area of previous work that may be relevant is Web-Single-Signon 
systems. These tend to rely on some unattractive mix of JavaScript, 
cookies, and other gimmicks to complete the authentication exchange, but 
they are representative of what people have tried to layer on top of 
HTTP/1.1 to replace Basic auth, and provide sessions of a sort.

Shibboleth and CAS are notable examples using SAML and Kerberos 
respectively.

It seems like there are use cases to delegate authentication to a 
trusted third-party and/or maintain sessions.

There may be some mechanisms that HTTP/2.0 could support to make this 
easier, but it's a different question than just the framework used by 
Basic and Digest auth.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 17 Jul 2013 13:13:02 +0200

>> proxy A

That we have standards to permit interoperability, and go away and do it
elsewhere is the perfect interop killer?

-- 
Nicolas Mailhot

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Jul 2013 12:57:53 -0500

On Wed, Jul 17, 2013 at 1:50 AM, Amos Jeffries <[email-masked]> wrote:
> requesting them. But how *do* you "logout" in a stateless protocol? Nobody
> (self included) has produced anything like a good proposal spec for
> resolving that problem AFAIS.

HTTP is stateless.  The application protocol layered above HTTP
needn't be, and often isn't.  Session state is almost always desired,
though often with the client storing the state on behalf of the server
(via, e.g., encrypted state cookies, like TLS session tickets) though
there are trade-offs w.r.t. replay protection.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Jul 2013 12:59:01 -0500

> elsewhere is the perfect interop killer?

You can standardize how to do it elsewhere.  Just because X is a
standard doesn't mean that some feature that X doesn't have belongs in
X.

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Jul 2013 13:00:59 -0500

On Wed, Jul 17, 2013 at 12:59 AM, Amos Jeffries <[email-masked]> wrote:
>>> seems

But you don't even list here the argument you listed above, nor give
examples.  Why argue about this anyways?  You and I seem to agree:

> endpoints interpret those" ... well so what? payload format is not HTTP.
> Good luck but go away and do it at a different layer.

Yes, do it at a different layer: that's my answer.

> 2) "HTTP auth is broken". Aka the headers dont let me login user X to proxy
> A and proxy B at the same time, in the same chain, with different

Oh, I'd never seen this argument.  This is an interesting one because
authentication to proxies is very interesting.  So this one is
definitely a legitimate argument, and one I would make.  Also, this
means I have to think about proxy auth for RESTauth (well, it's
straightforward, but I have to add it).  This is very helpful, thanks!

> exactly replacing the existing HTTP mechanism design, just extending it as
> it was intended to be extended.
>
> What am I missing?

At least the argument you'd made above:

>>> seems

I've never seen that argument.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 18 Jul 2013 12:36:37 +1200

> straightforward, but I have to add it).  This is very helpful, thanks!

The answr may surprise you. HTTP *already* provides teh necessary 
mechanism to do auth like that...

HTTP as a protocol offers no such thing as a NEXTHOP routing method, so 
the only way for a user to exactly specify that proxy-A is to relay the 
request to proxy-B (and not elsewhere) is for the user to send CONNECT. 
A CONNECT to proxy-A carries the credentials for proxy-auth on A, and 
the traffic inside be HTTP or HTTPS to proxy-B with proxy-auth 
credentials to the proxy B. CONNECT like that can be layered arbitrarily 
deep and sent between any two hops in the chain for arbitrary 
hopX-to-hopY auth credential delivery. Also, if one were to spec a 
NEXTHOP equivalent method, it would have to work very similarly to CONNECT.

I dont see anything particularly broken broken about the HTTP layer in 
the above, but that does not seem to stop proposals for new features to 
duplicate the ability. Most proposals seems  to be more driven by 
implementations application-layer lack of functionality than HTTP itself.

> I've never seen that argument.

For Yoav, by "fragile" I mean that each auth layer may fail to 
authenticate successfully, or have some implementation flaw. The more 
you add into one transaction the more reasons it has to error out and 
break the UX. Breaking the UX when error do happen is the right thing 
IMO, but having so many ways to hit errors in the first place is the 
problem.
  The existing HTTP auth header features/mechanism and methods seem to 
be able to cope with almost everything the HTTP layer specifically needs 
to cope with.

NOTE: The one niche use-case I have not been able to find clean 
algorithms for that work within existing HTTP semantics and applicatino 
layer logics. That case is automated logout between two proxies in the 
middle of a chain which have logged in automatically and independently 
of any user being aware of the login happening (thus no UA logout button 
possibility). That one still seems to require connection tear-down. 
Although that said, I've not seen it requested by anyone either.

Amos

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Jul 2013 21:50:44 -0500

On Wed, Jul 17, 2013 at 7:36 PM, Amos Jeffries <[email-masked]> wrote:
>>> proxy
> The answr may surprise you. HTTP *already* provides teh necessary mechanism
> to do auth like that...

No, I knew about CONNECT.  I've written a CONNECT proxy client for
traversing proxies that need HTTP/Negotiate authentication (which I'll
try to get contributed as open source to curl, if they'll take it).

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 18 Jul 2013 13:54:29 +0200

> standard doesn't mean that some feature that X doesn't have belongs in

And that have worked wonderfully didn't it? Need I point out once again
why everyone is moving to transparent interception now?

-- 
Nicolas Mailhot

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 18 Jul 2013 13:17:30 +0000

with the move (major sites) to https, interception is becoming more of a 
train-wreck.

We really need a way to reliably force a browser to use a proxy.  e.g. 
inside a network force explicit use of the company proxy.

You can't intercept port 443, and send back HTTP (rejections, auth 
challenges or pages) to clients.

------ Original Message ------
From: "Nicolas Mailhot" <[email-masked]>
To: "Nico Williams" <[email-masked]>
Cc: "Nicolas Mailhot" <[email-masked]>; "HTTP Working 
Group" <[email-masked]>
Sent: 18/07/2013 11:54:29 p.m.
Subject: Re: Authentication over HTTP