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

Brian Campbell <bcampbell@pingidentity.com> Mon, 16 March 2020 22:05 UTC

Return-Path: <bcampbell@pingidentity.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 06CB33A1238 for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 15:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 I-Es4b6h7Dr2 for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 15:05:13 -0700 (PDT)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 806EB3A1237 for <oauth@ietf.org>; Mon, 16 Mar 2020 15:05:12 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id r24so20559593ljd.4 for <oauth@ietf.org>; Mon, 16 Mar 2020 15:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2IJ9ckjKj+A7AglJNslzISe95OO7M6HbUVAC9TRWZL4=; b=RFq2+4rYUEuZWBxHHOLKoC+CJjFIMoJ+z9Fy+v12HjN/Qo21qkBqImO2VuBeJH3RRp 0rDrb9WMX+Jo1vRG/bzYSl1I1h3JbVa00POIhlyk6vrddV/6dSmuum7R+Yo7zQtkPezV GWNy4PBoLbFHwJi8ZYE6zuZCe/ylB4mIjicuFE9MEQqeySTCq2me7XZV4JlGyl3Adycc fUH0SprlHtY7/rpICKd+nSpOA5XchzwseYpEbSoTUg0db6c8kc4/CdFEo1XCcDU9/3jT axIlpt5a1zGoBfFlnhgQ3IsQ+x88oK+sC8p3JT/z3Kw5gtCcOYfdQ0hGScnV/XPIuJvH aYYA==
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; bh=2IJ9ckjKj+A7AglJNslzISe95OO7M6HbUVAC9TRWZL4=; b=QpbuVyxu10ZzFS6MlSRwjyc9WSFRV79IkoVZ0XtX4GM7N8Yr+BXc2uI1UDb/GiBFt4 wDmrnjMwB28VmYBentBZNlSglLu/df0QU5jXBUySEl4CdU72DpP+A/JgzQViGsyE/8ds cV/ZlFzDCduDBbZzt9VBF3sj0qNk3IYhqnY7MwI0wYXth2r7gbAI8ztUYm0/MKTfFFyc Mdu4oPYTD20ryFECpA2MT+L7MfALk8SOjAq5F8+iYadtq6IMxzE7okQ3wxDReHpbDW/P sqdZjMKsItbz3zOVHFgcCDwYfsnMxrFL32bF4fejeAVyvp9E1Q3WUHs+TjrNE75RqhRg H+uw==
X-Gm-Message-State: ANhLgQ1EY1fa+YYyF0TIrYB0iFCQ21PQiv+P12pbG06FXSCFTZX053SV PTSpBQHKQI/7BhETG7uqzgyroNX8QcKKKBsjiax13FpoH21iTgNoTASmktyR5vJrMbmt7h5leET 7xolJbA13NYM2tg==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vv86+cjsTlLXNC3r8WPcLeaVSPpDQ0b7EXtJLh9?= =?utf-8?q?07cP1GxelMfB1RAXfc796Q/SyZy4v9alJHyg8cRhl4ciS00=3D?=
X-Received: by 2002:a2e:9605:: with SMTP id v5mr882445ljh.0.1584396310573; Mon, 16 Mar 2020 15:05:10 -0700 (PDT)
MIME-Version: 1.0
References: <20200315215728.3CBA9F406C1@rfc-editor.org>
In-Reply-To: <20200315215728.3CBA9F406C1@rfc-editor.org>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 16 Mar 2020 16:04:44 -0600
Message-ID: <CA+k3eCROzbO4Voz+dx26-ZhT_mV6urg06xLD7G+b8_Mum-5-Og@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Dick Hardt <dick.hardt@gmail.com>, Roman Danyliw <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, 1983-01-06@gmx.net, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046977505a100035b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ha0X8fAcYv5PmrTj4S32pQp6A_0>
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:05:15 -0000

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._