Re: [OAUTH-WG] RFC 8705: How do we get client certificate from mTLS stack to OAuth stack for thumbprint confirmation

Takahiko Kawasaki <taka@authlete.com> Thu, 18 August 2022 10:46 UTC

Return-Path: <taka@authlete.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 88A8FC1522BC for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2022 03:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciaSEfnpl9wM for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2022 03:46:32 -0700 (PDT)
Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF0DC14CF05 for <oauth@ietf.org>; Thu, 18 Aug 2022 03:46:32 -0700 (PDT)
Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-32fd97c199fso30085407b3.6 for <oauth@ietf.org>; Thu, 18 Aug 2022 03:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=JyzQu1c3hnPiMyVs6H6GXixApwWzF8oyZvpPs55nEiY=; b=JSY8lTxjvhmLfBj7lzQ0XpRqKM2XUY+4dn6ac2eOYuP6pKcTqq913DHkOiI/jyj4oQ GfUndEBDPd4xRMYtAEDncyaLzeVXIohYFzZAJ7L1OcNImtQ+STgy4nmBvnz8NSwGk/Eb 7jokoSdQWnDB3gss8iJN7AirmCTQcLN6bhlZeYMjvK8M1rlM/pXsIETM5hsRl/Wz4hxu CJ9fhALRD00yghHAEKP7+PXd0lC7jaHGtPgOP0S+n2xmMcajOm6ShRPJa8tYogrUv67o IYiYh0vCzFPi/5n44cjJxpCYWmSNrTO4ILee0Odsw28/xj5s4Lf83Qjs92ZEXWI9oUJ4 BYng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=JyzQu1c3hnPiMyVs6H6GXixApwWzF8oyZvpPs55nEiY=; b=2OUBqjOYt5NMYiiazSG7lOJe0uRdg6+GqQOIDzPeNbTSDSg2lHEs4JrXldpf3H5iHI a227OzZcWncM2Ddi0Y8G0M5osoMN50Te/CF4081BaOsSZMDMJ1VQvhni4t4lKPc7ehlk 2ytTCW3A38ilyvyTRDCZcpcxAjhLIh/8LG0gTJQVFnF0R55rJdYInkCb7cohuuXHJy+g xww/MULtNFU23QYurR6Q/r52VKf1Q1bfBWAupJ+8feuHPPXHAp9an+TL3H0yYSmdeiGX IGOKvvQngbom6seNwt/oWowGHyuMUvliAkFFddwu/HhQ2GXh01Coit//LXDSV9YNoC+9 OV8Q==
X-Gm-Message-State: ACgBeo39gMgrnComxvvNiTBlfSqokoGfl4QPtlBOPSEBdaalMA9EXgx2 H+XmQt6o7/iS8YWsOe4Ixcq3byE5uPFvNUWmK5iZNX0gC8Rqkw==
X-Google-Smtp-Source: AA6agR6y1sKZ8tJUqDbc2h6+IVQxzhUUn3KVFCeZdD3sQ6+Lec6dAHd8CjIfSTRjN/6Sw6mQ3wkFXjdTs1cGJkigNO0=
X-Received: by 2002:a81:8003:0:b0:336:be9e:df56 with SMTP id q3-20020a818003000000b00336be9edf56mr1457912ywf.92.1660819591278; Thu, 18 Aug 2022 03:46:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAODMz5EvMHMuLZ2NMo_+CwUFDHzCY9nKtVjHQdOk2sEVGO6iJw@mail.gmail.com>
In-Reply-To: <CAODMz5EvMHMuLZ2NMo_+CwUFDHzCY9nKtVjHQdOk2sEVGO6iJw@mail.gmail.com>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Thu, 18 Aug 2022 19:46:20 +0900
Message-ID: <CAHdPCmOs4koqj6Yk_xeDapVbKYM6PB23s2rOLjsZNK7nb3SkCA@mail.gmail.com>
To: Jaimandeep Singh <jaimandeep.phdcs21=40nfsu.ac.in@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c6477305e681b10d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6GXNwB9sKRXp-iNcLdmtzcB6Xrc>
Subject: Re: [OAUTH-WG] RFC 8705: How do we get client certificate from mTLS stack to OAuth stack for thumbprint confirmation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 18 Aug 2022 10:46:36 -0000

Dear Jaimandeep,

