idnits 2.17.1 draft-ietf-oauth-mtls-05.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 (November 12, 2017) is 2350 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: May 16, 2018 Yubico 6 N. Sakimura 7 Nomura Research Institute 8 T. Lodderstedt 9 YES Europe AG 10 November 12, 2017 12 Mutual TLS Profile for OAuth 2.0 13 draft-ietf-oauth-mtls-05 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 May 16, 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 authentication 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 indicate 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 an 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 of 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 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 indicate 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 JSON Web Tokens (JWT)[RFC7519], 312 the certificate hash information SHOULD be represented using the 313 "x5t#S256" confirmation method member defined herein. 315 To represent the hash of a certificate in a JWT, this specification 316 defines the new JWT Confirmation Method RFC 7800 [RFC7800] member 317 "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value 318 of the "x5t#S256" member is a base64url-encoded SHA-256[SHS] hash 319 (a.k.a. thumbprint or digest) of the DER encoding of the X.509 320 certificate[RFC5280] (note that certificate thumbprints are also 321 sometimes known as certificate fingerprints). 323 The following is an example of a JWT payload containing an "x5t#S256" 324 certificate thumbprint confirmation method. 326 { 327 "iss": "https://server.example.com", 328 "sub": "ty.webb@example.com", 329 "exp": 1493726400, 330 "nbf": 1493722800, 331 "cnf":{ 332 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 333 } 334 } 336 Figure 1: Example claims of a Certificate Thumbprint Constrained JWT 338 If, in the future, certificate thumbprints need to be computed using 339 hash functions other than SHA-256, it is suggested that additional 340 related JWT confirmation methods members be defined for that purpose. 341 For example, a new "x5t#S512" (X.509 Certificate Thumbprint using 342 SHA-512) confirmation method member could be defined by registering 343 it in the the IANA "JWT Confirmation Methods" registry 344 [IANA.JWT.Claims] for JWT "cnf" member values established by 345 [RFC7800]. 347 3.2. Confirmation Method for Token Introspection 349 OAuth 2.0 Token Introspection [RFC7662] defines a method for a 350 protected resource to query an authorization server about the active 351 state of an access token as well as to determine meta-information 352 about the token. 354 For a mutual TLS sender constrained access token, the hash of the 355 certificate to which the token is bound is conveyed to the protected 356 resource as meta-information in a token introspection response. The 357 hash is conveyed using the same structure as the certificate SHA-256 358 thumbprint confirmation method, described in Section 3.1, as a top- 359 level member of the introspection response JSON. The protected 360 resource compares that certificate hash to a hash of the client 361 certificate used for mutual TLS authentication and rejects the 362 request, if they do not match. 364 Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] 365 defined the "cnf" (confirmation) claim, which enables confirmation 366 key information to be carried in a JWT. However, the same proof-of- 367 possession semantics are also useful for introspected access tokens 368 whereby the protected resource obtains the confirmation key data as 369 meta-information of a token introspection response and uses that 370 information in verifying proof-of-possession. Therefore this 371 specification defines and registers proof-of-possession semantics for 372 OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. 373 When included as a top-level member of an OAuth token introspection 374 response, "cnf" has the same semantics and format as the claim of the 375 same name defined in [RFC7800]. While this specification only 376 explicitly uses the "x5t#S256" confirmation method member, it needed 377 to define and register the higher level "cnf" structure as an 378 introspection response member in order to define and use its more 379 specific "x5t#S256" confirmation method. 381 The following is an example of an introspection response for an 382 active token with an "x5t#S256" certificate thumbprint confirmation 383 method. 385 HTTP/1.1 200 OK 386 Content-Type: application/json 388 { 389 "active": true, 390 "iss": "https://server.example.com", 391 "sub": "ty.webb@example.com", 392 "exp": 1493726400, 393 "nbf": 1493722800, 394 "cnf":{ 395 "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" 396 } 397 } 399 Figure 2: Example Introspection Response for a Certificate 400 Constrained Access Token 402 3.3. Authorization Server Metadata 404 This document introduces the following new authorization server 405 metadata parameter to signal the server's capability to issue 406 certificate bound access tokens: 408 mutual_tls_sender_constrained_access_tokens 409 OPTIONAL. Boolean value indicating server support for mutual TLS 410 sender constrained access tokens. If omitted, the default value 411 is "false". 413 3.4. Client Registration Metadata 415 The following new client metadata parameter is introduced to convey 416 the client's intention to use certificate bound access tokens: 418 mutual_tls_sender_constrained_access_tokens 419 OPTIONAL. Boolean value used to indicate the client's intention 420 to use mutual TLS sender constrained access tokens. If omitted, 421 the default value is "false". 423 4. Implementation Considerations 425 4.1. Authorization Server 427 The authorization server needs to setup its TLS configuration 428 appropriately for the binding methods it supports. 430 If the authorization server wants to support mutual TLS client 431 authentication and other client authentication methods in parallel, 432 it should make mutual TLS optional. 434 If the authorization server supports the Self-Signed Certificate 435 method, it should configure the TLS stack in a way that it does not 436 verify whether the certificate presented by the client during the 437 handshake is signed by a trusted CA certificate. 439 The authorization server may also consider hosting the token 440 endpoint, and other endpoints requiring client authentication, on a 441 separate host name in order to prevent unintended impact on the TLS 442 behavior of its other endpoints, e.g. authorization or registration. 444 4.2. Resource Server 446 From the perspective of the resource server, TLS client 447 authentication is used as a proof of possession method only. For the 448 purpose of client authentication, the resource server may completely 449 rely on the authorization server. So there is no need to validate 450 the trust chain of the client's certificate in any of the methods 451 defined in this document. The resource server should therefore 452 configure the TLS stack in a way that it does not verify whether the 453 certificate presented by the client during the handshake is signed by 454 a trusted CA certificate. 456 4.3. Sender Constrained Access Tokens Without Client Authentication 458 This document allows use of client authentication only or client 459 authentication in combination with sender constraint access tokens. 460 Use of mutual TLS sender constrained access tokens without client 461 authentication (e.g. to support binding access tokens to a TLS client 462 certificate for public clients) is also possible. The authorization 463 server would configure the TLS stack in the same manner as for the 464 Self-Signed Certificate method such that it does not verify that the 465 certificate presented by the client during the handshake is signed by 466 a trusted CA. Individual instances of a public client would then 467 create a self-signed certificate for mutual TLS with the 468 authorization server and resource server. The authorization server 469 would not authenticate the client at the OAuth layer but would bind 470 issued access tokens to the certificate, which the client has proven 471 possession of the corresponding private key. The access token is 472 then mutual TLS sender constrained and can only be used by the client 473 possessing the certificate and private key and utilizing them to 474 negotiate mutual TLS on connections to the resource server. 476 4.4. Certificate Bound Access Tokens 478 As described in Section 3, an access token is bound to a specific 479 client certificate, which means that the same certificate must be 480 used for mutual TLS on protected resource access. It also implies 481 that access tokens are invalidated when a client updates the 482 certificate, which can be handled similar to expired access tokens 483 where the client requests a new access token (typically with a 484 refresh token) and retries the protected resource request. 486 5. IANA Considerations 488 5.1. JWT Confirmation Methods Registration 490 This specification requests registration of the following value in 491 the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for 492 JWT "cnf" member values established by [RFC7800]. 494 o Confirmation Method Value: "x5t#S256" 495 o Confirmation Method Description: X.509 Certificate SHA-256 496 Thumbprint 497 o Change Controller: IESG 498 o Specification Document(s): Section 3.1 of [[ this specification ]] 500 5.2. OAuth Authorization Server Metadata Registration 502 This specification requests registration of the following value in 503 the IANA "OAuth Authorization Server Metadata" registry 504 [IANA.OAuth.Parameters] established by [I-D.ietf-oauth-discovery]. 506 o Metadata Name: "mutual_tls_sender_constrained_access_tokens" 507 o Metadata Description: Indicates authorization server support for 508 mutual TLS sender constrained access tokens. 509 o Change Controller: IESG 510 o Specification Document(s): Section 3.3 of [[ this specification ]] 512 5.3. Token Endpoint Authentication Method Registration 514 This specification requests registration of the following value in 515 the IANA "OAuth Token Endpoint Authentication Methods" registry 516 [IANA.OAuth.Parameters] established by [RFC7591]. 518 o Token Endpoint Authentication Method Name: "tls_client_auth" 519 o Change Controller: IESG 520 o Specification Document(s): Section 2.1.1 of [[ this specification 521 ]] 523 o Token Endpoint Authentication Method Name: 524 "self_signed_tls_client_auth" 525 o Change Controller: IESG 526 o Specification Document(s): Section 2.2.1 of [[ this specification 527 ]] 529 5.4. OAuth Token Introspection Response Registration 531 This specification requests registration of the following value in 532 the IANA "OAuth Token Introspection Response" registry 533 [IANA.OAuth.Parameters] established by [RFC7662]. 535 o Claim Name: "cnf" 536 o Claim Description: Confirmation 537 o Change Controller: IESG 538 o Specification Document(s): Section 3.2 of [[ this specification ]] 540 5.5. OAuth Dynamic Client Registration Metadata Registration 542 This specification requests registration of the following client 543 metadata definitions in the IANA "OAuth Dynamic Client Registration 544 Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: 546 o Client Metadata Name: 547 "mutual_tls_sender_constrained_access_tokens" 548 o Client Metadata Description: Indicates the client's intention to 549 use mutual TLS sender constrained access tokens. 550 o Change Controller: IESG 551 o Specification Document(s): Section 3.4 of [[ this specification ]] 553 o Client Metadata Name: "tls_client_auth_subject_dn" 554 o Client Metadata Description: String value specifying the expected 555 subject distinguished name of the client certificate. 556 o Change Controller: IESG 557 o Specification Document(s): Section 2.1.2 of [[ this specification 558 ]] 560 6. Security Considerations 562 6.1. TLS Versions and Best Practices 564 TLS 1.2 [RFC5246] is cited in this document because, at the time of 565 writing, it is the latest version that is widely deployed. However, 566 this document is applicable with other TLS versions supporting 567 certificate-based client authentication. Implementation security 568 considerations for TLS, including version recommendations, can be 569 found in Recommendations for Secure Use of Transport Layer Security 570 (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]. 572 6.2. X.509 Certificate Spoofing 574 If the PKI method is used, an attacker could try to impersonate a 575 client using a certificate for the same DN issued by another CA, 576 which the authorization server trusts. To cope with that threat, the 577 authorization server may decide to only accept a limited number of 578 CAs whose certificate issuance policy meets its security 579 requirements. 581 7. References 583 7.1. Normative References 585 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 586 "Recommendations for Secure Use of Transport Layer 587 Security (TLS) and Datagram Transport Layer Security 588 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 589 2015, . 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, 593 DOI 10.17487/RFC2119, March 1997, 594 . 596 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 597 (LDAP): String Representation of Distinguished Names", 598 RFC 4514, DOI 10.17487/RFC4514, June 2006, 599 . 601 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 602 (TLS) Protocol Version 1.2", RFC 5246, 603 DOI 10.17487/RFC5246, August 2008, 604 . 606 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 607 Housley, R., and W. Polk, "Internet X.509 Public Key 608 Infrastructure Certificate and Certificate Revocation List 609 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 610 . 612 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 613 RFC 6749, DOI 10.17487/RFC6749, October 2012, 614 . 616 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 617 Framework: Bearer Token Usage", RFC 6750, 618 DOI 10.17487/RFC6750, October 2012, 619 . 621 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 622 Possession Key Semantics for JSON Web Tokens (JWTs)", 623 RFC 7800, DOI 10.17487/RFC7800, April 2016, 624 . 626 [SHS] National Institute of Standards and Technology, "Secure 627 Hash Standard (SHS)", FIPS PUB 180-4, March 2012, 628 . 631 7.2. Informative References 633 [I-D.ietf-oauth-discovery] 634 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 635 Authorization Server Metadata", draft-ietf-oauth- 636 discovery-07 (work in progress), September 2017. 638 [IANA.JWT.Claims] 639 IANA, "JSON Web Token Claims", 640 . 642 [IANA.OAuth.Parameters] 643 IANA, "OAuth Parameters", 644 . 646 [OpenID.Discovery] 647 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 648 Connect Discovery 1.0", August 2015, 649 . 652 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 653 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 654 August 2013, . 656 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 657 DOI 10.17487/RFC7517, May 2015, 658 . 660 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 661 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 662 . 664 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 665 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 666 RFC 7591, DOI 10.17487/RFC7591, July 2015, 667 . 669 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 670 RFC 7662, DOI 10.17487/RFC7662, October 2015, 671 . 673 Appendix A. Acknowledgements 675 Scott "not Tomlinson" Tomilson and Matt Peterson were involved in 676 design and development work on a mutual TLS OAuth client 677 authentication implementation that informed some of the content of 678 this document. 680 Additionally, the authors would like to thank the following people 681 for their input and contributions to the specification: Sergey 682 Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Phil Hunt, Takahiko 683 Kawasaki Sean Leonard, Kepeng Li, James Manger, Jim Manico, Nov 684 Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and Hannes 685 Tschofenig. 687 Appendix B. Document(s) History 689 [[ to be removed by the RFC Editor before publication as an RFC ]] 691 draft-ietf-oauth-mtls-05 693 o Editorial fixes 695 draft-ietf-oauth-mtls-04 697 o Change the name of the 'Public Key method' to the more accurate 698 'Self-Signed Certificate method' and also change the associated 699 authentication method metadata value to 700 "self_signed_tls_client_auth". 701 o Removed the "tls_client_auth_root_dn" client metadata field as 702 discussed in https://mailarchive.ietf.org/arch/msg/oauth/ 703 swDV2y0be6o8czGKQi1eJV-g8qc 704 o Update draft-ietf-oauth-discovery reference to -07 705 o Clarify that MTLS client authentication isn't exclusive to the 706 token endpoint and can be used with other endpoints, e.g. RFC 707 7009 revocation and 7662 introspection, that utilize client 708 authentication as discussed in 709 https://mailarchive.ietf.org/arch/msg/oauth/ 710 bZ6mft0G7D3ccebhOxnEYUv4puI 711 o Reorganize the document somewhat in an attempt to more clearly 712 make a distinction between mTLS client authentication and 713 certificate bound access tokens as well as a more clear 714 delineation between the two (PKI/Public key) methods for client 715 authentication 716 o Editorial fixes and clarifications 718 draft-ietf-oauth-mtls-03 720 o Introduced metadata and client registration parameter to publish 721 and request support for mutual TLS sender constrained access 722 tokens 723 o Added description of two methods of binding the cert and client, 724 PKI and Public Key. 725 o Indicated that the "tls_client_auth" authentication method is for 726 the PKI method and introduced "pub_key_tls_client_auth" for the 727 Public Key method 728 o Added implementation considerations, mainly regarding TLS stack 729 configuration and trust chain validation, as well as how to to do 730 binding of access tokens to a TLS client certificate for public 731 clients, and considerations around certificate bound access tokens 732 o Added new section to security considerations on cert spoofing 733 o Add text suggesting that a new cnf member be defined in the 734 future, if hash function(s) other than SHA-256 need to be used for 735 certificate thumbprints 737 draft-ietf-oauth-mtls-02 739 o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ 740 U46UMEh8XIOQnvXY9pHFq1MKPns 741 o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is 742 better than "Mutual TLS Profiles for OAuth Clients"). 744 draft-ietf-oauth-mtls-01 745 o Added more explicit details of using RFC 7662 token introspection 746 with mutual TLS sender constrained access tokens. 747 o Added an IANA OAuth Token Introspection Response Registration 748 request for "cnf". 749 o Specify that tls_client_auth_subject_dn and 750 tls_client_auth_root_dn are RFC 4514 String Representation of 751 Distinguished Names. 752 o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. 753 o Changed the text in the Section 3 to not be specific about using a 754 hash of the cert. 755 o Changed the abbreviated title to 'OAuth Mutual TLS' (previously 756 was the acronym MTLSPOC). 758 draft-ietf-oauth-mtls-00 760 o Created the initial working group version from draft-campbell- 761 oauth-mtls 763 draft-campbell-oauth-mtls-01 765 o Fix some typos. 766 o Add to the acknowledgements list. 768 draft-campbell-oauth-mtls-00 770 o Add a Mutual TLS sender constrained protected resource access 771 method and a x5t#S256 cnf method for JWT access tokens (concepts 772 taken in part from draft-sakimura-oauth-jpop-04). 773 o Fixed "token_endpoint_auth_methods_supported" to 774 "token_endpoint_auth_method" for client metadata. 775 o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" 776 client metadata parameters and mention using "jwks_uri" or "jwks". 777 o Say that the authentication method is determined by client policy 778 regardless of whether the client was dynamically registered or 779 statically configured. 780 o Expand acknowledgements to those that participated in discussions 781 around draft-campbell-oauth-tls-client-auth-00 782 o Add Nat Sakimura and Torsten Lodderstedt to the author list. 784 draft-campbell-oauth-tls-client-auth-00 786 o Initial draft. 788 Authors' Addresses 789 Brian Campbell 790 Ping Identity 792 Email: brian.d.campbell@gmail.com 794 John Bradley 795 Yubico 797 Email: ve7jtb@ve7jtb.com 798 URI: http://www.thread-safe.com/ 800 Nat Sakimura 801 Nomura Research Institute 803 Email: n-sakimura@nri.co.jp 804 URI: https://nat.sakimura.org/ 806 Torsten Lodderstedt 807 YES Europe AG 809 Email: torsten@lodderstedt.net