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

Seitz Ludwig <ludwig.seitz@combitech.se> Wed, 24 March 2021 07:43 UTC

Return-Path: <ludwig.seitz@combitech.se>
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 D03223A262E; Wed, 24 Mar 2021 00:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 X5pDA84GVQmo; Wed, 24 Mar 2021 00:43:02 -0700 (PDT)
Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (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 4C7913A262D; Wed, 24 Mar 2021 00:42:59 -0700 (PDT)
Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.7/8.14.7) with ESMTP id 12O7gubK067570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Mar 2021 08:42:56 +0100
Received: from corpappl17771.corp.saab.se (corpappl17771.corp.saab.se [10.12.196.78]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 12O7gViI021423 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 24 Mar 2021 08:42:31 +0100
Received: from corpappl17773.corp.saab.se (10.12.196.80) by corpappl17771.corp.saab.se (10.12.196.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 24 Mar 2021 08:42:31 +0100
Received: from corpappl17773.corp.saab.se ([fe80::20a9:e9fa:54a3:2afd]) by corpappl17773.corp.saab.se ([fe80::20a9:e9fa:54a3:2afd%17]) with mapi id 15.02.0792.010; Wed, 24 Mar 2021 08:42:31 +0100
From: Seitz Ludwig <ludwig.seitz@combitech.se>
To: Benjamin Kaduk <kaduk@mit.edu>, Martin Duke <martin.h.duke@gmail.com>
CC: The IESG <iesg@ietf.org>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "ace@ietf.org" <ace@ietf.org>, "draft-ietf-ace-oauth-params@ietf.org" <draft-ietf-ace-oauth-params@ietf.org>
Thread-Topic: [EXTERNAL] Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-oauth-params-13: (with COMMENT)
Thread-Index: AQHXHfhSkhLtj/pc0UCybcMpIjr3vKqSxa0Q
Date: Wed, 24 Mar 2021 07:42:30 +0000
Message-ID: <b14728f2cff34d2cbfe651f761e05eb5@combitech.se>
References: <161609309354.6073.6421666447862558561@ietfa.amsl.com> <20210321021639.GL79563@kduck.mit.edu>
In-Reply-To: <20210321021639.GL79563@kduck.mit.edu>
Accept-Language: en-SE, sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [136.163.101.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Saab-MailScanner-Information: Please contact the ISP for more information
X-Saab-MailScanner-ID: 12O7gViI021423
X-Saab-MailScanner: Found to be clean
X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=2.594, required 5, HELO_NO_DOMAIN 0.00, KAM_ASCII_DIVIDERS 0.80, PDS_BAD_THREAD_QP_64 1.00, RDNS_NONE 0.79, URIBL_BLOCKED 0.00)
X-Saab-MailScanner-SpamScore: ss
X-Saab-MailScanner-From: ludwig.seitz@combitech.se
X-Saab-MailScanner-Watermark: 1617176553.53058@3y6NkVKwifnc481BonyO7A
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/PN9K97swYMGksRDmF-MQXMGUogY>
Subject: Re: [Ace] [EXTERNAL] Re: 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: Wed, 24 Mar 2021 07:43:07 -0000

Hi Martin, Ben,

If I were to change the offending sentence like so:
"It is RECOMMENDED that an AS reject a request containing a symmetric key value ... (Note: this does not apply to key identifiers referencing a symmetric key)"

(the "Note..." part being the new clarification), would that help making the intention distinction more visible?

/Ludwig


> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: den 21 mars 2021 03:17
> To: Martin Duke <martin.h.duke@gmail.com>
> Cc: The IESG <iesg@ietf.org>rg>; ace-chairs@ietf.org; ace@ietf.org; draft-ietf-
> ace-oauth-params@ietf.org
> Subject: [EXTERNAL] Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-
> oauth-params-13: (with COMMENT)
> 
> 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