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

Jim Schaad <> Tue, 11 December 2018 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A2E2130F99 for <>; Tue, 11 Dec 2018 12:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id do1eTgeXYGjQ for <>; Tue, 11 Dec 2018 12:38:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9466C130F81 for <>; Tue, 11 Dec 2018 12:38:41 -0800 (PST)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 12:33:35 -0800
From: Jim Schaad <>
To: 'Stefanie Gerdes' <>, 'Ludwig Seitz' <>, <>
References: <> <> <>
In-Reply-To: <>
Date: Tue, 11 Dec 2018 12:38:32 -0800
Message-ID: <03b601d49191$7d1bb400$77531c00$>
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: []
Archived-At: <>
Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Dec 2018 20:38:50 -0000

> -----Original Message-----
> From: Ace <> On Behalf Of Stefanie Gerdes
> Sent: Tuesday, December 11, 2018 4:11 AM
> To: Ludwig Seitz <>se>;
> Subject: Re: [Ace] Fwd: New Version Notification for
> 17.txt and draft-ietf-ace-oauth-params-01.txt
> Hi,
> I looked through the document again. Many issues have been fixed, but I
> have some comments:
> I still think that Section 5.8.1, in particular should point out
that RS must
> check the integrity of the token und validate that it stems from an
> AS. Checking the iss field does not help in this case and I don't see much
> 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
> exp field is in the future. This is difficult if the RS is not time
> Option 3 in section 5.8.3 seems to suggest that this field is not always
> Instead of demanding that the exp field is checked the document should
> demand that the RS somehow validates that the token is not expired.
> 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
> 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.  


> Viele Grüße
> Steffi
> _______________________________________________
> Ace mailing list