idnits 2.17.1 draft-ietf-oauth-mtls-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2019) is 1839 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' == Outdated reference: A later version (-08) exists of draft-ietf-oauth-token-binding-06 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group B. Campbell 3 Internet-Draft Ping Identity 4 Intended status: Standards Track J. Bradley 5 Expires: October 13, 2019 Yubico 6 N. Sakimura 7 Nomura Research Institute 8 T. Lodderstedt 9 YES.com AG 10 April 11, 2019 12 OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound 13 Access Tokens 14 draft-ietf-oauth-mtls-14 16 Abstract 18 This document describes OAuth client authentication and certificate- 19 bound access and refresh tokens using mutual Transport Layer Security 20 (TLS) authentication with X.509 certificates. OAuth clients are 21 provided a mechanism for authentication to the authorization server 22 using mutual TLS, based on either self-signed certificates or public 23 key infrastructure (PKI). OAuth authorization servers are provided a 24 mechanism for binding access tokens to a client's mutual TLS 25 certificate, and OAuth protected resources are provided a method for 26 ensuring that such an access token presented to it was issued to the 27 client presenting the token. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 13, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Notation and Conventions . . . . . . . . . . 5 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 5 67 2.1. PKI Mutual TLS Method . . . . . . . . . . . . . . . . . . 6 68 2.1.1. PKI Method Metadata Value . . . . . . . . . . . . . . 6 69 2.1.2. Client Registration Metadata . . . . . . . . . . . . 7 70 2.2. Self-Signed Certificate Mutual TLS Method . . . . . . . . 7 71 2.2.1. Self-Signed Method Metadata Value . . . . . . . . . . 8 72 2.2.2. Client Registration Metadata . . . . . . . . . . . . 8 73 3. Mutual TLS Client Certificate-Bound Access Tokens . . . . . . 8 74 3.1. JWT Certificate Thumbprint Confirmation Method . . . . . 9 75 3.2. Confirmation Method for Token Introspection . . . . . . . 10 76 3.3. Authorization Server Metadata . . . . . . . . . . . . . . 11 77 3.4. Client Registration Metadata . . . . . . . . . . . . . . 11 78 4. Public Clients and Certificate-Bound Tokens . . . . . . . . . 11 79 5. Metadata for Mutual TLS Endpoint Aliases . . . . . . . . . . 12 80 6. Implementation Considerations . . . . . . . . . . . . . . . . 13 81 6.1. Authorization Server . . . . . . . . . . . . . . . . . . 14 82 6.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 14 83 6.3. Certificate Expiration and Bound Access Tokens . . . . . 15 84 6.4. Implicit Grant Unsupported . . . . . . . . . . . . . . . 15 85 6.5. TLS Termination . . . . . . . . . . . . . . . . . . . . . 15 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 7.1. Certificate-Bound Refresh Tokens . . . . . . . . . . . . 15 88 7.2. Certificate Thumbprint Binding . . . . . . . . . . . . . 16 89 7.3. TLS Versions and Best Practices . . . . . . . . . . . . . 16 90 7.4. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 16 91 7.5. X.509 Certificate Parsing and Validation Complexity . . . 16 92 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 94 9.1. JWT Confirmation Methods Registration . . . . . . . . . . 17 95 9.2. Authorization Server Metadata Registration . . . . . . . 18 96 9.3. Token Endpoint Authentication Method Registration . . . . 18 97 9.4. Token Introspection Response Registration . . . . . . . . 18 98 9.5. Dynamic Client Registration Metadata Registration . . . . 19 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 101 10.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Appendix A. Example "cnf" Claim, Certificate and JWK . . . . . . 23 103 Appendix B. Relationship to Token Binding . . . . . . . . . . . 24 104 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 24 105 Appendix D. Document(s) History . . . . . . . . . . . . . . . . 25 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 108 1. Introduction 110 The OAuth 2.0 Authorization Framework [RFC6749] enables third-party 111 client applications to obtain delegated access to protected 112 resources. In the prototypical abstract OAuth flow, illustrated in 113 Figure 1, the client obtains an access token from an entity known as 114 an authorization server and then uses that token when accessing 115 protected resources, such as HTTPS APIs. 117 +--------+ +---------------+ 118 | | | | 119 | |<--(A)-- Get an access token --->| Authorization | 120 | | | Server | 121 | | | | 122 | | +---------------+ 123 | | ^ 124 | | | 125 | | 126 | | (C) | 127 | Client | Validate the 128 | | access token | 129 | | 130 | | | 131 | | v 132 | | +---------------+ 133 | | | (C) | 134 | | | | 135 | |<--(B)-- Use the access token -->| Protected | 136 | | | Resource | 137 | | | | 138 +--------+ +---------------+ 140 Figure 1: Abstract OAuth 2.0 Protocol Flow 142 The flow illustrated in Figure 1 includes the following steps: 144 (A) The client makes an HTTPS "POST" request to the authorization 145 server and presents a credential representing the authorization 146 grant. For certain types of clients (those that have been 147 issued or otherwise established a set of client credentials) the 148 request must be authenticated. In the response, the 149 authorization server issues an access token to the client. 151 (B) The client includes the access token when making a request to 152 access a protected resource. 154 (C) The protected resource validates the access token in order to 155 authorize the request. In some cases, such as when the token is 156 self-contained and cryptographically secured, the validation can 157 be done locally by the protected resource. While other cases 158 require that the protected resource call out to the 159 authorization server to determine the state of the token and 160 obtain meta-information about it. 162 Layering on the abstract flow above, this document standardizes 163 enhanced security options for OAuth 2.0 utilizing client certificate 164 based mutual TLS. Section 2 provides options for authenticating the 165 request in step (A). While step (C) is supported with semantics to 166 express the binding of the token to the client certificate for both 167 local and remote processing in Section 3.1 and Section 3.2 168 respectively. This ensures that, as described in Section 3, 169 protected resource access in step (B) is only possible by the 170 legitimate client bearing the access token and holding the private 171 key corresponding to the certificate. 173 OAuth 2.0 defines a shared secret method of client authentication but 174 also allows for definition and use of additional client 175 authentication mechanisms when interacting directly with the 176 authorization server. This document describes an additional 177 mechanism of client authentication utilizing mutual TLS certificate- 178 based authentication, which provides better security characteristics 179 than shared secrets. While [RFC6749] documents client authentication 180 for requests to the token endpoint, extensions to OAuth 2.0 (such as 181 Introspection [RFC7662], Revocation [RFC7009], and the Backchannel 182 Authentication Endpoint in [OpenID.CIBA]) define endpoints that also 183 utilize client authentication and the mutual TLS methods defined 184 herein are applicable to those endpoints as well. 186 Mutual TLS certificate-bound access tokens ensure that only the party 187 in possession of the private key corresponding to the certificate can 188 utilize the token to access the associated resources. Such a 189 constraint is sometimes referred to as key confirmation, proof-of- 190 possession, or holder-of-key and is unlike the case of the bearer 191 token described in [RFC6750], where any party in possession of the 192 access token can use it to access the associated resources. Binding 193 an access token to the client's certificate prevents the use of 194 stolen access tokens or replay of access tokens by unauthorized 195 parties. 197 Mutual TLS certificate-bound access tokens and mutual TLS client 198 authentication are distinct mechanisms, which are complementary but 199 don't necessarily need to be deployed or used together. 201 1.1. Requirements Notation and Conventions 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in BCP 206 14 [RFC2119] [RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 1.2. Terminology 211 Throughout this document the term "mutual TLS" refers to the process 212 whereby a client presents its X.509 certificate and proves possession 213 of the corresponding private key to a server when negotiating a TLS 214 session. In contemporary versions of TLS [RFC8446] [RFC5246] this 215 requires that the client send the Certificate and CertificateVerify 216 messages during the handshake and for the server to verify the 217 CertificateVerify and Finished messages. 219 2. Mutual TLS for OAuth Client Authentication 221 This section defines, as an extension of OAuth 2.0, Section 2.3 222 [RFC6749], two distinct methods of using mutual TLS X.509 client 223 certificates as client credentials. The requirement of mutual TLS 224 for client authentication is determined by the authorization server 225 based on policy or configuration for the given client (regardless of 226 whether the client was dynamically registered, statically configured, 227 or otherwise established). 229 In order to utilize TLS for OAuth client authentication, the TLS 230 connection between the client and the authorization server MUST have 231 been established or reestablished with mutual TLS X.509 certificate 232 authentication (i.e. the Client Certificate and Certificate Verify 233 messages are sent during the TLS Handshake). 235 For all requests to the authorization server utilizing mutual TLS 236 client authentication, the client MUST include the "client_id" 237 parameter, described in OAuth 2.0, Section 2.2 [RFC6749]. The 238 presence of the "client_id" parameter enables the authorization 239 server to easily identify the client independently from the content 240 of the certificate. The authorization server can locate the client 241 configuration using the client identifier and check the certificate 242 presented in the TLS Handshake against the expected credentials for 243 that client. The authorization server MUST enforce the binding 244 between client and certificate as described in either Section 2.1 or 245 Section 2.2 below. 247 2.1. PKI Mutual TLS Method 249 The PKI (public key infrastructure) method of mutual TLS OAuth client 250 authentication adheres to the way in which X.509 certificates are 251 traditionally used for authentication. It relies on a validated 252 certificate chain [RFC5280] and a single subject distinguished name 253 (DN) or a single subject alternative name (SAN) to authenticate the 254 client. Only one subject name value of any type is used for each 255 client. The TLS handshake is utilized to validate the client's 256 possession of the private key corresponding to the public key in the 257 certificate and to validate the corresponding certificate chain. The 258 client is successfully authenticated if the subject information in 259 the certificate matches the single expected subject configured or 260 registered for that particular client (note that a predictable 261 treatment of DN values, such as the distinguishedNameMatch rule from 262 [RFC4517], is needed in comparing the certificate's subject DN to the 263 client's registered DN). Revocation checking is possible with the 264 PKI method but if and how to check a certificate's revocation status 265 is a deployment decision at the discretion of the authorization 266 server. Clients can rotate their X.509 certificates without the need 267 to modify the respective authentication data at the authorization 268 server by obtaining a new certificate with the same subject from a 269 trusted certificate authority (CA). 271 2.1.1. PKI Method Metadata Value 273 For the PKI method of mutual TLS client authentication, this 274 specification defines and registers the following authentication 275 method metadata value into the "OAuth Token Endpoint Authentication 276 Methods" registry [IANA.OAuth.Parameters]. 278 tls_client_auth 279 Indicates that client authentication to the authorization server 280 will occur with mutual TLS utilizing the PKI method of associating 281 a certificate to a client. 283 2.1.2. Client Registration Metadata 285 In order to convey the expected subject of the certificate, the 286 following metadata parameters are introduced for the OAuth 2.0 287 Dynamic Client Registration Protocol [RFC7591] in support of the PKI 288 method of mutual TLS client authentication. A client using the 289 "tls_client_auth" authentication method MUST use exactly one of the 290 below metadata parameters to indicate the certificate subject value 291 that the authorization server is to expect when authenticating the 292 respective client. 294 tls_client_auth_subject_dn 295 An [RFC4514] string representation of the expected subject 296 distinguished name of the certificate, which the OAuth client will 297 use in mutual TLS authentication. 299 tls_client_auth_san_dns 300 A string containing the value of an expected dNSName SAN entry in 301 the certificate, which the OAuth client will use in mutual TLS 302 authentication. 304 tls_client_auth_san_uri 305 A string containing the value of an expected 306 uniformResourceIdentifier SAN entry in the certificate, which the 307 OAuth client will use in mutual TLS authentication. 309 tls_client_auth_san_ip 310 A string representation of an IP address in either dotted decimal 311 notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as 312 defined in [RFC4291] section 2.2) that is expected to be present 313 as an iPAddress SAN entry in the certificate, which the OAuth 314 client will use in mutual TLS authentication. 316 tls_client_auth_san_email 317 A string containing the value of an expected rfc822Name SAN entry 318 in the certificate, which the OAuth client will use in mutual TLS 319 authentication. 321 2.2. Self-Signed Certificate Mutual TLS Method 323 This method of mutual TLS OAuth client authentication is intended to 324 support client authentication using self-signed certificates. As 325 pre-requisite, the client registers its X.509 certificates (using 326 "jwks" defined in [RFC7591]) or a trusted source for its X.509 327 certificates (using "jwks_uri" from [RFC7591]) with the authorization 328 server. During authentication, TLS is utilized to validate the 329 client's possession of the private key corresponding to the public 330 key presented within the certificate in the respective TLS handshake. 332 In contrast to the PKI method, the client's certificate chain is not 333 validated by the server in this case. The client is successfully 334 authenticated if the certificate that it presented during the 335 handshake matches one of the certificates configured or registered 336 for that particular client. The Self-Signed Certificate method 337 allows the use of mutual TLS to authenticate clients without the need 338 to maintain a PKI. When used in conjunction with a "jwks_uri" for 339 the client, it also allows the client to rotate its X.509 340 certificates without the need to change its respective authentication 341 data directly with the authorization server. 343 2.2.1. Self-Signed Method Metadata Value 345 For the Self-Signed Certificate method of mutual TLS client 346 authentication, this specification defines and registers the 347 following authentication method metadata value into the "OAuth Token 348 Endpoint Authentication Methods" registry [IANA.OAuth.Parameters]. 350 self_signed_tls_client_auth 351 Indicates that client authentication to the authorization server 352 will occur using mutual TLS with the client utilizing a self- 353 signed certificate. 355 2.2.2. Client Registration Metadata 357 For the Self-Signed Certificate method of binding a certificate with 358 a client using mutual TLS client authentication, the existing 359 "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to 360 convey the client's certificates via JSON Web Key (JWK) in a JWK Set 361 (JWKS) [RFC7517]. The "jwks" metadata parameter is a JWK Set 362 containing the client's public keys as an array of JWKs while the 363 "jwks_uri" parameter is a URL that references a client's JWK Set. A 364 certificate is represented with the "x5c" parameter of an individual 365 JWK within the set. Note that the members of the JWK representing 366 the public key (e.g. "n" and "e" for RSA, "x" and "y" for EC) are 367 required parameters per [RFC7518] so will be present even though they 368 are not utilized in this context. Also note that that sec 4.7 of 369 [RFC7517] requires that the key in the first certificate of the "x5c" 370 parameter match the public key represented by those other members of 371 the JWK. 373 3. Mutual TLS Client Certificate-Bound Access Tokens 375 When mutual TLS is used by the client on the connection to the token 376 endpoint, the authorization server is able to bind the issued access 377 token to the client certificate. Such a binding is accomplished by 378 associating the certificate with the token in a way that can be 379 accessed by the protected resource, such as embedding the certificate 380 hash in the issued access token directly, using the syntax described 381 in Section 3.1, or through token introspection as described in 382 Section 3.2. Binding the access token to the client certificate in 383 that fashion has the benefit of decoupling that binding from the 384 client's authentication with the authorization server, which enables 385 mutual TLS during protected resource access to serve purely as a 386 proof-of-possession mechanism. Other methods of associating a 387 certificate with an access token are possible, per agreement by the 388 authorization server and the protected resource, but are beyond the 389 scope of this specification. 391 The client makes protected resource requests as described in 392 [RFC6750], however, those requests MUST be made over a mutually 393 authenticated TLS connection using the same certificate that was used 394 for mutual TLS at the token endpoint. 396 The protected resource MUST obtain, from its TLS implementation 397 layer, the client certificate used for mutual TLS and MUST verify 398 that the certificate matches the certificate associated with the 399 access token. If they do not match, the resource access attempt MUST 400 be rejected with an error per [RFC6750] using an HTTP 401 status code 401 and the "invalid_token" error code. 403 Metadata to convey server and client capabilities for mutual TLS 404 client certificate-bound access tokens is defined in Section 3.3 and 405 Section 3.4 respectively. 407 3.1. JWT Certificate Thumbprint Confirmation Method 409 When access tokens are represented as JSON Web Tokens (JWT)[RFC7519], 410 the certificate hash information SHOULD be represented using the 411 "x5t#S256" confirmation method member defined herein. 413 To represent the hash of a certificate in a JWT, this specification 414 defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" 415 for the X.509 Certificate SHA-256 Thumbprint. The value of the 416 "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash 417 (a.k.a. thumbprint, fingerprint or digest) of the DER encoding of the 418 X.509 certificate [RFC5280]. The base64url-encoded value MUST omit 419 all trailing pad '=' characters and MUST NOT include any line breaks, 420 whitespace, or other additional characters. 422 The following is an example of a JWT payload containing an "x5t#S256" 423 certificate thumbprint confirmation method. 425 { 426 "iss": "https://server.example.com", 427 "sub": "ty.webb@example.com", 428 "exp": 1493726400, 429 "nbf": 1493722800, 430 "cnf":{ 431 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 432 } 433 } 435 Figure 2: Example JWT Claims Set with an X.509 Certificate Thumbprint 436 Confirmation Method 438 3.2. Confirmation Method for Token Introspection 440 OAuth 2.0 Token Introspection [RFC7662] defines a method for a 441 protected resource to query an authorization server about the active 442 state of an access token as well as to determine meta-information 443 about the token. 445 For a mutual TLS client certificate-bound access token, the hash of 446 the certificate to which the token is bound is conveyed to the 447 protected resource as meta-information in a token introspection 448 response. The hash is conveyed using the same "cnf" with "x5t#S256" 449 member structure as the certificate SHA-256 thumbprint confirmation 450 method, described in Section 3.1, as a top-level member of the 451 introspection response JSON. The protected resource compares that 452 certificate hash to a hash of the client certificate used for mutual 453 TLS authentication and rejects the request, if they do not match. 455 The following is an example of an introspection response for an 456 active token with an "x5t#S256" certificate thumbprint confirmation 457 method. 459 HTTP/1.1 200 OK 460 Content-Type: application/json 462 { 463 "active": true, 464 "iss": "https://server.example.com", 465 "sub": "ty.webb@example.com", 466 "exp": 1493726400, 467 "nbf": 1493722800, 468 "cnf":{ 469 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 470 } 471 } 473 Figure 3: Example Introspection Response for a Certificate-Bound 474 Access Token 476 3.3. Authorization Server Metadata 478 This document introduces the following new authorization server 479 metadata parameter to signal the server's capability to issue 480 certificate bound access tokens: 482 tls_client_certificate_bound_access_tokens 483 OPTIONAL. Boolean value indicating server support for mutual TLS 484 client certificate-bound access tokens. If omitted, the default 485 value is "false". 487 3.4. Client Registration Metadata 489 The following new client metadata parameter is introduced to convey 490 the client's intention to use certificate bound access tokens: 492 tls_client_certificate_bound_access_tokens 493 OPTIONAL. Boolean value used to indicate the client's intention 494 to use mutual TLS client certificate-bound access tokens. If 495 omitted, the default value is "false". 497 4. Public Clients and Certificate-Bound Tokens 499 Mutual TLS OAuth client authentication and certificate-bound access 500 tokens can be used independently of each other. Use of certificate- 501 bound access tokens without mutual TLS OAuth client authentication, 502 for example, is possible in support of binding access tokens to a TLS 503 client certificate for public clients (those without authentication 504 credentials associated with the "client_id"). The authorization 505 server would configure the TLS stack in the same manner as for the 506 Self-Signed Certificate method such that it does not verify that the 507 certificate presented by the client during the handshake is signed by 508 a trusted CA. Individual instances of a client would create a self- 509 signed certificate for mutual TLS with both the authorization server 510 and resource server. The authorization server would not use the 511 mutual TLS certificate to authenticate the client at the OAuth layer 512 but would bind the issued access token to that certificate, for which 513 the client has proven possession of the corresponding private key. 514 The access token is then bound to the certificate and can only be 515 used by the client possessing the certificate and corresponding 516 private key and utilizing them to negotiate mutual TLS on connections 517 to the resource server. When the authorization server issues a 518 refresh token to such a client, it SHOULD also bind the refresh token 519 to the respective certificate. And check the binding when the 520 refresh token is presented to get new access tokens. The 521 implementation details of the binding the refresh token are at the 522 discretion of the authorization server. 524 5. Metadata for Mutual TLS Endpoint Aliases 526 The process of negotiating client certificate-based mutual TLS 527 involves a TLS server requesting a certificate from the TLS client 528 (the client does not provide one unsolicited). Although a server can 529 be configured such that client certificates are optional, meaning 530 that the connection is allowed to continue when the client does not 531 provide a certificate, the act of a server requesting a certificate 532 can result in undesirable behavior from some clients. This is 533 particularly true of web browsers as TLS clients, which will 534 typically present the end-user with an intrusive certificate 535 selection interface when the server requests a certificate. 537 Authorization servers supporting both clients using mutual TLS and 538 conventional clients MAY chose to isolate the server side mutual TLS 539 behaviour to only clients intending to do mutual TLS, thus avoiding 540 any undesirable effects it might have on conventional clients. The 541 following authorization server metadata parameter is introduced to 542 facilitate such separation: 544 mtls_endpoint_aliases 545 OPTIONAL. A JSON object containing alternative authorization 546 server endpoints that, when present, an OAuth client intending to 547 do mutual TLS uses in preference to the conventional endpoints. 548 The parameter value itself consists of one or more endpoint 549 parameters, such as "token_endpoint", "revocation_endpoint", 550 "introspection_endpoint", etc., conventionally defined for the 551 top-level of authorization server metadata. An OAuth client 552 intending to do mutual TLS (for OAuth client authentication and/or 553 to acquire or use certificate-bound tokens) when making a request 554 directly to the authorization server MUST use the alias URL of the 555 endpoint within the "mtls_endpoint_aliases", when present, in 556 preference to the endpoint URL of the same name at top-level of 557 metadata. When an endpoint is not present in 558 "mtls_endpoint_aliases", then the client uses the conventional 559 endpoint URL defined at the top-level of the authorization server 560 metadata. Metadata parameters within "mtls_endpoint_aliases" that 561 do not define endpoints to which an OAuth client makes a direct 562 request have no meaning and SHOULD be ignored. 564 Below is an example of an authorization server metatdata document 565 with the "mtls_endpoint_aliases" parameter, which indicates aliases 566 for the token, revocation, and introspection endpoints that an OAuth 567 client intending to do mutual TLS would in preference to the 568 conventional token, revocation, and introspection endpoints. Note 569 that the endpoints in "mtls_endpoint_aliases" use a different host 570 than their conventional counterparts, which allows the authorization 571 server (via SNI or actual distinct hosts) to differentiate its TLS 572 behavior as appropriate. 574 { 575 "issuer": "https://server.example.com", 576 "authorization_endpoint": "https://server.example.com/authz", 577 "token_endpoint": "https://server.example.com/token", 578 "introspection_endpoint": "https://server.example.com/introspect", 579 "revocation_endpoint": "https://server.example.com/revo", 580 "jwks_uri": "https://server.example.com/jwks", 581 "response_types_supported": ["code"], 582 "response_modes_supported": ["fragment","query","form_post"], 583 "grant_types_supported": ["authorization_code", "refresh_token"], 584 "token_endpoint_auth_methods_supported": 585 ["tls_client_auth","client_secret_basic","none"], 586 "tls_client_certificate_bound_access_tokens": true 587 "mtls_endpoint_aliases": { 588 "token_endpoint": "https://mtls.example.com/token", 589 "revocation_endpoint": "https://mtls.example.com/revo", 590 "introspection_endpoint": "https://mtls.example.com/introspect" 591 } 592 } 594 Figure 4: Example Authorization Server Metadata with Mutual TLS 595 Endpoint Aliases 597 6. Implementation Considerations 598 6.1. Authorization Server 600 The authorization server needs to set up its TLS configuration 601 appropriately for the OAuth client authentication methods it 602 supports. 604 An authorization server that supports mutual TLS client 605 authentication and other client authentication methods or public 606 clients in parallel would make mutual TLS optional (i.e. allowing a 607 handshake to continue after the server requests a client certificate 608 but the client does not send one). 610 In order to support the Self-Signed Certificate method, the 611 authorization server would configure the TLS stack in such a way that 612 it does not verify whether the certificate presented by the client 613 during the handshake is signed by a trusted CA certificate. 615 As described in Section 3, the authorization server binds the issued 616 access token to the TLS client certificate, which means that it will 617 only issue certificate-bound tokens for a certificate which the 618 client has proven possession of the corresponding private key. 620 The authorization server may also consider hosting the token 621 endpoint, and other endpoints requiring client authentication, on a 622 separate host name or port in order to prevent unintended impact on 623 the TLS behavior of its other endpoints, e.g. the authorization 624 endpoint. As described in Section 5, it may further isolate any 625 potential impact of the server requesting client certificates by 626 offering a distinct set of endpoints on a separate host or port, 627 which are aliases for the originals that a client intending to do 628 mutual TLS will use in preference to the conventional endpoints. 630 6.2. Resource Server 632 OAuth divides the roles and responsibilities such that the resource 633 server relies on the authorization server to perform client 634 authentication and obtain resource owner (end-user) authorization. 635 The resource server makes authorization decisions based on the access 636 token presented by the client but does not directly authenticate the 637 client per se. The the manner in which an access token is bound to 638 the client certificate decouples it from the specific method that the 639 client used to authenticate with the authorization server. Mutual 640 TLS during protected resource access can therefore serve purely as a 641 proof-of-possession mechanism. As such, it is not necessary for the 642 resource server to validate the trust chain of the client's 643 certificate in any of the methods defined in this document. The 644 resource server would therefore configure the TLS stack in a way that 645 it does not verify whether the certificate presented by the client 646 during the handshake is signed by a trusted CA certificate. 648 6.3. Certificate Expiration and Bound Access Tokens 650 As described in Section 3, an access token is bound to a specific 651 client certificate, which means that the same certificate must be 652 used for mutual TLS on protected resource access. It also implies 653 that access tokens are invalidated when a client updates the 654 certificate, which can be handled similar to expired access tokens 655 where the client requests a new access token (typically with a 656 refresh token) and retries the protected resource request. 658 6.4. Implicit Grant Unsupported 660 This document describes binding an access token to the client 661 certificate presented on the TLS connection from the client to the 662 authorization server's token endpoint, however, such binding of 663 access tokens issued directly from the authorization endpoint via the 664 implicit grant flow is explicitly out of scope. End users interact 665 directly with the authorization endpoint using a web browser and the 666 use of client certificates in user's browsers bring operational and 667 usability issues, which make it undesirable to support certificate- 668 bound access tokens issued in the implicit grant flow. 669 Implementations wanting to employ certificate-bound access tokens 670 should utilize grant types that involve the client making an access 671 token request directly to the token endpoint (e.g. the authorization 672 code and refresh token grant types). 674 6.5. TLS Termination 676 An authorization server or resource server MAY choose to terminate 677 TLS connections at a load balancer, reverse proxy, or other network 678 intermediary. How the client certificate metadata is securely 679 communicated between the intermediary and the application server in 680 this case is out of scope of this specification. 682 7. Security Considerations 684 7.1. Certificate-Bound Refresh Tokens 686 The OAuth 2.0 Authorization Framework [RFC6749] requires that an 687 authorization server bind refresh tokens to the client to which they 688 where issued and that confidential clients (those having established 689 authentication credentials with the authorization server) 690 authenticate to the AS when presenting a refresh token. As a result, 691 refresh tokens are indirectly certificate-bound when issued to 692 clients utilizing the "tls_client_auth" or 693 "self_signed_tls_client_auth" methods of client authentication. 694 Section 4 describes certificate-bound refresh tokens issued to public 695 clients (those without authentication credentials associated with the 696 "client_id"). 698 7.2. Certificate Thumbprint Binding 700 The binding between the certificate and access token specified in 701 Section 3.1 uses a cryptographic hash of the certificate. It relies 702 on the hash function having sufficient preimage and second-preimage 703 resistance so as to make it computationally infeasible to find or 704 create another certificate that produces to the same hash output 705 value. The SHA-256 hash function was used because it meets the 706 aforementioned requirement while being widely available. If, in the 707 future, certificate thumbprints need to be computed using hash 708 function(s) other than SHA-256, it is suggested that additional 709 related JWT confirmation methods members be defined for that purpose 710 and registered in the the IANA "JWT Confirmation Methods" registry 711 [IANA.JWT.Claims] for JWT "cnf" member values. 713 7.3. TLS Versions and Best Practices 715 In the abstract this document is applicable with any TLS version 716 supporting certificate-based client authentication. Both TLS 1.3 717 [RFC8446] and TLS 1.2 [RFC5246] are cited herein because, at the time 718 of writing, 1.3 is the newest version while 1.2 is the most widely 719 deployed. General implementation and security considerations for 720 TLS, including version recommendations, can be found in [BCP195]. 722 7.4. X.509 Certificate Spoofing 724 If the PKI method of client authentication is used, an attacker could 725 try to impersonate a client using a certificate with the same subject 726 (DN or SAN) but issued by a different CA, which the authorization 727 server trusts. To cope with that threat, the authorization server 728 SHOULD only accept as trust anchors a limited number of CAs whose 729 certificate issuance policy meets its security requirements. There 730 is an assumption then that the client and server agree on the set of 731 trust anchors that the server uses to create and validate the 732 certificate chain. Without this assumption the use of a subject to 733 identify the client certificate would open the server up to 734 certificate spoofing attacks. 736 7.5. X.509 Certificate Parsing and Validation Complexity 738 Parsing and validation of X.509 certificates and certificate chains 739 is complex and implementation mistakes have previously exposed 740 security vulnerabilities. Complexities of validation include (but 741 are not limited to) [CX5P] [DCW] [RFC5280]: 743 o checking of Basic Constraints, basic and extended Key Usage 744 constraints, validity periods, and critical extensions; 746 o handling of null-terminator bytes and non-canonical string 747 representations in subject names; 749 o handling of wildcard patterns in subject names; 751 o recursive verification of certificate chains and checking 752 certificate revocation. 754 For these reasons, implementors SHOULD use an established and well- 755 tested X.509 library (such as one used by an established TLS library) 756 for validation of X.509 certificate chains and SHOULD NOT attempt to 757 write their own X.509 certificate validation procedures. 759 8. Privacy Considerations 761 In TLS versions prior to 1.3, the client's certificate is sent 762 unencrypted in the initial handshake and can potentially be used by 763 third parties to monitor, track, and correlate client activity. This 764 is likely of little concern for clients that act on behalf of a 765 significant number of end-users because individual user activity will 766 not be discernible amidst the client activity as a whole. However, 767 clients that act on behalf of a single end-user, such as a native 768 application on a mobile device, should use TLS version 1.3 whenever 769 possible or consider the potential privacy implications of using 770 mutual TLS on earlier versions. 772 9. IANA Considerations 774 9.1. JWT Confirmation Methods Registration 776 This specification requests registration of the following value in 777 the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for 778 JWT "cnf" member values established by [RFC7800]. 780 o Confirmation Method Value: "x5t#S256" 781 o Confirmation Method Description: X.509 Certificate SHA-256 782 Thumbprint 783 o Change Controller: IESG 784 o Specification Document(s): Section 3.1 of [[ this specification ]] 786 9.2. Authorization Server Metadata Registration 788 This specification requests registration of the following value in 789 the IANA "OAuth Authorization Server Metadata" registry 790 [IANA.OAuth.Parameters] established by [RFC8414]. 792 o Metadata Name: "tls_client_certificate_bound_access_tokens" 793 o Metadata Description: Indicates authorization server support for 794 mutual TLS client certificate-bound access tokens. 795 o Change Controller: IESG 796 o Specification Document(s): Section 3.3 of [[ this specification ]] 798 o Metadata Name: "mtls_endpoint_aliases" 799 o Metadata Description: JSON object containing alternative 800 authorization server endpoints, which a client intending to do 801 mutual TLS will use in preference to the conventional endpoints. 802 o Change Controller: IESG 803 o Specification Document(s): Section 5 of [[ this specification ]] 805 9.3. Token Endpoint Authentication Method Registration 807 This specification requests registration of the following value in 808 the IANA "OAuth Token Endpoint Authentication Methods" registry 809 [IANA.OAuth.Parameters] established by [RFC7591]. 811 o Token Endpoint Authentication Method Name: "tls_client_auth" 812 o Change Controller: IESG 813 o Specification Document(s): Section 2.1.1 of [[ this specification 814 ]] 816 o Token Endpoint Authentication Method Name: 817 "self_signed_tls_client_auth" 818 o Change Controller: IESG 819 o Specification Document(s): Section 2.2.1 of [[ this specification 820 ]] 822 9.4. Token Introspection Response Registration 824 Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] 825 defined the "cnf" (confirmation) claim, which enables confirmation 826 key information to be carried in a JWT. However, the same proof-of- 827 possession semantics are also useful for introspected access tokens 828 whereby the protected resource obtains the confirmation key data as 829 meta-information of a token introspection response and uses that 830 information in verifying proof-of-possession. Therefore this 831 specification defines and registers proof-of-possession semantics for 832 OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. 833 When included as a top-level member of an OAuth token introspection 834 response, "cnf" has the same semantics and format as the claim of the 835 same name defined in [RFC7800]. While this specification only 836 explicitly uses the "x5t#S256" confirmation method member (see 837 Section 3.2), it needs to define and register the higher level "cnf" 838 structure as an introspection response member in order to define and 839 use the more specific certificate thumbprint confirmation method. 841 As such, this specification requests registration of the following 842 value in the IANA "OAuth Token Introspection Response" registry 843 [IANA.OAuth.Parameters] established by [RFC7662]. 845 o Claim Name: "cnf" 846 o Claim Description: Confirmation 847 o Change Controller: IESG 848 o Specification Document(s): [RFC7800] and [[ this specification ]] 850 9.5. Dynamic Client Registration Metadata Registration 852 This specification requests registration of the following client 853 metadata definitions in the IANA "OAuth Dynamic Client Registration 854 Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: 856 o Client Metadata Name: "tls_client_certificate_bound_access_tokens" 857 o Client Metadata Description: Indicates the client's intention to 858 use mutual TLS client certificate-bound access tokens. 859 o Change Controller: IESG 860 o Specification Document(s): Section 3.4 of [[ this specification ]] 862 o Client Metadata Name: "tls_client_auth_subject_dn" 863 o Client Metadata Description: String value specifying the expected 864 subject DN of the client certificate. 865 o Change Controller: IESG 866 o Specification Document(s): Section 2.1.2 of [[ this specification 867 ]] 869 o Client Metadata Name: "tls_client_auth_san_dns" 870 o Client Metadata Description: String value specifying the expected 871 dNSName SAN entry in the client certificate. 872 o Change Controller: IESG 873 o Specification Document(s): Section 2.1.2 of [[ this specification 874 ]] 876 o Client Metadata Name: "tls_client_auth_san_uri" 877 o Client Metadata Description: String value specifying the expected 878 uniformResourceIdentifier SAN entry in the client certificate. 879 o Change Controller: IESG 880 o Specification Document(s): Section 2.1.2 of [[ this specification 881 ]] 883 o Client Metadata Name: "tls_client_auth_san_ip" 884 o Client Metadata Description: String value specifying the expected 885 iPAddress SAN entry in the client certificate. 886 o Change Controller: IESG 887 o Specification Document(s): Section 2.1.2 of [[ this specification 888 ]] 890 o Client Metadata Name: "tls_client_auth_san_email" 891 o Client Metadata Description: String value specifying the expected 892 rfc822Name SAN entry in the client certificate. 893 o Change Controller: IESG 894 o Specification Document(s): Section 2.1.2 of [[ this specification 895 ]] 897 10. References 899 10.1. Normative References 901 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 902 "Recommendations for Secure Use of Transport Layer 903 Security (TLS) and Datagram Transport Layer Security 904 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 905 2015, . 907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 908 Requirement Levels", BCP 14, RFC 2119, 909 DOI 10.17487/RFC2119, March 1997, 910 . 912 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 913 (LDAP): String Representation of Distinguished Names", 914 RFC 4514, DOI 10.17487/RFC4514, June 2006, 915 . 917 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 918 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 919 . 921 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 922 (TLS) Protocol Version 1.2", RFC 5246, 923 DOI 10.17487/RFC5246, August 2008, 924 . 926 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 927 Housley, R., and W. Polk, "Internet X.509 Public Key 928 Infrastructure Certificate and Certificate Revocation List 929 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 930 . 932 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 933 RFC 6749, DOI 10.17487/RFC6749, October 2012, 934 . 936 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 937 Framework: Bearer Token Usage", RFC 6750, 938 DOI 10.17487/RFC6750, October 2012, 939 . 941 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 942 Possession Key Semantics for JSON Web Tokens (JWTs)", 943 RFC 7800, DOI 10.17487/RFC7800, April 2016, 944 . 946 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 947 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 948 . 950 [SHS] National Institute of Standards and Technology, "Secure 951 Hash Standard (SHS)", FIPS PUB 180-4, March 2012, 952 . 955 10.2. Informative References 957 [CX5P] Wong, D., "Common x509 certificate validation/creation 958 pitfalls", September 2016, 959 . 962 [DCW] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, 963 D., and V. Shmatikov, "The Most Dangerous Code in the 964 World: Validating SSL Certificates in Non-Browser 965 Software", 966 . 968 [I-D.ietf-oauth-token-binding] 969 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 970 "OAuth 2.0 Token Binding", draft-ietf-oauth-token- 971 binding-06 (work in progress), March 2018. 973 [IANA.JWT.Claims] 974 IANA, "JSON Web Token Claims", 975 . 977 [IANA.OAuth.Parameters] 978 IANA, "OAuth Parameters", 979 . 981 [OpenID.CIBA] 982 Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. 983 Campbell, "OpenID Connect Client Initiated Backchannel 984 Authentication Flow - Core 1.0", January 2019, 985 . 988 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 989 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 990 2006, . 992 [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol 993 (LDAP): Syntaxes and Matching Rules", RFC 4517, 994 DOI 10.17487/RFC4517, June 2006, 995 . 997 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 998 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 999 August 2013, . 1001 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1002 DOI 10.17487/RFC7517, May 2015, 1003 . 1005 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1006 DOI 10.17487/RFC7518, May 2015, 1007 . 1009 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1010 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1011 . 1013 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 1014 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 1015 RFC 7591, DOI 10.17487/RFC7591, July 2015, 1016 . 1018 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 1019 RFC 7662, DOI 10.17487/RFC7662, October 2015, 1020 . 1022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1023 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1024 May 2017, . 1026 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 1027 Authorization Server Metadata", RFC 8414, 1028 DOI 10.17487/RFC8414, June 2018, 1029 . 1031 Appendix A. Example "cnf" Claim, Certificate and JWK 1033 For reference, an "x5t#S256" value and the X.509 Certificate from 1034 which it was calculated are provided in the following example 1035 figures. A JWK representation of the certificate's public key along 1036 with the "x5c" member is also provided. 1038 "cnf":{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"} 1040 Figure 5: x5t#S256 Confirmation Claim 1042 -----BEGIN CERTIFICATE----- 1043 MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTAx 1044 ODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGByqG 1045 SM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZjjJ 1046 /Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0EAwID 1047 SQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2eXZOV 1048 bUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY= 1049 -----END CERTIFICATE----- 1051 Figure 6: PEM Encoded Self-Signed Certificate 1053 { 1054 "kty":"EC", 1055 "x":"1yfLHCpXqFjxCeHHHMVDTcLscpb07KUxudBmOMn8C7Q", 1056 "y":"8_coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8", 1057 "crv":"P-256", 1058 "x5c":[ 1059 "MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTA 1060 xODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGBy 1061 qGSM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZ 1062 jjJ/Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0E 1063 AwIDSQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2 1064 eXZOVbUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY=" 1065 ] 1066 } 1068 Figure 7: JSON Web Key 1070 Appendix B. Relationship to Token Binding 1072 OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the 1073 application of Token Binding to the various artifacts and tokens 1074 employed throughout OAuth. That includes binding of an access token 1075 to a Token Binding key, which bears some similarities in motivation 1076 and design to the mutual TLS client certificate-bound access tokens 1077 defined in this document. Both documents define what is often called 1078 a proof-of-possession security mechanism for access tokens, whereby a 1079 client must demonstrate possession of cryptographic keying material 1080 when accessing a protected resource. The details differ somewhat 1081 between the two documents but both have the authorization server bind 1082 the access token that it issues to an asymmetric key pair held by the 1083 client. The client then proves possession of the private key from 1084 that pair with respect to the TLS connection over which the protected 1085 resource is accessed. 1087 Token Binding uses bare keys that are generated on the client, which 1088 avoids many of the difficulties of creating, distributing, and 1089 managing certificates used in this specification. However, at the 1090 time of writing, Token Binding is fairly new and there is relatively 1091 little support for it in available application development platforms 1092 and tooling. Until better support for the underlying core Token 1093 Binding specifications exists, practical implementations of OAuth 2.0 1094 Token Binding are infeasible. Mutual TLS, on the other hand, has 1095 been around for some time and enjoys widespread support in web 1096 servers and development platforms. As a consequence, OAuth 2.0 1097 Mutual TLS Client Authentication and Certificate-Bound Access Tokens 1098 can be built and deployed now using existing platforms and tools. In 1099 the future, the two specifications are likely to be deployed in 1100 parallel for solving similar problems in different environments. 1101 Authorization servers may even support both specifications 1102 simultaneously using different proof-of-possession mechanisms for 1103 tokens issued to different clients. 1105 Appendix C. Acknowledgements 1107 Scott "not Tomlinson" Tomilson and Matt Peterson were involved in 1108 design and development work on a mutual TLS OAuth client 1109 authentication implementation, which predates this document. 1110 Experience and learning from that work informed some of the content 1111 of this document. 1113 This specification was developed within the OAuth Working Group under 1114 the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with 1115 Eric Rescorla and Benjamin Kaduk serving as Security Area Directors. 1116 Additionally, the following individuals contributed ideas, feedback, 1117 and wording that helped shape this specification: Vittorio Bertocci, 1118 Sergey Beryozkin, Ralph Bragg, Sophie Bremer, Vladimir Dzhuvinov, 1119 Samuel Erdtman, Evan Gilman, Leif Johansson, Michael Jones, Phil 1120 Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean Leonard, Kepeng Li, 1121 Neil Madden, James Manger, Jim Manico, Nov Matake, Sascha Preibisch, 1122 Eric Rescorla, Justin Richer, Filip Skokan, Dave Tonge, and Hannes 1123 Tschofenig. 1125 Appendix D. Document(s) History 1127 [[ to be removed by the RFC Editor before publication as an RFC ]] 1129 draft-ietf-oauth-mtls-14 1131 o Editorial clarifications around there being only a single subject 1132 registered/configured per client for the tls_client_auth method. 1133 o Add a brief explanation about how, with tls_client_auth and 1134 self_signed_tls_client_auth, refresh tokens are certificate-bound 1135 indirectly via the client authentication. 1136 o Add mention of refresh tokens in the abstract. 1138 draft-ietf-oauth-mtls-13 1140 o Add an abstract protocol flow and diagram to serve as an overview 1141 of OAuth in general and baseline to describe the various ways in 1142 which the mechanisms defined herein are intended to be used. 1143 o A little bit less of that German influence. 1144 o Rework the TLS references a bit and, in the Terminology section, 1145 clean up the description of what messages are sent and verified in 1146 the handshake to do 'mutual TLS'. 1147 o Move the explanation about "cnf" introspection registration into 1148 the IANA Considerations. 1149 o Add CIBA as an informational reference and additional example of 1150 an OAuth extension that defines an endpoint that utilizes client 1151 authentication. 1152 o Shorten a few of the section titles. 1153 o Add new client metadata values to allow for the use of a SAN in 1154 the PKI MTLS client authentication method. 1155 o Add privacy considerations attempting to discuss the implications 1156 of the client cert being sent in the clear in TLS 1.2. 1157 o Changed the 'Certificate Bound Access Tokens Without Client 1158 Authentication' section to 'Public Clients and Certificate-Bound 1159 Tokens' and moved it up to be a top level section while adding 1160 discussion of binding refresh tokens for public clients. 1161 o Reword/restructure the main PKI method section somewhat to 1162 (hopefully) improve readability. 1163 o Reword/restructure the Self-Signed method section a bit to 1164 (hopefully) make it more comprehensible. 1166 o Reword the AS and RS Implementation Considerations somewhat to 1167 (hopefully) improve readability. 1168 o Clarify that the protected resource obtains the client certificate 1169 used for mutual TLS from its TLS implementation layer. 1170 o Add Security Considerations section about the certificate 1171 thumbprint binding that includes the hash algorithm agility 1172 recommendation. 1173 o Add an "mtls_endpoint_aliases" AS metadata parameter that is a 1174 JSON object containing alternative authorization server endpoints, 1175 which a client intending to do mutual TLS will use in preference 1176 to the conventional endpoints. 1177 o Minor editorial updates. 1179 draft-ietf-oauth-mtls-12 1181 o Add an example certificate, JWK, and confirmation method claim. 1182 o Minor editorial updates based on implementer feedback. 1183 o Additional Acknowledgements. 1185 draft-ietf-oauth-mtls-11 1187 o Editorial updates. 1188 o Mention/reference TLS 1.3 RFC8446 in the TLS Versions and Best 1189 Practices section. 1191 draft-ietf-oauth-mtls-10 1193 o Update draft-ietf-oauth-discovery reference to RFC8414 1195 draft-ietf-oauth-mtls-09 1197 o Change "single certificates" to "self-signed certificates" in the 1198 Abstract 1200 draft-ietf-oauth-mtls-08 1202 o Incorporate clarifications and editorial improvements from Justin 1203 Richer's WGLC review 1204 o Drop the use of the "sender constrained" terminology per WGLC 1205 feedback from Neil Madden (including changing the metadata 1206 parameters from mutual_tls_sender_constrained_access_tokens to 1207 tls_client_certificate_bound_access_tokens) 1208 o Add a new security considerations section on X.509 parsing and 1209 validation per WGLC feedback from Neil Madden and Benjamin Kaduk 1210 o Note that a server can terminate TLS at a load balancer, reverse 1211 proxy, etc. but how the client certificate metadata is securely 1212 communicated to the backend is out of scope per WGLC feedback 1214 o Note that revocation checking is at the discretion of the AS per 1215 WGLC feedback 1216 o Editorial updates and clarifications 1217 o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf- 1218 oauth-token-binding to -06 1219 o Add folks involved in WGLC feedback to the acknowledgements list 1221 draft-ietf-oauth-mtls-07 1223 o Update to use the boilerplate from RFC 8174 1225 draft-ietf-oauth-mtls-06 1227 o Add an appendix section describing the relationship of this 1228 document to OAuth Token Binding as requested during the the 1229 Singapore meeting https://datatracker.ietf.org/doc/minutes- 1230 100-oauth/ 1231 o Add an explicit note that the implicit flow is not supported for 1232 obtaining certificate bound access tokens as discussed at the 1233 Singapore meeting https://datatracker.ietf.org/doc/minutes- 1234 100-oauth/ 1235 o Add/incorporate text to the Security Considerations on Certificate 1236 Spoofing as suggested https://mailarchive.ietf.org/arch/msg/oauth/ 1237 V26070X-6OtbVSeUz_7W2k94vCo 1238 o Changed the title to be more descriptive 1239 o Move the Security Considerations section to before the IANA 1240 Considerations 1241 o Elaborated on certificate-bound access tokens a bit more in the 1242 Abstract 1243 o Update draft-ietf-oauth-discovery reference to -08 1245 draft-ietf-oauth-mtls-05 1247 o Editorial fixes 1249 draft-ietf-oauth-mtls-04 1251 o Change the name of the 'Public Key method' to the more accurate 1252 'Self-Signed Certificate method' and also change the associated 1253 authentication method metadata value to 1254 "self_signed_tls_client_auth". 1255 o Removed the "tls_client_auth_root_dn" client metadata field as 1256 discussed in https://mailarchive.ietf.org/arch/msg/oauth/ 1257 swDV2y0be6o8czGKQi1eJV-g8qc 1258 o Update draft-ietf-oauth-discovery reference to -07 1259 o Clarify that MTLS client authentication isn't exclusive to the 1260 token endpoint and can be used with other endpoints, e.g. RFC 1261 7009 revocation and 7662 introspection, that utilize client 1262 authentication as discussed in 1263 https://mailarchive.ietf.org/arch/msg/oauth/ 1264 bZ6mft0G7D3ccebhOxnEYUv4puI 1265 o Reorganize the document somewhat in an attempt to more clearly 1266 make a distinction between mTLS client authentication and 1267 certificate-bound access tokens as well as a more clear 1268 delineation between the two (PKI/Public key) methods for client 1269 authentication 1270 o Editorial fixes and clarifications 1272 draft-ietf-oauth-mtls-03 1274 o Introduced metadata and client registration parameter to publish 1275 and request support for mutual TLS sender constrained access 1276 tokens 1277 o Added description of two methods of binding the cert and client, 1278 PKI and Public Key. 1279 o Indicated that the "tls_client_auth" authentication method is for 1280 the PKI method and introduced "pub_key_tls_client_auth" for the 1281 Public Key method 1282 o Added implementation considerations, mainly regarding TLS stack 1283 configuration and trust chain validation, as well as how to to do 1284 binding of access tokens to a TLS client certificate for public 1285 clients, and considerations around certificate-bound access tokens 1286 o Added new section to security considerations on cert spoofing 1287 o Add text suggesting that a new cnf member be defined in the 1288 future, if hash function(s) other than SHA-256 need to be used for 1289 certificate thumbprints 1291 draft-ietf-oauth-mtls-02 1293 o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ 1294 U46UMEh8XIOQnvXY9pHFq1MKPns 1295 o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is 1296 better than "Mutual TLS Profiles for OAuth Clients"). 1298 draft-ietf-oauth-mtls-01 1300 o Added more explicit details of using RFC 7662 token introspection 1301 with mutual TLS sender constrained access tokens. 1302 o Added an IANA OAuth Token Introspection Response Registration 1303 request for "cnf". 1304 o Specify that tls_client_auth_subject_dn and 1305 tls_client_auth_root_dn are RFC 4514 String Representation of 1306 Distinguished Names. 1307 o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. 1308 o Changed the text in the Section 3 to not be specific about using a 1309 hash of the cert. 1311 o Changed the abbreviated title to 'OAuth Mutual TLS' (previously 1312 was the acronym MTLSPOC). 1314 draft-ietf-oauth-mtls-00 1316 o Created the initial working group version from draft-campbell- 1317 oauth-mtls 1319 draft-campbell-oauth-mtls-01 1321 o Fix some typos. 1322 o Add to the acknowledgements list. 1324 draft-campbell-oauth-mtls-00 1326 o Add a Mutual TLS sender constrained protected resource access 1327 method and a x5t#S256 cnf method for JWT access tokens (concepts 1328 taken in part from draft-sakimura-oauth-jpop-04). 1329 o Fixed "token_endpoint_auth_methods_supported" to 1330 "token_endpoint_auth_method" for client metadata. 1331 o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" 1332 client metadata parameters and mention using "jwks_uri" or "jwks". 1333 o Say that the authentication method is determined by client policy 1334 regardless of whether the client was dynamically registered or 1335 statically configured. 1336 o Expand acknowledgements to those that participated in discussions 1337 around draft-campbell-oauth-tls-client-auth-00 1338 o Add Nat Sakimura and Torsten Lodderstedt to the author list. 1340 draft-campbell-oauth-tls-client-auth-00 1342 o Initial draft. 1344 Authors' Addresses 1346 Brian Campbell 1347 Ping Identity 1349 Email: brian.d.campbell@gmail.com 1351 John Bradley 1352 Yubico 1354 Email: ve7jtb@ve7jtb.com 1355 URI: http://www.thread-safe.com/ 1356 Nat Sakimura 1357 Nomura Research Institute 1359 Email: n-sakimura@nri.co.jp 1360 URI: https://nat.sakimura.org/ 1362 Torsten Lodderstedt 1363 YES.com AG 1365 Email: torsten@lodderstedt.net