IETF Logo Mail Archive

[dispatch] SASL Authentication for HTTP

Rick van Rein <rick@openfortress.nl> Tue, 25 February 2020 08:10 UTC

Return-Path: <rick@openfortress.nl>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46293A09B1 for <dispatch@ietfa.amsl.com>; Tue, 25 Feb 2020 00:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvwYSj95_TWT for <dispatch@ietfa.amsl.com>; Tue, 25 Feb 2020 00:10:43 -0800 (PST)
Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C501E3A09AE for <dispatch@ietf.org>; Tue, 25 Feb 2020 00:10:42 -0800 (PST)
Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud8.xs4all.net with ESMTP id 6VIajC2ZLPKvK6VIbjp6ci; Tue, 25 Feb 2020 09:10:37 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1582618230; h=message-id : date : from : mime-version : to : cc : subject : content-type : content-transfer-encoding : date : from : subject; bh=fVDnUvfYvRnzt/PWYGEaS1UHTeaSxHb9cj1R3O8F/YA=; b=VBJTEwY+xQv7R4Y4JL2ZFbtHJNhPMcj+BVxI/SCLi++VG1XyiZ0w0uQ9 8g46DGxNtBol9WZwNRvQIDS9XADj8E6C75ym87Z7sVZIAz8NQ0cRqhDAxM pwQ0ET1j+lTUxZfOoC2P6IqByjpSsZWsITCjTsoIt1xoD9P79DKhljsuY=
Received: by fame.vanrein.org (Postfix, from userid 1006) id 69E3826766; Tue, 25 Feb 2020 08:10:29 +0000 (UTC)
X-Original-To: dispatch@ietf.org
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 2C3952675D; Tue, 25 Feb 2020 08:10:24 +0000 (UTC)
Message-ID: <5E54D66F.5070902@openfortress.nl>
Date: Tue, 25 Feb 2020 09:10:23 +0100
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: DISPATCH WG <dispatch@ietf.org>
CC: "Henri Manson (ARPA2)" <henri.manson@arpa2.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4
X-CMAE-Envelope: MS4wfJkwBv0EV+aLM93L1Gg17W8HN9v/Uys/8IsB6m0YT3WKcetmm8ceZO/4pVqSdjgqhhZMc9EhZU6IdvC1wDBTwevgl04Esk24f0ySURrZtyE6YvUUApIq pXKcNPqadajOj3MRutaLV4OcIa+m1piLum9raspUN/OG76Sw5ss5QzmSRiJKtuNqGXOmCNXTeO3GRQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/D19RAxHhbzhh-QQnDPlNIj9EUM8>
Subject: [dispatch] SASL Authentication for HTTP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2020 08:10:46 -0000

Hello,

This draft proposes to introduce SASL as an authentication mechanism
into HTTP.  Adding such mechanisms requires IETF Review according to RFC
7235.

I don't know where to turn, and this has long stopped this proposal from
progressing.  It has now been proposed to go through DISPATCH, as this
is more related to the binding with protocol headers than to SASL, which
itself is quite clear on requirements to its carrier.

I have been made aware that SASL in HTTP has been tried before; the
reasons why that didn't finish 15 years ago are resolved in this draft:

Scalability:

 - stateless server side (server state relays through the client)
 - sequential messages distributed over connections is no problem

Security:

 - no fixation on DIGEST-MD5 (compatibility pulls down security)
 - support for channel binding without fixating protocol layering


Benjamin Kaduk noted my search for IETF mechanisms and responded with:

> That said, I'm happy to see work in this space and would be willing to
> AD-sponsor it upon a recommendation of either DISPATCH group, if that is
> the recommendation.


The authors of the prior HTTP SASL proposal also welcome this work being
done.


What are your recommendations towards this work?


Thanks,
 -Rick


---------


A new version of I-D, draft-vanrein-httpauth-sasl-03.txt
has been successfully submitted by Rick van Rein and posted to the
IETF repository.

Name:		draft-vanrein-httpauth-sasl
Revision:	03
Title:		HTTP Authentication with SASL
Document date:	2020-01-20
Group:		Individual Submission
Pages:		12
URL:
https://www.ietf.org/internet-drafts/draft-vanrein-httpauth-sasl-03.txt
Status:
https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/
Htmlized:       https://tools.ietf.org/html/draft-vanrein-httpauth-sasl-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl
Diff:
https://www.ietf.org/rfcdiff?url2=draft-vanrein-httpauth-sasl-03

Abstract:
   Most application-level protocols standardise their authentication
   exchanges under the SASL framework.  HTTP has taken another course,
   and often ends up replicating the work to allow individual
   mechanisms.  This specification adopts full SASL authentication into
   HTTP.

v2.23.0 | Report a Bug | By Email