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