idnits 2.17.1 draft-ietf-oauth-mtls-06.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 15, 2018) is 2286 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: July 19, 2018 Yubico 6 N. Sakimura 7 Nomura Research Institute 8 T. Lodderstedt 9 YES Europe AG 10 January 15, 2018 12 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access 13 Tokens 14 draft-ietf-oauth-mtls-06 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 July 19, 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 RFC 139 2119 [RFC2119]. 141 1.2. Terminology 143 This specification uses the following phrases interchangeably: 145 Transport Layer Security (TLS) Mutual Authentication 147 Mutual TLS 149 These phrases all refer to the process whereby a client presents its 150 X.509 certificate and proves possession of the corresponding private 151 key to a server when negotiating a TLS session. In TLS 1.2 [RFC5246] 152 this requires the client to send Client Certificate and Certificate 153 Verify messages during the TLS handshake and for the server to verify 154 these messages. 156 2. Mutual TLS for OAuth Client Authentication 158 This section defines, as an extension of OAuth 2.0, Section 2.3 159 [RFC6749], two distinct methods of using mutual TLS X.509 client 160 certificates as client credentials. The requirement of mutual TLS 161 for client authentication is determined by the authorization server 162 based on policy or configuration for the given client (regardless of 163 whether the client was dynamically registered or statically 164 configured or otherwise established). 166 In order to utilize TLS for OAuth client authentication, the TLS 167 connection between the client and the authorization server MUST have 168 been established or reestablished with mutual X.509 certificate 169 authentication (i.e. the Client Certificate and Certificate Verify 170 messages are sent during the TLS Handshake [RFC5246]). 172 For all requests to the authorization server utilizing mutual TLS 173 client authentication, the client MUST include the "client_id" 174 parameter, described in OAuth 2.0, Section 2.2 [RFC6749]. The 175 presence of the "client_id" parameter enables the authorization 176 server to easily identify the client independently from the content 177 of the certificate. The authorization server can locate the client 178 configuration using the client identifier and check the certificate 179 presented in the TLS Handshake against the expected credentials for 180 that client. The authorization server MUST enforce some method of 181 binding a certificate to a client. Sections Section 2.1 and 182 Section 2.2 below define two ways of binding a certificate to a 183 client as two distinct client authentication methods. 185 2.1. PKI Mutual TLS OAuth Client Authentication Method 187 The PKI (public key infrastructure) method of mutual TLS OAuth client 188 authentication uses a subject distinguished name (DN) and validated 189 certificate chain to identify the client. The TLS handshake is 190 utilized to validate the client's possession of the private key 191 corresponding to the public key in the certificate and to validate 192 the corresponding certificate chain. The client is successfully 193 authenticated if the subject information in the certificate matches 194 the expected DN configured or registered for that particular client. 195 The PKI method facilitates the way X.509 certificates are 196 traditionally being used for authentication. It also allows the 197 client to rotate its X.509 certificates without the need to modify 198 its respective authentication data at the authorization server by 199 obtaining a new certificate with the same subject DN from a trusted 200 certificate authority (CA). 202 2.1.1. PKI Authentication Method Metadata Value 204 The "OAuth Token Endpoint Authentication Methods" registry 205 [IANA.OAuth.Parameters] contains values, each of which specify a 206 method of authenticating a client to the authorization server. The 207 values are used to indicate supported and utilized client 208 authentication methods in authorization server metadata, such as 209 OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0 210 Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the 211 OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the 212 PKI method of mutual TLS client authentication, this specification 213 defines and registers the following authentication method metadata 214 value. 216 tls_client_auth 217 Indicates that client authentication to the authorization server 218 will occur with mutual TLS utilizing the PKI method of associating 219 a certificate to a client. 221 2.1.2. Client Registration Metadata 223 The following metadata parameter is introduced for the OAuth 2.0 224 Dynamic Client Registration Protocol [RFC7591] in support of the PKI 225 method of binding a certificate to a client: 227 tls_client_auth_subject_dn 228 An [RFC4514] string representation of the expected subject 229 distinguished name of the certificate the OAuth client will use in 230 mutual TLS authentication. 232 2.2. Self-Signed Certificate Mutual TLS OAuth Client Authentication 233 Method 235 This method of mutual TLS OAuth client authentication is intended to 236 support client authentication using self-signed certificates. As 237 pre-requisite, the client registers an X.509 certificate or a trusted 238 source for its X.509 certificates (such as the "jwks_uri" as defined 239 in [RFC7591]) with the authorization server. During authentication, 240 TLS is utilized to validate the client's possession of the private 241 key corresponding to the public key presented within the certificate 242 in the respective TLS handshake. In contrast to the PKI method, the 243 certificate chain is not validated in this case. The client is 244 successfully authenticated, if the subject public key info of the 245 certificate matches the subject public key info of one of the 246 certificates configured or registered for that particular client. 247 The Self-Signed Certificate method allows to use mutual TLS to 248 authenticate clients without the need to maintain a PKI. When used 249 in conjunction with a "jwks_uri" for the client, it also allows the 250 client to rotate its X.509 certificates without the need to change 251 its respective authentication data directly with the authorization 252 server. 254 2.2.1. Self-Signed Certificate Authentication Method Metadata Value 256 The "OAuth Token Endpoint Authentication Methods" registry 257 [IANA.OAuth.Parameters] contains values, each of which specify a 258 method of authenticating a client to the authorization server. The 259 values are used to indicate supported and utilized client 260 authentication methods in authorization server metadata, such as 261 OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0 262 Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the 263 OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the 264 Self-Signed Certificate method of binding a certificate to a client 265 using mutual TLS client authentication, this specification defines 266 and registers the following authentication method metadata value. 268 self_signed_tls_client_auth 269 Indicates that client authentication to the authorization server 270 will occur using mutual TLS with the client utilizing a self- 271 signed certificate. 273 2.2.2. Client Registration Metadata 275 For the Self-Signed Certificate method of binding a certificate to a 276 client using mutual TLS client authentication, the existing 277 "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to 278 convey the client's certificates and public keys, where the X.509 279 certificates are represented using the JSON Web Key (JWK) [RFC7517] 280 "x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key 281 in the first certificate of the "x5c" parameter must match the public 282 key represented by other members of the JWK). 284 3. Mutual TLS Sender Constrained Resources Access 286 When mutual TLS is used by the client on the connection to the token 287 endpoint, the authorization server is able to bind the issued access 288 token to the client certificate. Such a binding is accomplished by 289 associating the certificate with the token in a way that can be 290 accessed by the protected resource, such as embedding the certificate 291 hash in the issued access token directly, using the syntax described 292 in Section 3.1, or through token introspection as described in 293 Section 3.2. Other methods of associating a certificate with an 294 access token are possible, per agreement by the authorization server 295 and the protected resource, but are beyond the scope of this 296 specification. 298 The client makes protected resource requests as described in 299 [RFC6750], however, those requests MUST be made over a mutually 300 authenticated TLS connection using the same certificate that was used 301 for mutual TLS at the token endpoint. 303 The protected resource MUST obtain the client certificate used for 304 mutual TLS authentication and MUST verify that the certificate 305 matches the certificate associated with the access token. If they do 306 not match, the resource access attempt MUST be rejected with an error 307 per [RFC6750] using an HTTP 401 status code and the "invalid_token" 308 error code. 310 Metadata to convey server and client capabilities for mutual TLS 311 sender constrained access tokens is defined in Section 3.3 and 312 Section 3.4 respectively. 314 3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 316 When access tokens are represented as JSON Web Tokens (JWT)[RFC7519], 317 the certificate hash information SHOULD be represented using the 318 "x5t#S256" confirmation method member defined herein. 320 To represent the hash of a certificate in a JWT, this specification 321 defines the new JWT Confirmation Method RFC 7800 [RFC7800] member 322 "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value 323 of the "x5t#S256" member is a base64url-encoded SHA-256[SHS] hash 324 (a.k.a. thumbprint or digest) of the DER encoding of the X.509 325 certificate[RFC5280] (note that certificate thumbprints are also 326 sometimes known as certificate fingerprints). 328 The following is an example of a JWT payload containing an "x5t#S256" 329 certificate thumbprint confirmation method. 331 { 332 "iss": "https://server.example.com", 333 "sub": "ty.webb@example.com", 334 "exp": 1493726400, 335 "nbf": 1493722800, 336 "cnf":{ 337 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 338 } 339 } 341 Figure 1: Example claims of a Certificate Thumbprint Constrained JWT 343 If, in the future, certificate thumbprints need to be computed using 344 hash functions other than SHA-256, it is suggested that additional 345 related JWT confirmation methods members be defined for that purpose. 346 For example, a new "x5t#S512" (X.509 Certificate Thumbprint using 347 SHA-512) confirmation method member could be defined by registering 348 it in the the IANA "JWT Confirmation Methods" registry 349 [IANA.JWT.Claims] for JWT "cnf" member values established by 350 [RFC7800]. 352 3.2. Confirmation Method for Token Introspection 354 OAuth 2.0 Token Introspection [RFC7662] defines a method for a 355 protected resource to query an authorization server about the active 356 state of an access token as well as to determine meta-information 357 about the token. 359 For a mutual TLS sender constrained access token, the hash of the 360 certificate to which the token is bound is conveyed to the protected 361 resource as meta-information in a token introspection response. The 362 hash is conveyed using the same structure as the certificate SHA-256 363 thumbprint confirmation method, described in Section 3.1, as a top- 364 level member of the introspection response JSON. The protected 365 resource compares that certificate hash to a hash of the client 366 certificate used for mutual TLS authentication and rejects the 367 request, if they do not match. 369 Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] 370 defined the "cnf" (confirmation) claim, which enables confirmation 371 key information to be carried in a JWT. However, the same proof-of- 372 possession semantics are also useful for introspected access tokens 373 whereby the protected resource obtains the confirmation key data as 374 meta-information of a token introspection response and uses that 375 information in verifying proof-of-possession. Therefore this 376 specification defines and registers proof-of-possession semantics for 377 OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. 378 When included as a top-level member of an OAuth token introspection 379 response, "cnf" has the same semantics and format as the claim of the 380 same name defined in [RFC7800]. While this specification only 381 explicitly uses the "x5t#S256" confirmation method member, it needed 382 to define and register the higher level "cnf" structure as an 383 introspection response member in order to define and use its more 384 specific "x5t#S256" confirmation method. 386 The following is an example of an introspection response for an 387 active token with an "x5t#S256" certificate thumbprint confirmation 388 method. 390 HTTP/1.1 200 OK 391 Content-Type: application/json 393 { 394 "active": true, 395 "iss": "https://server.example.com", 396 "sub": "ty.webb@example.com", 397 "exp": 1493726400, 398 "nbf": 1493722800, 399 "cnf":{ 400 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 401 } 402 } 404 Figure 2: Example Introspection Response for a Certificate 405 Constrained Access Token 407 3.3. Authorization Server Metadata 409 This document introduces the following new authorization server 410 metadata parameter to signal the server's capability to issue 411 certificate bound access tokens: 413 mutual_tls_sender_constrained_access_tokens 414 OPTIONAL. Boolean value indicating server support for mutual TLS 415 sender constrained access tokens. If omitted, the default value 416 is "false". 418 3.4. Client Registration Metadata 420 The following new client metadata parameter is introduced to convey 421 the client's intention to use certificate bound access tokens: 423 mutual_tls_sender_constrained_access_tokens 424 OPTIONAL. Boolean value used to indicate the client's intention 425 to use mutual TLS sender constrained access tokens. If omitted, 426 the default value is "false". 428 4. Implementation Considerations 430 4.1. Authorization Server 432 The authorization server needs to setup its TLS configuration 433 appropriately for the binding methods it supports. 435 If the authorization server wants to support mutual TLS client 436 authentication and other client authentication methods in parallel, 437 it should make mutual TLS optional. 439 If the authorization server supports the Self-Signed Certificate 440 method, it should configure the TLS stack in a way that it does not 441 verify whether the certificate presented by the client during the 442 handshake is signed by a trusted CA certificate. 444 The authorization server may also consider hosting the token 445 endpoint, and other endpoints requiring client authentication, on a 446 separate host name in order to prevent unintended impact on the TLS 447 behavior of its other endpoints, e.g. authorization or registration. 449 4.2. Resource Server 451 From the perspective of the resource server, TLS client 452 authentication is used as a proof of possession method only. For the 453 purpose of client authentication, the resource server may completely 454 rely on the authorization server. So there is no need to validate 455 the trust chain of the client's certificate in any of the methods 456 defined in this document. The resource server should therefore 457 configure the TLS stack in a way that it does not verify whether the 458 certificate presented by the client during the handshake is signed by 459 a trusted CA certificate. 461 4.3. Sender Constrained Access Tokens Without Client Authentication 463 This document allows use of client authentication only or client 464 authentication in combination with sender constraint access tokens. 465 Use of mutual TLS sender constrained access tokens without client 466 authentication (e.g. to support binding access tokens to a TLS client 467 certificate for public clients) is also possible. The authorization 468 server would configure the TLS stack in the same manner as for the 469 Self-Signed Certificate method such that it does not verify that the 470 certificate presented by the client during the handshake is signed by 471 a trusted CA. Individual instances of a public client would then 472 create a self-signed certificate for mutual TLS with the 473 authorization server and resource server. The authorization server 474 would not authenticate the client at the OAuth layer but would bind 475 issued access tokens to the certificate, which the client has proven 476 possession of the corresponding private key. The access token is 477 then mutual TLS sender constrained and can only be used by the client 478 possessing the certificate and private key and utilizing them to 479 negotiate mutual TLS on connections to the resource server. 481 4.4. Certificate Bound Access Tokens 483 As described in Section 3, an access token is bound to a specific 484 client certificate, which means that the same certificate must be 485 used for mutual TLS on protected resource access. It also implies 486 that access tokens are invalidated when a client updates the 487 certificate, which can be handled similar to expired access tokens 488 where the client requests a new access token (typically with a 489 refresh token) and retries the protected resource request. 491 4.5. Implicit Grant Unsupported 493 This document describes binding an access token to the client 494 certificate presented on the TLS connection from the client to the 495 authorization server's token endpoint, however, certificate binding 496 of access tokens issued directly from the authorization endpoint via 497 the implicit grant flow is explicitly out of scope. End users 498 interact directly with the authorization endpoint using a web browser 499 and the use of client certificates in user's browsers bring 500 operational and usability issues, which make it undesirable to 501 support certificate bound access tokens issued in the implicit grant 502 flow. Implementations wanting to employ certificate bound sender 503 constrained access tokens should utilize grant types that involve the 504 client making an access token request directly to the token endpoint 505 (e.g. the authorization code and refresh token grant types). 507 5. Security Considerations 509 5.1. TLS Versions and Best Practices 511 TLS 1.2 [RFC5246] is cited in this document because, at the time of 512 writing, it is the latest version that is widely deployed. However, 513 this document is applicable with other TLS versions supporting 514 certificate-based client authentication. Implementation security 515 considerations for TLS, including version recommendations, can be 516 found in Recommendations for Secure Use of Transport Layer Security 517 (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]. 519 5.2. X.509 Certificate Spoofing 521 If the PKI method of client authentication is used, an attacker could 522 try to impersonate a client using a certificate with the same subject 523 DN but issued by a different CA, which the authorization server 524 trusts. To cope with that threat, the authorization server should 525 only accept as trust anchors a limited number of CAs whose 526 certificate issuance policy meets its security requirements. There 527 is an assumption then that the client and server agree on the set of 528 trust anchors that the server uses to create and validate the 529 certificate chain. Without this assumption the use of a Subject DN 530 to identify the client certificate would open the server up to 531 certificate spoofing attacks. 533 6. IANA Considerations 535 6.1. JWT Confirmation Methods Registration 537 This specification requests registration of the following value in 538 the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for 539 JWT "cnf" member values established by [RFC7800]. 541 o Confirmation Method Value: "x5t#S256" 542 o Confirmation Method Description: X.509 Certificate SHA-256 543 Thumbprint 544 o Change Controller: IESG 545 o Specification Document(s): Section 3.1 of [[ this specification ]] 547 6.2. OAuth Authorization Server Metadata Registration 549 This specification requests registration of the following value in 550 the IANA "OAuth Authorization Server Metadata" registry 551 [IANA.OAuth.Parameters] established by [I-D.ietf-oauth-discovery]. 553 o Metadata Name: "mutual_tls_sender_constrained_access_tokens" 554 o Metadata Description: Indicates authorization server support for 555 mutual TLS sender constrained access tokens. 556 o Change Controller: IESG 557 o Specification Document(s): Section 3.3 of [[ this specification ]] 559 6.3. Token Endpoint Authentication Method Registration 561 This specification requests registration of the following value in 562 the IANA "OAuth Token Endpoint Authentication Methods" registry 563 [IANA.OAuth.Parameters] established by [RFC7591]. 565 o Token Endpoint Authentication Method Name: "tls_client_auth" 566 o Change Controller: IESG 567 o Specification Document(s): Section 2.1.1 of [[ this specification 568 ]] 570 o Token Endpoint Authentication Method Name: 571 "self_signed_tls_client_auth" 572 o Change Controller: IESG 573 o Specification Document(s): Section 2.2.1 of [[ this specification 574 ]] 576 6.4. OAuth Token Introspection Response Registration 578 This specification requests registration of the following value in 579 the IANA "OAuth Token Introspection Response" registry 580 [IANA.OAuth.Parameters] established by [RFC7662]. 582 o Claim Name: "cnf" 583 o Claim Description: Confirmation 584 o Change Controller: IESG 585 o Specification Document(s): Section 3.2 of [[ this specification ]] 587 6.5. OAuth Dynamic Client Registration Metadata Registration 589 This specification requests registration of the following client 590 metadata definitions in the IANA "OAuth Dynamic Client Registration 591 Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: 593 o Client Metadata Name: 594 "mutual_tls_sender_constrained_access_tokens" 595 o Client Metadata Description: Indicates the client's intention to 596 use mutual TLS sender constrained access tokens. 597 o Change Controller: IESG 598 o Specification Document(s): Section 3.4 of [[ this specification ]] 600 o Client Metadata Name: "tls_client_auth_subject_dn" 601 o Client Metadata Description: String value specifying the expected 602 subject distinguished name of the client certificate. 603 o Change Controller: IESG 604 o Specification Document(s): Section 2.1.2 of [[ this specification 605 ]] 607 7. References 609 7.1. Normative References 611 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 612 "Recommendations for Secure Use of Transport Layer 613 Security (TLS) and Datagram Transport Layer Security 614 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 615 2015, . 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 623 (LDAP): String Representation of Distinguished Names", 624 RFC 4514, DOI 10.17487/RFC4514, June 2006, 625 . 627 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 628 (TLS) Protocol Version 1.2", RFC 5246, 629 DOI 10.17487/RFC5246, August 2008, 630 . 632 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 633 Housley, R., and W. Polk, "Internet X.509 Public Key 634 Infrastructure Certificate and Certificate Revocation List 635 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 636 . 638 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 639 RFC 6749, DOI 10.17487/RFC6749, October 2012, 640 . 642 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 643 Framework: Bearer Token Usage", RFC 6750, 644 DOI 10.17487/RFC6750, October 2012, 645 . 647 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 648 Possession Key Semantics for JSON Web Tokens (JWTs)", 649 RFC 7800, DOI 10.17487/RFC7800, April 2016, 650 . 652 [SHS] National Institute of Standards and Technology, "Secure 653 Hash Standard (SHS)", FIPS PUB 180-4, March 2012, 654 . 657 7.2. Informative References 659 [I-D.ietf-oauth-discovery] 660 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 661 Authorization Server Metadata", draft-ietf-oauth- 662 discovery-08 (work in progress), November 2017. 664 [I-D.ietf-oauth-token-binding] 665 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 666 "OAuth 2.0 Token Binding", draft-ietf-oauth-token- 667 binding-05 (work in progress), October 2017. 669 [IANA.JWT.Claims] 670 IANA, "JSON Web Token Claims", 671 . 673 [IANA.OAuth.Parameters] 674 IANA, "OAuth Parameters", 675 . 677 [OpenID.Discovery] 678 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 679 Connect Discovery 1.0", August 2015, 680 . 683 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 684 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 685 August 2013, . 687 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 688 DOI 10.17487/RFC7517, May 2015, 689 . 691 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 692 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 693 . 695 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 696 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 697 RFC 7591, DOI 10.17487/RFC7591, July 2015, 698 . 700 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 701 RFC 7662, DOI 10.17487/RFC7662, October 2015, 702 . 704 Appendix A. Relationship to Token Binding 706 OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the 707 application of Token Binding to the various artifacts and tokens 708 employed throughout OAuth. That includes binding of an access token 709 to a Token Binding key, which bears some similarities in motivation 710 and design to the mutual TLS sender constrained resources access 711 defined in this document. Both documents define what is often called 712 a proof-of-possession security mechanism for access tokens, whereby a 713 client must demonstrate possession of cryptographic keying material 714 when accessing a protected resource. The details differ somewhat 715 between the two documents but both have the authorization server bind 716 the access token it issues to an asymmetric key pair on the client. 717 The client then proves possession of the private key from that pair 718 on the TLS connection over which the protected resource is accessed. 720 The two documents then are effectively competing specifications, at 721 least with respect to the binding of access tokens. Token Binding 722 uses bare keys that are generated on the client, which avoids many of 723 the difficulties of creating, distributing, and managing certificates 724 and has the potential to see wider scale adoption and deployment. 725 However, at the time of writing, Token Binding is fairly new and 726 there is relatively little support for it in available application 727 development platforms and tooling. Until better support for the 728 underlying core Token Binding specifications exists, practical 729 implementations of OAuth 2.0 Token Binding are infeasible. Despite 730 its name, Token Binding doesn't have a monopoly on the binding of 731 tokens. Mutual TLS, on the other hand, has been around for some time 732 and enjoys widespread support in web servers and development 733 platforms. Mutual TLS for OAuth 2.0 can be built and deployed now 734 using existing platforms and tools. There are emerging and immediate 735 scenarios, such as OAuth enabled financial transactions motivated by 736 regulatory requirements in some cases, which demand the additional 737 security protections of proof-of-possession access tokens. This 738 document aspires to provide standardized and expeditious solution for 739 those scenarios. 741 Appendix B. Acknowledgements 743 Scott "not Tomlinson" Tomilson and Matt Peterson were involved in 744 design and development work on a mutual TLS OAuth client 745 authentication implementation that informed some of the content of 746 this document. 748 Additionally, the authors would like to thank the following people 749 for their input and contributions to the specification: Sergey 750 Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Leif Johansson, Phil 751 Hunt, Takahiko Kawasaki, Sean Leonard, Kepeng Li, James Manger, Jim 752 Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and 753 Hannes Tschofenig. 755 Appendix C. Document(s) History 757 [[ to be removed by the RFC Editor before publication as an RFC ]] 759 draft-ietf-oauth-mtls-06 761 o Add an appendix section describing the relationship of this 762 document to OAuth Token Binding as requested during the the 763 Singapore meeting https://datatracker.ietf.org/doc/minutes- 764 100-oauth/ 765 o Add an explicit note that the implicit flow is not supported for 766 obtaining certificate bound access tokens as discussed at the 767 Singapore meeting https://datatracker.ietf.org/doc/minutes- 768 100-oauth/ 769 o Add/incorporate text to the Security Considerations on Certificate 770 Spoofing as suggested https://mailarchive.ietf.org/arch/msg/oauth/ 771 V26070X-6OtbVSeUz_7W2k94vCo 772 o Changed the title to be more descriptive 773 o Move the Security Considerations section to before the IANA 774 Considerations 775 o Elaborated on certificate bound access tokens a bit more in the 776 Abstract 777 o Update draft-ietf-oauth-discovery reference to -08 779 draft-ietf-oauth-mtls-05 781 o Editorial fixes 783 draft-ietf-oauth-mtls-04 785 o Change the name of the 'Public Key method' to the more accurate 786 'Self-Signed Certificate method' and also change the associated 787 authentication method metadata value to 788 "self_signed_tls_client_auth". 789 o Removed the "tls_client_auth_root_dn" client metadata field as 790 discussed in https://mailarchive.ietf.org/arch/msg/oauth/ 791 swDV2y0be6o8czGKQi1eJV-g8qc 792 o Update draft-ietf-oauth-discovery reference to -07 793 o Clarify that MTLS client authentication isn't exclusive to the 794 token endpoint and can be used with other endpoints, e.g. RFC 795 7009 revocation and 7662 introspection, that utilize client 796 authentication as discussed in 797 https://mailarchive.ietf.org/arch/msg/oauth/ 798 bZ6mft0G7D3ccebhOxnEYUv4puI 800 o Reorganize the document somewhat in an attempt to more clearly 801 make a distinction between mTLS client authentication and 802 certificate bound access tokens as well as a more clear 803 delineation between the two (PKI/Public key) methods for client 804 authentication 805 o Editorial fixes and clarifications 807 draft-ietf-oauth-mtls-03 809 o Introduced metadata and client registration parameter to publish 810 and request support for mutual TLS sender constrained access 811 tokens 812 o Added description of two methods of binding the cert and client, 813 PKI and Public Key. 814 o Indicated that the "tls_client_auth" authentication method is for 815 the PKI method and introduced "pub_key_tls_client_auth" for the 816 Public Key method 817 o Added implementation considerations, mainly regarding TLS stack 818 configuration and trust chain validation, as well as how to to do 819 binding of access tokens to a TLS client certificate for public 820 clients, and considerations around certificate bound access tokens 821 o Added new section to security considerations on cert spoofing 822 o Add text suggesting that a new cnf member be defined in the 823 future, if hash function(s) other than SHA-256 need to be used for 824 certificate thumbprints 826 draft-ietf-oauth-mtls-02 828 o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ 829 U46UMEh8XIOQnvXY9pHFq1MKPns 830 o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is 831 better than "Mutual TLS Profiles for OAuth Clients"). 833 draft-ietf-oauth-mtls-01 835 o Added more explicit details of using RFC 7662 token introspection 836 with mutual TLS sender constrained access tokens. 837 o Added an IANA OAuth Token Introspection Response Registration 838 request for "cnf". 839 o Specify that tls_client_auth_subject_dn and 840 tls_client_auth_root_dn are RFC 4514 String Representation of 841 Distinguished Names. 842 o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. 843 o Changed the text in the Section 3 to not be specific about using a 844 hash of the cert. 845 o Changed the abbreviated title to 'OAuth Mutual TLS' (previously 846 was the acronym MTLSPOC). 848 o Created the initial working group version from draft-campbell- 849 oauth-mtls 851 draft-campbell-oauth-mtls-01 853 o Fix some typos. 854 o Add to the acknowledgements list. 856 draft-campbell-oauth-mtls-00 858 o Add a Mutual TLS sender constrained protected resource access 859 method and a x5t#S256 cnf method for JWT access tokens (concepts 860 taken in part from draft-sakimura-oauth-jpop-04). 861 o Fixed "token_endpoint_auth_methods_supported" to 862 "token_endpoint_auth_method" for client metadata. 863 o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" 864 client metadata parameters and mention using "jwks_uri" or "jwks". 865 o Say that the authentication method is determined by client policy 866 regardless of whether the client was dynamically registered or 867 statically configured. 868 o Expand acknowledgements to those that participated in discussions 869 around draft-campbell-oauth-tls-client-auth-00 870 o Add Nat Sakimura and Torsten Lodderstedt to the author list. 872 draft-campbell-oauth-tls-client-auth-00 874 o Initial draft. 876 Authors' Addresses 878 Brian Campbell 879 Ping Identity 881 Email: brian.d.campbell@gmail.com 883 John Bradley 884 Yubico 886 Email: ve7jtb@ve7jtb.com 887 URI: http://www.thread-safe.com/ 888 Nat Sakimura 889 Nomura Research Institute 891 Email: n-sakimura@nri.co.jp 892 URI: https://nat.sakimura.org/ 894 Torsten Lodderstedt 895 YES Europe AG 897 Email: torsten@lodderstedt.net