Re: [kitten] Stating support for HTTP-SASL on the HTTP WG list

Nico Williams <nico@cryptonector.com> Sun, 29 January 2023 04:45 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22017C14CE40 for <kitten@ietfa.amsl.com>; Sat, 28 Jan 2023 20:45:50 -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_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cryptonector.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 493HK01KnB5K for <kitten@ietfa.amsl.com>; Sat, 28 Jan 2023 20:45:46 -0800 (PST)
Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) (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 15C80C14F730 for <kitten@ietf.org>; Sat, 28 Jan 2023 20:45:45 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 221628C0752; Sun, 29 Jan 2023 04:45:45 +0000 (UTC)
Received: from pdx1-sub0-mail-a234.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B0A598C0A02; Sun, 29 Jan 2023 04:45:44 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1674967544; a=rsa-sha256; cv=none; b=sEMGVpTr50A9v42YExMJCF1YbFcWtVkaTX9NGbmVeSeS2EWrLhHvPD6FwN8PfbM0F0O/Dw rBrtPlCOYQPWJjCcQffemdsz4LLjFTaLkZ2LW2z7xb1+pTP2St5PUVdEWmeEFzNJ6s5Kdq XMTcud3WFO+6RwQo8H0L8/VotKzqx3CfIDFQwLqw4oKW2slpus5wjLTjDXeOPw4nGk5NYf JVMNflCIwONDUBltmACZF+b6RVYbtwPGMfopVlzwjfzq1iowPbXNkRzBJ3QMYB1Mg3HNse YhuTxh/qV09h9Rf7Ju/ZyuHWM8HpERqdBvjvRcbBDsFzMgf2IjhAaGR/D0fELA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1674967544; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Kozac9eFIGfa0wb0Bb6E+PLWJbOLRXJkcBEHxNouYbg=; b=LtK2nQ9lMmYWQbbaEq5h6CbiAnYfYXWbwjUQ2wNWWRh7HhFFN1lc51wRsMrkSfxZtU/Zme 2ZV7FcKYCMIqCN8+5LADWMsc3lnB2UymBmDJpHaGBxCR6v10Eyfhm8tHilV0/j9SJPz9o1 N13/uAvn7ZtM1GXekwR6vNxR/hHAir8ZDXXHqzNmLhijRRVWugXv5E9/Y6YZUVmSIVX2g2 aMGfgaG6LRQFu7Yxa8U+7svt0OFiEdIfae3K8j58M+6jJ7zTAPrOAbpIQiW3QDx4+qYIVh alb18LbAMKiQ9kLeSvP+Y7Yc1yUd2WIToH2yQd3P2IMVdOgi8vf9o1MpvSieIA==
ARC-Authentication-Results: i=1; rspamd-5fb8f68d88-zgmxp; auth=pass smtp.auth=dreamhost smtp.mailfrom=nico@cryptonector.com
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Reign-Trail: 46c6085d77fe7f05_1674967544958_3974501400
X-MC-Loop-Signature: 1674967544958:1508635215
X-MC-Ingress-Time: 1674967544958
Received: from pdx1-sub0-mail-a234.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.97.48.86 (trex/6.7.1); Sun, 29 Jan 2023 04:45:44 +0000
Received: from gmail.com (cpe-66-25-27-1.tx.res.rr.com [66.25.27.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a234.dreamhost.com (Postfix) with ESMTPSA id 4P4JfJ18MFzC2; Sat, 28 Jan 2023 20:45:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cryptonector.com; s=dreamhost; t=1674967544; bh=Kozac9eFIGfa0wb0Bb6E+PLWJbOLRXJkcBEHxNouYbg=; h=Date:From:To:Cc:Subject:Content-Type; b=Uzuhc0qeuFTCkjIQEylrLeQuwBKNzO7iB2uhSOHT0dRQ+pDMCzqpniwbjR+pLtUmS CWic6br+GT5wT6x9+0cxh5q+X5/ks7VH+RPDMCD8JX+JnxvFC7U0LbGGghGfW8UHZl fRIm9c68Q7ZzVPIngLFPDoP+4bGDV74/WhY0nGAAyxiJiosgBFnC7p2QJfQs0uAa78 2SKngT7uKmX6YWmmFcAsPjNhmikBNIDs6P2fzkGgqJC6GqVBx21DrSdr0dInW8S5+s grGVS2tQjvNHo7ksCRqN4aV0DDxRCg6+XwgLyvGJgBTSEDKpu8prJL9vcRDeXbyj5t tMjs4METDFAfw==
Date: Sat, 28 Jan 2023 22:45:41 -0600
From: Nico Williams <nico@cryptonector.com>
To: Ken Hornstein <kenh@pobox.com>
Cc: kitten@ietf.org
Message-ID: <Y9X59aiqnkK5Cvdx@gmail.com>
References: <20230127160101.GB635@openfortress.nl> <048e6943f02302bb5cf7b8c55521931ce3748d30.camel@redhat.com> <20230128215854.629841D6333@pb-smtp20.pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230128215854.629841D6333@pb-smtp20.pobox.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/yi5mAvvFhmt9jD7mHFo1IOM3f2g>
Subject: Re: [kitten] Stating support for HTTP-SASL on the HTTP WG list
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Jan 2023 04:45:50 -0000

On Sat, Jan 28, 2023 at 04:58:49PM -0500, Ken Hornstein wrote:
> >I would like to see a standardized mechanism to return a bearer token
> >(aka session cookie) that allows the client to retain (if they want) an
> >authorization token to be used in following requests.
> 
> I am DEFINITELY not the expert here, but in my limited experience in this
> area it seems like OIDC is being used for this purpose more and more.

Different beast.  JWT is just a token sent in Authorization:, with no
mechanism for indicating where to get the token (the application has to
know a priori), only that it's needed.  Whereas OIDC uses redirects to
solve that problem, and OIDC uses URI q-params to convey the outcome
token (called a "code"), but putting tokens in q-params is dangerous
because URIs tend to get logged, so in OIDC the server has to
authenticate as itself to exchange the code from the URI for an actual
JWT token.

Applications that use JWT, OIDC, Negotiate, etc., will still generally
want to use encrypted state cookies even though they could a token as a
cookie just because a) there may be other state they might want to
include, b) symmetric AEAD ciphers will be faster than asymmetric public
key signature validation (which is relevant to some schemes, like JWT).

Simo's proposal for a standard encrypted application state cookie sounds
good to me, but it's mostly a solved problem and one where we don't
really need a standard so much as guidance -- guidance that the W3C
probably already gives.  Since a standard for encrypted application
state cookies is not necessary for HTTP SASL auth to progress (just as
it wasn't for any other HTTP auth scheme), and since KITTEN WG isn't the
right venue for that either (just checked the charter), I think we
probably should not tackle that.

Nico
--