Re: Authentication over HTTP

Nico Williams <> Tue, 16 July 2013 06:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9061C11E8222 for <>; Mon, 15 Jul 2013 23:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.377
X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=3.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p844ZcDgRqFi for <>; Mon, 15 Jul 2013 23:25:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB71821F9D09 for <>; Mon, 15 Jul 2013 23:25:26 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uyygu-0003r0-H8 for; Tue, 16 Jul 2013 06:24:52 +0000
Resent-Date: Tue, 16 Jul 2013 06:24:52 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uyygl-0003qB-PQ for; Tue, 16 Jul 2013 06:24:43 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1Uyygk-0004FU-D9 for; Tue, 16 Jul 2013 06:24:43 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 6BA3135007A for <>; Mon, 15 Jul 2013 23:24:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=oHkygIqW02t4fzzESzk8FGGIZkU=; b=ALCviDaPzT0 vcGQWdrdzCyIhBbPcd21M2AmYpcNhcy84xpGKKuyKlFChsn5yxPgYLNv5RSFwbpf 7CkmmlDRH/mEP0V16d1SG+WQshdBm88t7sE/gRrxiJTBG47+pVpGfmEHEihKdP9X JZoQbn2/s6IVYH4OEhh/vmtITpIwkeDc=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id EB297350079 for <>; Mon, 15 Jul 2013 23:24:20 -0700 (PDT)
Received: by with SMTP id k10so242515wiv.17 for <>; Mon, 15 Jul 2013 23:24:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NtP+HcNV7JPATHvRWWuWSooODmWVEFnUAWspZ/Ui+Oc=; b=EJTEXSzikUckZDgn6kq63QriAKa5abiYy0paz30KlPDr0188FMGfuga3uRSXSDUd6e m5OaNIPLVHs6gWDPNVi9N0NMDFmzq+sjFUjRBDXIDvEA1VWkPcKPP8imNlNkyFlpupAk NT4aLN44ISfEoXtqFpOf2C0aRdRepaSV9bYVaCmhhGCJLVqy0lYZJMm+OchM2UO6MkEL gnK8YalCBhhxjVSs4DX+Qj7PWl29C9Ijglbg0LKCZ+j9+nf5yIs02cpfHUKvS/rFvvmu 2U2l7/FLU+IbQB2VRy/xqAx4PZzu+xGWji6Hdjumurbw55tcX2Q0ItyxrnKIzuzb2NFP S3mA==
MIME-Version: 1.0
X-Received: by with SMTP id w6mr11058386wiy.36.1373955859193; Mon, 15 Jul 2013 23:24:19 -0700 (PDT)
Received: by with HTTP; Mon, 15 Jul 2013 23:24:19 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 16 Jul 2013 01:24:19 -0500
Message-ID: <>
From: Nico Williams <>
To: Yoav Nir <>
Cc: M Stefan <>, "<>" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.449, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: 1Uyygk-0004FU-D9 24047d2385efcd951d4a2b0f62feeb3a
Subject: Re: Authentication over HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/18797
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mon, Jul 15, 2013 at 1:51 AM, Yoav Nir <> wrote:
> On Jul 15, 2013, at 2:15 AM, M Stefan <> wrote:
>> 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.
> Basic and Digest are pretty outdated. There is a working group to deal with this:

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

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

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

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

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
(ah, I need to submit the WG version).

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

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


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

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

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 +

>> For instance, an EKE (encrypted key exchange) mechanism could be embedded in HTTP2.0 for
>> [...]


See also my comments above about scalability of ZKPPs.