Regarding the first question.

If the token endpoint of an authorization server and protected resource
endpoints of a resource server directly communicate with client
applications, meaning that there is no reverse proxy in between the
endpoints and client applications, the endpoints must be able to extract a
client certificate directly from a mutual TLS connection.

On the other hand, if a reverse proxy sits in between the endpoints and
client applications, the reverse proxy must be able to extract a client
certificate from a mutual TLS connection and pass it to the endpoints
behind the reverse proxy. In turn, the endpoints must be able to receive a
client certificate from the reverse proxy. How a reverse proxy passes a
client certificate to the backend server depends on implementations.

In both patterns, details vary depending on implementations of web
frameworks and reverse proxies / API gateways. In the first pattern, for
example, in Java's Servlet API, endpoints can extract a client certificate
by calling
HttpServletRequest.getAttribute("javax.servlet.request.X509Certificate").
In the second pattern, X-Ssl-Cert and X-Ssl-Cert-Chain-* HTTP headers are
often used to convey a client certificate chain from a reverse proxy to a
backend server, but the HTTP headers are not standardized ones. There
exists a proposed standard that defines Client-Cert and Client-Cert-Chain
HTTP headers for the purpose (
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert-field/ ).
Cloud-based API gateway solutions often take their own approaches. For
example, in Amazon API Gateway, a Lambda function can extract a client
certificate from
event['requestContext']['authentication']['clientCert']['clientCertPem'] (
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-lambda-authorizer-input.html
).

As listed above, there are a variety of ways to extract a client
certificate from a mutual TLS connection and pass it to endpoints. So, it
might not be appropriate to list implementation-specific examples in the
specification.

If you are interested in real examples, please read an online document
below where you can find "NGINX" and "Amazon API Gateway" examples.

Financial-grade Amazon API Gateway
https://www.authlete.com/developers/tutorial/financial_grade_apigateway/

Regarding the second question.

A resource server does not have to publish its public keys via "jwks_uri",
"jwks" or something equivalent unless the resource server wants the
authorization server to encrypt access tokens with an "asymmetric"
algorithm (where the resource server must hold a "private" key to decrypt
access tokens and the authorization server uses the corresponding "public"
key to encrypt access tokens).

PKI has already established a solid method to validate a certificate chain,
so there is little need to publish public keys for verifying certificate
signatures via "jwks_uri" or "jwks".

Best Regards,
Takahiko Kawasaki


On Tue, Aug 16, 2022 at 3:57 PM Jaimandeep Singh <jaimandeep.phdcs21=
40nfsu.ac.in@dmarc.ietf.org> wrote:

> Hi All,
>
> 1. RFC 8705, requires thumbprint confirmation of the client certificate.
> It is the same client certificate which is used by client application while
> establishing mutual-TLS with the authorisation server or the protected
> resource server. I have not found any specific methodology in the RFC to
> get this client certificate from the mTLS stack to the OAuth stack for
> enabling thumbprint confirmation. Section 3.2 of RFC 8705 states:
>
> The protected resource compares that certificate hash to a hash of the
> client certificate used for mutual-TLS authentication and rejects the
> request if they do not match.
>
>
>
> 2. The RFC 8705 has provision of associating client certificate metadata
> in the form of 'jwks_uri' or 'jwks' with the authorisation server. Section
> 2.2.2. states
>
>> For the Self-Signed Certificate method of binding a certificate with a
>> client using mutual-TLS client authentication, the existing jwks_uri or
>> jwks metadata parameters from [RFC7591] are used to convey the client's
>> certificates via JSON Web Key (JWK) in a JWK Set [RFC7517].
>
> However, the RFC does not spell out any association of 'jwks_uri' or
> 'jwks' with protected resource servers. Also, as per RFC 7517  'jwks_uri'
> or 'jwks' is used at application level mostly to validate the signatures of
> the signed tokens. Is there any update in RFC for TLS to use 'jwks_uri' or
> 'jwks' as keystores for the client certificates in TLS based authentication
> mechanism? Section 2 of RFC 7517 states:
>
>> For instance, these keys might be used by some applications for
>> validating signed requests made to the token endpoint when using JWTs for
>> client authentication
>
>
> 3. It will be great if someone can help with clarity on the above aspects.
>
> Regards and Best Wishes
> Jaimandeep Singh
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>