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

Jim Schaad <ietf@augustcellars.com> Tue, 11 December 2018 20:38 UTC

Return-Path: <ietf@augustcellars.com>
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 7A2E2130F99 for <ace@ietfa.amsl.com>; Tue, 11 Dec 2018 12:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 do1eTgeXYGjQ for <ace@ietfa.amsl.com>; Tue, 11 Dec 2018 12:38:42 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9466C130F81 for <ace@ietf.org>; Tue, 11 Dec 2018 12:38:41 -0800 (PST)
Received: from Jude (192.168.1.160) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 12:33:35 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Stefanie Gerdes' <gerdes@tzi.de>, '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>
In-Reply-To: <a0cdd836-7fe3-339e-0c48-961503857447@tzi.de>
Date: Tue, 11 Dec 2018 12:38:32 -0800
Message-ID: <03b601d49191$7d1bb400$77531c00$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQK3+H3pFttPP+s38ebErlDfr5TlzwGwIdvjAojcdAajkWggkA==
Content-Language: en-us
X-Originating-IP: [192.168.1.160]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Z2t_O16xeHw2o_Rq5i43Skd7Odg>
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 20:38:50 -0000


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Stefanie Gerdes
> Sent: Tuesday, December 11, 2018 4:11 AM
> To: Ludwig Seitz <ludwig.seitz@ri.se>se>; ace@ietf.org
> Subject: Re: [Ace] Fwd: New Version Notification for
draft-ietf-ace-oauth-authz-
> 17.txt and draft-ietf-ace-oauth-params-01.txt
> 
> 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.

I would agree with this.  I have never been sure why the 'iss' field is
going to be useful.  The only place that I can see this would be an AS which
is using one key but two identities.  I would argue that this is a situation
that is prone to configuration errors and incorrect security.

> 
> 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.

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.

> 
> 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.  

Jim

> 
> Viele Grüße
> Steffi
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace