Re: [Ace] WGLC for draft-ietf-ace-authz

Jim Schaad <ietf@augustcellars.com> Wed, 31 October 2018 11:06 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 BC364130DF9 for <ace@ietfa.amsl.com>; Wed, 31 Oct 2018 04:06:13 -0700 (PDT)
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 7ak9Wso9VnlB for <ace@ietfa.amsl.com>; Wed, 31 Oct 2018 04:06:10 -0700 (PDT)
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 6A05F12D4EA for <ace@ietf.org>; Wed, 31 Oct 2018 04:06:10 -0700 (PDT)
Received: from Jude (65.158.186.241) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 31 Oct 2018 04:01:19 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mike Jones' <Michael.Jones=40microsoft.com@dmarc.ietf.org>, 'Ludwig Seitz' <ludwig.seitz@ri.se>, ace@ietf.org
References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <SN6PR00MB0301580A2D802AB0F559A170F5F70@SN6PR00MB0301.namprd00.prod.outlook.com> <5eb071c6-1a9e-e86a-a7d1-cc0fb8cbac42@ri.se> <SN6PR00MB03017E27B15E777091EDFD31F5CC0@SN6PR00MB0301.namprd00.prod.outlook.com>
In-Reply-To: <SN6PR00MB03017E27B15E777091EDFD31F5CC0@SN6PR00MB0301.namprd00.prod.outlook.com>
Date: Wed, 31 Oct 2018 04:05:57 -0700
Message-ID: <049901d47109$b72d9850$2588c8f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAMjXR8HAlXem/oCw/01UqOiuS+w
Content-Language: en-us
X-Originating-IP: [65.158.186.241]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/NFOTKrmliB6Jb1d4SRpmNUOEfzs>
Subject: Re: [Ace] WGLC for draft-ietf-ace-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, 31 Oct 2018 11:06:14 -0000

Mike,

Writing a document to do this is easy.  I am not clear that there is anybody
that is going to implement this.   Are industries such as banking going to
abandon JWT for CWT?

