Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
Benjamin Kaduk <kaduk@mit.edu> Thu, 09 January 2020 21:22 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 AA47712080F; Thu, 9 Jan 2020 13:22:16 -0800 (PST)
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 OJgDAMwu-RHN; Thu, 9 Jan 2020 13:22:14 -0800 (PST)
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 81BF4120807; Thu, 9 Jan 2020 13:22:14 -0800 (PST)
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 009LLii5018214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jan 2020 16:21:46 -0500
Date: Thu, 09 Jan 2020 13:21:43 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jim Schaad <ietf@augustcellars.com>
Cc: 'Olaf Bergmann' <bergmann@tzi.org>, draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org
Message-ID: <20200109212143.GH57294@kduck.mit.edu>
References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> <878smkrjg0.fsf@wangari> <000801d5c4bc$cf418110$6dc48330$@augustcellars.com> <87o8vclvaf.fsf@wangari> <20200109201700.GF57294@kduck.mit.edu> <00b801d5c72e$c6dd42b0$5497c810$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <00b801d5c72e$c6dd42b0$5497c810$@augustcellars.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/swgFCuksQ72F5D5wFrn9_6sFTCw>
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: Thu, 09 Jan 2020 21:22:17 -0000
On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote: > > > -----Original Message----- > From: Benjamin Kaduk <kaduk@mit.edu> > Sent: Thursday, January 9, 2020 12:17 PM > To: Olaf Bergmann <bergmann@tzi.org> > Cc: Jim Schaad <ietf@augustcellars.com>; ace@ietf.org; > draft-ietf-ace-dtls-authorize.all@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > > Hi Jim, > > > > Jim Schaad <ietf@augustcellars.com> writes: > > > > > -----Original Message----- > > > From: Ace <ace-bounces@ietf.org> On Behalf Of Olaf Bergmann > > > Sent: Monday, January 6, 2020 2:03 AM > > > To: Jim Schaad <ietf@augustcellars.com> > > > Cc: ace@ietf.org; 'Benjamin Kaduk' <kaduk@mit.edu>; > > > draft-ietf-ace-dtls-authorize.all@ietf.org > > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > > > 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. > > > > > > [JLS] What if I do the following sequence of events: > > > 1. The AS is configured with RPK1 for the client and the client is > configured with RPK2 for the AS. > > > 2. The client and the AS run some type of POP algorithm, not currently > specified, to configure RPK3 into the AS for a second RPK to work with some > set of audiences (AUD1). > > > 3. The client then uses RPK1 to authenticate to the AS and asks for a > new token for AUD1 and provides (explicitly or implicitly RPK3). The AS > knows that it is tied to the client due to what happened in step 2. The AS > then creates a new token for AUD1 which contains RPK3 for the client (and > RPK4 for the RS) and returns it. > > > > > > The AS does a current POP for RPK1 when the token is being asked for. > > > The AS did a POP for RPK3 when it was placed into the system. > > > The AS has not done a POP for RPK4 - that was simply configured without > that step ever being done. The ACE framework has no ability for the AS to > do the POP on RPK4 and ensure that it current. The client would do a POP > when the TLS session is created but has to rely on the AS that it is for the > correct RS. > > > > > > Note that the client can never generate a brand new RPK9 and send it to > the AS in the token request because the AS will never have seen this before > and would need to run the POP algorithm of step 2 in order to assure that it > is bound to the correct client and not pulled out of thin air. RPK9 could > not be used to authenticate the token request because the AS has no idea > what client it is tied to. > > > > okay, I see you have a valid point here. I will try to come up with > > some text that says that the AS must ensure that (in your scenario) > > RPK1 and > > RPK3 are bound to the same entity. > > Jim's proposal seems broadly reasonable (though I think in general there > needs to be some AS contributory nature in order to get proof of current > possession of RPK3 at the time of (2). I think I would phrase it as "in > possession of the same entity" rather than "bound to the same entity", > though. > > [JLS] If I was to write this out as a real protocol, it would end up > something along the lines of Sign(RPK1, Sign(RPK3, RPK1 || RPK3 || AS > Nonce || Client Nonce )) so that we know that both keys are in the > possession of a single entity (or a cabal collaborating) and it is current > to the run of the POP protocol. With a fixed protocol/context string to indicate the intent of what's being signed, of course :) I am too distracted to do a proper analysis right now but seem to recall that usually an indication of "both parties/keys agree to <X>" involves three signatures, so that each party certifies the signature of the other over the operation (in addition to the operation itself). -Ben
- [Ace] AD review of draft-ietf-ace-dtls-authorize-… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Carsten Bormann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Carsten Bormann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-dtls-author… Olaf Bergmann