idnits 2.17.1 draft-ietf-oauth-mtls-07.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 (January 29, 2018) is 2278 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 (-10) exists of draft-ietf-oauth-discovery-08 == Outdated reference: A later version (-08) exists of draft-ietf-oauth-token-binding-05 Summary: 2 errors (**), 0 flaws (~~), 3 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: August 2, 2018 Yubico 6 N. Sakimura 7 Nomura Research Institute 8 T. Lodderstedt 9 YES Europe AG 10 January 29, 2018 12 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access 13 Tokens 14 draft-ietf-oauth-mtls-07 16 Abstract 18 This document describes Transport Layer Security (TLS) mutual 19 authentication using X.509 certificates as a mechanism for OAuth 20 client authentication to the authorization sever as well as for 21 certificate bound sender constrained access tokens as a method for a 22 protected resource to ensure that an access token presented to it by 23 a given client was issued to that client by the authorization server. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 2, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 4 63 2.1. PKI Mutual TLS OAuth Client Authentication Method . . . . 5 64 2.1.1. PKI Authentication Method Metadata Value . . . . . . 5 65 2.1.2. Client Registration Metadata . . . . . . . . . . . . 5 66 2.2. Self-Signed Certificate Mutual TLS OAuth Client 67 Authentication Method . . . . . . . . . . . . . . . . . . 6 68 2.2.1. Self-Signed Certificate Authentication Method 69 Metadata Value . . . . . . . . . . . . . . . . . . . 6 70 2.2.2. Client Registration Metadata . . . . . . . . . . . . 6 71 3. Mutual TLS Sender Constrained Resources Access . . . . . . . 7 72 3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 7 73 3.2. Confirmation Method for Token Introspection . . . . . . . 8 74 3.3. Authorization Server Metadata . . . . . . . . . . . . . . 9 75 3.4. Client Registration Metadata . . . . . . . . . . . . . . 9 76 4. Implementation Considerations . . . . . . . . . . . . . . . . 10 77 4.1. Authorization Server . . . . . . . . . . . . . . . . . . 10 78 4.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 10 79 4.3. Sender Constrained Access Tokens Without Client 80 Authentication . . . . . . . . . . . . . . . . . . . . . 10 81 4.4. Certificate Bound Access Tokens . . . . . . . . . . . . . 11 82 4.5. Implicit Grant Unsupported . . . . . . . . . . . . . . . 11 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 5.1. TLS Versions and Best Practices . . . . . . . . . . . . . 11 85 5.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 12 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 6.1. JWT Confirmation Methods Registration . . . . . . . . . . 12 88 6.2. OAuth Authorization Server Metadata Registration . . . . 12 89 6.3. Token Endpoint Authentication Method Registration . . . . 12 90 6.4. OAuth Token Introspection Response Registration . . . . . 13 91 6.5. OAuth Dynamic Client Registration Metadata Registration . 13 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 94 7.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Appendix A. Relationship to Token Binding . . . . . . . . . . . 16 96 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 97 Appendix C. Document(s) History . . . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 This document describes Transport Layer Security (TLS) mutual 103 authentication using X.509 certificates as a mechanism for OAuth 104 client authentication to the authorization sever as well as for 105 sender constrained access to OAuth protected resources. 107 The OAuth 2.0 Authorization Framework [RFC6749] defines a shared 108 secret method of client authentication but also allows for the 109 definition and use of additional client authentication mechanisms 110 when interacting directly with the authorization server. This 111 document describes an additional mechanism of client authentication 112 utilizing mutual TLS [RFC5246] certificate-based authentication, 113 which provides better security characteristics than shared secrets. 114 While [RFC6749] documents client authentication for requests to the 115 token endpoint, extensions to OAuth 2.0 (such as Introspection 116 [RFC7662] and Revocation [RFC7009]) define endpoints that also 117 utilize client authentication and the mutual TLS methods defined 118 herein are applicable to those endpoints as well. 120 Mutual TLS sender constrained access to protected resources ensures 121 that only the party in possession of the private key corresponding to 122 the certificate can utilize the access token to get access to the 123 associated resources. Such a constraint is unlike the case of the 124 basic bearer token described in [RFC6750], where any party in 125 possession of the access token can use it to access the associated 126 resources. Mutual TLS sender constrained access binds the access 127 token to the client's certificate thus preventing the use of stolen 128 access tokens or replay of access tokens by unauthorized parties. 130 Mutual TLS sender constrained access tokens and mutual TLS client 131 authentication are distinct mechanisms, which are complementary but 132 don't necessarily need to be deployed together. 134 1.1. Requirements Notation and Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 1.2. Terminology 144 This specification uses the following phrases interchangeably: 146 Transport Layer Security (TLS) Mutual Authentication 148 Mutual TLS 150 These phrases all refer to the process whereby a client presents its 151 X.509 certificate and proves possession of the corresponding private 152 key to a server when negotiating a TLS session. In TLS 1.2 [RFC5246] 153 this requires the client to send Client Certificate and Certificate 154 Verify messages during the TLS handshake and for the server to verify 155 these messages. 157 2. Mutual TLS for OAuth Client Authentication 159 This section defines, as an extension of OAuth 2.0, Section 2.3 160 [RFC6749], two distinct methods of using mutual TLS X.509 client 161 certificates as client credentials. The requirement of mutual TLS 162 for client authentication is determined by the authorization server 163 based on policy or configuration for the given client (regardless of 164 whether the client was dynamically registered or statically 165 configured or otherwise established). 167 In order to utilize TLS for OAuth client authentication, the TLS 168 connection between the client and the authorization server MUST have 169 been established or reestablished with mutual X.509 certificate 170 authentication (i.e. the Client Certificate and Certificate Verify 171 messages are sent during the TLS Handshake [RFC5246]). 173 For all requests to the authorization server utilizing mutual TLS 174 client authentication, the client MUST include the "client_id" 175 parameter, described in OAuth 2.0, Section 2.2 [RFC6749]. The 176 presence of the "client_id" parameter enables the authorization 177 server to easily identify the client independently from the content 178 of the certificate. The authorization server can locate the client 179 configuration using the client identifier and check the certificate 180 presented in the TLS Handshake against the expected credentials for 181 that client. The authorization server MUST enforce some method of 182 binding a certificate to a client. Sections Section 2.1 and 183 Section 2.2 below define two ways of binding a certificate to a 184 client as two distinct client authentication methods. 186 2.1. PKI Mutual TLS OAuth Client Authentication Method 188 The PKI (public key infrastructure) method of mutual TLS OAuth client 189 authentication uses a subject distinguished name (DN) and validated 190 certificate chain to identify the client. The TLS handshake is 191 utilized to validate the client's possession of the private key 192 corresponding to the public key in the certificate and to validate 193 the corresponding certificate chain. The client is successfully 194 authenticated if the subject information in the certificate matches 195 the expected DN configured or registered for that particular client. 196 The PKI method facilitates the way X.509 certificates are 197 traditionally being used for authentication. It also allows the 198 client to rotate its X.509 certificates without the need to modify 199 its respective authentication data at the authorization server by 200 obtaining a new certificate with the same subject DN from a trusted 201 certificate authority (CA). 203 2.1.1. PKI Authentication Method Metadata Value 205 The "OAuth Token Endpoint Authentication Methods" registry 206 [IANA.OAuth.Parameters] contains values, each of which specify a 207 method of authenticating a client to the authorization server. The 208 values are used to indicate supported and utilized client 209 authentication methods in authorization server metadata, such as 210 OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0 211 Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the 212 OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the 213 PKI method of mutual TLS client authentication, this specification 214 defines and registers the following authentication method metadata 215 value. 217 tls_client_auth 218 Indicates that client authentication to the authorization server 219 will occur with mutual TLS utilizing the PKI method of associating 220 a certificate to a client. 222 2.1.2. Client Registration Metadata 224 The following metadata parameter is introduced for the OAuth 2.0 225 Dynamic Client Registration Protocol [RFC7591] in support of the PKI 226 method of binding a certificate to a client: 228 tls_client_auth_subject_dn 229 An [RFC4514] string representation of the expected subject 230 distinguished name of the certificate the OAuth client will use in 231 mutual TLS authentication. 233 2.2. Self-Signed Certificate Mutual TLS OAuth Client Authentication 234 Method 236 This method of mutual TLS OAuth client authentication is intended to 237 support client authentication using self-signed certificates. As 238 pre-requisite, the client registers an X.509 certificate or a trusted 239 source for its X.509 certificates (such as the "jwks_uri" as defined 240 in [RFC7591]) with the authorization server. During authentication, 241 TLS is utilized to validate the client's possession of the private 242 key corresponding to the public key presented within the certificate 243 in the respective TLS handshake. In contrast to the PKI method, the 244 certificate chain is not validated in this case. The client is 245 successfully authenticated, if the subject public key info of the 246 certificate matches the subject public key info of one of the 247 certificates configured or registered for that particular client. 248 The Self-Signed Certificate method allows to use mutual TLS to 249 authenticate clients without the need to maintain a PKI. When used 250 in conjunction with a "jwks_uri" for the client, it also allows the 251 client to rotate its X.509 certificates without the need to change 252 its respective authentication data directly with the authorization 253 server. 255 2.2.1. Self-Signed Certificate Authentication Method Metadata Value 257 The "OAuth Token Endpoint Authentication Methods" registry 258 [IANA.OAuth.Parameters] contains values, each of which specify a 259 method of authenticating a client to the authorization server. The 260 values are used to indicate supported and utilized client 261 authentication methods in authorization server metadata, such as 262 OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0 263 Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the 264 OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the 265 Self-Signed Certificate method of binding a certificate to a client 266 using mutual TLS client authentication, this specification defines 267 and registers the following authentication method metadata value. 269 self_signed_tls_client_auth 270 Indicates that client authentication to the authorization server 271 will occur using mutual TLS with the client utilizing a self- 272 signed certificate. 274 2.2.2. Client Registration Metadata 276 For the Self-Signed Certificate method of binding a certificate to a 277 client using mutual TLS client authentication, the existing 278 "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to 279 convey the client's certificates and public keys, where the X.509 280 certificates are represented using the JSON Web Key (JWK) [RFC7517] 281 "x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key 282 in the first certificate of the "x5c" parameter must match the public 283 key represented by other members of the JWK). 285 3. Mutual TLS Sender Constrained Resources Access 287 When mutual TLS is used by the client on the connection to the token 288 endpoint, the authorization server is able to bind the issued access 289 token to the client certificate. Such a binding is accomplished by 290 associating the certificate with the token in a way that can be 291 accessed by the protected resource, such as embedding the certificate 292 hash in the issued access token directly, using the syntax described 293 in Section 3.1, or through token introspection as described in 294 Section 3.2. Other methods of associating a certificate with an 295 access token are possible, per agreement by the authorization server 296 and the protected resource, but are beyond the scope of this 297 specification. 299 The client makes protected resource requests as described in 300 [RFC6750], however, those requests MUST be made over a mutually 301 authenticated TLS connection using the same certificate that was used 302 for mutual TLS at the token endpoint. 304 The protected resource MUST obtain the client certificate used for 305 mutual TLS authentication and MUST verify that the certificate 306 matches the certificate associated with the access token. If they do 307 not match, the resource access attempt MUST be rejected with an error 308 per [RFC6750] using an HTTP 401 status code and the "invalid_token" 309 error code. 311 Metadata to convey server and client capabilities for mutual TLS 312 sender constrained access tokens is defined in Section 3.3 and 313 Section 3.4 respectively. 315 3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 317 When access tokens are represented as JSON Web Tokens (JWT)[RFC7519], 318 the certificate hash information SHOULD be represented using the 319 "x5t#S256" confirmation method member defined herein. 321 To represent the hash of a certificate in a JWT, this specification 322 defines the new JWT Confirmation Method RFC 7800 [RFC7800] member 323 "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value 324 of the "x5t#S256" member is a base64url-encoded SHA-256[SHS] hash 325 (a.k.a. thumbprint or digest) of the DER encoding of the X.509 326 certificate[RFC5280] (note that certificate thumbprints are also 327 sometimes known as certificate fingerprints). 329 The following is an example of a JWT payload containing an "x5t#S256" 330 certificate thumbprint confirmation method. 332 { 333 "iss": "https://server.example.com", 334 "sub": "ty.webb@example.com", 335 "exp": 1493726400, 336 "nbf": 1493722800, 337 "cnf":{ 338 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 339 } 340 } 342 Figure 1: Example claims of a Certificate Thumbprint Constrained JWT 344 If, in the future, certificate thumbprints need to be computed using 345 hash functions other than SHA-256, it is suggested that additional 346 related JWT confirmation methods members be defined for that purpose. 347 For example, a new "x5t#S512" (X.509 Certificate Thumbprint using 348 SHA-512) confirmation method member could be defined by registering 349 it in the the IANA "JWT Confirmation Methods" registry 350 [IANA.JWT.Claims] for JWT "cnf" member values established by 351 [RFC7800]. 353 3.2. Confirmation Method for Token Introspection 355 OAuth 2.0 Token Introspection [RFC7662] defines a method for a 356 protected resource to query an authorization server about the active 357 state of an access token as well as to determine meta-information 358 about the token. 360 For a mutual TLS sender constrained access token, the hash of the 361 certificate to which the token is bound is conveyed to the protected 362 resource as meta-information in a token introspection response. The 363 hash is conveyed using the same structure as the certificate SHA-256 364 thumbprint confirmation method, described in Section 3.1, as a top- 365 level member of the introspection response JSON. The protected 366 resource compares that certificate hash to a hash of the client 367 certificate used for mutual TLS authentication and rejects the 368 request, if they do not match. 370 Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] 371 defined the "cnf" (confirmation) claim, which enables confirmation 372 key information to be carried in a JWT. However, the same proof-of- 373 possession semantics are also useful for introspected access tokens 374 whereby the protected resource obtains the confirmation key data as 375 meta-information of a token introspection response and uses that 376 information in verifying proof-of-possession. Therefore this 377 specification defines and registers proof-of-possession semantics for 378 OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. 379 When included as a top-level member of an OAuth token introspection 380 response, "cnf" has the same semantics and format as the claim of the 381 same name defined in [RFC7800]. While this specification only 382 explicitly uses the "x5t#S256" confirmation method member, it needed 383 to define and register the higher level "cnf" structure as an 384 introspection response member in order to define and use its more 385 specific "x5t#S256" confirmation method. 387 The following is an example of an introspection response for an 388 active token with an "x5t#S256" certificate thumbprint confirmation 389 method. 391 HTTP/1.1 200 OK 392 Content-Type: application/json 394 { 395 "active": true, 396 "iss": "https://server.example.com", 397 "sub": "ty.webb@example.com", 398 "exp": 1493726400, 399 "nbf": 1493722800, 400 "cnf":{ 401 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 402 } 403 } 405 Figure 2: Example Introspection Response for a Certificate 406 Constrained Access Token 408 3.3. Authorization Server Metadata 410 This document introduces the following new authorization server 411 metadata parameter to signal the server's capability to issue 412 certificate bound access tokens: 414 mutual_tls_sender_constrained_access_tokens 415 OPTIONAL. Boolean value indicating server support for mutual TLS 416 sender constrained access tokens. If omitted, the default value 417 is "false". 419 3.4. Client Registration Metadata 421 The following new client metadata parameter is introduced to convey 422 the client's intention to use certificate bound access tokens: 424 mutual_tls_sender_constrained_access_tokens 425 OPTIONAL. Boolean value used to indicate the client's intention 426 to use mutual TLS sender constrained access tokens. If omitted, 427 the default value is "false". 429 4. Implementation Considerations 431 4.1. Authorization Server 433 The authorization server needs to setup its TLS configuration 434 appropriately for the binding methods it supports. 436 If the authorization server wants to support mutual TLS client 437 authentication and other client authentication methods in parallel, 438 it should make mutual TLS optional. 440 If the authorization server supports the Self-Signed Certificate 441 method, it should configure the TLS stack in a way that it does not 442 verify whether the certificate presented by the client during the 443 handshake is signed by a trusted CA certificate. 445 The authorization server may also consider hosting the token 446 endpoint, and other endpoints requiring client authentication, on a 447 separate host name in order to prevent unintended impact on the TLS 448 behavior of its other endpoints, e.g. authorization or registration. 450 4.2. Resource Server 452 From the perspective of the resource server, TLS client 453 authentication is used as a proof of possession method only. For the 454 purpose of client authentication, the resource server may completely 455 rely on the authorization server. So there is no need to validate 456 the trust chain of the client's certificate in any of the methods 457 defined in this document. The resource server should therefore 458 configure the TLS stack in a way that it does not verify whether the 459 certificate presented by the client during the handshake is signed by 460 a trusted CA certificate. 462 4.3. Sender Constrained Access Tokens Without Client Authentication 464 This document allows use of client authentication only or client 465 authentication in combination with sender constraint access tokens. 466 Use of mutual TLS sender constrained access tokens without client 467 authentication (e.g. to support binding access tokens to a TLS client 468 certificate for public clients) is also possible. The authorization 469 server would configure the TLS stack in the same manner as for the 470 Self-Signed Certificate method such that it does not verify that the 471 certificate presented by the client during the handshake is signed by 472 a trusted CA. Individual instances of a public client would then 473 create a self-signed certificate for mutual TLS with the 474 authorization server and resource server. The authorization server 475 would not authenticate the client at the OAuth layer but would bind 476 issued access tokens to the certificate, which the client has proven 477 possession of the corresponding private key. The access token is 478 then mutual TLS sender constrained and can only be used by the client 479 possessing the certificate and private key and utilizing them to 480 negotiate mutual TLS on connections to the resource server. 482 4.4. Certificate Bound Access Tokens 484 As described in Section 3, an access token is bound to a specific 485 client certificate, which means that the same certificate must be 486 used for mutual TLS on protected resource access. It also implies 487 that access tokens are invalidated when a client updates the 488 certificate, which can be handled similar to expired access tokens 489 where the client requests a new access token (typically with a 490 refresh token) and retries the protected resource request. 492 4.5. Implicit Grant Unsupported 494 This document describes binding an access token to the client 495 certificate presented on the TLS connection from the client to the 496 authorization server's token endpoint, however, certificate binding 497 of access tokens issued directly from the authorization endpoint via 498 the implicit grant flow is explicitly out of scope. End users 499 interact directly with the authorization endpoint using a web browser 500 and the use of client certificates in user's browsers bring 501 operational and usability issues, which make it undesirable to 502 support certificate bound access tokens issued in the implicit grant 503 flow. Implementations wanting to employ certificate bound sender 504 constrained access tokens should utilize grant types that involve the 505 client making an access token request directly to the token endpoint 506 (e.g. the authorization code and refresh token grant types). 508 5. Security Considerations 510 5.1. TLS Versions and Best Practices 512 TLS 1.2 [RFC5246] is cited in this document because, at the time of 513 writing, it is the latest version that is widely deployed. However, 514 this document is applicable with other TLS versions supporting 515 certificate-based client authentication. Implementation security 516 considerations for TLS, including version recommendations, can be 517 found in Recommendations for Secure Use of Transport Layer Security 518 (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]. 520 5.2. X.509 Certificate Spoofing 522 If the PKI method of client authentication is used, an attacker could 523 try to impersonate a client using a certificate with the same subject 524 DN but issued by a different CA, which the authorization server 525 trusts. To cope with that threat, the authorization server should 526 only accept as trust anchors a limited number of CAs whose 527 certificate issuance policy meets its security requirements. There 528 is an assumption then that the client and server agree on the set of 529 trust anchors that the server uses to create and validate the 530 certificate chain. Without this assumption the use of a Subject DN 531 to identify the client certificate would open the server up to 532 certificate spoofing attacks. 534 6. IANA Considerations 536 6.1. JWT Confirmation Methods Registration 538 This specification requests registration of the following value in 539 the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for 540 JWT "cnf" member values established by [RFC7800]. 542 o Confirmation Method Value: "x5t#S256" 543 o Confirmation Method Description: X.509 Certificate SHA-256 544 Thumbprint 545 o Change Controller: IESG 546 o Specification Document(s): Section 3.1 of [[ this specification ]] 548 6.2. OAuth Authorization Server Metadata Registration 550 This specification requests registration of the following value in 551 the IANA "OAuth Authorization Server Metadata" registry 552 [IANA.OAuth.Parameters] established by [I-D.ietf-oauth-discovery]. 554 o Metadata Name: "mutual_tls_sender_constrained_access_tokens" 555 o Metadata Description: Indicates authorization server support for 556 mutual TLS sender constrained access tokens. 557 o Change Controller: IESG 558 o Specification Document(s): Section 3.3 of [[ this specification ]] 560 6.3. Token Endpoint Authentication Method Registration 562 This specification requests registration of the following value in 563 the IANA "OAuth Token Endpoint Authentication Methods" registry 564 [IANA.OAuth.Parameters] established by [RFC7591]. 566 o Token Endpoint Authentication Method Name: "tls_client_auth" 567 o Change Controller: IESG 568 o Specification Document(s): Section 2.1.1 of [[ this specification 569 ]] 571 o Token Endpoint Authentication Method Name: 572 "self_signed_tls_client_auth" 573 o Change Controller: IESG 574 o Specification Document(s): Section 2.2.1 of [[ this specification 575 ]] 577 6.4. OAuth Token Introspection Response Registration 579 This specification requests registration of the following value in 580 the IANA "OAuth Token Introspection Response" registry 581 [IANA.OAuth.Parameters] established by [RFC7662]. 583 o Claim Name: "cnf" 584 o Claim Description: Confirmation 585 o Change Controller: IESG 586 o Specification Document(s): Section 3.2 of [[ this specification ]] 588 6.5. OAuth Dynamic Client Registration Metadata Registration 590 This specification requests registration of the following client 591 metadata definitions in the IANA "OAuth Dynamic Client Registration 592 Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: 594 o Client Metadata Name: 595 "mutual_tls_sender_constrained_access_tokens" 596 o Client Metadata Description: Indicates the client's intention to 597 use mutual TLS sender constrained access tokens. 598 o Change Controller: IESG 599 o Specification Document(s): Section 3.4 of [[ this specification ]] 601 o Client Metadata Name: "tls_client_auth_subject_dn" 602 o Client Metadata Description: String value specifying the expected 603 subject distinguished name of the client certificate. 604 o Change Controller: IESG 605 o Specification Document(s): Section 2.1.2 of [[ this specification 606 ]] 608 7. References 610 7.1. Normative References 612 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 613 "Recommendations for Secure Use of Transport Layer 614 Security (TLS) and Datagram Transport Layer Security 615 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 616 2015, . 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, 620 DOI 10.17487/RFC2119, March 1997, 621 . 623 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 624 (LDAP): String Representation of Distinguished Names", 625 RFC 4514, DOI 10.17487/RFC4514, June 2006, 626 . 628 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 629 (TLS) Protocol Version 1.2", RFC 5246, 630 DOI 10.17487/RFC5246, August 2008, 631 . 633 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 634 Housley, R., and W. Polk, "Internet X.509 Public Key 635 Infrastructure Certificate and Certificate Revocation List 636 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 637 . 639 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 640 RFC 6749, DOI 10.17487/RFC6749, October 2012, 641 . 643 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 644 Framework: Bearer Token Usage", RFC 6750, 645 DOI 10.17487/RFC6750, October 2012, 646 . 648 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 649 Possession Key Semantics for JSON Web Tokens (JWTs)", 650 RFC 7800, DOI 10.17487/RFC7800, April 2016, 651 . 653 [SHS] National Institute of Standards and Technology, "Secure 654 Hash Standard (SHS)", FIPS PUB 180-4, March 2012, 655 . 658 7.2. Informative References 660 [I-D.ietf-oauth-discovery] 661 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 662 Authorization Server Metadata", draft-ietf-oauth- 663 discovery-08 (work in progress), November 2017. 665 [I-D.ietf-oauth-token-binding] 666 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 667 "OAuth 2.0 Token Binding", draft-ietf-oauth-token- 668 binding-05 (work in progress), October 2017. 670 [IANA.JWT.Claims] 671 IANA, "JSON Web Token Claims", 672 . 674 [IANA.OAuth.Parameters] 675 IANA, "OAuth Parameters", 676 . 678 [OpenID.Discovery] 679 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 680 Connect Discovery 1.0", August 2015, 681 . 684 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 685 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 686 August 2013, . 688 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 689 DOI 10.17487/RFC7517, May 2015, 690 . 692 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 693 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 694 . 696 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 697 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 698 RFC 7591, DOI 10.17487/RFC7591, July 2015, 699 . 701 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 702 RFC 7662, DOI 10.17487/RFC7662, October 2015, 703 . 705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 707 May 2017, . 709 Appendix A. Relationship to Token Binding 711 OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the 712 application of Token Binding to the various artifacts and tokens 713 employed throughout OAuth. That includes binding of an access token 714 to a Token Binding key, which bears some similarities in motivation 715 and design to the mutual TLS sender constrained resources access 716 defined in this document. Both documents define what is often called 717 a proof-of-possession security mechanism for access tokens, whereby a 718 client must demonstrate possession of cryptographic keying material 719 when accessing a protected resource. The details differ somewhat 720 between the two documents but both have the authorization server bind 721 the access token it issues to an asymmetric key pair on the client. 722 The client then proves possession of the private key from that pair 723 on the TLS connection over which the protected resource is accessed. 725 The two documents then are effectively competing specifications, at 726 least with respect to the binding of access tokens. Token Binding 727 uses bare keys that are generated on the client, which avoids many of 728 the difficulties of creating, distributing, and managing certificates 729 and has the potential to see wider scale adoption and deployment. 730 However, at the time of writing, Token Binding is fairly new and 731 there is relatively little support for it in available application 732 development platforms and tooling. Until better support for the 733 underlying core Token Binding specifications exists, practical 734 implementations of OAuth 2.0 Token Binding are infeasible. Despite 735 its name, Token Binding doesn't have a monopoly on the binding of 736 tokens. Mutual TLS, on the other hand, has been around for some time 737 and enjoys widespread support in web servers and development 738 platforms. Mutual TLS for OAuth 2.0 can be built and deployed now 739 using existing platforms and tools. There are emerging and immediate 740 scenarios, such as OAuth enabled financial transactions motivated by 741 regulatory requirements in some cases, which demand the additional 742 security protections of proof-of-possession access tokens. This 743 document aspires to provide standardized and expeditious solution for 744 those scenarios. 746 Appendix B. Acknowledgements 748 Scott "not Tomlinson" Tomilson and Matt Peterson were involved in 749 design and development work on a mutual TLS OAuth client 750 authentication implementation that informed some of the content of 751 this document. 753 Additionally, the authors would like to thank the following people 754 for their input and contributions to the specification: Sergey 755 Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Leif Johansson, Phil 756 Hunt, Takahiko Kawasaki, Sean Leonard, Kepeng Li, James Manger, Jim 757 Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and 758 Hannes Tschofenig. 760 Appendix C. Document(s) History 762 [[ to be removed by the RFC Editor before publication as an RFC ]] 764 draft-ietf-oauth-mtls-07 766 o Update to use the boilerplate from RFC 8174 768 draft-ietf-oauth-mtls-06 770 o Add an appendix section describing the relationship of this 771 document to OAuth Token Binding as requested during the the 772 Singapore meeting https://datatracker.ietf.org/doc/minutes- 773 100-oauth/ 774 o Add an explicit note that the implicit flow is not supported for 775 obtaining certificate bound access tokens as discussed at the 776 Singapore meeting https://datatracker.ietf.org/doc/minutes- 777 100-oauth/ 778 o Add/incorporate text to the Security Considerations on Certificate 779 Spoofing as suggested https://mailarchive.ietf.org/arch/msg/oauth/ 780 V26070X-6OtbVSeUz_7W2k94vCo 781 o Changed the title to be more descriptive 782 o Move the Security Considerations section to before the IANA 783 Considerations 784 o Elaborated on certificate bound access tokens a bit more in the 785 Abstract 786 o Update draft-ietf-oauth-discovery reference to -08 788 draft-ietf-oauth-mtls-05 790 o Editorial fixes 792 draft-ietf-oauth-mtls-04 794 o Change the name of the 'Public Key method' to the more accurate 795 'Self-Signed Certificate method' and also change the associated 796 authentication method metadata value to 797 "self_signed_tls_client_auth". 798 o Removed the "tls_client_auth_root_dn" client metadata field as 799 discussed in https://mailarchive.ietf.org/arch/msg/oauth/ 800 swDV2y0be6o8czGKQi1eJV-g8qc 802 o Update draft-ietf-oauth-discovery reference to -07 803 o Clarify that MTLS client authentication isn't exclusive to the 804 token endpoint and can be used with other endpoints, e.g. RFC 805 7009 revocation and 7662 introspection, that utilize client 806 authentication as discussed in 807 https://mailarchive.ietf.org/arch/msg/oauth/ 808 bZ6mft0G7D3ccebhOxnEYUv4puI 809 o Reorganize the document somewhat in an attempt to more clearly 810 make a distinction between mTLS client authentication and 811 certificate bound access tokens as well as a more clear 812 delineation between the two (PKI/Public key) methods for client 813 authentication 814 o Editorial fixes and clarifications 816 draft-ietf-oauth-mtls-03 818 o Introduced metadata and client registration parameter to publish 819 and request support for mutual TLS sender constrained access 820 tokens 821 o Added description of two methods of binding the cert and client, 822 PKI and Public Key. 823 o Indicated that the "tls_client_auth" authentication method is for 824 the PKI method and introduced "pub_key_tls_client_auth" for the 825 Public Key method 826 o Added implementation considerations, mainly regarding TLS stack 827 configuration and trust chain validation, as well as how to to do 828 binding of access tokens to a TLS client certificate for public 829 clients, and considerations around certificate bound access tokens 830 o Added new section to security considerations on cert spoofing 831 o Add text suggesting that a new cnf member be defined in the 832 future, if hash function(s) other than SHA-256 need to be used for 833 certificate thumbprints 835 draft-ietf-oauth-mtls-02 837 o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ 838 U46UMEh8XIOQnvXY9pHFq1MKPns 839 o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is 840 better than "Mutual TLS Profiles for OAuth Clients"). 842 draft-ietf-oauth-mtls-01 844 o Added more explicit details of using RFC 7662 token introspection 845 with mutual TLS sender constrained access tokens. 846 o Added an IANA OAuth Token Introspection Response Registration 847 request for "cnf". 849 o Specify that tls_client_auth_subject_dn and 850 tls_client_auth_root_dn are RFC 4514 String Representation of 851 Distinguished Names. 852 o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. 853 o Changed the text in the Section 3 to not be specific about using a 854 hash of the cert. 855 o Changed the abbreviated title to 'OAuth Mutual TLS' (previously 856 was the acronym MTLSPOC). 858 draft-ietf-oauth-mtls-00 860 o Created the initial working group version from draft-campbell- 861 oauth-mtls 863 draft-campbell-oauth-mtls-01 865 o Fix some typos. 866 o Add to the acknowledgements list. 868 draft-campbell-oauth-mtls-00 870 o Add a Mutual TLS sender constrained protected resource access 871 method and a x5t#S256 cnf method for JWT access tokens (concepts 872 taken in part from draft-sakimura-oauth-jpop-04). 873 o Fixed "token_endpoint_auth_methods_supported" to 874 "token_endpoint_auth_method" for client metadata. 875 o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" 876 client metadata parameters and mention using "jwks_uri" or "jwks". 877 o Say that the authentication method is determined by client policy 878 regardless of whether the client was dynamically registered or 879 statically configured. 880 o Expand acknowledgements to those that participated in discussions 881 around draft-campbell-oauth-tls-client-auth-00 882 o Add Nat Sakimura and Torsten Lodderstedt to the author list. 884 draft-campbell-oauth-tls-client-auth-00 886 o Initial draft. 888 Authors' Addresses 890 Brian Campbell 891 Ping Identity 893 Email: brian.d.campbell@gmail.com 894 John Bradley 895 Yubico 897 Email: ve7jtb@ve7jtb.com 898 URI: http://www.thread-safe.com/ 900 Nat Sakimura 901 Nomura Research Institute 903 Email: n-sakimura@nri.co.jp 904 URI: https://nat.sakimura.org/ 906 Torsten Lodderstedt 907 YES Europe AG 909 Email: torsten@lodderstedt.net