IETF Logo Mail Archive

Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

Justin Richer <jricher@mit.edu> Wed, 10 November 2021 15:24 UTC

Return-Path: <jricher@mit.edu>
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 05EDB3A0DB6; Wed, 10 Nov 2021 07:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level:
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2NsNjngZUESu; Wed, 10 Nov 2021 07:24:00 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65543A0D7B; Wed, 10 Nov 2021 07:23:59 -0800 (PST)
Received: from smtpclient.apple (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1AAFNuQa001648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Nov 2021 10:23:57 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <F15CE2F2-1B9A-4201-900E-7BD06AFF3E41@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_08B2E38F-CE0D-444C-8D05-6FF2B66A6FE5"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Wed, 10 Nov 2021 10:23:55 -0500
In-Reply-To: <CAOtx8D=6yEjTEVkx7LnaWk_FYrW80+KxhskGjreQs8X0dnVsnA@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
To: Dmitry Telegin <dmitryt=40backbase.com@dmarc.ietf.org>
References: <CAOtx8Dk5f9dLT=mF4_G3ytTm4BzjYxohHVbc27R0nikiQxsdsA@mail.gmail.com> <CAOtx8D=6yEjTEVkx7LnaWk_FYrW80+KxhskGjreQs8X0dnVsnA@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc>
Subject: Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate
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: Wed, 10 Nov 2021 15:24:04 -0000

This is just my interpretation, but this feels more like invalid token, because you’re not presenting all of the material required for the token itself. The DPoP draft has added “invalid_dpop_proof” as an error code, which I think is even better, but the MTLS draft is missing such an element and that is arguably a mistake in the document. The MTLS draft also re-uses “Bearer” as a token header, which is also a mistake in my opinion. 

But given the codes available, “invalid_token” seems to fit better because you aren’t messing up the request _to the resource_ itself, you’re messing up the token presentation.

 — Justin

> On Nov 10, 2021, at 10:17 AM, Dmitry Telegin <dmitryt=40backbase.com@dmarc.ietf.org> wrote:
> 
> Any updates on this one? The missing certificate case looks more like "invalid_request" to me:
> 
> invalid_request
>          The request is missing a required parameter, includes an
>          unsupported parameter or parameter value, repeats the same
>          parameter, uses more than one method for including an access
>          token, or is otherwise malformed.  The resource server SHOULD
>          respond with the HTTP 400 (Bad Request) status code.
> 
> On Fri, Sep 24, 2021 at 2:23 AM Dmitry Telegin <dmitryt@backbase.com <mailto:dmitryt@backbase.com>> wrote:
> From the document:
> 
>    The protected resource MUST obtain, from its TLS implementation
>    layer, the client certificate used for mutual TLS and MUST verify
>    that the certificate matches the certificate associated with the
>    access token.  If they do not match, the resource access attempt MUST
>    be rejected with an error, per [RFC6750 <https://datatracker.ietf.org/doc/html/rfc6750>], using an HTTP 401 status
>    code and the "invalid_token" error code.
> 
> Should the same error code be used in the case when the resource failed to obtain a certificate from the TLS layer? This could happen, for example, if the TLS stack has been misconfigured (e.g. verify-client="REQUESTED" instead of "REQUIRED" for Undertow), and the user agent provided no certificate.
> 
> Thanks,
> Dmitry
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email