Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt

Ludwig Seitz <> Wed, 12 December 2018 10:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BED812F295 for <>; Wed, 12 Dec 2018 02:04:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ldKHEyCfmamM for <>; Wed, 12 Dec 2018 02:04:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B993F12777C for <>; Wed, 12 Dec 2018 02:04:25 -0800 (PST)
Received: from 1gX1NN-0002uW-TH by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1gX1NN-0002w3-Ua; Wed, 12 Dec 2018 02:04:21 -0800
Received: by emcmailer; Wed, 12 Dec 2018 02:04:21 -0800
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1gX1NN-0002uW-TH; Wed, 12 Dec 2018 02:04:21 -0800
Received: from [] ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 12 Dec 2018 11:04:20 +0100
To: Stefanie Gerdes <>, Jim Schaad <>, <>
References: <> <> <> <03b601d49191$7d1bb400$77531c00$> <>
From: Ludwig Seitz <>
Message-ID: <>
Date: Wed, 12 Dec 2018 11:04:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-Proto: esmtps
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-PolicySMART: 14510320
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
Archived-At: <>
Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Dec 2018 10:04:29 -0000

On 12/12/2018 10:27, Stefanie Gerdes wrote:
> Hi Jim,
> thank you for your quick response.
> On 12/11/2018 09:38 PM, Jim Schaad wrote:
>>> C may receive keying material for the communication with RS from AS.
>>> Unfortunately, the AS does not inform C how long the keying material is
>> valid. C
>>> therefore may use outdated keying material for the communication. C cannot
>>> rely on RS to reject messages that were sent with outdated keying material
>>> because 1. the information in the request sent by C may be confidential
>> and is
>>> then compromised and 2. C cannot be sure that it is actually communicating
>>> with the intended RS if the keying material is no longer valid.
>> Would you feel that this would be eased by requiring the expires_in field to
>> be required as part of the response?  It is the expiration of the token, but
>> I have never understood the difference between the expiration of the token
>> and the expiration of keying material myself.  Keying material never
>> expires, you just cannot use it without a valid token.
> As long as it is clear that the expires_in field describes the time
> until the keying material expires, this is at least better than nothing,
> although it leaves the problem that the client does not know when the
> token was created and how much time has already passed since then.
> The ACE framework should also point out that a client must check if its
> keying material for RS is still valid before it makes a request.
> BTW, I don't think keying material should be valid forever, especially
> if there is no useful revocation mechanism.

Note that expires_in (exi) is currently defined as "expires in x seconds 
from the time at which the RS first saw the token".

I am aware that this is quite weak since malicious clients can hoard 
tokens that would be valid indefinitely. I do not currently see any 
other means of expiration when the RS has no connectivity to the AS and 
no synchronized clock. I would be open for suggestions if you have 
better ideas.

>>> I did not find any indication how the client knows how to choose the
>> correct
>>> req_aud for RS. The document must point out that C may communicate with
>>> the wrong RS unless C and AS have a common understanding how RS is
>>> identified.
>> Scope is also something that the client does not know how to build.
> In the worst case, a wrong scope can only prevent a client from
> accessing a certain resource. Even if the client does not specify any
> scope, the AS can still grant it permissions. If they are broad enough,
> they will likely cover the resource that C wants to access.
> A wrong req_aud however may cause the client to communicate with the
> wrong RS. Even worse, C will not be able to notice that it communicates
> with the wrong RS. This is a serious security risk.  > Currently, the ACE
> framework does not even acknowledge that such a risk exists.
We do acknowledge that, in the security considerations of 
draft-ietf-ace-oauth-params where req_aud is defined. I'll add 
additional clarification to that text though, since it currently only 
talks about the needing to RS know which audiences it recognizes.

Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51