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

Ludwig Seitz <ludwig.seitz@ri.se> Tue, 30 October 2018 12:20 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 9FB7212D4EF; Tue, 30 Oct 2018 05:20:43 -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 ygM_ogy4RKFL; Tue, 30 Oct 2018 05:20:39 -0700 (PDT)
Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.33]) (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 A6C3912D4EC; Tue, 30 Oct 2018 05:20:39 -0700 (PDT)
Received: from 1gHT0d-000HPA-Vb by out10a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) 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 [194.218.146.197] (helo=sp-mail-2.sp.se) by out10a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gHT0d-000HPA-Vb; Tue, 30 Oct 2018 05:20:35 -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.1531.3; Tue, 30 Oct 2018 13:20:35 +0100
To: Jim Schaad <ietf@augustcellars.com>, <draft-ietf-ace-oauth-authz@ietf.org>
CC: <ace@ietf.org>
References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> <e430cb24-1ac8-5eaf-2513-399c345fc999@ri.se> <038001d46b00$767a8520$636f8f60$@augustcellars.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <6ed644e4-0d41-661e-c717-1dabaedbf574@ri.se>
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$@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-2.sp.se (10.100.0.162) 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/Yt6t8kAIl460cYsSrPephq87sgY>
Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
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: Tue, 30 Oct 2018 12:20:44 -0000

On 23/10/2018 20:44, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Ludwig Seitz <ludwig.seitz@ri.se>; 
>> Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad
>> <ietf@augustcellars.com>;; draft-ietf-ace-oauth- authz@ietf.org Cc:
>> ace@ietf.org 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




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