Re: [Ace] Overwriting Tokens

Jim Schaad <ietf@augustcellars.com> Wed, 12 December 2018 19:17 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 78061130F1A for <ace@ietfa.amsl.com>; Wed, 12 Dec 2018 11:17:04 -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 JpuFAdVFRYW1 for <ace@ietfa.amsl.com>; Wed, 12 Dec 2018 11:17:02 -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 3C309130F09 for <ace@ietf.org>; Wed, 12 Dec 2018 11:17:02 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 11:11:31 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Stefanie Gerdes' <gerdes@tzi.de>, <ace@ietf.org>
References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <cbd083d1-cb95-0732-aa8b-7c7de3f480d1@ri.se> <a0cdd836-7fe3-339e-0c48-961503857447@tzi.de> <043bc23f-f566-55d0-7c94-200d72b98341@tzi.de> <b22fece0-cabb-b387-74a0-1a786056eb08@ri.se> <c9f0deca-5cf8-e36d-b150-feabb0c8b82e@tzi.de>
In-Reply-To: <c9f0deca-5cf8-e36d-b150-feabb0c8b82e@tzi.de>
Date: Wed, 12 Dec 2018 11:16:29 -0800
Message-ID: <04a001d4924f$30e235f0$92a6a1d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQK3+H3pFttPP+s38ebErlDfr5TlzwGwIdvjAojcdAYBSBXfoQJkucpIAfCVoJKjZfmHUA==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/NIkVDNbltmj9Cj6DmuHGhIxxSuQ>
Subject: Re: [Ace] Overwriting Tokens
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: Wed, 12 Dec 2018 19:17:04 -0000


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Stefanie Gerdes
> Sent: Wednesday, December 12, 2018 2:17 AM
> To: ace@ietf.org
> Subject: Re: [Ace] Overwriting Tokens
> 
> Hi Ludwig,
> 
> On 12/12/2018 11:05 AM, Ludwig Seitz wrote:
> > On 12/12/2018 10:33, Stefanie Gerdes wrote:
> >> Hi again,
> >>
> >> I have one additional comment to ace-oauth-17:
> >>
> >> Section 5.8.1 recommends that RS stores only one token per key and
> >> that existing tokens are overwritten by new tokens. I wonder how the
> >> RS knows which token is the most recent. I don't think the expiration
> >> time helps in this case because it should be possible for the AS to
> >> provide a token that expires earlier than the previous token.
> >>
> >>
> >> Viele Grüße
> >> Steffi
> >>
> >
> > "Recent" here is meant as "most recently received". That is something
> > the RS definitely can track.
> 
> The token most recently received by RS is not necessarily the newest.
> A client may (accidentally or not) send the older token later than the
newer
> token.

And as you stated above, the older token may have a longer expiration than
the newer because of a different set of permissions.  I think that having
the RS use the most recently received token is probably the best strategy
for an RS that I only going to keep one token.   The client will know which
token is tagged to what original request if it is keeping more than one
token itself.  If it is must immediately posting tokens as it goes along,
then the AS could provide an older, but still valid, token on the next
request.

Jim

> 
> Viele Grüße
> Steffi
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace