Re: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11

Benjamin Kaduk <kaduk@mit.edu> Mon, 27 July 2020 18:07 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 8CD963A1B6B; Mon, 27 Jul 2020 11:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 57uVxjFMhMGi; Mon, 27 Jul 2020 11:07:49 -0700 (PDT)
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 0E8FF3A1B5D; Mon, 27 Jul 2020 11:07:48 -0700 (PDT)
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 06RI7hsk012246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 14:07:45 -0400
Date: Mon, 27 Jul 2020 11:07:42 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: ops-dir@ietf.org, draft-ietf-ace-oscore-profile.all@ietf.org, ace@ietf.org, last-call@ietf.org
Message-ID: <20200727180742.GG41010@kduck.mit.edu>
References: <159521497745.9074.17834135527258230957@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <159521497745.9074.17834135527258230957@ietfa.amsl.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/IRerQbhrN7w0iAjlRBBz-B2I-R0>
Subject: Re: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11
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, 27 Jul 2020 18:07:51 -0000

Hi Linda,

On Sun, Jul 19, 2020 at 08:16:17PM -0700, Linda Dunbar via Datatracker wrote:
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> This document describes how to set specific parameters in using  the
> Authentication and Authorization for Constrained Environments (ACE) framework
> [I-D.ietf-ace-oauth-authz]. The document is written clear, except some minor
> issues:
> 
>  Section 4.1.1 states that Nonce Parameter must be sent from the client to RS.
>  What would be the problem if the client doesn't include the "NONCE"?

There's a little more discussion of the N1 in the previous section, but in
essence, this nonce is required to protect the client against replayed
responses.  Since the token contents (including key derivation material)
would be unchanged across security contexts, the nonce is used to make each
one different; it has to be client-generated so that the client is sure
that this security context is "fresh" (vs. replayed).

> Page 12: It asks RFC editor to validate the numbers listed in Figure 7.  There
> is no explanation or comments for those values. It will be very difficult for
> RFC editor to validate. It seems to me there are 4 columns but  I can't
> understand the meaning of the values under 1st, 2nd, and 3rd columns.

I think this is just a note that the RFC Editor should make sure that
someone has checked the values (i.e., the authors).  The RFC Editor does
not need to be the one actually doing the checking.

Thanks for the review,

Ben

> it is kind of difficult to validate the correctness by just reading through the
> document.  It would be better to have an implementation report of the proposed
> "Profile".
> 
> Best Regards,
>  Linda Dunbar
> 
> 
>