Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-oauth-params-13: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sun, 21 March 2021 02:16 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 7F8623A1217; Sat, 20 Mar 2021 19:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.403
X-Spam-Level:
X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 Rz6hmR-cJKwX; Sat, 20 Mar 2021 19:16:48 -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 5C3603A1218; Sat, 20 Mar 2021 19:16:47 -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 12L2Gdbb000894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Mar 2021 22:16:44 -0400
Date: Sat, 20 Mar 2021 19:16:39 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: The IESG <iesg@ietf.org>, ace-chairs@ietf.org, ace@ietf.org, draft-ietf-ace-oauth-params@ietf.org
Message-ID: <20210321021639.GL79563@kduck.mit.edu>
References: <161609309354.6073.6421666447862558561@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <161609309354.6073.6421666447862558561@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/SrmluxJHsWtFHdkVSxQCrZcxokM>
Subject: Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-oauth-params-13: (with COMMENT)
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: Sun, 21 Mar 2021 02:16:54 -0000

Hi Martin,

On Thu, Mar 18, 2021 at 11:44:53AM -0700, Martin Duke via Datatracker wrote:
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In sec 3.1 it says the AS SHOULD reject req_cnf if the key is symmetric. But in
> Sec 5 it presents a totally reasonable use case where the C and RS hold a
> previously established (symmetric?) key.  These observations are somewhat
> contradictory. Should 3.1 include a qualifier. Would the AS know about this key
> a priori so that it can ignore the recommendation? If not, how can this be done
> safely?

I think there is a subtle distinction between the two cases, if I am
remembering correctly.  In particular, in Section 3.1 it says that "[i]t is
RECOMMENDED that an AS reject a request containing a symmetric key value",
and the last word ("value") is important!  This is saying, if the client
tries to propose to the AS the actual symmetric key to be (encapsulated in
the token and) used to secure C/RS communications, the AS typically should
reject it, since a constrained client is likely to have a much worse RNG
than the AS.  If, on the other hand, some out-of-band management system has
provisioned a symmetric key shared by C and RS, that key is presumed to be
strong, but in the scenario depicted in Section 5 it is "the key-identifier
of a previously established key between C and RS" that "req_cnf" conveys.
Note that this scenario is only the identifier, not the key value itself.

This is clearly a pretty subtle distinction to make, and if you have any
suggestions for how to word things to make it more obvious, we'd love to
have them.

Thanks,

Ben