Re: [http-auth] Why is there no SASL support in HTTP?

Rick van Rein <> Mon, 14 August 2017 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C7A112426E for <>; Mon, 14 Aug 2017 09:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NXP4qDJqJCro for <>; Mon, 14 Aug 2017 09:19:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABF24124207 for <>; Mon, 14 Aug 2017 09:19:35 -0700 (PDT)
Received: from airhead.local ([IPv6:2001:980:93a5:1:681e:d64c:e91a:ef73]) by with ESMTPSA id hI5UdYaB8dRLjhI5VdPH5R; Mon, 14 Aug 2017 18:19:34 +0200
Message-ID: <>
Date: Mon, 14 Aug 2017 18:19:31 +0200
From: Rick van Rein <>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfO9s36AcWZvo35i0w4yYYK180MwjMsBjFGHcyCiICTlS0Z9nFytVmMxohBQZWLZfwh+a5W/DSJrt2YhTwd0+IiFaTlGhQqcd7tKz4FlMCDNap0M3BAiR JHWLwcxRlbypZ7UoQb+wCUvptReg8OoxIW0WmEZrN5quTZoMYfTFs3Fi3g7LlqZO0OLVQPeYRluOGrPkJQsRHXvHwEXkeQEiOuNyMV3ScGpXCgemp3wmxv5A Azf+/9yMJB7FsPNrjutH8C+jpv1bzFAp82hUI3xm7kM=
Archived-At: <>
Subject: Re: [http-auth] Why is there no SASL support in HTTP?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: HTTP authentication methods <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Aug 2017 16:19:39 -0000

Hello former WG,

In Januari I wrote...

> I've been wondering why HTTP Authentication does not support SASL, but
> instead chooses independent mechanisms from SASL?

...and given the positive replies back then, I have now written a draft
to cover this idea.

Related to this is a proposal that can be helpful to pass SASL over EAP
to (shared) backend infrastructure,

It includes channel binding, which AFAIK is new to HTTP, but SASL is
clear about how to do this: skip over the application protocol and
incorporate TLS through tls-unique, as a minimum mechanism.  So the
reasoning for SCRAM-* to not support it because HTTP does not define it,
does not seem to apply here.  I hope I'm not poking in a hornet's nest
by saying this...

Given that the HTTPAUTH WG has been dismantled, I am not sure what to do
next.  Any advise is welcome.

Best wishes,

Rick van Rein / /