Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-oscore-profile-17: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sun, 21 March 2021 05:26 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 862A03A15ED; Sat, 20 Mar 2021 22:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.404
X-Spam-Level:
X-Spam-Status: No, score=0.404 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, URIBL_BLOCKED=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 O04se20b9dIK; Sat, 20 Mar 2021 22:26:51 -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 2DBE03A15EC; Sat, 20 Mar 2021 22:26:50 -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 12L5QeGU025037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Mar 2021 01:26:45 -0400
Date: Sat, 20 Mar 2021 22:26:40 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ace-oscore-profile@ietf.org, ietf@augustcellars.com, ace-chairs@ietf.org, ace@ietf.org
Message-ID: <20210321052640.GQ79563@kduck.mit.edu>
References: <161619357138.21782.3555422752704211953@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <161619357138.21782.3555422752704211953@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/UiuICSefistrdBiu1tQs9Vwg6gU>
Subject: Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-oscore-profile-17: (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 05:26:56 -0000

On Fri, Mar 19, 2021 at 03:39:31PM -0700, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-ace-oscore-profile-17: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Sec 4.1. I don't understand how the OSCORE security context is secure. In Sec
> 4.1 it says the C-RS communications need not be protected. But the context is
> fully derived from parameters that go back and forth over this channel. Why
> can't an observer simply compute the OSCORE keys?

The POST to the authz-info endpoint includes just the access_token, nonce1,
and ace_client_recipientid.  I think that your concerns focuus on the
access_token itself, since that is how the various OSCORE security context
parameters are conveyed from AS to RS (via C).  Note that these parameters
need not be conveyed directly in the token, since the token could be an
opaque reference that requires the RS to use token introspection in order
to retrieve the associated parameters.  However, when introspection is not
used, the security context parameters are indeed carried directly in the
token, and this scheme does not provide security in that case unless the
token contents themselves are protected.

It seems (on a quick check, so I might have missed it) that we don't
actually say "you have to use an encrypted or opaque token" (not one that's
only signed) anywhere.  So ... good catch, and thank you!

-Ben