Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt

Stefanie Gerdes <gerdes@tzi.de> Wed, 12 December 2018 09:27 UTC

Return-Path: <gerdes@tzi.de>
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 6812F130DC5 for <ace@ietfa.amsl.com>; Wed, 12 Dec 2018 01:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 f58_iwlTLMhf for <ace@ietfa.amsl.com>; Wed, 12 Dec 2018 01:27:52 -0800 (PST)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC1C1286E3 for <ace@ietf.org>; Wed, 12 Dec 2018 01:27:51 -0800 (PST)
Received: from [192.168.1.109] (p508A4EFC.dip0.t-ipconnect.de [80.138.78.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id B2AE9204F6; Wed, 12 Dec 2018 10:27:49 +0100 (CET)
To: Jim Schaad <ietf@augustcellars.com>, 'Ludwig Seitz' <ludwig.seitz@ri.se>, ace@ietf.org
References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <cbd083d1-cb95-0732-aa8b-7c7de3f480d1@ri.se> <a0cdd836-7fe3-339e-0c48-961503857447@tzi.de> <03b601d49191$7d1bb400$77531c00$@augustcellars.com>
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <2778adbc-a453-f9bf-b8b8-2e23bafd5da2@tzi.de>
Date: Wed, 12 Dec 2018 10:27:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <03b601d49191$7d1bb400$77531c00$@augustcellars.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/9LAcivsXNLIa3gsgwXaRVgLj1Xs>
Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
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: Wed, 12 Dec 2018 09:27:55 -0000

Hi Jim,

thank you for your quick response.

On 12/11/2018 09:38 PM, Jim Schaad wrote:
>>
>> C may receive keying material for the communication with RS from AS.
>> Unfortunately, the AS does not inform C how long the keying material is
> valid. C
>> therefore may use outdated keying material for the communication. C cannot
>> rely on RS to reject messages that were sent with outdated keying material
>> because 1. the information in the request sent by C may be confidential
> and is
>> then compromised and 2. C cannot be sure that it is actually communicating
>> with the intended RS if the keying material is no longer valid.
> 
> Would you feel that this would be eased by requiring the expires_in field to
> be required as part of the response?  It is the expiration of the token, but
> I have never understood the difference between the expiration of the token
> and the expiration of keying material myself.  Keying material never
> expires, you just cannot use it without a valid token.

As long as it is clear that the expires_in field describes the time
until the keying material expires, this is at least better than nothing,
although it leaves the problem that the client does not know when the
token was created and how much time has already passed since then.

The ACE framework should also point out that a client must check if its
keying material for RS is still valid before it makes a request.

BTW, I don't think keying material should be valid forever, especially
if there is no useful revocation mechanism.

> 
>>
>> I did not find any indication how the client knows how to choose the
> correct
>> req_aud for RS. The document must point out that C may communicate with
>> the wrong RS unless C and AS have a common understanding how RS is
>> identified.
> 
> Scope is also something that the client does not know how to build.  

In the worst case, a wrong scope can only prevent a client from
accessing a certain resource. Even if the client does not specify any
scope, the AS can still grant it permissions. If they are broad enough,
they will likely cover the resource that C wants to access.
A wrong req_aud however may cause the client to communicate with the
wrong RS. Even worse, C will not be able to notice that it communicates
with the wrong RS. This is a serious security risk. Currently, the ACE
framework does not even acknowledge that such a risk exists.

Viele Grüße
Steffi