Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz
Jim Schaad <ietf@augustcellars.com> Wed, 30 January 2019 18:23 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 B7DBB131310; Wed, 30 Jan 2019 10:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iBUAKq1rnU3g; Wed, 30 Jan 2019 10:23:37 -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 F32D4131313; Wed, 30 Jan 2019 10:23:36 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 30 Jan 2019 10:23:27 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, draft-ietf-ace-oauth-authz@ietf.org
CC: ace@ietf.org
References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se>
In-Reply-To: <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se>
Date: Wed, 30 Jan 2019 10:23:26 -0800
Message-ID: <021c01d4b8c8$e5ee0ba0$b1ca22e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMO0G41vSMoQObT7FZTfu2Mz+Bo2AG5F3Zko0YkrmA=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ZZn03SnodlD9UBXpZmcy209kBVY>
Subject: Re: [Ace] Shepard review for draft-ietf-ace-oauth-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: Wed, 30 Jan 2019 18:23:40 -0000
> -----Original Message----- > From: Ludwig Seitz <ludwig.seitz@ri.se> > Sent: Wednesday, January 30, 2019 12:38 AM > To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-ace-oauth- > authz@ietf.org > Cc: ace@ietf.org > Subject: Re: Shepard review for draft-ietf-ace-oauth-authz > > Thank you Jim, > > I'll upload a new version as soon as we have resolved my questions below. > > /Ludwig > > On 30/01/2019 07:01, Jim Schaad wrote: > > 1. Update the reference from RFC 5246 to RFC 8446 in all locations > > > > > > > > Items that don't appear to be resolved: > > > > * Section 3.1 - Refresh Token - I don't think that refresh tokens are > > going to be strings because binary is more efficient. > > Unless you are going to say that this is not OAuth 2.0, then a > > refresh token is still a text string. > > > > * I don't see any text that is addressing this. > > That text just describes how it is in OAuth 2.0 (where refresh tokens are > strings), since we didn't see the need to specify the use of refresh tokens in > ACE, we didn't mention them further. If we had we would certainly have > defined them to be binary. That would be fine, but you actually do define a CBOR mapping tag for refresh tokens in the body of the text and define it as binary. > > > > >> On 22/10/2018 21:09, Jim Schaad wrote: > >>> * Section 5.8.2 - If the RS is going to do introspection, can it send > > some > >>> type of "Server Busy - try again in xxx" while it does the introspection > >>> rather than just doing an ack of the request and possibly waiting a long > >>> time? > >> > >> This is probably transport protocol specific, and we were asked not to > >> link the framework to a specific protocol, thus I don't know if we can > >> provide guidance here. > > > > I think it would be okay to say something like "some transport protocols > > may provide a way to indicate that the server is busy and the client should > > retry after an interval; this type of status update would be appropriate > > while the server is waiting for an introspection response". Which does > > provide guidance, but in a non-normative fashion that does not require or > > prohibit any given transport protocol. > > > > * I don't see anything that I think addresses this issue. I would expect > > it to be a security consideration > > There is text in the draft according to the suggestion above in section > 5.8.1 "The Authorization Information Endpoint". Should that text be > moved to security considerations? No, I just missed the text. It just took me three times reading through to find it. > > > > > Comments on protection of CWT/Token: I am wondering if there needs to > be > > any comments on how a CWT is going to be protected. While it is ok to use > > either a symmetric key or a direct key agreement operation for a single > > recipient without forcing a signature operation to occur. If the token is > > going to be targeted a single audience hosted on multiple RSs then a > > signature operation would be required for the purposes of authentication. > > > > Right. I'll add some security considerations on that. > > > > ****** IANA Section Issues > > > > 1. None of the new registries appear to have any guidance for the DEs to > > use when approving items. > > Is it acceptable to add a single guidance section for all of the new > registries, or does it need to be separate for each of them? As long as the guidance is comment this is fine. That is what I did for all of the COSE registries > > > > > 2. The title of the registry "ACE Authorization Server Information" is not > > really descriptive of what is in the registry. It makes sense in the text > > but not as a stand along title. Something along the lines of "ACE > > Authorization Server Request Creation Hints" seems to be closer to a solid > > identification. > > > Would "ACE Authorization Server Discovery Hints" be better? I thought about that, but it does not really cover the idea of having the nonce value there or the possibility of later adding things like - ok you should use this audience or this scope or some other similar thing. > > > 3. The mapping registries should use the OAuth registry name as a prefix. > > Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR > Mappings". > > > Done. Actually quite some changes were required to align all of the > mappings sections with the OAuth registry names. > > > 4. What is the initial registrations that need to occur for the "ACE > > Profile" registry. If there are none then this needs to be stated. > > > It's initially empty, since draft-ieft-ace-oauth-authz doesn't define a > profile. However the DTLS and OSCORE profile will provide the two > initial entries. I added a sentence to that effect in the IANA section. Yea, I thought that was the case since the registrations are actually done in the profile documents. I just wanted to make sure that IANA realized that this was initially going to be an empty registry. Jim > > > 5. For the CBOR Web Token Claims - how many of these should have the > JWT > > Claim name filled in? It would seem that all of them should. If not a > > comment about this is needed. > Fixed. > > /Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51
- [Ace] Shepard review for draft-ietf-ace-oauth-aut… Jim Schaad
- Re: [Ace] Shepard review for draft-ietf-ace-oauth… Ludwig Seitz
- Re: [Ace] Shepard review for draft-ietf-ace-oauth… Benjamin Kaduk
- Re: [Ace] Shepard review for draft-ietf-ace-oauth… Jim Schaad
- Re: [Ace] Shepard review for draft-ietf-ace-oauth… Ludwig Seitz
- Re: [Ace] Shepard review for draft-ietf-ace-oauth… Ludwig Seitz
- Re: [Ace] Shepard review for draft-ietf-ace-oauth… Jim Schaad
- [Ace] Unresolved issue blocking progress for draf… Ludwig Seitz
- Re: [Ace] Unresolved issue blocking progress for … Jim Schaad
- Re: [Ace] Unresolved issue blocking progress for … Göran Selander