Hi Takahiko, 1. Thx a lot for taking out the time and efforts for the detailed explanation. I especially liked your real world examples for extracting client certificates. I now realize that most of the HTTP servers provide a way for extraction of client certificates. Although, there is a degree of adhocism existing there in the absence of any standard methodology. The same is now being addressed in the draft RFC <https://www.ietf.org/archive/id/draft-ietf-httpbis-client-cert-field-02.html> pointed out by you for the reverse proxy cases.
2. It was also nice to see that RFC 8705 has been mentioned as a use case in the draft RFC <https://www.ietf.org/archive/id/draft-ietf-httpbis-client-cert-field-02.html> referred to by you. Section B.3 states: > Furthermore, some applications, such as [RFC8705], make use of the entire > certificate. In order to accommodate the latter and ensure wide > applicability by not trying to cherry-pick particular certificate > information, this draft opted to pass the full encoded certificate as the > value of the Client-Cert field. 3. With your detailed explanation everything falls in place. Since the authorisation server can extract the client certificates from the TLS stack and hand it over to the application layer. It becomes an application layer problem which can be handled well by 'jwks_uri' or 'jwks'. Also, it clarifies why 'jwks_uri' and 'jwks' are not required by the resource servers as it depends upon introspection metadata received from the authorization server. Regards and Best Wishes Jaimandeep singh On Thu, Aug 18, 2022 at 4:16 PM Takahiko Kawasaki <t...@authlete.com> wrote: > 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...@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 >> > -- Regards and Best Wishes Jaimandeep Singh LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
