Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (6017)

Aaron Parecki <aaron@parecki.com> Mon, 16 March 2020 22:31 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF813A128F for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 15:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
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 2bddRE8XDF4V for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 15:31:06 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDEAC3A1290 for <oauth@ietf.org>; Mon, 16 Mar 2020 15:31:05 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id j69so18215144ila.11 for <oauth@ietf.org>; Mon, 16 Mar 2020 15:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=32N8ujBdODa9jUuFo+mzM4dDFf0bNrjkahNFnDxOh+0=; b=T6XJRV1fkPacdNabzpGyI9dfriNk7gYi1wN3Aoz5owayFwFtdPWDqdUpoRrE/Olt71 8xRUy8xc5+OCflMzKSHtBK4Smxi7dpEayH6T2BsxZWxQtg4pvp4rHbljPXExhbVUgaFJ zVUICVuH/I/3C03EkLreKXCvsKicwVcX+j3KfRZ4R2GzHImpJH+tyAoTmJa+eOp2MfTI 1JZvIhuWKtRrxSzwxIzy51nDkSEKTQ0CDqTKuXJBdc12rVLy3IyPNHlngI/zP4s+Vx8V AJ8fEhX+4MuO5m4DJyV61fLrOH2r055BX0Mlqbuh1ogeBfaSe4FwwF0rHTQbvdMIyTbQ vnHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=32N8ujBdODa9jUuFo+mzM4dDFf0bNrjkahNFnDxOh+0=; b=DU1x+eWoSsItw0xmizJLSlH6vq8gwn4OW5uy7RE5aUW4hz80udwxPDp3zMJC9IhhO7 UCAsX5UwIzYGUmddQ7nYG3Ui+eCR1FwCYzii9pvSyHqxx0lx2827igDUTWyaAunfGN5q tVdtZMz9KjFux/Gdn/XYlJcITkSiI1zHbzlAUyVnxIi2vB90dEjhJXk77HlRBPpMpIMQ FdJkLK+Npyhh6AHfcvcMOSajTziU0Xes1t5kBLSc7HLCvcdbsB+LHkkAVkkHaPQXUJF5 p3Vf2C6Kl0kPwERGFfnNsFiLGLWCQlaQ5vzPbtWI42K7HUXXYvcKnowX5O3FDhdm9i8r 3Mcw==
X-Gm-Message-State: ANhLgQ0/NVzPhgPJZtpPXLvTb+Lxk5oOMtXp2NwYGNIFvaj6r7IVu0ct bJGjJtSgsC28G50TQkVMzStRzIb87qA=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vubgfAIxTbReGRqlME4Bhw5qOxNAY1XnDJuR4Js?= =?utf-8?q?FrdPnX+H+RUoqJ+nPX4dr+N9jLVfn98Zyg=3D=3D?=
X-Received: by 2002:a92:af53:: with SMTP id n80mr2171203ili.42.1584397863899; Mon, 16 Mar 2020 15:31:03 -0700 (PDT)
Received: from mail-il1-f177.google.com (mail-il1-f177.google.com. [209.85.166.177]) by smtp.gmail.com with ESMTPSA id j18sm547502ila.56.2020.03.16.15.31.03 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Mar 2020 15:31:03 -0700 (PDT)
Received: by mail-il1-f177.google.com with SMTP id p2so10410809ile.9 for <oauth@ietf.org>; Mon, 16 Mar 2020 15:31:03 -0700 (PDT)
X-Received: by 2002:a92:1b59:: with SMTP id b86mr2052935ilb.291.1584397863054; Mon, 16 Mar 2020 15:31:03 -0700 (PDT)
MIME-Version: 1.0
References: =?utf-8?q?=3CDM6PR00MB06843DC0A553896D165CC1E2F5F90=40DM6PR00MB0?= =?utf-8?q?684=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CDM6PR00MB06843DC0A553896D165CC1E2F5F90=40DM6PR00MB?= =?utf-8?q?0684=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?=
From: Aaron Parecki <aaron@parecki.com>
Date: Mon, 16 Mar 2020 15:30:51 -0700
X-Gmail-Original-Message-ID: <CAGBSGjpUdMTbceLdUj24q-HzapfcXgMGLZOo1i5Z284=peZA-Q@mail.gmail.com>
Message-ID: <CAGBSGjpUdMTbceLdUj24q-HzapfcXgMGLZOo1i5Z284=peZA-Q@mail.gmail.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "1983-01-06@gmx.net" <1983-01-06@gmx.net>, oauth <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Rr494-RU92VF6Wwo7bZaFcd29OQ>
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (6017)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2020 22:31:08 -0000

My understanding was that errata are only for when the text of the RFC
was incorrect based on the information available at the time. Since
RFC7617 was published after RFC6749, it can't be considered an errata
of 6749. I also think this should be rejected.

----
Aaron Parecki
aaronparecki.com
@aaronpk

On Mon, Mar 16, 2020 at 3:07 PM Mike Jones
<Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:
>
> +1
>
>
>
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
> Sent: Monday, March 16, 2020 3:05 PM
> To: RFC Errata System <rfc-editor@rfc-editor.org>
> Cc: 1983-01-06@gmx.net; oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (6017)
>
>
>
> While the use of "application/x-www-form-urlencoded" on the username (client_id) and password (client_secret) values before the base64 encoding for the HTTP Basic token is rather ugly and less than ideal, I don't believe that using/referencing RFC7617 would actually address all the reasons for which form-urlencoding was used. That a client_id value (https://tools.ietf.org/html/rfc6749?#appendix-A.1) might contain a colon character ":" being a key reason. Not doing the "application/x-www-form-urlencoded" encoding/decoding step in OAuth for the client secret basic would also be a breaking change for working implementations, which is beyond what an errata can/should do. As such, I think this erratum should be rejected
>
>
>
>
>
>
>
> On Sun, Mar 15, 2020 at 3:57 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6017
>
> --------------------------------------
> Type: Technical
> Reported by: Michael Osipov <1983-01-06@gmx.net>
>
> Section: 2.3.1
>
> Original Text
> -------------
> Clients in possession of a client password MAY use the HTTP Basic
>    authentication scheme as defined in [RFC2617] to authenticate with
>    the authorization server.  The client identifier is encoded using the
>    "application/x-www-form-urlencoded" encoding algorithm per
>    Appendix B, and the encoded value is used as the username; the client
>    password is encoded using the same algorithm and used as the
>    password.
>
> Corrected Text
> --------------
> Clients in possession of a client password MAY use the HTTP Basic
>    authentication scheme as defined in [RFC7617] to authenticate with
>    the authorization server.
>
> Notes
> -----
> RFC 2617 has been superseded by RFC7617 which clearly defines in section 2.1 how a charset can be provided to solve the usecase described with encoding.
>
> The original text of this RFC violates the approach described for Basic authentication.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6749 (draft-ietf-oauth-v2-31)
> --------------------------------------
> Title               : The OAuth 2.0 Authorization Framework
> Publication Date    : October 2012
> Author(s)           : D. Hardt, Ed.
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth