Re: [Wish] Can a client switch tokens?

Juliusz Chroboczek <jch@irif.fr> Sun, 14 January 2024 13:44 UTC

Return-Path: <jch@irif.fr>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C357DC14F615 for <wish@ietfa.amsl.com>; Sun, 14 Jan 2024 05:44:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=irif.fr
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 xHzb3aW4xElt for <wish@ietfa.amsl.com>; Sun, 14 Jan 2024 05:43:59 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 C9ED3C14F5F9 for <wish@ietf.org>; Sun, 14 Jan 2024 05:43:57 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 40EDhr5p024487; Sun, 14 Jan 2024 14:43:53 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 944F96A066; Sun, 14 Jan 2024 14:43:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-type:content-type:mime-version:user-agent:references :in-reply-to:subject:subject:from:from:message-id:date:date :received:received; s=dkim-irif; t=1705239831; x=1706103832; bh= fSr4ylajSMhCg8WLyNj3CK8dCgrXqiWgqLKdiNrEbzk=; b=hSyeDNoreVoGE0wN guneaIsp+jmIzn58gFSfZFLtmWTzvp6yFmP6WaBIsydx06qsB6OMWVjp7FhrQ9bj szl0ZqkQ5BD1loEnNfRAjPonmRVxf3KEl9Hme0+x8TPaXD7FbqHfutd+/WqqfpVW sGfN8tXdzOaQkI4QMEPwq+XA/xHDsqMKGBit4zLDUZ2mkx6bkV4dkfazPGOoLZ09 hIty8dj3CMkbknuTVfcdNUN6fSQ+Rvw63oxPQwlVbVlrtcd6UBzLyfu+vcvsCOD3 Cuvpy6W01qLsE9Yc8RmHpfleVOPxQ7quGaSlh/3Tgr4sQS6I5XHBtuCE/Qzou3Cc klBAoQ==
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id zfmLe36wutye; Sun, 14 Jan 2024 14:43:51 +0100 (CET)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id DB3D769FE6; Sun, 14 Jan 2024 14:43:50 +0100 (CET)
Date: Sun, 14 Jan 2024 14:43:50 +0100
Message-ID: <87frz0hvxl.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: WISH List <wish@ietf.org>
In-Reply-To: <CA+ag07btC4fxv52hkd3W=h6pMXUrDvuWBLJY_m17DT6Dimnufg@mail.gmail.com>
References: <87v87x46xu.wl-jch@irif.fr> <CA+ag07a0E7itrUONH8c8skZU_-bw_-bddjZtCa8Sho7YhL2WCQ@mail.gmail.com> <87edek4qn8.wl-jch@irif.fr> <CA+ag07btC4fxv52hkd3W=h6pMXUrDvuWBLJY_m17DT6Dimnufg@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.1 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 14 Jan 2024 14:43:53 +0100 (CET)
X-Miltered: at korolev with ID 65A3E519.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 65A3E519.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 65A3E519.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/1VZZjTxSKQa_Kz65JS7L5lBw89U>
Subject: Re: [Wish] Can a client switch tokens?
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wish>, <mailto:wish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish/>
List-Post: <mailto:wish@ietf.org>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wish>, <mailto:wish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jan 2024 13:44:04 -0000

> what do you mean by switch/update tokens?

The client C requests a token T1.

C uses T1 to create a WHIP session:

  C->S: POST(T1) offer
  S->C: answer

An hour later, C decides to do an ICE restart.  However, T1 has expired.
There are two possible client behaviours:

1. C uses token T1 for the ICE restart, even though it has expired:

  C->S: PATCH(T1)

2. C requests a new token T2, and uses the new, unexpired token:

  C->S: PATCH(T2)

In case 1, the server needs to allow the client to use an expired token
with a WHIP session, as long as the token is identical to the one used for
creating the session.  This is easy to implement, both on the client (the
client never renews a token) and on the server (the server retains the
original token in the data structure that represents a WHIP session).

In case 2, the server needs to allow the client to use a different token
for PATCH requests than the one used during session creation.  There is
also the need to communicate to the client the information that a token
has expired.  I have no idea how to implement case 2.

Galene currently uses approach 1, it stores the token used for session
creation and allows it to be reused for PATCH even when it has expired.
Is this the intended behaviour for a WHIP client?  If it is, then I think
we need to document (possibly in an informational appendix) that a PATCH
request may use an expired token.  If it is not, then please explain the
intended behaviour.

-- Juliusz