Re: [Ace] WGLC for draft-ietf-ace-authz

Ludwig Seitz <> Tue, 30 October 2018 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FB7212D4EF; Tue, 30 Oct 2018 05:20:43 -0700 (PDT)
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 ygM_ogy4RKFL; Tue, 30 Oct 2018 05:20:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6C3912D4EC; Tue, 30 Oct 2018 05:20:39 -0700 (PDT)
Received: from 1gHT0d-000HPA-Vb by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1gHT0e-000HRm-Tu; Tue, 30 Oct 2018 05:20:36 -0700
Received: by emcmailer; Tue, 30 Oct 2018 05:20:36 -0700
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1gHT0d-000HPA-Vb; Tue, 30 Oct 2018 05:20:35 -0700
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; Tue, 30 Oct 2018 13:20:35 +0100
To: Jim Schaad <>, <>
CC: <>
References: <065b01d45f4e$b8d372a0$2a7a57e0$> <028d01d46a3a$bc6414f0$352c3ed0$> <> <038001d46b00$767a8520$636f8f60$>
From: Ludwig Seitz <>
Message-ID: <>
Date: Tue, 30 Oct 2018 13:20:35 +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: <038001d46b00$767a8520$636f8f60$>
Content-Type: text/plain; charset="utf-8"; 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-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <>
Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
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: Tue, 30 Oct 2018 12:20:44 -0000

On 23/10/2018 20:44, Jim Schaad wrote:
>> -----Original Message----- From: Ludwig Seitz <>; 
>> Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad
>> <>;; draft-ietf-ace-oauth- Cc:
>> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
>> Hallo Jim,
>> thank you for the review! Comments inline.
>> /Ludwig
>> On 22/10/2018 21:09, Jim Schaad wrote:
>>> * Section 5.8.1 - What is the purpose of creating an identifier
>>> for a token? Is this supposed to be used rather than the one from
>>> the AS for something like shared secret TLS?  Note that this is
>>> an unprotected value.
>> AFAIK cti is not a mandatory claim of an access token, thus a RS
>> might want to create an identifier for tokens that do not have a
>> cti.
> Ok - so the client has this cti - what could it use it for?

You might want to treat the token as a RESTful resource under 
/authz-info that the client can GET or DELETE using the cti as part of 
the URI.

I admit this is never explicitly stated and would need to be worked out
quite a bit (as Steffi remarked, there would need to be access control
on the tokens), so I wouldn't argue against removing the comment from
the draft altogether.

>>> * Section 5.8.1 - If the token is "not valid" is the RS required
>>> (i.e. MUST) to try introspection before returning a response if
>>> the RS does introspection?  The text currently says MAY.  If this
>>> is really MAY then the text should say that the token is always
>>> successfully accepted by the RS.
>> I'm not sure I understand the issue. Introspection is optional in 
>> general, and may be required in specific use cases. If the RS
>> determines that the token is not valid on its own, why would it
>> want to do introspection on top of this?
> The RS has just received a token.  The RS wants to validate said
> token.  It can do it on its own or it can do it with introspection.
> If it is going to do it with introspection can it defer this
> validation until first use or does it need to do it immediately so it
> is not going to store an invalid token?  It is possible that an RS is
> going to both support some tokens and require introspection on
> others.  In that case it would decide the token was not valid, but
> would not necessarily know if it was a legal introspection token.

I'm not convinced we need to REQUIRE a certain behavior here. I would 
however agree to put some text in the draft outlining these options and 
analyzing the resulting security implications.

Would that address your comment sufficiently?


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