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> Tue, 11 December 2018 12:11 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 C65DB130DDB for <ace@ietfa.amsl.com>; Tue, 11 Dec 2018 04:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ukZY1yr-aMQB for <ace@ietfa.amsl.com>; Tue, 11 Dec 2018 04:11:38 -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 AEDB9130DD0 for <ace@ietf.org>; Tue, 11 Dec 2018 04:11:38 -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 CCE8B20752; Tue, 11 Dec 2018 13:11:36 +0100 (CET)
To: Ludwig Seitz <ludwig.seitz@ri.se>, "ace@ietf.org" <ace@ietf.org>
References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <cbd083d1-cb95-0732-aa8b-7c7de3f480d1@ri.se>
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <a0cdd836-7fe3-339e-0c48-961503857447@tzi.de>
Date: Tue, 11 Dec 2018 13:11:29 +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: <cbd083d1-cb95-0732-aa8b-7c7de3f480d1@ri.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/CBTkVUBzYrfC55zH3_UJDngiy9U>
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: Tue, 11 Dec 2018 12:11:41 -0000

Hi,

I looked through the document again. Many issues have been fixed, but I
still have some comments:

I still think that Section 5.8.1, in particular 5.8.1.1 should point out
that RS must check the integrity of the token und validate that it stems
from an authorized AS. Checking the iss field does not help in this case
and I don't see much value in this check; cryptographic assurance such
as AS' signature or MAC of the token is required to ascertain the
authenticity, and in this case the issuer, of the token.

5.8.1. exiting -> existing

Section 5.8.1. states that RS must check that the expiration time given
in the exp field is in the future. This is difficult if the RS is not
time synchronized. Option 3 in section 5.8.3 seems to suggest that this
field is not always required. Instead of demanding that the exp field is
checked the document should demand that the RS somehow validates that
the token is not expired. Checking the exp field may be one example.

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.

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.

Viele Grüße
Steffi