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

Rick van Rein <rick@openfortress.nl> Mon, 02 January 2017 11:42 UTC

Return-Path: <rick@openfortress.nl>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 82B37128DF6 for <http-auth@ietfa.amsl.com>; Mon, 2 Jan 2017 03:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nE6DDD7xzc2h for <http-auth@ietfa.amsl.com>; Mon, 2 Jan 2017 03:42:20 -0800 (PST)
Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60B0126579 for <http-auth@ietf.org>; Mon, 2 Jan 2017 03:42:19 -0800 (PST)
Received: from airhead.local ([IPv6:2001:980:93a5:1:fd59:a831:6620:1614]) by smtp-cloud3.xs4all.net with ESMTP id TPiE1u0081ikzLt01PiF44; Mon, 02 Jan 2017 12:42:17 +0100
Message-ID: <586A3C94.4090504@openfortress.nl>
Date: Mon, 02 Jan 2017 12:42:12 +0100
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: http-auth@ietf.org
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/sO0o6Qez6lgWjSQmu_uYSd5uX_Q>
Subject: [http-auth] Why is there no SASL support in HTTP?
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jan 2017 11:42:22 -0000


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

Having a pluggable framework that is updated independently from HTTP
appears beneficial to me.  Also, integration with other systems that do
use SASL would be greatly improved.  With support for SASL is so many
mail clients already, its introduction to HTTP clients may be relatively

I am aware that mechanisms need to store state on the validating side,
so the server, which contradicts HTTP design.  That may be easily
resolved by passing some state back to the client, and making it supply
when it continues.  For example, digest-based authentication might send
back random bytes as state, and hash it with an internal key to form a
challenge.  When presented with the state and response, the computation
can be validated without a need for state on the server.

Alternatives to state on the server may also exist -- for instance, a
TLS wrapper may provide consistent entropy using RFC 5705.

One thing I've been thinking is that SASL EXTERNAL may be a useful
addition.  Not to actually authenticate, but it could trigger
authorisation processes, possibly using another identity and/or
triggering the generation of Authorization-Info headers that might relay
information (such as identity) to the client at the HTTP layer.

If so desired, I am willing to write an I-D for this.


Rick van Rein
(wishing all a properly secured 2017)