[Ace] AUTH48 changes to draft-ietf-ace-coap-est-18.txt

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 31 March 2022 13:15 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733073A0819 for <ace@ietfa.amsl.com>; Thu, 31 Mar 2022 06:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 XUPn8oX673eP for <ace@ietfa.amsl.com>; Thu, 31 Mar 2022 06:14:55 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253733A0DB0 for <ace@ietf.org>; Thu, 31 Mar 2022 06:13:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DA9E238E2D for <ace@ietf.org>; Thu, 31 Mar 2022 09:24:37 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RUUFCwZrn-n6 for <ace@ietf.org>; Thu, 31 Mar 2022 09:24:35 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3FC4538E2E for <ace@ietf.org>; Thu, 31 Mar 2022 09:24:35 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1648733075; bh=Vj+AZ2AbDerQ4iOuUaRVsib52Htc9pbUyKY9j8/nd8E=; h=From:To:Subject:In-Reply-To:References:Date:From; b=GQvNo14bc3wTvFVNIiQlfcY4Xsb6shrmg4LtbIiYqJSALmNy/UcIQzN9NnKcEtId4 lU95pbJYJ+Gb7bqOe5lXsw0aIagcYfh5a2KQ5PLbeMxkzI+cg2xRImdfLiV7Od1gq3 HCm60wars//jlzrFqG9UD1ZXXmt0zL5M76L3SajPvBVvzpp778QRXbbmPcZvfY7Jje CdHjyjcb3V7vwcWpMDboBiA5tpahCkYVCQgFbf94p13recGDg08zC0lVhjEXoXabaC XI1B/sBQyLj9bUaOMZXc6tynMaMg2RbCziFuJUSryW7G4BQQhYptWH082LRdshSk+W Ee58O4yzOvrGg==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 349654A7 for <ace@ietf.org>; Thu, 31 Mar 2022 09:13:46 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ace@ietf.org
In-Reply-To: <20220322211318.GO13021@mit.edu>
References: <17584.1645467335@localhost> <a02b14a0741149b08dbdd09028a15ac5@EX13D01ANC003.ant.amazon.com> <23184.1645546621@localhost> <F93B7AFB-B110-4378-96CA-38D939090B1A@amsl.com> <b1476640cd754d588f91ca5feed5b5f9@EX13D01ANC003.ant.amazon.com> <88257CE4-7C8B-4FF6-A144-6DAEADB29093@amsl.com> <CAEhiCPxeXhXpjNgH_HHB28jsjN+de5g0vZf=bthFELM=8PZ64w@mail.gmail.com> <29882.1646334731@localhost> <36B36748-6A38-425F-9D7A-3B04E1BEE50C@amsl.com> <25712.1646507185@localhost> <20220322211318.GO13021@mit.edu>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 31 Mar 2022 09:13:46 -0400
Message-ID: <14845.1648732426@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/8UxZ0hRXlP_oXHGfAwgvgfgAHLI>
Subject: [Ace] AUTH48 changes to draft-ietf-ace-coap-est-18.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2022 13:15:04 -0000

Hi,

draft-ietf-ace-coap-est-18 finished the author interaction and approval a
couple of weeks ago.  One of the things that came up at the last minute was
the way in which "tls-unique" from TLS 1.2 is replaced with a key exporter in
TLS 1.3.

This is explained in draft-ietf-kitten-tls-channel-bindings-for-tls13,
and we added an informative to reference to that document.

This was suggested by the Area Director, and the authors were completely in
agreement.

Basically, we inserted this paragraph in section 3.

   For (D)TLS 1.3, Appendix C.5 of [RFC8446] describes lack of
   channel bindings similar to tls-unique.  [TLS13-CHANNEL-BINDINGS] can
   be used instead to derive a 32-byte tls-exporter binding from the
   (D)TLS 1.3 master secret by using a PRF negotiated in the (D)TLS 1.3
   handshake, "EXPORTER-Channel-Binding" with no terminating NUL as the
   label, the ClientHello.random and ServerHello.random, and a zero-
   length context string.  When proof-of-possession is desired, the
   client adds the tls-exporter value as a challengePassword in the
   attributes section of following the algorithm described PKCS #10
   CertificationRequest [RFC5967] to
   prove that the client is indeed control the private key at the
   time of the (D)TLS session establishment.

This email is something we meant to send at the time, but we didn't assign
someone to do that.  I was cleaning up my inbox...

I think the RFC itself will emerge from RPC any minute now.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide