Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

Olaf Bergmann <bergmann@tzi.org> Mon, 06 January 2020 10:03 UTC

Return-Path: <bergmann@tzi.org>
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 0D624120127; Mon, 6 Jan 2020 02:03:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, 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 M95b47-vbvQI; Mon, 6 Jan 2020 02:02:58 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C349120124; Mon, 6 Jan 2020 02:02:58 -0800 (PST)
Received: from wangari.tzi.org (p54BDE7FE.dip0.t-ipconnect.de [84.189.231.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47rrfm0jbNzyNT; Mon, 6 Jan 2020 11:02:56 +0100 (CET)
From: Olaf Bergmann <bergmann@tzi.org>
To: Jim Schaad <ietf@augustcellars.com>
Cc: 'Benjamin Kaduk' <kaduk@mit.edu>, draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org
References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com>
Date: Mon, 06 Jan 2020 11:02:55 +0100
In-Reply-To: <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> (Jim Schaad's message of "Fri, 3 Jan 2020 20:36:54 -0800")
Message-ID: <878smkrjg0.fsf@wangari>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/l0R52onTjftFN1blZUQ3Xv8ZSTA>
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
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, 06 Jan 2020 10:03:00 -0000

Jim,

Jim Schaad <ietf@augustcellars.com> writes:

[Ben's review]
> We also are potentially in violation of the framework's requirements with respect to the independent selection of profiles for client/AS and client/RS interactions -- at present, when DTLS+RPK is used for client/RS, we require that DTLS+RPK is also used for client/AS, in order to prove possession of the key.  We could perhaps weasel our way out by saying that the framework's requirement applies at the profile granularity, and with symmetric PSK we can be fully independent, but we still need to say something about this property and the interaction with the framework's requirements.
>
> [JLS] I am missing where it is saying this.   Can you give a pointer?  I don't believe that the POP of the RPK is required at the time that the token is obtained.

The problem is that AS must bind the Access Token to the RPK that the
Client has presented, and the Client must use the very same RPK to
establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS
has issued the Token to the same entity that is currently communicating
with RS.

Grüße
Olaf