[Ace] minor comments on draft-ietf-ace-oscore-profile-16

Benjamin Kaduk <kaduk@mit.edu> Thu, 04 March 2021 02:29 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D9923A0B56; Wed, 3 Mar 2021 18:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id brC0ZDOgAwHw; Wed, 3 Mar 2021 18:29:45 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) (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 988BF3A0B5F; Wed, 3 Mar 2021 18:29:29 -0800 (PST)
Received: from kduck.mit.edu ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1242TMpd006329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Mar 2021 21:29:27 -0500
Date: Wed, 3 Mar 2021 18:29:22 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-ace-oscore-profile@ietf.org
Cc: ace@ietf.org
Message-ID: <20210304022922.GN56617@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Z_UOHksVi0bio8d0lcAdUp5ERHA>
Subject: [Ace] minor comments on draft-ietf-ace-oscore-profile-16
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, 04 Mar 2021 02:29:47 -0000

Hi all,

I was going through the four drafts that have been "waiting for writeup"
for a while, to check that the latest changes are good and they are ready
to go once the last point from the secdir review of
draft-ietf-ace-dtls-authorize is wrapped up.  In short: they are, but I had
a couple comments on the OSCORE profile that might help improve it.

In section 2, we have some discussion:

   The use of nonces during the exchange prevents the reuse of an
   Authenticated Encryption with Associated Data (AEAD) nonces/key pair
   for two different messages.  Reuse might otherwise occur when client
   and RS derive a new Security Context from an existing (non- expired)
   access token, as might occur when either party has just rebooted, and
   might lead to loss of both confidentiality and integrity.  Instead,
   by using nonces as part of the Master Salt, the request to the authz-
   info endpoint posting the same token results in a different Security
   Context, by OSCORE construction, since even though the Master Secret,
   Sender ID and Recipient ID are the same, the Master Salt is different
   (see Section 3.2.1 of [RFC8613]).  If nonces were reused, a node
   reusing a non-expired old token would be susceptible to on-path
   attackers provoking the creation of OSCORE messages using old AEAD
   keys and nonces.

Where we talk about how the nonces (N1 and N2) exchanged during the
authz-info request/response are used to prevent the use of nonce+key
combinations for the AEAD used for the OSCORE messages.  But there's really
two classes of nonce: the ones for the AEAD, and the ones used in
constructing the master salt.  Whenever we just say "nonce" or "nonces"
there is potential for ambiguity, so we might want to add an adjective
every time we use the word, as tedious as it is to do so.

Also in Section 2, I just wanted to check on the location of the "mutual
authentication" indication -- currently it's show after the second OSCORE
Response, but I am not sure why it is not achieved after just the first
Request/Response exchange that performs proof of possession.