Re: [dispatch] SASL Authentication for HTTP

Ben Campbell <ben@nostrum.com> Tue, 03 March 2020 20:03 UTC

Return-Path: <ben@nostrum.com>
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 D7D653A0890 for <dispatch@ietfa.amsl.com>; Tue, 3 Mar 2020 12:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.087
X-Spam-Level:
X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=1.49, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 ykynVdW5aIsh for <dispatch@ietfa.amsl.com>; Tue, 3 Mar 2020 12:03:49 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792753A088A for <dispatch@ietf.org>; Tue, 3 Mar 2020 12:03:49 -0800 (PST)
Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 023K3jx8019335 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Mar 2020 14:03:46 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1583265827; bh=3upcIhBb3J1j41FeNFnXany2HgF/GAgz5KL38Tk6sBE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=jd5FPvqpKBTRVhQepdMjbT+2F3Axll7AsSIf4KMUFleRVIPFJRa7Q9hTntHwXy+7z j/zqz07rUJKHu8l39vGKcCtUBQIOdR8NEwqY+/gile5hc7TxKMq+58aOc9CscywT3H OwEe6EceA3ANY62ZhwunpKp0bzM4GF0TbvKUVuGo=
X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <B275B223-6985-4D4D-9A24-0A1E1B2D1E36@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_26FEBA23-E63C-44ED-AC5E-A1BB77E41101"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Tue, 03 Mar 2020 14:03:38 -0600
In-Reply-To: <5E54D66F.5070902@openfortress.nl>
Cc: Tommy Pauly <tpauly@apple.com>, Mark Nottingham <mnot@mnot.net>
To: DISPATCH WG <dispatch@ietf.org>
References: <5E54D66F.5070902@openfortress.nl>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/pOv_9_eRXNmmyR7XIXe1_lrnukQ>
Subject: Re: [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, 03 Mar 2020 20:03:58 -0000

Hi,

Does anyone in DISPATCH (esp. our HTTP experts) have thoughts on Rick’s draft?

I see that it had a small amount of discussion in HTTPBIS back in January. Is this something that should be discussed in DISPATCH or does it clearly belong to HTTPBIS? (I’ve copied the HTTPBIS chairs)

Thanks!

Ben.

> On Feb 25, 2020, at 2:10 AM, Rick van Rein <rick@openfortress.nl> wrote:
> 
> 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.
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch