idnits 2.17.1 draft-ietf-oauth-mtls-04.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 (October 11, 2017) is 2388 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-07 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group B. Campbell 3 Internet-Draft Ping Identity 4 Intended status: Standards Track J. Bradley 5 Expires: April 14, 2018 Yubico 6 N. Sakimura 7 Nomura Research Institute 8 T. Lodderstedt 9 YES Europe AG 10 October 11, 2017 12 Mutual TLS Profile for OAuth 2.0 13 draft-ietf-oauth-mtls-04 15 Abstract 17 This document describes Transport Layer Security (TLS) mutual 18 authentication using X.509 certificates as a mechanism for OAuth 19 client authentication to the authorization sever as well as for 20 certificate bound sender constrained access tokens. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 14, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 4 60 2.1. PKI Mutual TLS OAuth Client Authentication Method . . . . 4 61 2.1.1. PKI Authentication Method Metadata Value . . . . . . 5 62 2.1.2. Client Registration Metadata . . . . . . . . . . . . 5 63 2.2. Self-Signed Certificate Mutual TLS OAuth Client 64 Authentication Method . . . . . . . . . . . . . . . . . . 5 65 2.2.1. Self-Signed Certificate Authentication Method 66 Metadata Value . . . . . . . . . . . . . . . . . . . 6 67 2.2.2. Client Registration Metadata . . . . . . . . . . . . 6 68 3. Mutual TLS Sender Constrained Resources Access . . . . . . . 6 69 3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 7 70 3.2. Confirmation Method for Token Introspection . . . . . . . 8 71 3.3. Authorization Server Metadata . . . . . . . . . . . . . . 9 72 3.4. Client Registration Metadata . . . . . . . . . . . . . . 9 73 4. Implementation Considerations . . . . . . . . . . . . . . . . 10 74 4.1. Authorization Server . . . . . . . . . . . . . . . . . . 10 75 4.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 10 76 4.3. Sender Constrained Access Tokens Without Client 77 Authentication . . . . . . . . . . . . . . . . . . . . . 10 78 4.4. Certificate Bound Access Tokens . . . . . . . . . . . . . 11 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. JWT Confirmation Methods Registration . . . . . . . . . . 11 81 5.2. OAuth Authorization Server Metadata Registration . . . . 11 82 5.3. Token Endpoint Authentication Method Registration . . . . 12 83 5.4. OAuth Token Introspection Response Registration . . . . . 12 84 5.5. OAuth Dynamic Client Registration Metadata Registration . 12 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 6.1. TLS Versions and Best Practices . . . . . . . . . . . . . 13 87 6.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 13 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 7.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 92 Appendix B. Document(s) History . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 95 1. Introduction 97 This document describes Transport Layer Security (TLS) mutual 98 authentication using X.509 certificates as a mechanism for OAuth 99 client authentication to the authorization sever as well as for 100 sender constrained access to OAuth protected resources. 102 The OAuth 2.0 Authorization Framework [RFC6749] defines a shared 103 secret method of client authentication but also allows for the 104 definition and use of additional client authentication mechanisms 105 when interacting directly with the authorization server. This 106 document describes an additional mechanism of client authentication 107 utilizing mutual TLS [RFC5246] certificate-based authentication, 108 which provides better security characteristics than shared secrets. 109 While [RFC6749] documents client authentication for requests to the 110 token endpoint, extensions to OAuth 2.0 (such as Introspection 111 [RFC7662] and Revocation [RFC7009]) define endpoints that also 112 utilize client authentication and the mutual TLS methods defined 113 herein are applicable to those endpoints as well. 115 Mutual TLS sender constrained access to protected resources ensures 116 that only the party in possession of the private key corresponding to 117 the certificate can utilize the access token to get access to the 118 associated resources. Such a constraint is unlike the case of the 119 basic bearer token described in [RFC6750], where any party in 120 possession of the access token can use it to access the associated 121 resources. Mutual TLS sender constrained access binds the access 122 token to the client's certificate thus preventing the use of stolen 123 access tokens or replay of access tokens by unauthorized parties. 125 Mutual TLS sender constrained access tokens and mutual TLS client 126 authentication are distinct mechanisms, which are complementary but 127 don't necessarily need to be deployed together. 129 1.1. Requirements Notation and Conventions 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in RFC 134 2119 [RFC2119]. 136 1.2. Terminology 138 This specification uses the following phrases interchangeably: 140 Transport Layer Security (TLS) Mutual Authentication 142 Mutual TLS 144 These phrases all refer to the process whereby a client presents its 145 X.509 certificate and proves possession of the corresponding private 146 key to a server when negotiating a TLS session. In TLS 1.2 [RFC5246] 147 this requires the client to send Client Certificate and Certificate 148 Verify messages during the TLS handshake and for the server to verify 149 these messages. 151 2. Mutual TLS for OAuth Client Authentication 153 This section defines, as an extension of OAuth 2.0, Section 2.3 154 [RFC6749], two distinct methods of using mutual TLS X.509 client 155 certificates as client credentials. The requirement of mutual TLS 156 for client authentications is determined by the authorization server 157 based on policy or configuration for the given client (regardless of 158 whether the client was dynamically registered or statically 159 configured or otherwise established). 161 In order to utilize TLS for OAuth client authentication, the TLS 162 connection between the client and the authorization server MUST have 163 been established or reestablished with mutual X.509 certificate 164 authentication (i.e. the Client Certificate and Certificate Verify 165 messages are sent during the TLS Handshake [RFC5246]). 167 For all requests to the authorization server utilizing mutual TLS 168 client authentication, the client MUST include the "client_id" 169 parameter, described in OAuth 2.0, Section 2.2 [RFC6749]. The 170 presence of the "client_id" parameter enables the authorization 171 server to easily identify the client independently from the content 172 of the certificate. The authorization server can locate the client 173 configuration using the client identifier and check the certificate 174 presented in the TLS Handshake against the expected credentials for 175 that client. The authorization server MUST enforce some method of 176 binding a certificate to a client. Sections Section 2.1 and 177 Section 2.2 below define two ways of binding a certificate to a 178 client as two distinct client authentication methods. 180 2.1. PKI Mutual TLS OAuth Client Authentication Method 182 The PKI (public key infrastructure) method of mutual TLS OAuth client 183 authentication uses a subject distinguished name (DN) and validated 184 certificate chain to identify the client. The TLS handshake is 185 utilized to validate the client's possession of the private key 186 corresponding to the public key in the certificate and to validate 187 the corresponding certificate chain. The client is successfully 188 authenticated if the subject information in the certificate matches 189 the expected DN configured or registered for that particular client. 190 The PKI method facilitates the way X.509 certificates are 191 traditionally being used for authentication. It also allows the 192 client to rotate its X.509 certificates without the need to modify 193 its respective authentication data at the authorization server by 194 obtaining a new certificate with the same subject DN from a trusted 195 certificate authority (CA). 197 2.1.1. PKI Authentication Method Metadata Value 199 The "OAuth Token Endpoint Authentication Methods" registry 200 [IANA.OAuth.Parameters] contains values, each of which specify a 201 method of authenticating a client to the authorization server. The 202 values are used to indicated supported and utilized client 203 authentication methods in authorization server metadata, such as 204 OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0 205 Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the 206 OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the 207 PKI method of mutual TLS client authentication, this specification 208 defines and registers the following authentication method metadata 209 value. 211 tls_client_auth 212 Indicates that client authentication to the authorization server 213 will occur with mutual TLS utilizing the PKI method of associating 214 a certificate to a client. 216 2.1.2. Client Registration Metadata 218 The following metadata parameter is introduced for the OAuth 2.0 219 Dynamic Client Registration Protocol [RFC7591] in support of the PKI 220 method of binding a certificate to a client: 222 tls_client_auth_subject_dn 223 An [RFC4514] string representation of the expected subject 224 distinguished name of the certificate the OAuth client will use in 225 mutual TLS authentication. 227 2.2. Self-Signed Certificate Mutual TLS OAuth Client Authentication 228 Method 230 This method of mutual TLS OAuth client authentication is intended to 231 support client authentication using self-signed certificates. As 232 pre-requisite, the client registers a X.509 certificate or a trusted 233 source for its X.509 certificates (such as the "jwks_uri" as defined 234 in [RFC7591]) with the authorization server. During authentication, 235 TLS is utilized to validate the client's possession of the private 236 key corresponding to the public key presented within the certificate 237 in the respective TLS handshake. In contrast to the PKI method, the 238 certificate chain is not validated in this case. The client is 239 successfully authenticated, if the subject public key info of the 240 certificate matches the subject public key info of one the 241 certificates configured or registered for that particular client. 242 The Self-Signed Certificate method allows to use mutual TLS to 243 authenticate clients without the need to maintain a PKI. When used 244 in conjunction with a "jwks_uri" for the client, it also allows the 245 client to rotate its X.509 certificates without the need to change 246 its respective authentication data directly with at the authorization 247 server. 249 2.2.1. Self-Signed Certificate Authentication Method Metadata Value 251 The "OAuth Token Endpoint Authentication Methods" registry 252 [IANA.OAuth.Parameters] contains values, each of which specify a 253 method of authenticating a client to the authorization server. The 254 values are used to indicated supported and utilized client 255 authentication methods in authorization server metadata, such as 256 OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0 257 Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the 258 OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the 259 Self-Signed Certificate method of binding a certificate to a client 260 using mutual TLS client authentication, this specification defines 261 and registers the following authentication method metadata value. 263 self_signed_tls_client_auth 264 Indicates that client authentication to the authorization server 265 will occur using mutual TLS with the client utilizing a self- 266 signed certificate. 268 2.2.2. Client Registration Metadata 270 For the Self-Signed Certificate method of binding a certificate to a 271 client using mutual TLS client authentication, the existing 272 "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to 273 convey client's certificates and public keys, where the X.509 274 certificates are represented using the JSON Web Key (JWK) [RFC7517] 275 "x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key 276 in the first certificate of the "x5c" parameter must match the public 277 key represented by other members of the JWK). 279 3. Mutual TLS Sender Constrained Resources Access 281 When mutual TLS is used at the token endpoint, the authorization 282 server is able to bind the issued access token to the client 283 certificate. Such a binding is accomplished by associating the 284 certificate with the token in a way that can be accessed by the 285 protected resource, such as embedding the certificate hash in the 286 issued access token directly, using the syntax described in 287 Section 3.1, or through token introspection as described in 288 Section 3.2. Other methods of associating a certificate with an 289 access token are possible, per agreement by the authorization server 290 and the protected resource, but are beyond the scope of this 291 specification. 293 The client makes protected resource requests as described in 294 [RFC6750], however, those requests MUST be made over a mutually 295 authenticated TLS connection using the same certificate that was used 296 for mutual TLS at the token endpoint. 298 The protected resource MUST obtain the client certificate used for 299 mutual TLS authentication and MUST verify that the certificate 300 matches the certificate associated with the access token. If they do 301 not match, the resource access attempt MUST be rejected with an error 302 per [RFC6750] using an HTTP 401 status code and the "invalid_token" 303 error code. 305 Metadata to convey server and client capabilities for mutual TLS 306 sender constrained access tokens is defined in Section 3.3 and 307 Section 3.4 respectively. 309 3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 311 When access tokens are represented as a JSON Web Tokens 312 (JWT)[RFC7519], the certificate hash information SHOULD be 313 represented using the "x5t#S256" confirmation method member defined 314 herein. 316 To represent the hash of a certificate in a JWT, this specification 317 defines the new JWT Confirmation Method RFC 7800 [RFC7800] member 318 "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value 319 of the "x5t#S256" member is a base64url-encoded SHA-256[SHS] hash 320 (a.k.a. thumbprint or digest) of the DER encoding of the X.509 321 certificate[RFC5280] (note that certificate thumbprints are also 322 sometimes also known as certificate fingerprints). 324 The following is an example of a JWT payload containing an "x5t#S256" 325 certificate thumbprint confirmation method. 327 { 328 "iss": "https://server.example.com", 329 "sub": "ty.webb@example.com", 330 "exp": 1493726400, 331 "nbf": 1493722800, 332 "cnf":{ 333 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 334 } 335 } 337 Figure 1: Example claims of a Certificate Thumbprint Constrained JWT 339 If, in the future, certificate thumbprints need to be computed using 340 hash functions other than SHA-256, it is suggested that additional 341 related JWT confirmation methods members be defined for that purpose. 342 For example, a new "x5t#S512" (X.509 Certificate Thumbprint using 343 SHA-512) confirmation method member could be defined by registering 344 it in the the IANA "JWT Confirmation Methods" registry 345 [IANA.JWT.Claims] for JWT "cnf" member values established by 346 [RFC7800]. 348 3.2. Confirmation Method for Token Introspection 350 OAuth 2.0 Token Introspection [RFC7662] defines a method for a 351 protected resource to query an authorization server about the active 352 state of an access token as well as to determine meta-information 353 about the token. 355 For a mutual TLS sender constrained access token, the hash of the 356 certificate to which the token is bound is conveyed to the protected 357 resource as meta-information in a token introspection response. The 358 hash is conveyed using the same structure as the certificate SHA-256 359 thumbprint confirmation method, described in Section 3.1, as a top- 360 level member of the introspection response JSON. The protected 361 resource compares that certificate hash to a hash of the client 362 certificate used for mutual TLS authentication and rejects the 363 request, if they do not match. 365 Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] 366 defined the "cnf" (confirmation) claim, which enables confirmation 367 key information to be carried in a JWT. However, the same proof-of- 368 possession semantics are also useful for introspected access tokens 369 whereby the protected resource obtains the confirmation key data as 370 meta-information of a token introspection response and uses that 371 information in verifying proof-of-possession. Therefore this 372 specification defines and registers proof-of-possession semantics for 373 OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. 374 When included as a top-level member of an OAuth token introspection 375 response, "cnf" has the same semantics and format as the claim of the 376 same name defined in [RFC7800]. While this specification only 377 explicitly uses the "x5t#S256" confirmation method member, it needed 378 to define and register the higher level "cnf" structure as an 379 introspection response member in order to define and use its more 380 specific "x5t#S256" confirmation method. 382 The following is an example of an introspection response for an 383 active token with an "x5t#S256" certificate thumbprint confirmation 384 method. 386 HTTP/1.1 200 OK 387 Content-Type: application/json 389 { 390 "active": true, 391 "iss": "https://server.example.com", 392 "sub": "ty.webb@example.com", 393 "exp": 1493726400, 394 "nbf": 1493722800, 395 "cnf":{ 396 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 397 } 398 } 400 Figure 2: Example Introspection Response for a Certificate 401 Constrained Access Token 403 3.3. Authorization Server Metadata 405 This document introduces the following new authorization server 406 metadata parameter to signal the server's capability to issue 407 certificate bound access tokens: 409 mutual_tls_sender_constrained_access_tokens 410 OPTIONAL. Boolean value indicating server support for mutual TLS 411 sender constrained access tokens. If omitted, the default value 412 is "false". 414 3.4. Client Registration Metadata 416 The following new client metadata parameter is introduced to convey 417 the client's intention to use certificate bound access tokens: 419 mutual_tls_sender_constrained_access_tokens 420 OPTIONAL. Boolean value used to indicate the client's intention 421 to use mutual TLS sender constrained access tokens. If omitted, 422 the default value is "false". 424 4. Implementation Considerations 426 4.1. Authorization Server 428 The authorization server needs to setup its TLS configuration 429 appropriately for the binding methods it supports. 431 If the authorization server wants to support mutual TLS client 432 authentication and other client authentication methods in parallel, 433 it should make mutual TLS optional. 435 If the authorization server supports the Self-Signed Certificate 436 method, it should configure the TLS stack in a way that it does not 437 verify whether the certificate presented by the client during the 438 handshake is signed by a trusted CA certificate. 440 The authorization server may also consider hosting the token 441 endpoint, and other endpoints requiring client authentication, on a 442 separate host name in order to prevent unintended impact on the TLS 443 behavior of its other endpoints, e.g. authorization or registration. 445 4.2. Resource Server 447 From the perspective of the resource server, TLS client 448 authentication is used as a proof of possession method only. For the 449 purpose of client authentication, the resource server may completely 450 rely on the authorization server. So there is no need to validate 451 the trust chain of the client's certificate in any of the methods 452 defined in this document. The resource server should therefore 453 configure the TLS stack in a way that it does not verify whether the 454 certificate presented by the client during the handshake is signed by 455 a trusted CA certificate. 457 4.3. Sender Constrained Access Tokens Without Client Authentication 459 This document allows for the use of client authentication only or 460 client authentication in combination with sender constraint access 461 tokens. Use of mutual TLS sender constrained access tokens without 462 client authentication (e.g. to support binding access tokens to a TLS 463 client certificate for public clients) is also possible. The 464 authorization server would configure the TLS stack in the same manner 465 as for the Self-Signed Certificate method such that it does not 466 verify that the certificate presented by the client during the 467 handshake is signed by a trusted CA. Individual instances of a 468 public client would then create a self-signed certificate for mutual 469 TLS with the authorization server and resource server. The 470 authorization server would not authenticate the client at the OAuth 471 layer but would bind issued access tokens to the certificate, which 472 the client has proven possession of the corresponding private key. 473 The access token is then mutual TLS sender constrained and can only 474 be used by the client possessing the certificate and private key and 475 utilizing them to negotiate mutual TLS on connections to the resource 476 server. 478 4.4. Certificate Bound Access Tokens 480 As described in Section 3, an access token is bound to a specific 481 client certificate, which means that the same certificate must be 482 used for mutual TLS on protected resource access. It also implies 483 that access tokens are invalidated when a client updates the 484 certificate, which can be handled similar to expired access tokens 485 where the client requests a new access token (typically with a 486 refresh token) and retries the protected resource request. 488 5. IANA Considerations 490 5.1. JWT Confirmation Methods Registration 492 This specification requests registration of the following value in 493 the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for 494 JWT "cnf" member values established by [RFC7800]. 496 o Confirmation Method Value: "x5t#S256" 497 o Confirmation Method Description: X.509 Certificate SHA-256 498 Thumbprint 499 o Change Controller: IESG 500 o Specification Document(s): Section 3.1 of [[ this specification ]] 502 5.2. OAuth Authorization Server Metadata Registration 504 This specification requests registration of the following value in 505 the IANA "OAuth Authorization Server Metadata" registry 506 [IANA.OAuth.Parameters] established by [I-D.ietf-oauth-discovery]. 508 o Metadata Name: "mutual_tls_sender_constrained_access_tokens" 509 o Metadata Description: Indicates authorization server support for 510 mutual TLS sender constrained access tokens. 511 o Change Controller: IESG 512 o Specification Document(s): Section 3.3 of [[ this specification ]] 514 5.3. Token Endpoint Authentication Method Registration 516 This specification requests registration of the following value in 517 the IANA "OAuth Token Endpoint Authentication Methods" registry 518 [IANA.OAuth.Parameters] established by [RFC7591]. 520 o Token Endpoint Authentication Method Name: "tls_client_auth" 521 o Change Controller: IESG 522 o Specification Document(s): Section 2.1.1 of [[ this specification 523 ]] 525 o Token Endpoint Authentication Method Name: 526 "self_signed_tls_client_auth" 527 o Change Controller: IESG 528 o Specification Document(s): Section 2.2.1 of [[ this specification 529 ]] 531 5.4. OAuth Token Introspection Response Registration 533 This specification requests registration of the following value in 534 the IANA "OAuth Token Introspection Response" registry 535 [IANA.OAuth.Parameters] established by [RFC7662]. 537 o Claim Name: "cnf" 538 o Claim Description: Confirmation 539 o Change Controller: IESG 540 o Specification Document(s): Section 3.2 of [[ this specification ]] 542 5.5. OAuth Dynamic Client Registration Metadata Registration 544 This specification requests registration of the following client 545 metadata definitions in the IANA "OAuth Dynamic Client Registration 546 Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: 548 o Client Metadata Name: 549 "mutual_tls_sender_constrained_access_tokens" 550 o Client Metadata Description: Indicates the client's intention to 551 use mutual TLS sender constrained access tokens. 552 o Change Controller: IESG 553 o Specification Document(s): Section 3.4 of [[ this specification ]] 555 o Client Metadata Name: "tls_client_auth_subject_dn" 556 o Client Metadata Description: String value specifying the expected 557 subject distinguished name of the client certificate. 558 o Change Controller: IESG 559 o Specification Document(s): Section 2.1.2 of [[ this specification 560 ]] 562 6. Security Considerations 564 6.1. TLS Versions and Best Practices 566 TLS 1.2 [RFC5246] is cited in this document because, at the time of 567 writing, it is latest version that is widely deployed. However, this 568 document is applicable with other TLS versions supporting 569 certificate-based client authentication. Implementation security 570 considerations for TLS, including version recommendations, can be 571 found in Recommendations for Secure Use of Transport Layer Security 572 (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]. 574 6.2. X.509 Certificate Spoofing 576 If the PKI method is used, an attacker could try to impersonate a 577 client using a certificate for the same DN issued by another CA, 578 which the authorization server trusts. To cope with that threat, the 579 authorization server may decide to only accept a limited number of 580 CAs whose certificate issuance policy meets its security 581 requirements. 583 7. References 585 7.1. Normative References 587 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 588 "Recommendations for Secure Use of Transport Layer 589 Security (TLS) and Datagram Transport Layer Security 590 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 591 2015, . 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, 595 DOI 10.17487/RFC2119, March 1997, 596 . 598 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 599 (LDAP): String Representation of Distinguished Names", 600 RFC 4514, DOI 10.17487/RFC4514, June 2006, 601 . 603 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 604 (TLS) Protocol Version 1.2", RFC 5246, 605 DOI 10.17487/RFC5246, August 2008, 606 . 608 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 609 Housley, R., and W. Polk, "Internet X.509 Public Key 610 Infrastructure Certificate and Certificate Revocation List 611 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 612 . 614 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 615 RFC 6749, DOI 10.17487/RFC6749, October 2012, 616 . 618 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 619 Framework: Bearer Token Usage", RFC 6750, 620 DOI 10.17487/RFC6750, October 2012, 621 . 623 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 624 Possession Key Semantics for JSON Web Tokens (JWTs)", 625 RFC 7800, DOI 10.17487/RFC7800, April 2016, 626 . 628 [SHS] National Institute of Standards and Technology, "Secure 629 Hash Standard (SHS)", FIPS PUB 180-4, March 2012, 630 . 633 7.2. Informative References 635 [I-D.ietf-oauth-discovery] 636 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 637 Authorization Server Metadata", draft-ietf-oauth- 638 discovery-07 (work in progress), September 2017. 640 [IANA.JWT.Claims] 641 IANA, "JSON Web Token Claims", 642 . 644 [IANA.OAuth.Parameters] 645 IANA, "OAuth Parameters", 646 . 648 [OpenID.Discovery] 649 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 650 Connect Discovery 1.0", August 2015, 651 . 654 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 655 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 656 August 2013, . 658 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 659 DOI 10.17487/RFC7517, May 2015, 660 . 662 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 663 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 664 . 666 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 667 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 668 RFC 7591, DOI 10.17487/RFC7591, July 2015, 669 . 671 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 672 RFC 7662, DOI 10.17487/RFC7662, October 2015, 673 . 675 Appendix A. Acknowledgements 677 Scott "not Tomlinson" Tomilson and Matt Peterson were involved in 678 design and development work on a mutual TLS OAuth client 679 authentication implementation that informed some of the content of 680 this document. 682 Additionally, the authors would like to thank the following people 683 for their input and contributions to the specification: Sergey 684 Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Phil Hunt, Sean 685 Leonard, Kepeng Li, James Manger, Jim Manico, Nov Matake, Sascha 686 Preibisch, Justin Richer, Dave Tonge, and Hannes Tschofenig. 688 Appendix B. Document(s) History 690 [[ to be removed by the RFC Editor before publication as an RFC ]] 692 draft-ietf-oauth-mtls-04 694 o Change the name of the 'Public Key method' to the more accurate 695 'Self-Signed Certificate method' and also change the associated 696 authentication method metadata value to 697 "self_signed_tls_client_auth". 698 o Removed the "tls_client_auth_root_dn" client metadata field as 699 discussed in https://mailarchive.ietf.org/arch/msg/oauth/ 700 swDV2y0be6o8czGKQi1eJV-g8qc 701 o Update draft-ietf-oauth-discovery reference to -07 702 o Clarify that MTLS client authentication isn't exclusive to the 703 token endpoint and can be used with other endpoints, e.g. RFC 704 7009 revocation and 7662 introspection, that utilize client 705 authentication as discussed in 706 https://mailarchive.ietf.org/arch/msg/oauth/ 707 bZ6mft0G7D3ccebhOxnEYUv4puI 708 o Reorganize the document somewhat in an attempt to more clearly 709 make a distinction between mTLS client authentication and 710 certificate bound access tokens as well as a more clear 711 delineation between the two (PKI/Public key) methods for client 712 authentication 713 o Editorial fixes and clarifications 715 draft-ietf-oauth-mtls-03 717 o Introduced metadata and client registration parameter to publish 718 and request support for mutual TLS sender constrained access 719 tokens 720 o Added description of two methods of binding the cert and client, 721 PKI and Public Key. 722 o Indicated that the "tls_client_auth" authentication method is for 723 the PKI method and introduced "pub_key_tls_client_auth" for the 724 Public Key method 725 o Added implementation considerations, mainly regarding TLS stack 726 configuration and trust chain validation, as well as how to to do 727 binding of access tokens to a TLS client certificate for public 728 clients, and considerations around certificate bound access tokens 729 o Added new section to security considerations on cert spoofing 730 o Add text suggesting that a new cnf member be defined in the 731 future, if hash function(s) other than SHA-256 need to be used for 732 certificate thumbprints 734 draft-ietf-oauth-mtls-02 736 o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ 737 U46UMEh8XIOQnvXY9pHFq1MKPns 738 o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is 739 better than "Mutual TLS Profiles for OAuth Clients"). 741 draft-ietf-oauth-mtls-01 743 o Added more explicit details of using RFC 7662 token introspection 744 with mutual TLS sender constrained access tokens. 745 o Added an IANA OAuth Token Introspection Response Registration 746 request for "cnf". 747 o Specify that tls_client_auth_subject_dn and 748 tls_client_auth_root_dn are RFC 4514 String Representation of 749 Distinguished Names. 751 o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. 752 o Changed the text in the Section 3 to not be specific about using a 753 hash of the cert. 754 o Changed the abbreviated title to 'OAuth Mutual TLS' (previously 755 was the acronym MTLSPOC). 757 draft-ietf-oauth-mtls-00 759 o Created the initial working group version from draft-campbell- 760 oauth-mtls 762 draft-campbell-oauth-mtls-01 764 o Fix some typos. 765 o Add to the acknowledgements list. 767 draft-campbell-oauth-mtls-00 769 o Add a Mutual TLS sender constrained protected resource access 770 method and a x5t#S256 cnf method for JWT access tokens (concepts 771 taken in part from draft-sakimura-oauth-jpop-04). 772 o Fixed "token_endpoint_auth_methods_supported" to 773 "token_endpoint_auth_method" for client metadata. 774 o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" 775 client metadata parameters and mention using "jwks_uri" or "jwks". 776 o Say that the authentication method is determined by client policy 777 regardless of whether the client was dynamically registered or 778 statically configured. 779 o Expand acknowledgements to those that participated in discussions 780 around draft-campbell-oauth-tls-client-auth-00 781 o Add Nat Sakimura and Torsten Lodderstedt to the author list. 783 draft-campbell-oauth-tls-client-auth-00 785 o Initial draft. 787 Authors' Addresses 789 Brian Campbell 790 Ping Identity 792 Email: brian.d.campbell@gmail.com 793 John Bradley 794 Yubico 796 Email: ve7jtb@ve7jtb.com 797 URI: http://www.thread-safe.com/ 799 Nat Sakimura 800 Nomura Research Institute 802 Email: n-sakimura@nri.co.jp 803 URI: https://nat.sakimura.org/ 805 Torsten Lodderstedt 806 YES Europe AG 808 Email: torsten@lodderstedt.net