Re: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08

Benjamin Kaduk <kaduk@mit.edu> Mon, 21 October 2019 21:56 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 DED111209F9; Mon, 21 Oct 2019 14:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 XljANE2eqq0k; Mon, 21 Oct 2019 14:56:52 -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 4D17F1209C9; Mon, 21 Oct 2019 14:56:52 -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 x9LLuiTU003275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Oct 2019 17:56:47 -0400
Date: Mon, 21 Oct 2019 14:56:44 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-ace-cwt-proof-of-possession.all@ietf.org" <draft-ietf-ace-cwt-proof-of-possession.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <20191021215644.GF69013@kduck.mit.edu>
References: <157021105722.1446.14439223392992273252@ietfa.amsl.com> <DM6PR00MB0569B15A50D4CA0EEA4B4DECF5920@DM6PR00MB0569.namprd00.prod.outlook.com> <BYAPR00MB0565E923C1482C57AFDAF0C5F56C0@BYAPR00MB0565.namprd00.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BYAPR00MB0565E923C1482C57AFDAF0C5F56C0@BYAPR00MB0565.namprd00.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/_4IaVgKInHiqzth-IpTwNPDUf9k>
Subject: Re: [Ace] Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08
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, 21 Oct 2019 21:56:55 -0000

Thanks for the update, Mike.

I will go ahead and get this in front of the whole IESG, but one comment
below...

On Fri, Oct 18, 2019 at 10:57:06PM +0000, Mike Jones wrote:
> Hi Christer,
> 
> https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 has been published, which addresses your review comments in the ways proposed below.  Thanks again for your review!
> 
>                                                        -- Mike
> 
> From: Mike Jones
> Sent: Wednesday, October 16, 2019 12:40 PM
> To: Christer Holmberg <christer.holmberg@ericsson.com>;; gen-art@ietf.org
> Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org; ietf@ietf.org; ace@ietf.org
> Subject: RE: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08
> 
> 
> Thanks for your review, Christer.  Replies are inline, prefixed by "Mike>"…
> 
> 
> 
> -----Original Message-----
> From: Christer Holmberg via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>>
> Sent: Friday, October 4, 2019 10:44 AM
> To: gen-art@ietf.org<mailto:gen-art@ietf.org>
> Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org<mailto:draft-ietf-ace-cwt-proof-of-possession.all@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>; ace@ietf.org<mailto:ace@ietf.org>
> Subject: Genart last call review of draft-ietf-ace-cwt-proof-of-possession-08
> 
> 
> 
> Reviewer: Christer Holmberg
> 
> Review result: Ready with Issues
> 
> 
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
> 
> 
> 
> For more information, please see the FAQ at
> 
> 
> 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C4ffc136d2e014bc995db08d748f27b79%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637058078607739810&amp;sdata=Lusqkbg276AKiI%2Fd5MNEMGYKLcP3y%2FfrHP5L1u6UqYw%3D&amp;reserved=0>;.
> 
> 
> 
> Document: draft-ietf-ace-cwt-proof-of-possession-08
> 
> Reviewer: Christer Holmberg
> 
> Review Date: 2019-10-04
> 
> IETF LC End Date: 2019-10-09
> 
> IESG Telechat date: Not scheduled for a telechat
> 
> 
> 
> Summary: For most part the document is ready, but I have a few editorial comments and an issue.
> 
> 
> 
> Major issues: N/A
> 
> 
> 
> Minor issues:
> 
> 
> 
> The text says in the Security Considerations that one must ensure that the might not understand the "cnf" claim, and that applications must ensure that receivers support it.
> 
> 
> 
> Q1: How are you going to ensure that, and why do you have to ensure that? RFC
> 
> 8392 doesn't even seem to require that one must ensure that the receivers support CWT.
> 
> 
> 
> Mike> I agree that this text isn't actually actionable.  I propose that we simply delete it.
> 
> 
> 
> Q2: For receivers that do support CWT, RFC 8392 says that unsupported claims must be discarded. If that can't be applied for "cnf" I think you need to explain why.
> 
> 
> 
> Mike> The RFC 8392 requirement does apply.  This is also aligned with the text in 3.1, so I don't think there are any changes needed to the spec for this.

I don't think there's anything else we can reasonably do/say here, but it
does seem potentially surprising that we could get into a state where
client and AS both think that the token is a PoP token but the RS
interprets it as a bearer token.  I expect that in most cases where PoP
CWTs are used in an application context, either the client would be able to
detect this (e.g., by the RS not asking for a confirmation message) or the
client would send a confirmation message and the RS would treat it as
malformed, so the scope for practical impact seems limited, but it's hard
to confidently make sweeping statements.

-Ben