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

Benjamin Kaduk <kaduk@mit.edu> Mon, 08 March 2021 12:14 UTC

Return-Path: <kaduk@mit.edu>
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 BA1073A0D76; Mon, 8 Mar 2021 04:14:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lciQYMMVNPYw; Mon, 8 Mar 2021 04:14:17 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CDEFE3A0D03; Mon, 8 Mar 2021 04:14:16 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 128CE7rD022235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Mar 2021 07:14:11 -0500
Date: Mon, 8 Mar 2021 04:14:06 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: =?iso-8859-1?Q?G=F6ran?= Selander <goran.selander@ericsson.com>
Cc: "ace@ietf.org" <ace@ietf.org>, "draft-ietf-ace-oscore-profile@ietf.org" <draft-ietf-ace-oscore-profile@ietf.org>
Message-ID: <20210308121406.GK56617@kduck.mit.edu>
References: <20210304022922.GN56617@kduck.mit.edu> <7D651AAF-74DB-4DE7-A688-DEB5DD2FB4C8@ericsson.com> <20210304210857.GV56617@kduck.mit.edu> <772747A5-E0F7-4934-B97B-7227D360F4A7@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <772747A5-E0F7-4934-B97B-7227D360F4A7@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/h0cOyD4ZIvjKJw3ib59qVokohuY>
Subject: Re: [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: Mon, 08 Mar 2021 12:14:24 -0000

Hi Göran,

Thanks for doing the sweep through the document checking for "nonce" usage.
The change you call out below (and the entire -17) looks good to me.

Thanks again,

Ben

On Mon, Mar 08, 2021 at 11:24:17AM +0000, Göran Selander wrote:
> 
> Hi Ben, and all,
> 
> I just submitted -17 based on Ben's comments in this mail thread, and also a change of a security consideration.
> 
> * "mutual authentication" removed from figure
> * the changes proposed below are all included, and further changes to the same effect
> 
> When I went through the  61 occurrences of "nonce" I found a description of an attack which I thought needed to clarified. Please review.
> 
> OLD
> If that is not guaranteed, nodes are susceptible to reuse of AEAD (nonce, key) pairs, especially since an on-path attacker can cause the client to use an arbitrary nonce for Security Context establishment by replaying client-to-server messages.
> 
> NEW
> If that is not guaranteed, nodes are susceptible to reuse of AEAD (nonce, key) pairs, especially since an on-path attacker can cause the use of a previously exchanged client nonce N1 for Security Context establishment by replaying the corresponding client-to-server message.
> 
> 
> Göran
> 
> 
> 
> On 2021-03-04, 22:09, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> 
>     On Thu, Mar 04, 2021 at 04:17:52PM +0000, Göran Selander wrote:
>     > Hi Ben,
>     > 
>     > Thanks for good comments. 
>     > 
>     > Starting with the second comment, I agree the text "mutual authentication" in the figure should appear after the first exchange. It seems to have been left and forgotten during the ASCII art session. It is described in Section 4 so could be removed from the figure if it isn't possible to find a place for it to print well.
> 
>     Sounds reasonable.
> 
>     > On 2021-03-04, 03:29, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
>     > 
>     >     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.
>     > 
>     > [GS] Here is a proposal to address your first comment. There are already nonce qualifications in partial use so it didn't make sense to me to insert extra adjectives on every occasion. See below.
>     > 
>     >       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. 
>     > 
>     > [GS] In the sentence above the difference between the nonces should be clear, right?
> 
>     Yes, though if we name N1 and N2 (so, "the use of nonces N1 and N2 during
>     the exchange") that would let us use N1 and N2 as disambiguators later in
>     the paragraph, if we need to.  (We may not need to use the names N1 and N2,
>     though.)
> 
>     >       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-
>     > 
>     > [GS] "Instead, by using the exchanged nonces as part of the Master Salt, ..."
> 
>     +1
> 
>     >        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
>     > 
>     > [GS] "If the exchanged nonces were reused, ... "
> 
>     +1
> 
>     >        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.
>     > 
>     > [GS] "... the creation of an OSCORE message using an old AEAD key and nonce."
> 
>     +1
> 
>     > [GS] In the rest of the document we would use nonce without qualification as it is referring to the exchanged value. Is that clear enough or do you want a consistent adjective throughout the draft?
> 
>     My expectation is that the rest of the document is clear enough as-is, and
>     that only this portion needs special treatment since it's specifically
>     talking about the risks of "nonce reuse" for a different type of nonce.
> 
>     Thanks for putting this together,
> 
>     Ben
>