Jim


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Mike Jones
> Sent: Tuesday, October 30, 2018 11:52 AM
> To: Ludwig Seitz <ludwig.seitz@ri.se>; ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
> 
> Thanks for your responses, Ludwig.
> 
> Responding to your point about "Note that we have aligned these
> abbreviations with the claim abbreviations defined in [RFC8392]."  The
point
> of the alignment was to enable signed requests to be expressed as CWTs -
> just as OAuth signed requests are expressed as JWTs.  But given the high
> likelihood of numeric CWT claim collisions with unregistered OAuth request
> number values assigned by the spec, this won't actually work in the long
term
> unless the request parameters are registered as CWT claims.
Collision-free
> alignment without IANA registration is a fleeting situation.  Please make
the
> alignment permanent by registering the needed claims.
> 
> I get Jim's point that there are other ways to do signed requests.  If
this
> working group wants to define a different signed request syntax for ACE
> OAuth requests than CWTs, that's fine, but if so, please do so before this
> draft finishes.  If a different signed request format is used, I'll note
that
> there's no need for claim alignment with CWT [RFC8392] - in which case the
> draft should probably abandon it up front.  I'll note that abandoning the
> current alignment is more work and would be more confusing to
> implementers than simply using CWTs but multiple choices are possible.
The
> most important thing is to pick one now.  Industries such as banking are
> REQUIRING signed requests.
> 
> Since you asked about signed responses, those are also in the works for
> OAuth, for the same reasons - including requirements from the banking
> industry.  See https://openid.net/specs/openid-financial-api-jarm.html.
(Just
> as the OpenID Foundation standardized signed requests in 2014 in
> https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests in
> 2014 and then an IETF version was created, signed responses are currently
> on a similar trajectory.)
> 
> Per your question about values in IANA registries to be assigned by
> designated experts being TBD, the normal way of providing short-term
> values for interop purposes is to say "TBD (maybe <some number>).  For
> instance, you'll see that usage at
https://tools.ietf.org/html/draft-ietf-ace-
> cwt-proof-of-possession-03#section-7.1.1.
> 
> I could live with "access_token" having a single-byte representation,
since as
> you point out, it is needed for every ACE OAuth interaction.  An "error"
value
> is only needed when something goes wrong, so that doesn't seem like a case
> that needs to be optimized for space.  A two-byte "error" representation
will
> only be used when errors have occurred, so shouldn't be a problem.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Ludwig Seitz
> Sent: Tuesday, October 30, 2018 5:13 AM
> To: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
> 
> On 25/10/2018 02:58, Mike Jones wrote:
> > IT CAN'T BE A COINCIDENCE:  There's clearly a relationship between
> > many of the CBOR numeric values used in this this specification and
> > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the
> > relationship is currently unspecified and the goals behind it are
> > undefined.  The spec should be augmented to make the nature and goals
> > of this relationship explicit.  I infer that there's such a
> > relationship because the Mapping Parameters to CBOR in Section 5.6.5
> > apparently carefully do not overlap with the values registered in the
> > IANA CWT Claims registry at
> > https://www.iana.org/assignments/cwt/cwt.xhtml.  The Introspection
> > mappings in Section 5.7.4 apparently carefully use the same values as
> > CWT for the same things, but then adds additional values.  And some of
> > these values are the same as values proposed for the CWT Claims
> > registry in 8.13.  This has to be more than a coincidence but the spec
> > doesn't currently say why.
> 
> For example in "5.6.5 Mapping Parameters to CBOR" there is this:
> 
> "Note that we have aligned these abbreviations with the claim
>     abbreviations defined in [RFC8392]."
> 
> I can add some text to explain that this makes it easier to manage the
> abbreviations in code (no need to handle complex namespace issues, when
> you just use one abbreviation space). Would that address the "to make the
> nature and goals of this relationship explicit." part of your comment?
> 
> >
> > Per my earlier reviews of the ace-authz spec, I believe that the ACE
> > OAuth parameters should all be registered in the CWT Claims registry
> > because of the possibility of them being used in signed requests in a
> > manner analogous to
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The
> > parameters need to be registered to avoid future claim number
> > conflicts.  While conflicts have clearly been carefully avoided to
> > date, they will inevitably occur in the future unless the values are
> > actually registered.  Please do so.
> >
> 
> I have avoided doing this so far, since there was no precedent from OAuth
on
> doing so (registering OAuth req/resp parameters as JWT claims) and I was
> trying to align with OAuth in that respect.
> For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of the
> classical OAuth req/resp parameters as JWT claims ("This specification
> requests no actions by IANA.")
> 
> How is the position of the OAuth WG on this?
> 
> > DON'T SQUAT ON NUMERIC REGISTRY VALUES:  Please change all
> instances
> > of numbers to be assigned by designated experts in existing registries
> > from specific values to "TBD".  For instance, all the values for the
> > CWT Claims Registry in Section 8.13 (currently 12, 16, and 17) should
> > be changed to TBD.  Our chair, Jim Schaad has been a vigorous advocate
> > of not squatting in my past interactions with him as a Designated
> > Expert and I believe would support this request.
> > Likewise, the "19" in the CoAP Content-Format Registration in Section
> > 8.15 should become TBD.
> >
> I get your point.
> 
> Any hints on how one usually do that while still providing provisory
numbers
> for interop tests?
> 
> > req_aud: Several examples use the "req_aud" parameter without defining
> > it.  Doesn't this duplicate the "resource" parameter defined by
> > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?
> > If so, please delete this parameter and use "resource".  If not, say
> > how it is different and why the differences are necessary.
> >
> > rs_cnf:  There isn't a clear normative definition of this parameter.
> > It's mentioned obliquely but its purpose, syntax, and semantics should
> > be plainly stated (as with each other newly defined parameter).
> >
> 
> This is probably heritage from the document split.
> Note however that the framework (draft-ietf-ace-oauth-authz) defines
> some of these a CWT claims, while the params draft
> (draft-ietf-ace-oauth-params) only defines request/response parameters
> (which happen to have the same name, abbreviation and semantics).
> 
> I'll go over those sections and see if there are artifacts left that
> need to be adjusted.
> 
> 
> > The proposed numbers in Figures 12 and 16 contain mismatches.  For
> > instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13"
> > in Figure 16 in Section 5.7.4.
> >
> Sorry for that. Errors when trying to make the alignment.
> 
>  > There's too much alignment for it to
>  > be a coincidence but if you intend alignment, please say so
>  > explicitly and fix the alignment.  The proposed ongoing alignment
>  > should also be described in the registration instructions for the
>  > Designated Experts.
> 
> "5.7.4.  Mapping Introspection parameters to CBOR
> [...]
>     Note that we have aligned these abbreviations with the claim
>     abbreviations defined in [RFC8392].
> "
> 
> (so yes, we do already say so explicitly)
> 
> I will add the requested instructions for Designated Experts (good catch!)
> 
> 
> > -- Mike
> >
> > P.S.  Per my earlier reviews of this specification, in my view as a
> > Designated Expert for the CWT Claims registry, I believe that it's
> > not appropriate to use up rare single-byte identifiers for most of
> > the OAuth parameter encodings specified in 5.6.5.  I could be
> > persuaded that "scope" merits one of these rare numbers, but
> > "profile", "error", "grant_type", "access_token", and "token_type"
> > probably do not, as they are application-specific and not of general
> > applicability.  I also believe that some of the other Designated
> > Experts for this registry agree with me.
> >
> 
> I would argue that the rare single-byte identifiers should be used for
> the parameters typically used in constrained applications.
> 
> Since "error", "grant_type", "access_token", and "token_type" are all
> mandatory to use, they are bound to appear in constrained cases.
> 
> If we made "grant_type" and "token_type" non-mandatory in ACE (as
> opposed to how it is in OAuth) and define defaults I'd agree to move
> those into the two-byte space.
> 
> "profile" is arguably going to be used in less constrained scenarios
> where more than one profile could be supported, so I'd agree to move
> that to the two-byte space as well.
> 
> 
> "error" and "access_token" are used in every OAuth/ACE interaction, so I
> would need some really good arguments why they shouldn't have a one-byte
> abbreviation.
> 
> Can we reach some compromise based on these observations Mike?
> 
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace