[Secdispatch] Draft: Adding SASL to HTTP

Rick van Rein <rick@openfortress.nl> Fri, 06 March 2020 07:24 UTC

Return-Path: <rick@openfortress.nl>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584BF3A08E1 for <secdispatch@ietfa.amsl.com>; Thu, 5 Mar 2020 23:24:39 -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 JqYWDV1oZMog for <secdispatch@ietfa.amsl.com>; Thu, 5 Mar 2020 23:24:37 -0800 (PST)
Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 03CC03A08E0 for <secdispatch@ietf.org>; Thu, 5 Mar 2020 23:24:36 -0800 (PST)
Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id A7LUjoBvN9Im2A7LVjCYuB; Fri, 06 Mar 2020 08:24:34 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1583479466; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=IcFFHrZzuv/rhltlhldASMVYiJsQ7UATVmBeheF8yno=; b=E2Q+OLOqEGZQP/zv3xMDpIaE6SvXRk08KpiQxx8PCRaJwHhv/8yAq/XF 4N/G43/osbzduzhyCth96k9Jby6VoBdxmw+C4dcK8kDRWim5TL0XWu8l01 jdWfUJJyX7gmHqSfNKLD3WiDpkbTXi1FT+/+0Q7kuj687AWbsdVHXgjE0=
Received: by fame.vanrein.org (Postfix, from userid 1006) id 05DE0271E9; Fri, 6 Mar 2020 07:24:25 +0000 (UTC)
X-Original-To: secdispatch@ietf.org
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 20E3F271E6; Fri, 6 Mar 2020 07:24:21 +0000 (UTC)
Message-ID: <5E61FAA4.3030902@openfortress.nl>
Date: Fri, 06 Mar 2020 08:24:20 +0100
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: SECDISPATCH WG <secdispatch@ietf.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: MS4wfKoV/y5kp6ui3ycQ+gz4XAWhu8mypmoEclwaE0xER8kEEXrAI7pBxz/SrTomUBbFQect4ZdHJdYA1vYsByIORtDXsQI3PeowfnI3zBiB3L/El02Ug7Hl krLNpCL82M5GlOMRayP43S6Y9vlaQb81m2xCvp1ATkXXxYP5UNXs1n5B990Q4vBCaXnbYSe1WAERpA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/1HJnsIBVTPzdIo6rQ_Oz8-NtBdU>
Subject: [Secdispatch] Draft: Adding SASL to HTTP
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2020 07:24:39 -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 currently hangs somewhere between DISPATCH And
SECDISPATCH, so it would be useful to hear thoughts about this proposal.

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


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

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.