Re: [Ace] JWT + OAuth Request

Ludwig Seitz <ludwig.seitz@ri.se> Thu, 04 October 2018 06:48 UTC

Return-Path: <ludwig.seitz@ri.se>
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 117A1130DC6 for <ace@ietfa.amsl.com>; Wed, 3 Oct 2018 23:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzMF48V_mEtY for <ace@ietfa.amsl.com>; Wed, 3 Oct 2018 23:48:07 -0700 (PDT)
Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25664130DE6 for <ace@ietf.org>; Wed, 3 Oct 2018 23:48:06 -0700 (PDT)
Received: from 1g7xQa-000oGN-TO by out11d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1g7xQa-000oGk-UB for ace@ietf.org; Wed, 03 Oct 2018 23:48:04 -0700
Received: by emcmailer; Wed, 03 Oct 2018 23:48:04 -0700
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1g7xQa-000oGN-TO for ace@ietf.org; Wed, 03 Oct 2018 23:48:04 -0700
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 4 Oct 2018 08:48:04 +0200
To: ace@ietf.org
References: <037301d45b84$29065ac0$7b131040$@augustcellars.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <56b76a04-50d3-faa9-c136-d87c0c16d432@ri.se>
Date: Thu, 04 Oct 2018 08:47:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <037301d45b84$29065ac0$7b131040$@augustcellars.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162)
X-Outbound-IP: 194.218.146.197
X-Env-From: ludwig.seitz@ri.se
X-Proto: esmtps
X-Revdns:
X-HELO: sp-mail-2.sp.se
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Authenticated_ID:
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/lt5r9d3FZKgbrQ9uiEzg3OQ-ktY>
Subject: Re: [Ace] JWT + OAuth Request
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: Thu, 04 Oct 2018 06:48:10 -0000

On 04/10/18 03:47, Jim Schaad wrote:
> The OAuth group discovered a problem with some the names of our new OAuth
> fields that was caused by the fact that they have an ID that is someplace
> between the IESG and the RFC Editor which introduced the concept of using a
> JWT to as the transport for an OAuth request.  This allows for doing
> end-to-end security on the OAuth request in the event it needs to be
> forwarded to another authorizer.  Due to the design decision that they made,
> this was done by included all of the OAuth request fields as JWT claims thus
> combining the two namespaces.  Based on this we now need to make a decision
> on what to do with our COSE versions of this.  From my point of view we have
> two different options:
> 
> 1.  Ignore the problem and hope it goes away.
> 2.  Deal with the problem by combining the current CWT registry with the
> OAuth registry that is going to be created.
> 
> Why option 1 might be acceptable:
> 
> A.  The reason that they are doing this is because they want to get an E2E
> solution for requests.  We have this already to some degree with the OSCORE
> profile of OAuth and could easily go the rest of the way by creating a COSE
> profile which allowed for full COSE rather than the restricted version of
> OSCORE.   There may be some unknown benefits to using a JWT for this
> purpose, but I would then want to ask two questions:  Is this really
> something that is useful and important? If is really that important or
> useful, why is it not part of the base OAuth protocol?
> 
> B. If a CWT version is this is really needed, perhaps we can get a different
> design to be used.  Specifically, create two new CWT claims: "oauth_req",
> "oauth_resp" and then place the OAuth parameters in those fields and not
> make them CWT claims.  I am sure that there would be complaints about this,
> but much as COSE fixed problems that it saw as being wrong, the WG could do
> the same thing.
> 
> Jim
> 
I'm not sure if there really is a problem here. If an AS forwards a 
{C/J}WT to another AS, this would clearly not be an access token, 
meaning the claims can be interpreted accordingly. If there is room for 
confusion OAuth should define a token type such as e.g. "request_token" 
and make that a mandatory claim in the token or parameter of the request.

Therefore I would lean towards option 1.

/Ludwig

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