[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.
- [Secdispatch] Draft: Adding SASL to HTTP Rick van Rein
- Re: [Secdispatch] Draft: Adding SASL to HTTP Benjamin Kaduk