Re: [Ace] Unresolved issue blocking progress for draft-ietf-ace-oauth-authz

Jim Schaad <ietf@augustcellars.com> Mon, 11 February 2019 18:28 UTC

Return-Path: <ietf@augustcellars.com>
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 2884F131111 for <ace@ietfa.amsl.com>; Mon, 11 Feb 2019 10:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 KCxUVjWwkLvl for <ace@ietfa.amsl.com>; Mon, 11 Feb 2019 10:28:54 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0BD131110 for <ace@ietf.org>; Mon, 11 Feb 2019 10:28:54 -0800 (PST)
Received: from Jude (50.224.60.41) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Feb 2019 10:28:47 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, <ace@ietf.org>
References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> <1ce364d1-2154-3fc3-5589-5be3d7606717@ri.se> <ff6287e0-31a9-1a0a-ff4c-c6797f1e72f7@ri.se>
In-Reply-To: <ff6287e0-31a9-1a0a-ff4c-c6797f1e72f7@ri.se>
Date: Mon, 11 Feb 2019 10:28:44 -0800
Message-ID: <068b01d4c237$a049d4d0$e0dd7e70$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMO0G41vSMoQObT7FZTfu2Mz+Bo2AJLdn9lAwqfxWCjPB1c0A==
Content-Language: en-us
X-Originating-IP: [50.224.60.41]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/B4e840T9vD-qax9gdo6sJ_wk09o>
Subject: Re: [Ace] Unresolved issue blocking progress for draft-ietf-ace-oauth-authz
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, 11 Feb 2019 18:28:57 -0000


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Ludwig Seitz
> Sent: Monday, February 11, 2019 6:23 AM
> To: ace@ietf.org
> Subject: [Ace] Unresolved issue blocking progress for draft-ietf-ace-oauth-
> authz
> 
> Hello all,
> 
> I would like to call the group's attention to this message of mine (it was
> probably drowned out in the shepherd's review thread):
> 
> On 31/01/2019 10:40, Ludwig Seitz wrote:
> > Hello,
> >
> > we have an unresolved review comment by Steffi that got lost in the
> > holiday season:
> >
> >
> https://mailarchive.ietf.org/arch/msg/ace/CBTkVUBzYrfC55zH3_UJDngiy9U
> >
> https://mailarchive.ietf.org/arch/msg/ace/NrQWetugoy0TWp9eg3lwtSictc8
> >
> >
> > The issue is the following (my words):
> >
> > The AS provides the client with key material used by the RS. This can
> > either be a common symmetric pop-key, or an asymmetric key used by the
> > RS to authenticate towards the client.
> >
> > Since there is (currently) no metadata associated to those keys, the
> > client has no way of knowing if these keys are still valid. This may
> > lead to situations where the client sends requests containing
> > sensitive information to the RS using a key that is expired and
> > possibly in the hands of an attacker, or accepts responses from the RS
> > that are not properly protected and could possibly have been forged by an
> attacker.
> >
> >
> > The options to resolve this that I currently see are this:
> >
> >
> > 1. If the client has no additional data it MUST assume that the key is
> > valid as long as the access token together with which it received that
> > key. Since the access token is opaque to the client, the client MUST
> > now determine how long the token is valid:
> >
> > Option 1.1 The client is provisioned in advance with a default
> > validity time for tokens issued by the AS. This could be done when the
> > client is registered at the AS.
> >
> > Option 1.2 The AS informs the client using the "expires_in" parameter
> > in the Access Information.
> >
> > This means that we need to implement a check whether the client knows
> > a default validity, and if that is not the case reject an access token
> > that does not come together with an "expires_in" parameter.

This is my personal preference.  Telling the client that the RS key expires in a long time is only reasonable if you are planning to do client anonymous TLS connections.  It also has the problem that you no longer have a way to revoke that key.

Jim

> >
> > 2. We can define a new parameter that informs the client specifically
> > about the validity of the keys the RS uses, if that differs from the
> > validity of the token. Note that this is a realistic use case, since
> > the RS might use an asymmetric key for authentication that is valid
> > for a significantly longer period than some access token.
> >
> >
> > I would need some feed-back from the group to proceed here.
> >
> > /Ludwig
> >
> 
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51