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

Ludwig Seitz <> Tue, 30 October 2018 10:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C389C12F1AB; Tue, 30 Oct 2018 03:19:56 -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 UIBoPW5PdVsG; Tue, 30 Oct 2018 03:19:53 -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 9FC48130DC1; Tue, 30 Oct 2018 03:19:53 -0700 (PDT)
Received: from 1gHR7l-000MiF-Vh by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1gHR7m-000Mjz-Tj; Tue, 30 Oct 2018 03:19:50 -0700
Received: by emcmailer; Tue, 30 Oct 2018 03:19:50 -0700
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1gHR7l-000MiF-Vh; Tue, 30 Oct 2018 03:19:49 -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 11:19:49 +0100
To: Jim Schaad <>, <>
CC: <>
References: <065b01d45f4e$b8d372a0$2a7a57e0$> <028d01d46a3a$bc6414f0$352c3ed0$>
From: Ludwig Seitz <>
Message-ID: <>
Date: Tue, 30 Oct 2018 11:19:44 +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: <028d01d46a3a$bc6414f0$352c3ed0$>
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 10:19:57 -0000

On 22/10/2018 21:09, Jim Schaad wrote:

> * Registries -  I am wondering if we should think about re-writing a couple
> of the registries.  As things stand it appears that the application/ace+cbor
> content type is being used in 5 or 6 places.  It might make more sense to
> have a registry for all of the CBOR abbreviations that are being used in a
> single table and have multiple columns for each of the different places were
> the content format is being used.  This would make it easier to keep
> everything constant and can make re-use of integer values easier to see.

Yes in the light of the ensuing discussion with Mike, Carsten and Olaf 
it is clear that the whole registry process needs a second (third, n-th) 

I'd very much like to have all abbreviations in a single table, however 
some of them are in the new draft-ietf-ace-oauth-params, so I'm not sure 
on where to do the table, since I'd like to have the parameters from 
there in it.

> * Comments on protection of CWT/Token:  I am wondering if there needs to be
> any comments on how a CWT is going to be protected.  While it is ok to use
> either a symmetric key or a direct key agreement operation for a single
> recipient without forcing a signature operation to occur.  If the token is
> going to be targeted a single audience hosted on multiple RSs then a
> signature operation would be required for the purposes of authentication.

In the light of your and Steffi's comments, this seems to merit a 
section in the security considerations.

> * I am not sure where this issue should be raised so I am putting it here.
> Both of the profiles have as their last security consideration a statement
> that the use of multiple access tokens is a bad idea.  Both of them also
> devote a large section of text to how to deal with multiple access tokens as
> does this document.  More methods of having multiple access tokens seem to
> be coming down the path from the OAuth group.  This appears to be a distinct
> contradiction within the set of documents that should be resolved.

I'd like to have the view of our OAuth experts here: How is OAuth 
typically used, when a client needs to get more permissions than 
initially granted?
Is the old token invalidated and a new token issued, or is there 
something like "add-on" scopes in additional tokens?

Given the amount of trouble the handling of multiple tokens for one 
client-RS pair can raise, I'm not disinclined to forbid them or at least 
recommend against their use. However with audiences possibly addressing 
overlapping sets of RSs this might be more difficult than it looks.


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