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 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5356113114B; Wed, 12 Dec 2018 01:09:46 -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 G7k3Le-7QGf1; Wed, 12 Dec 2018 01:09:43 -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 AA59B13114A; Wed, 12 Dec 2018 01:09:43 -0800 (PST)
Received: from 1gX0WS-000KB6-UF by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1gX0WS-000KDg-Vj; Wed, 12 Dec 2018 01:09:40 -0800
Received: by emcmailer; Wed, 12 Dec 2018 01:09:40 -0800
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1gX0WS-000KB6-UF; Wed, 12 Dec 2018 01:09:40 -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 10:09:39 +0100
To: Jim Schaad <>, <>
CC: <>
References: <> <> <042a01d4873c$a91bb5a0$fb5320e0$>
From: Ludwig Seitz <>
Message-ID: <>
Date: Wed, 12 Dec 2018 10:09:39 +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: <042a01d4873c$a91bb5a0$fb5320e0$>
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] 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 09:09:46 -0000

On 28/11/2018 18:06, Jim Schaad wrote:
> Ludwig,
> It looks good.  A couple of additional things that have occurred to me.
> (Always a problem when on reads drafts again and again.)
> 1.  I don't really have a problem with figure 6, but I don't know if we want
> to more correctly reflect what an OSCORE message would look like in this
> location.  This would basically be a re-write of the entire example
> structure to reflect that you have an outer and an inner CoAP message.  It
> might be confusing for people who are not fully immersed in the OSCORE
> world.

As far as the example goes, we would need to add an OSCORE option, I 
wouldn't want to expand the encrypted payload to reflect the full OSCORE 
structure, since that is likely going to be more confusing than helpful.

> 2.  I have no idea of where this would go and it is perhaps something that
> the OAuth people need to think about as well.  If an AS receives a request
> which has message level security (OSCORE/CWT/JWT) over a session level
> security connection (TLS/DTLS/IPSEC) are there any rules/suggestions about
> which keys should be used for evaluating the resulting request.  While I
> assume that message security wins and the session security is ignored, I
> have not seen this anyplace.

Good point. I would think that message level security would prevail, but 
that would need to be specified in a profile.

> 3. In section 5.8.1 - It says that for a CWT access token that the
> application/cwt content type MUST be used.  There are two possible issues
> with this.  1) How does the client know what the type of the token is.  It
> could be a CWT, an introspection token, or something else entirely.  2)  Is
> it an error if a CWT token is received and the content type is not present?

Right, the token is supposed to be opaque to the client. I will remove 
that requirement.


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