idnits 2.17.1 draft-ietf-oauth-mtls-15.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 (July 3, 2019) is 1757 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-08) exists of draft-ietf-oauth-token-binding-06 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: January 4, 2020 Yubico 6 N. Sakimura 7 Nomura Research Institute 8 T. Lodderstedt 9 YES.com AG 10 July 3, 2019 12 OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound 13 Access Tokens 14 draft-ietf-oauth-mtls-15 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 January 4, 2020. 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 . . . . . . . . . . . . . . 7 69 2.1.2. Client Registration Metadata . . . . . . . . . . . . 7 70 2.2. Self-Signed Certificate Mutual TLS Method . . . . . . . . 8 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 . . . . . . 9 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 . . . . . . . . . 12 79 5. Metadata for Mutual TLS Endpoint Aliases . . . . . . . . . . 12 80 6. Implementation Considerations . . . . . . . . . . . . . . . . 14 81 6.1. Authorization Server . . . . . . . . . . . . . . . . . . 14 82 6.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 15 83 6.3. Certificate Expiration and Bound Access Tokens . . . . . 15 84 6.4. Implicit Grant Unsupported . . . . . . . . . . . . . . . 15 85 6.5. TLS Termination . . . . . . . . . . . . . . . . . . . . . 16 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 7.1. Certificate-Bound Refresh Tokens . . . . . . . . . . . . 16 88 7.2. Certificate Thumbprint Binding . . . . . . . . . . . . . 16 89 7.3. TLS Versions and Best Practices . . . . . . . . . . . . . 17 90 7.4. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 17 91 7.5. X.509 Certificate Parsing and Validation Complexity . . . 17 92 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 9.1. JWT Confirmation Methods Registration . . . . . . . . . . 18 95 9.2. Authorization Server Metadata Registration . . . . . . . 18 96 9.3. Token Endpoint Authentication Method Registration . . . . 19 97 9.4. Token Introspection Response Registration . . . . . . . . 19 98 9.5. Dynamic Client Registration Metadata Registration . . . . 20 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 101 10.2. Informative References . . . . . . . . . . . . . . . . . 22 102 Appendix A. Example "cnf" Claim, Certificate and JWK . . . . . . 23 103 Appendix B. Relationship to Token Binding . . . . . . . . . . . 24 104 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 25 105 Appendix D. Document(s) History . . . . . . . . . . . . . . . . 25 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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 Additional client metadata parameters are introduced by this document 202 in support of certificate-bound access tokens and mutual TLS client 203 authentication. The authorization server can obtain client metadata 204 via the Dynamic Client Registration Protocol [RFC7591], which defines 205 mechanisms for dynamically registering OAuth 2.0 client metadata with 206 authorization servers. Also the metadata defined by RFC7591, and 207 registered extensions to it, imply a general data model for clients 208 that is useful for authorization server implementations even when the 209 Dynamic Client Registration Protocol isn't in play. Such 210 implementations will typically have some sort of user interface 211 available for managing client configuration. 213 1.1. Requirements Notation and Conventions 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in BCP 218 14 [RFC2119] [RFC8174] when, and only when, they appear in all 219 capitals, as shown here. 221 1.2. Terminology 223 Throughout this document the term "mutual TLS" refers to the process 224 whereby a client presents its X.509 certificate and proves possession 225 of the corresponding private key to a server when negotiating a TLS 226 session. In contemporary versions of TLS [RFC8446] [RFC5246] this 227 requires that the client send the Certificate and CertificateVerify 228 messages during the handshake and for the server to verify the 229 CertificateVerify and Finished messages. 231 2. Mutual TLS for OAuth Client Authentication 233 This section defines, as an extension of OAuth 2.0, Section 2.3 234 [RFC6749], two distinct methods of using mutual TLS X.509 client 235 certificates as client credentials. The requirement of mutual TLS 236 for client authentication is determined by the authorization server 237 based on policy or configuration for the given client (regardless of 238 whether the client was dynamically registered, statically configured, 239 or otherwise established). 241 In order to utilize TLS for OAuth client authentication, the TLS 242 connection between the client and the authorization server MUST have 243 been established or reestablished with mutual TLS X.509 certificate 244 authentication (i.e. the Client Certificate and Certificate Verify 245 messages are sent during the TLS Handshake). 247 For all requests to the authorization server utilizing mutual TLS 248 client authentication, the client MUST include the "client_id" 249 parameter, described in OAuth 2.0, Section 2.2 [RFC6749]. The 250 presence of the "client_id" parameter enables the authorization 251 server to easily identify the client independently from the content 252 of the certificate. The authorization server can locate the client 253 configuration using the client identifier and check the certificate 254 presented in the TLS Handshake against the expected credentials for 255 that client. The authorization server MUST enforce the binding 256 between client and certificate as described in either Section 2.1 or 257 Section 2.2 below. If the presented certificate doesn't match that 258 which is expected for the given "client_id", the authorization server 259 returns a normal OAuth 2.0 error response per Section 5.2 of RFC6749 260 [RFC6749] with the "invalid_client" error code to indicate failed 261 client authentication. 263 2.1. PKI Mutual TLS Method 265 The PKI (public key infrastructure) method of mutual TLS OAuth client 266 authentication adheres to the way in which X.509 certificates are 267 traditionally used for authentication. It relies on a validated 268 certificate chain [RFC5280] and a single subject distinguished name 269 (DN) or a single subject alternative name (SAN) to authenticate the 270 client. Only one subject name value of any type is used for each 271 client. The TLS handshake is utilized to validate the client's 272 possession of the private key corresponding to the public key in the 273 certificate and to validate the corresponding certificate chain. The 274 client is successfully authenticated if the subject information in 275 the certificate matches the single expected subject configured or 276 registered for that particular client (note that a predictable 277 treatment of DN values, such as the distinguishedNameMatch rule from 278 [RFC4517], is needed in comparing the certificate's subject DN to the 279 client's registered DN). Revocation checking is possible with the 280 PKI method but if and how to check a certificate's revocation status 281 is a deployment decision at the discretion of the authorization 282 server. Clients can rotate their X.509 certificates without the need 283 to modify the respective authentication data at the authorization 284 server by obtaining a new certificate with the same subject from a 285 trusted certificate authority (CA). 287 2.1.1. PKI Method Metadata Value 289 For the PKI method of mutual TLS client authentication, this 290 specification defines and registers the following authentication 291 method metadata value into the "OAuth Token Endpoint Authentication 292 Methods" registry [IANA.OAuth.Parameters]. 294 tls_client_auth 295 Indicates that client authentication to the authorization server 296 will occur with mutual TLS utilizing the PKI method of associating 297 a certificate to a client. 299 2.1.2. Client Registration Metadata 301 In order to convey the expected subject of the certificate, the 302 following metadata parameters are introduced for the OAuth 2.0 303 Dynamic Client Registration Protocol [RFC7591] in support of the PKI 304 method of mutual TLS client authentication. A client using the 305 "tls_client_auth" authentication method MUST use exactly one of the 306 below metadata parameters to indicate the certificate subject value 307 that the authorization server is to expect when authenticating the 308 respective client. 310 tls_client_auth_subject_dn 311 An [RFC4514] string representation of the expected subject 312 distinguished name of the certificate, which the OAuth client will 313 use in mutual TLS authentication. 315 tls_client_auth_san_dns 316 A string containing the value of an expected dNSName SAN entry in 317 the certificate, which the OAuth client will use in mutual TLS 318 authentication. 320 tls_client_auth_san_uri 321 A string containing the value of an expected 322 uniformResourceIdentifier SAN entry in the certificate, which the 323 OAuth client will use in mutual TLS authentication. 325 tls_client_auth_san_ip 326 A string representation of an IP address in either dotted decimal 327 notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as 328 defined in [RFC4291] section 2.2) that is expected to be present 329 as an iPAddress SAN entry in the certificate, which the OAuth 330 client will use in mutual TLS authentication. 332 tls_client_auth_san_email 333 A string containing the value of an expected rfc822Name SAN entry 334 in the certificate, which the OAuth client will use in mutual TLS 335 authentication. 337 2.2. Self-Signed Certificate Mutual TLS Method 339 This method of mutual TLS OAuth client authentication is intended to 340 support client authentication using self-signed certificates. As a 341 prerequisite, the client registers its X.509 certificates (using 342 "jwks" defined in [RFC7591]) or a reference to a trusted source for 343 its X.509 certificates (using "jwks_uri" from [RFC7591]) with the 344 authorization server. During authentication, TLS is utilized to 345 validate the client's possession of the private key corresponding to 346 the public key presented within the certificate in the respective TLS 347 handshake. In contrast to the PKI method, the client's certificate 348 chain is not validated by the server in this case. The client is 349 successfully authenticated if the certificate that it presented 350 during the handshake matches one of the certificates configured or 351 registered for that particular client. The Self-Signed Certificate 352 method allows the use of mutual TLS to authenticate clients without 353 the need to maintain a PKI. When used in conjunction with a 354 "jwks_uri" for the client, it also allows the client to rotate its 355 X.509 certificates without the need to change its respective 356 authentication data directly with the authorization server. 358 2.2.1. Self-Signed Method Metadata Value 360 For the Self-Signed Certificate method of mutual TLS client 361 authentication, this specification defines and registers the 362 following authentication method metadata value into the "OAuth Token 363 Endpoint Authentication Methods" registry [IANA.OAuth.Parameters]. 365 self_signed_tls_client_auth 366 Indicates that client authentication to the authorization server 367 will occur using mutual TLS with the client utilizing a self- 368 signed certificate. 370 2.2.2. Client Registration Metadata 372 For the Self-Signed Certificate method of binding a certificate with 373 a client using mutual TLS client authentication, the existing 374 "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to 375 convey the client's certificates via JSON Web Key (JWK) in a JWK Set 376 (JWKS) [RFC7517]. The "jwks" metadata parameter is a JWK Set 377 containing the client's public keys as an array of JWKs while the 378 "jwks_uri" parameter is a URL that references a client's JWK Set. A 379 certificate is represented with the "x5c" parameter of an individual 380 JWK within the set. Note that the members of the JWK representing 381 the public key (e.g. "n" and "e" for RSA, "x" and "y" for EC) are 382 required parameters per [RFC7518] so will be present even though they 383 are not utilized in this context. Also note that that Section 4.7 of 384 [RFC7517] requires that the key in the first certificate of the "x5c" 385 parameter match the public key represented by those other members of 386 the JWK. 388 3. Mutual TLS Client Certificate-Bound Access Tokens 390 When mutual TLS is used by the client on the connection to the token 391 endpoint, the authorization server is able to bind the issued access 392 token to the client certificate. Such a binding is accomplished by 393 associating the certificate with the token in a way that can be 394 accessed by the protected resource, such as embedding the certificate 395 hash in the issued access token directly, using the syntax described 396 in Section 3.1, or through token introspection as described in 397 Section 3.2. Binding the access token to the client certificate in 398 that fashion has the benefit of decoupling that binding from the 399 client's authentication with the authorization server, which enables 400 mutual TLS during protected resource access to serve purely as a 401 proof-of-possession mechanism. Other methods of associating a 402 certificate with an access token are possible, per agreement by the 403 authorization server and the protected resource, but are beyond the 404 scope of this specification. 406 The client makes protected resource requests as described in 407 [RFC6750], however, those requests MUST be made over a mutually 408 authenticated TLS connection using the same certificate that was used 409 for mutual TLS at the token endpoint. 411 The protected resource MUST obtain, from its TLS implementation 412 layer, the client certificate used for mutual TLS and MUST verify 413 that the certificate matches the certificate associated with the 414 access token. If they do not match, the resource access attempt MUST 415 be rejected with an error per [RFC6750] using an HTTP 401 status code 416 and the "invalid_token" error code. 418 Metadata to convey server and client capabilities for mutual TLS 419 client certificate-bound access tokens is defined in Section 3.3 and 420 Section 3.4 respectively. 422 3.1. JWT Certificate Thumbprint Confirmation Method 424 When access tokens are represented as JSON Web Tokens (JWT)[RFC7519], 425 the certificate hash information SHOULD be represented using the 426 "x5t#S256" confirmation method member defined herein. 428 To represent the hash of a certificate in a JWT, this specification 429 defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" 430 for the X.509 Certificate SHA-256 Thumbprint. The value of the 431 "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash 432 (a.k.a. thumbprint, fingerprint or digest) of the DER encoding [X690] 433 of the X.509 certificate [RFC5280]. The base64url-encoded value MUST 434 omit all trailing pad '=' characters and MUST NOT include any line 435 breaks, whitespace, or other additional characters. 437 The following is an example of a JWT payload containing an "x5t#S256" 438 certificate thumbprint confirmation method. The new JWT content 439 introduced by this specification is the "cnf" confirmation method 440 claim at the bottom of the example that has the "x5t#S256" 441 confirmation method member containing the value that is the hash of 442 the client certificate to which the access token is bound. 444 { 445 "iss": "https://server.example.com", 446 "sub": "ty.webb@example.com", 447 "exp": 1493726400, 448 "nbf": 1493722800, 449 "cnf":{ 450 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 451 } 452 } 454 Figure 2: Example JWT Claims Set with an X.509 Certificate Thumbprint 455 Confirmation Method 457 3.2. Confirmation Method for Token Introspection 459 OAuth 2.0 Token Introspection [RFC7662] defines a method for a 460 protected resource to query an authorization server about the active 461 state of an access token as well as to determine meta-information 462 about the token. 464 For a mutual TLS client certificate-bound access token, the hash of 465 the certificate to which the token is bound is conveyed to the 466 protected resource as meta-information in a token introspection 467 response. The hash is conveyed using the same "cnf" with "x5t#S256" 468 member structure as the certificate SHA-256 thumbprint confirmation 469 method, described in Section 3.1, as a top-level member of the 470 introspection response JSON. The protected resource compares that 471 certificate hash to a hash of the client certificate used for mutual 472 TLS authentication and rejects the request, if they do not match. 474 The following is an example of an introspection response for an 475 active token with an "x5t#S256" certificate thumbprint confirmation 476 method. The new introspection response content introduced by this 477 specification is the "cnf" confirmation method at the bottom of the 478 example that has the "x5t#S256" confirmation method member containing 479 the value that is the hash of the client certificate to which the 480 access token is bound. 482 HTTP/1.1 200 OK 483 Content-Type: application/json 485 { 486 "active": true, 487 "iss": "https://server.example.com", 488 "sub": "ty.webb@example.com", 489 "exp": 1493726400, 490 "nbf": 1493722800, 491 "cnf":{ 492 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 493 } 494 } 496 Figure 3: Example Introspection Response for a Certificate-Bound 497 Access Token 499 3.3. Authorization Server Metadata 501 This document introduces the following new authorization server 502 metadata parameter to signal the server's capability to issue 503 certificate bound access tokens: 505 tls_client_certificate_bound_access_tokens 506 OPTIONAL. Boolean value indicating server support for mutual TLS 507 client certificate-bound access tokens. If omitted, the default 508 value is "false". 510 3.4. Client Registration Metadata 512 The following new client metadata parameter is introduced to convey 513 the client's intention to use certificate bound access tokens: 515 tls_client_certificate_bound_access_tokens 516 OPTIONAL. Boolean value used to indicate the client's intention 517 to use mutual TLS client certificate-bound access tokens. If 518 omitted, the default value is "false". 520 4. Public Clients and Certificate-Bound Tokens 522 Mutual TLS OAuth client authentication and certificate-bound access 523 tokens can be used independently of each other. Use of certificate- 524 bound access tokens without mutual TLS OAuth client authentication, 525 for example, is possible in support of binding access tokens to a TLS 526 client certificate for public clients (those without authentication 527 credentials associated with the "client_id"). The authorization 528 server would configure the TLS stack in the same manner as for the 529 Self-Signed Certificate method such that it does not verify that the 530 certificate presented by the client during the handshake is signed by 531 a trusted CA. Individual instances of a client would create a self- 532 signed certificate for mutual TLS with both the authorization server 533 and resource server. The authorization server would not use the 534 mutual TLS certificate to authenticate the client at the OAuth layer 535 but would bind the issued access token to that certificate, for which 536 the client has proven possession of the corresponding private key. 537 The access token is then bound to the certificate and can only be 538 used by the client possessing the certificate and corresponding 539 private key and utilizing them to negotiate mutual TLS on connections 540 to the resource server. When the authorization server issues a 541 refresh token to such a client, it SHOULD also bind the refresh token 542 to the respective certificate. And check the binding when the 543 refresh token is presented to get new access tokens. The 544 implementation details of the binding the refresh token are at the 545 discretion of the authorization server. 547 5. Metadata for Mutual TLS Endpoint Aliases 549 The process of negotiating client certificate-based mutual TLS 550 involves a TLS server requesting a certificate from the TLS client 551 (the client does not provide one unsolicited). Although a server can 552 be configured such that client certificates are optional, meaning 553 that the connection is allowed to continue when the client does not 554 provide a certificate, the act of a server requesting a certificate 555 can result in undesirable behavior from some clients. This is 556 particularly true of web browsers as TLS clients, which will 557 typically present the end-user with an intrusive certificate 558 selection interface when the server requests a certificate. 560 Authorization servers supporting both clients using mutual TLS and 561 conventional clients MAY chose to isolate the server side mutual TLS 562 behaviour to only clients intending to do mutual TLS, thus avoiding 563 any undesirable effects it might have on conventional clients. The 564 following authorization server metadata parameter is introduced to 565 facilitate such separation: 567 mtls_endpoint_aliases 568 OPTIONAL. A JSON object containing alternative authorization 569 server endpoints that, when present, an OAuth client intending to 570 do mutual TLS uses in preference to the conventional endpoints. 571 The parameter value itself consists of one or more endpoint 572 parameters, such as "token_endpoint", "revocation_endpoint", 573 "introspection_endpoint", etc., conventionally defined for the 574 top-level of authorization server metadata. An OAuth client 575 intending to do mutual TLS (for OAuth client authentication and/or 576 to acquire or use certificate-bound tokens) when making a request 577 directly to the authorization server MUST use the alias URL of the 578 endpoint within the "mtls_endpoint_aliases", when present, in 579 preference to the endpoint URL of the same name at top-level of 580 metadata. When an endpoint is not present in 581 "mtls_endpoint_aliases", then the client uses the conventional 582 endpoint URL defined at the top-level of the authorization server 583 metadata. Metadata parameters within "mtls_endpoint_aliases" that 584 do not define endpoints to which an OAuth client makes a direct 585 request have no meaning and SHOULD be ignored. 587 Below is an example of an authorization server metadata document with 588 the "mtls_endpoint_aliases" parameter, which indicates aliases for 589 the token, revocation, and introspection endpoints that an OAuth 590 client intending to do mutual TLS would in preference to the 591 conventional token, revocation, and introspection endpoints. Note 592 that the endpoints in "mtls_endpoint_aliases" use a different host 593 than their conventional counterparts, which allows the authorization 594 server (via SNI or actual distinct hosts) to differentiate its TLS 595 behavior as appropriate. 597 { 598 "issuer": "https://server.example.com", 599 "authorization_endpoint": "https://server.example.com/authz", 600 "token_endpoint": "https://server.example.com/token", 601 "introspection_endpoint": "https://server.example.com/introspect", 602 "revocation_endpoint": "https://server.example.com/revo", 603 "jwks_uri": "https://server.example.com/jwks", 604 "response_types_supported": ["code"], 605 "response_modes_supported": ["fragment","query","form_post"], 606 "grant_types_supported": ["authorization_code", "refresh_token"], 607 "token_endpoint_auth_methods_supported": 608 ["tls_client_auth","client_secret_basic","none"], 609 "tls_client_certificate_bound_access_tokens": true 610 "mtls_endpoint_aliases": { 611 "token_endpoint": "https://mtls.example.com/token", 612 "revocation_endpoint": "https://mtls.example.com/revo", 613 "introspection_endpoint": "https://mtls.example.com/introspect" 614 } 615 } 617 Figure 4: Example Authorization Server Metadata with Mutual TLS 618 Endpoint Aliases 620 6. Implementation Considerations 622 6.1. Authorization Server 624 The authorization server needs to set up its TLS configuration 625 appropriately for the OAuth client authentication methods it 626 supports. 628 An authorization server that supports mutual TLS client 629 authentication and other client authentication methods or public 630 clients in parallel would make mutual TLS optional (i.e. allowing a 631 handshake to continue after the server requests a client certificate 632 but the client does not send one). 634 In order to support the Self-Signed Certificate method, the 635 authorization server would configure the TLS stack in such a way that 636 it does not verify whether the certificate presented by the client 637 during the handshake is signed by a trusted CA certificate. 639 As described in Section 3, the authorization server binds the issued 640 access token to the TLS client certificate, which means that it will 641 only issue certificate-bound tokens for a certificate which the 642 client has proven possession of the corresponding private key. 644 The authorization server may also consider hosting the token 645 endpoint, and other endpoints requiring client authentication, on a 646 separate host name or port in order to prevent unintended impact on 647 the TLS behavior of its other endpoints, e.g. the authorization 648 endpoint. As described in Section 5, it may further isolate any 649 potential impact of the server requesting client certificates by 650 offering a distinct set of endpoints on a separate host or port, 651 which are aliases for the originals that a client intending to do 652 mutual TLS will use in preference to the conventional endpoints. 654 6.2. Resource Server 656 OAuth divides the roles and responsibilities such that the resource 657 server relies on the authorization server to perform client 658 authentication and obtain resource owner (end-user) authorization. 659 The resource server makes authorization decisions based on the access 660 token presented by the client but does not directly authenticate the 661 client per se. The manner in which an access token is bound to the 662 client certificate decouples it from the specific method that the 663 client used to authenticate with the authorization server. Mutual 664 TLS during protected resource access can therefore serve purely as a 665 proof-of-possession mechanism. As such, it is not necessary for the 666 resource server to validate the trust chain of the client's 667 certificate in any of the methods defined in this document. The 668 resource server would therefore configure the TLS stack in a way that 669 it does not verify whether the certificate presented by the client 670 during the handshake is signed by a trusted CA certificate. 672 6.3. Certificate Expiration and Bound Access Tokens 674 As described in Section 3, an access token is bound to a specific 675 client certificate, which means that the same certificate must be 676 used for mutual TLS on protected resource access. It also implies 677 that access tokens are invalidated when a client updates the 678 certificate, which can be handled similar to expired access tokens 679 where the client requests a new access token (typically with a 680 refresh token) and retries the protected resource request. 682 6.4. Implicit Grant Unsupported 684 This document describes binding an access token to the client 685 certificate presented on the TLS connection from the client to the 686 authorization server's token endpoint, however, such binding of 687 access tokens issued directly from the authorization endpoint via the 688 implicit grant flow is explicitly out of scope. End users interact 689 directly with the authorization endpoint using a web browser and the 690 use of client certificates in user's browsers bring operational and 691 usability issues, which make it undesirable to support certificate- 692 bound access tokens issued in the implicit grant flow. 693 Implementations wanting to employ certificate-bound access tokens 694 should utilize grant types that involve the client making an access 695 token request directly to the token endpoint (e.g. the authorization 696 code and refresh token grant types). 698 6.5. TLS Termination 700 An authorization server or resource server MAY choose to terminate 701 TLS connections at a load balancer, reverse proxy, or other network 702 intermediary. How the client certificate metadata is securely 703 communicated between the intermediary and the application server in 704 this case is out of scope of this specification. 706 7. Security Considerations 708 7.1. Certificate-Bound Refresh Tokens 710 The OAuth 2.0 Authorization Framework [RFC6749] requires that an 711 authorization server bind refresh tokens to the client to which they 712 where issued and that confidential clients (those having established 713 authentication credentials with the authorization server) 714 authenticate to the AS when presenting a refresh token. As a result, 715 refresh tokens are indirectly certificate-bound when issued to 716 clients utilizing the "tls_client_auth" or 717 "self_signed_tls_client_auth" methods of client authentication. 718 Section 4 describes certificate-bound refresh tokens issued to public 719 clients (those without authentication credentials associated with the 720 "client_id"). 722 7.2. Certificate Thumbprint Binding 724 The binding between the certificate and access token specified in 725 Section 3.1 uses a cryptographic hash of the certificate. It relies 726 on the hash function having sufficient preimage and second-preimage 727 resistance so as to make it computationally infeasible to find or 728 create another certificate that produces to the same hash output 729 value. The SHA-256 hash function was used because it meets the 730 aforementioned requirement while being widely available. If, in the 731 future, certificate thumbprints need to be computed using hash 732 function(s) other than SHA-256, it is suggested that additional 733 related JWT confirmation methods members be defined for that purpose 734 and registered in the IANA "JWT Confirmation Methods" registry 735 [IANA.JWT.Claims] for JWT "cnf" member values. 737 7.3. TLS Versions and Best Practices 739 In the abstract this document is applicable with any TLS version 740 supporting certificate-based client authentication. Both TLS 1.3 741 [RFC8446] and TLS 1.2 [RFC5246] are cited herein because, at the time 742 of writing, 1.3 is the newest version while 1.2 is the most widely 743 deployed. General implementation and security considerations for 744 TLS, including version recommendations, can be found in [BCP195]. 746 7.4. X.509 Certificate Spoofing 748 If the PKI method of client authentication is used, an attacker could 749 try to impersonate a client using a certificate with the same subject 750 (DN or SAN) but issued by a different CA, which the authorization 751 server trusts. To cope with that threat, the authorization server 752 SHOULD only accept as trust anchors a limited number of CAs whose 753 certificate issuance policy meets its security requirements. There 754 is an assumption then that the client and server agree on the set of 755 trust anchors that the server uses to create and validate the 756 certificate chain. Without this assumption the use of a subject to 757 identify the client certificate would open the server up to 758 certificate spoofing attacks. 760 7.5. X.509 Certificate Parsing and Validation Complexity 762 Parsing and validation of X.509 certificates and certificate chains 763 is complex and implementation mistakes have previously exposed 764 security vulnerabilities. Complexities of validation include (but 765 are not limited to) [CX5P] [DCW] [RFC5280]: 767 o checking of Basic Constraints, basic and extended Key Usage 768 constraints, validity periods, and critical extensions; 770 o handling of null-terminator bytes and non-canonical string 771 representations in subject names; 773 o handling of wildcard patterns in subject names; 775 o recursive verification of certificate chains and checking 776 certificate revocation. 778 For these reasons, implementors SHOULD use an established and well- 779 tested X.509 library (such as one used by an established TLS library) 780 for validation of X.509 certificate chains and SHOULD NOT attempt to 781 write their own X.509 certificate validation procedures. 783 8. Privacy Considerations 785 In TLS versions prior to 1.3, the client's certificate is sent 786 unencrypted in the initial handshake and can potentially be used by 787 third parties to monitor, track, and correlate client activity. This 788 is likely of little concern for clients that act on behalf of a 789 significant number of end-users because individual user activity will 790 not be discernible amidst the client activity as a whole. However, 791 clients that act on behalf of a single end-user, such as a native 792 application on a mobile device, should use TLS version 1.3 whenever 793 possible or consider the potential privacy implications of using 794 mutual TLS on earlier versions. 796 9. IANA Considerations 798 9.1. JWT Confirmation Methods Registration 800 This specification requests registration of the following value in 801 the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for 802 JWT "cnf" member values established by [RFC7800]. 804 o Confirmation Method Value: "x5t#S256" 805 o Confirmation Method Description: X.509 Certificate SHA-256 806 Thumbprint 807 o Change Controller: IESG 808 o Specification Document(s): Section 3.1 of [[ this specification ]] 810 9.2. Authorization Server Metadata Registration 812 This specification requests registration of the following value in 813 the IANA "OAuth Authorization Server Metadata" registry 814 [IANA.OAuth.Parameters] established by [RFC8414]. 816 o Metadata Name: "tls_client_certificate_bound_access_tokens" 817 o Metadata Description: Indicates authorization server support for 818 mutual TLS client certificate-bound access tokens. 819 o Change Controller: IESG 820 o Specification Document(s): Section 3.3 of [[ this specification ]] 822 o Metadata Name: "mtls_endpoint_aliases" 823 o Metadata Description: JSON object containing alternative 824 authorization server endpoints, which a client intending to do 825 mutual TLS will use in preference to the conventional endpoints. 826 o Change Controller: IESG 827 o Specification Document(s): Section 5 of [[ this specification ]] 829 9.3. Token Endpoint Authentication Method Registration 831 This specification requests registration of the following value in 832 the IANA "OAuth Token Endpoint Authentication Methods" registry 833 [IANA.OAuth.Parameters] established by [RFC7591]. 835 o Token Endpoint Authentication Method Name: "tls_client_auth" 836 o Change Controller: IESG 837 o Specification Document(s): Section 2.1.1 of [[ this specification 838 ]] 840 o Token Endpoint Authentication Method Name: 841 "self_signed_tls_client_auth" 842 o Change Controller: IESG 843 o Specification Document(s): Section 2.2.1 of [[ this specification 844 ]] 846 9.4. Token Introspection Response Registration 848 Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] 849 defined the "cnf" (confirmation) claim, which enables confirmation 850 key information to be carried in a JWT. However, the same proof-of- 851 possession semantics are also useful for introspected access tokens 852 whereby the protected resource obtains the confirmation key data as 853 meta-information of a token introspection response and uses that 854 information in verifying proof-of-possession. Therefore this 855 specification defines and registers proof-of-possession semantics for 856 OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. 857 When included as a top-level member of an OAuth token introspection 858 response, "cnf" has the same semantics and format as the claim of the 859 same name defined in [RFC7800]. While this specification only 860 explicitly uses the "x5t#S256" confirmation method member (see 861 Section 3.2), it needs to define and register the higher level "cnf" 862 structure as an introspection response member in order to define and 863 use the more specific certificate thumbprint confirmation method. 865 As such, this specification requests registration of the following 866 value in the IANA "OAuth Token Introspection Response" registry 867 [IANA.OAuth.Parameters] established by [RFC7662]. 869 o Claim Name: "cnf" 870 o Claim Description: Confirmation 871 o Change Controller: IESG 872 o Specification Document(s): [RFC7800] and [[ this specification ]] 874 9.5. Dynamic Client Registration Metadata Registration 876 This specification requests registration of the following client 877 metadata definitions in the IANA "OAuth Dynamic Client Registration 878 Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: 880 o Client Metadata Name: "tls_client_certificate_bound_access_tokens" 881 o Client Metadata Description: Indicates the client's intention to 882 use mutual TLS client certificate-bound access tokens. 883 o Change Controller: IESG 884 o Specification Document(s): Section 3.4 of [[ this specification ]] 886 o Client Metadata Name: "tls_client_auth_subject_dn" 887 o Client Metadata Description: String value specifying the expected 888 subject DN of the client certificate. 889 o Change Controller: IESG 890 o Specification Document(s): Section 2.1.2 of [[ this specification 891 ]] 893 o Client Metadata Name: "tls_client_auth_san_dns" 894 o Client Metadata Description: String value specifying the expected 895 dNSName SAN entry in the client certificate. 896 o Change Controller: IESG 897 o Specification Document(s): Section 2.1.2 of [[ this specification 898 ]] 900 o Client Metadata Name: "tls_client_auth_san_uri" 901 o Client Metadata Description: String value specifying the expected 902 uniformResourceIdentifier SAN entry in the client certificate. 903 o Change Controller: IESG 904 o Specification Document(s): Section 2.1.2 of [[ this specification 905 ]] 907 o Client Metadata Name: "tls_client_auth_san_ip" 908 o Client Metadata Description: String value specifying the expected 909 iPAddress SAN entry in the client certificate. 910 o Change Controller: IESG 911 o Specification Document(s): Section 2.1.2 of [[ this specification 912 ]] 914 o Client Metadata Name: "tls_client_auth_san_email" 915 o Client Metadata Description: String value specifying the expected 916 rfc822Name SAN entry in the client certificate. 917 o Change Controller: IESG 918 o Specification Document(s): Section 2.1.2 of [[ this specification 919 ]] 921 10. References 923 10.1. Normative References 925 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 926 "Recommendations for Secure Use of Transport Layer 927 Security (TLS) and Datagram Transport Layer Security 928 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 929 2015, . 931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 932 Requirement Levels", BCP 14, RFC 2119, 933 DOI 10.17487/RFC2119, March 1997, 934 . 936 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 937 (LDAP): String Representation of Distinguished Names", 938 RFC 4514, DOI 10.17487/RFC4514, June 2006, 939 . 941 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 942 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 943 . 945 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 946 (TLS) Protocol Version 1.2", RFC 5246, 947 DOI 10.17487/RFC5246, August 2008, 948 . 950 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 951 Housley, R., and W. Polk, "Internet X.509 Public Key 952 Infrastructure Certificate and Certificate Revocation List 953 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 954 . 956 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 957 RFC 6749, DOI 10.17487/RFC6749, October 2012, 958 . 960 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 961 Framework: Bearer Token Usage", RFC 6750, 962 DOI 10.17487/RFC6750, October 2012, 963 . 965 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 966 Possession Key Semantics for JSON Web Tokens (JWTs)", 967 RFC 7800, DOI 10.17487/RFC7800, April 2016, 968 . 970 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 971 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 972 . 974 [SHS] National Institute of Standards and Technology, "Secure 975 Hash Standard (SHS)", FIPS PUB 180-4, March 2012, 976 . 979 [X690] International Telephone and Telegraph Consultative 980 Committee, "ASN.1 encoding rules: Specification of basic 981 encoding Rules (BER), Canonical encoding rules (CER) and 982 Distinguished encoding rules (DER)", CCITT Recommendation 983 X.690, July 2015. 985 10.2. Informative References 987 [CX5P] Wong, D., "Common x509 certificate validation/creation 988 pitfalls", September 2016, 989 . 992 [DCW] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, 993 D., and V. Shmatikov, "The Most Dangerous Code in the 994 World: Validating SSL Certificates in Non-Browser 995 Software", 996 . 998 [I-D.ietf-oauth-token-binding] 999 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 1000 "OAuth 2.0 Token Binding", draft-ietf-oauth-token- 1001 binding-06 (work in progress), March 2018. 1003 [IANA.JWT.Claims] 1004 IANA, "JSON Web Token Claims", 1005 . 1007 [IANA.OAuth.Parameters] 1008 IANA, "OAuth Parameters", 1009 . 1011 [OpenID.CIBA] 1012 Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. 1013 Campbell, "OpenID Connect Client Initiated Backchannel 1014 Authentication Flow - Core 1.0", January 2019, 1015 . 1018 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1019 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1020 2006, . 1022 [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol 1023 (LDAP): Syntaxes and Matching Rules", RFC 4517, 1024 DOI 10.17487/RFC4517, June 2006, 1025 . 1027 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 1028 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 1029 August 2013, . 1031 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1032 DOI 10.17487/RFC7517, May 2015, 1033 . 1035 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1036 DOI 10.17487/RFC7518, May 2015, 1037 . 1039 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1040 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1041 . 1043 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 1044 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 1045 RFC 7591, DOI 10.17487/RFC7591, July 2015, 1046 . 1048 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 1049 RFC 7662, DOI 10.17487/RFC7662, October 2015, 1050 . 1052 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1053 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1054 May 2017, . 1056 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 1057 Authorization Server Metadata", RFC 8414, 1058 DOI 10.17487/RFC8414, June 2018, 1059 . 1061 Appendix A. Example "cnf" Claim, Certificate and JWK 1063 For reference, an "x5t#S256" value and the X.509 Certificate from 1064 which it was calculated are provided in the following examples, 1065 Figure 5 and Figure 6 respectively. A JWK representation of the 1066 certificate's public key along with the "x5c" member is also provided 1067 in Figure 7. 1069 "cnf":{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"} 1071 Figure 5: x5t#S256 Confirmation Claim 1073 -----BEGIN CERTIFICATE----- 1074 MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTAx 1075 ODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGByqG 1076 SM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZjjJ 1077 /Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0EAwID 1078 SQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2eXZOV 1079 bUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY= 1080 -----END CERTIFICATE----- 1082 Figure 6: PEM Encoded Self-Signed Certificate 1084 { 1085 "kty":"EC", 1086 "x":"1yfLHCpXqFjxCeHHHMVDTcLscpb07KUxudBmOMn8C7Q", 1087 "y":"8_coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8", 1088 "crv":"P-256", 1089 "x5c":[ 1090 "MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTA 1091 xODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGBy 1092 qGSM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZ 1093 jjJ/Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0E 1094 AwIDSQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2 1095 eXZOVbUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY=" 1096 ] 1097 } 1099 Figure 7: JSON Web Key 1101 Appendix B. Relationship to Token Binding 1103 OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the 1104 application of Token Binding to the various artifacts and tokens 1105 employed throughout OAuth. That includes binding of an access token 1106 to a Token Binding key, which bears some similarities in motivation 1107 and design to the mutual TLS client certificate-bound access tokens 1108 defined in this document. Both documents define what is often called 1109 a proof-of-possession security mechanism for access tokens, whereby a 1110 client must demonstrate possession of cryptographic keying material 1111 when accessing a protected resource. The details differ somewhat 1112 between the two documents but both have the authorization server bind 1113 the access token that it issues to an asymmetric key pair held by the 1114 client. The client then proves possession of the private key from 1115 that pair with respect to the TLS connection over which the protected 1116 resource is accessed. 1118 Token Binding uses bare keys that are generated on the client, which 1119 avoids many of the difficulties of creating, distributing, and 1120 managing certificates used in this specification. However, at the 1121 time of writing, Token Binding is fairly new and there is relatively 1122 little support for it in available application development platforms 1123 and tooling. Until better support for the underlying core Token 1124 Binding specifications exists, practical implementations of OAuth 2.0 1125 Token Binding are infeasible. Mutual TLS, on the other hand, has 1126 been around for some time and enjoys widespread support in web 1127 servers and development platforms. As a consequence, OAuth 2.0 1128 Mutual TLS Client Authentication and Certificate-Bound Access Tokens 1129 can be built and deployed now using existing platforms and tools. In 1130 the future, the two specifications are likely to be deployed in 1131 parallel for solving similar problems in different environments. 1132 Authorization servers may even support both specifications 1133 simultaneously using different proof-of-possession mechanisms for 1134 tokens issued to different clients. 1136 Appendix C. Acknowledgements 1138 Scott "not Tomlinson" Tomilson and Matt Peterson were involved in 1139 design and development work on a mutual TLS OAuth client 1140 authentication implementation, which predates this document. 1141 Experience and learning from that work informed some of the content 1142 of this document. 1144 This specification was developed within the OAuth Working Group under 1145 the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with 1146 Eric Rescorla, Benjamin Kaduk, and Roman Danyliw serving as Security 1147 Area Directors. Additionally, the following individuals contributed 1148 ideas, feedback, and wording that helped shape this specification: 1149 Vittorio Bertocci, Sergey Beryozkin, Ralph Bragg, Sophie Bremer, 1150 Roman Danyliw, Vladimir Dzhuvinov, Samuel Erdtman, Evan Gilman, Leif 1151 Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko 1152 Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim 1153 Manico, Nov Matake, Sascha Preibisch, Eric Rescorla, Justin Richer, 1154 Filip Skokan, Dave Tonge, and Hannes Tschofenig. 1156 Appendix D. Document(s) History 1158 [[ to be removed by the RFC Editor before publication as an RFC ]] 1160 draft-ietf-oauth-mtls-15 1161 o Editorial updates from second AD review. 1163 draft-ietf-oauth-mtls-14 1165 o Editorial clarifications around there being only a single subject 1166 registered/configured per client for the tls_client_auth method. 1167 o Add a brief explanation about how, with tls_client_auth and 1168 self_signed_tls_client_auth, refresh tokens are certificate-bound 1169 indirectly via the client authentication. 1170 o Add mention of refresh tokens in the abstract. 1172 draft-ietf-oauth-mtls-13 1174 o Add an abstract protocol flow and diagram to serve as an overview 1175 of OAuth in general and baseline to describe the various ways in 1176 which the mechanisms defined herein are intended to be used. 1177 o A little bit less of that German influence. 1178 o Rework the TLS references a bit and, in the Terminology section, 1179 clean up the description of what messages are sent and verified in 1180 the handshake to do 'mutual TLS'. 1181 o Move the explanation about "cnf" introspection registration into 1182 the IANA Considerations. 1183 o Add CIBA as an informational reference and additional example of 1184 an OAuth extension that defines an endpoint that utilizes client 1185 authentication. 1186 o Shorten a few of the section titles. 1187 o Add new client metadata values to allow for the use of a SAN in 1188 the PKI MTLS client authentication method. 1189 o Add privacy considerations attempting to discuss the implications 1190 of the client cert being sent in the clear in TLS 1.2. 1191 o Changed the 'Certificate Bound Access Tokens Without Client 1192 Authentication' section to 'Public Clients and Certificate-Bound 1193 Tokens' and moved it up to be a top level section while adding 1194 discussion of binding refresh tokens for public clients. 1195 o Reword/restructure the main PKI method section somewhat to 1196 (hopefully) improve readability. 1197 o Reword/restructure the Self-Signed method section a bit to 1198 (hopefully) make it more comprehensible. 1199 o Reword the AS and RS Implementation Considerations somewhat to 1200 (hopefully) improve readability. 1201 o Clarify that the protected resource obtains the client certificate 1202 used for mutual TLS from its TLS implementation layer. 1203 o Add Security Considerations section about the certificate 1204 thumbprint binding that includes the hash algorithm agility 1205 recommendation. 1206 o Add an "mtls_endpoint_aliases" AS metadata parameter that is a 1207 JSON object containing alternative authorization server endpoints, 1208 which a client intending to do mutual TLS will use in preference 1209 to the conventional endpoints. 1210 o Minor editorial updates. 1212 draft-ietf-oauth-mtls-12 1214 o Add an example certificate, JWK, and confirmation method claim. 1215 o Minor editorial updates based on implementer feedback. 1216 o Additional Acknowledgements. 1218 draft-ietf-oauth-mtls-11 1220 o Editorial updates. 1221 o Mention/reference TLS 1.3 RFC8446 in the TLS Versions and Best 1222 Practices section. 1224 draft-ietf-oauth-mtls-10 1226 o Update draft-ietf-oauth-discovery reference to RFC8414 1228 draft-ietf-oauth-mtls-09 1230 o Change "single certificates" to "self-signed certificates" in the 1231 Abstract 1233 draft-ietf-oauth-mtls-08 1235 o Incorporate clarifications and editorial improvements from Justin 1236 Richer's WGLC review 1237 o Drop the use of the "sender constrained" terminology per WGLC 1238 feedback from Neil Madden (including changing the metadata 1239 parameters from mutual_tls_sender_constrained_access_tokens to 1240 tls_client_certificate_bound_access_tokens) 1241 o Add a new security considerations section on X.509 parsing and 1242 validation per WGLC feedback from Neil Madden and Benjamin Kaduk 1243 o Note that a server can terminate TLS at a load balancer, reverse 1244 proxy, etc. but how the client certificate metadata is securely 1245 communicated to the backend is out of scope per WGLC feedback 1246 o Note that revocation checking is at the discretion of the AS per 1247 WGLC feedback 1248 o Editorial updates and clarifications 1249 o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf- 1250 oauth-token-binding to -06 1251 o Add folks involved in WGLC feedback to the acknowledgements list 1253 draft-ietf-oauth-mtls-07 1255 o Update to use the boilerplate from RFC 8174 1256 o Add an appendix section describing the relationship of this 1257 document to OAuth Token Binding as requested during the Singapore 1258 meeting https://datatracker.ietf.org/doc/minutes-100-oauth/ 1259 o Add an explicit note that the implicit flow is not supported for 1260 obtaining certificate bound access tokens as discussed at the 1261 Singapore meeting https://datatracker.ietf.org/doc/minutes- 1262 100-oauth/ 1263 o Add/incorporate text to the Security Considerations on Certificate 1264 Spoofing as suggested https://mailarchive.ietf.org/arch/msg/oauth/ 1265 V26070X-6OtbVSeUz_7W2k94vCo 1266 o Changed the title to be more descriptive 1267 o Move the Security Considerations section to before the IANA 1268 Considerations 1269 o Elaborated on certificate-bound access tokens a bit more in the 1270 Abstract 1271 o Update draft-ietf-oauth-discovery reference to -08 1273 draft-ietf-oauth-mtls-05 1275 o Editorial fixes 1277 draft-ietf-oauth-mtls-04 1279 o Change the name of the 'Public Key method' to the more accurate 1280 'Self-Signed Certificate method' and also change the associated 1281 authentication method metadata value to 1282 "self_signed_tls_client_auth". 1283 o Removed the "tls_client_auth_root_dn" client metadata field as 1284 discussed in https://mailarchive.ietf.org/arch/msg/oauth/ 1285 swDV2y0be6o8czGKQi1eJV-g8qc 1286 o Update draft-ietf-oauth-discovery reference to -07 1287 o Clarify that MTLS client authentication isn't exclusive to the 1288 token endpoint and can be used with other endpoints, e.g. RFC 1289 7009 revocation and 7662 introspection, that utilize client 1290 authentication as discussed in 1291 https://mailarchive.ietf.org/arch/msg/oauth/ 1292 bZ6mft0G7D3ccebhOxnEYUv4puI 1293 o Reorganize the document somewhat in an attempt to more clearly 1294 make a distinction between mTLS client authentication and 1295 certificate-bound access tokens as well as a more clear 1296 delineation between the two (PKI/Public key) methods for client 1297 authentication 1298 o Editorial fixes and clarifications 1300 draft-ietf-oauth-mtls-03 1301 o Introduced metadata and client registration parameter to publish 1302 and request support for mutual TLS sender constrained access 1303 tokens 1304 o Added description of two methods of binding the cert and client, 1305 PKI and Public Key. 1306 o Indicated that the "tls_client_auth" authentication method is for 1307 the PKI method and introduced "pub_key_tls_client_auth" for the 1308 Public Key method 1309 o Added implementation considerations, mainly regarding TLS stack 1310 configuration and trust chain validation, as well as how to to do 1311 binding of access tokens to a TLS client certificate for public 1312 clients, and considerations around certificate-bound access tokens 1313 o Added new section to security considerations on cert spoofing 1314 o Add text suggesting that a new cnf member be defined in the 1315 future, if hash function(s) other than SHA-256 need to be used for 1316 certificate thumbprints 1318 draft-ietf-oauth-mtls-02 1320 o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ 1321 U46UMEh8XIOQnvXY9pHFq1MKPns 1322 o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is 1323 better than "Mutual TLS Profiles for OAuth Clients"). 1325 draft-ietf-oauth-mtls-01 1327 o Added more explicit details of using RFC 7662 token introspection 1328 with mutual TLS sender constrained access tokens. 1329 o Added an IANA OAuth Token Introspection Response Registration 1330 request for "cnf". 1331 o Specify that tls_client_auth_subject_dn and 1332 tls_client_auth_root_dn are RFC 4514 String Representation of 1333 Distinguished Names. 1334 o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. 1335 o Changed the text in the Section 3 to not be specific about using a 1336 hash of the cert. 1337 o Changed the abbreviated title to 'OAuth Mutual TLS' (previously 1338 was the acronym MTLSPOC). 1340 draft-ietf-oauth-mtls-00 1342 o Created the initial working group version from draft-campbell- 1343 oauth-mtls 1345 draft-campbell-oauth-mtls-01 1347 o Fix some typos. 1348 o Add to the acknowledgements list. 1350 o Add a Mutual TLS sender constrained protected resource access 1351 method and a x5t#S256 cnf method for JWT access tokens (concepts 1352 taken in part from draft-sakimura-oauth-jpop-04). 1353 o Fixed "token_endpoint_auth_methods_supported" to 1354 "token_endpoint_auth_method" for client metadata. 1355 o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" 1356 client metadata parameters and mention using "jwks_uri" or "jwks". 1357 o Say that the authentication method is determined by client policy 1358 regardless of whether the client was dynamically registered or 1359 statically configured. 1360 o Expand acknowledgements to those that participated in discussions 1361 around draft-campbell-oauth-tls-client-auth-00 1362 o Add Nat Sakimura and Torsten Lodderstedt to the author list. 1364 draft-campbell-oauth-tls-client-auth-00 1366 o Initial draft. 1368 Authors' Addresses 1370 Brian Campbell 1371 Ping Identity 1373 Email: brian.d.campbell@gmail.com 1375 John Bradley 1376 Yubico 1378 Email: ve7jtb@ve7jtb.com 1379 URI: http://www.thread-safe.com/ 1381 Nat Sakimura 1382 Nomura Research Institute 1384 Email: n-sakimura@nri.co.jp 1385 URI: https://nat.sakimura.org/ 1387 Torsten Lodderstedt 1388 YES.com AG 1390 Email: torsten@lodderstedt.net