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