draft-ietf-oauth-mtls-11.txt   draft-ietf-oauth-mtls-12.txt 
OAuth Working Group B. Campbell OAuth Working Group B. Campbell
Internet-Draft Ping Identity Internet-Draft Ping Identity
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: March 3, 2019 Yubico Expires: April 21, 2019 Yubico
N. Sakimura N. Sakimura
Nomura Research Institute Nomura Research Institute
T. Lodderstedt T. Lodderstedt
YES Europe AG YES.com AG
August 30, 2018 October 18, 2018
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access
Tokens Tokens
draft-ietf-oauth-mtls-11 draft-ietf-oauth-mtls-12
Abstract Abstract
This document describes OAuth client authentication and certificate This document describes OAuth client authentication and certificate
bound access tokens using mutual Transport Layer Security (TLS) bound access tokens using mutual Transport Layer Security (TLS)
authentication with X.509 certificates. OAuth clients are provided a authentication with X.509 certificates. OAuth clients are provided a
mechanism for authentication to the authorization server using mutual mechanism for authentication to the authorization server using mutual
TLS, based on either self-signed certificates or public key TLS, based on either self-signed certificates or public key
infrastructure (PKI). OAuth authorization servers are provided a infrastructure (PKI). OAuth authorization servers are provided a
mechanism for binding access tokens to a client's mutual TLS mechanism for binding access tokens to a client's mutual TLS
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2019. This Internet-Draft will expire on April 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
5.3. X.509 Certificate Parsing and Validation Complexity . . . 12 5.3. X.509 Certificate Parsing and Validation Complexity . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. JWT Confirmation Methods Registration . . . . . . . . . . 13 6.1. JWT Confirmation Methods Registration . . . . . . . . . . 13
6.2. OAuth Authorization Server Metadata Registration . . . . 13 6.2. OAuth Authorization Server Metadata Registration . . . . 13
6.3. Token Endpoint Authentication Method Registration . . . . 13 6.3. Token Endpoint Authentication Method Registration . . . . 13
6.4. OAuth Token Introspection Response Registration . . . . . 14 6.4. OAuth Token Introspection Response Registration . . . . . 14
6.5. OAuth Dynamic Client Registration Metadata Registration . 14 6.5. OAuth Dynamic Client Registration Metadata Registration . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Relationship to Token Binding . . . . . . . . . . . 17 Appendix A. Example Certificate, JSON Web Key, and Confirmation
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Method . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix C. Document(s) History . . . . . . . . . . . . . . . . 18 Appendix B. Relationship to Token Binding . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Appendix D. Document(s) History . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document describes OAuth client authentication and certificate This document describes OAuth client authentication and certificate
bound access tokens using mutual TLS [RFC5246] authentication with bound access tokens using mutual TLS [RFC5246] authentication with
X.509 certificates. OAuth clients are provided mechanisms for X.509 certificates. OAuth clients are provided mechanisms for
authentication to the authorization server using mutual TLS. OAuth authentication to the authorization server using mutual TLS. OAuth
authorization servers are provided a mechanism for binding access authorization servers are provided a mechanism for binding access
tokens to a client's mutual TLS certificate, and OAuth protected tokens to a client's mutual TLS certificate, and OAuth protected
resources are provided a method for ensuring that such an access resources are provided a method for ensuring that such an access
skipping to change at page 6, line 47 skipping to change at page 6, line 47
will occur using mutual TLS with the client utilizing a self- will occur using mutual TLS with the client utilizing a self-
signed certificate. signed certificate.
2.2.2. Client Registration Metadata 2.2.2. Client Registration Metadata
For the Self-Signed Certificate method of binding a certificate to a For the Self-Signed Certificate method of binding a certificate to a
client using mutual TLS client authentication, the existing client using mutual TLS client authentication, the existing
"jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to
convey the client's certificates and public keys, where the X.509 convey the client's certificates and public keys, where the X.509
certificates are represented using the JSON Web Key (JWK) [RFC7517] certificates are represented using the JSON Web Key (JWK) [RFC7517]
"x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key "x5c" parameter. Note that Sec 4.7 of [RFC7517] requires that the
in the first certificate of the "x5c" parameter must match the public key in the first certificate of the "x5c" parameter must match the
key represented by other members of the JWK). public key represented by other members of the JWK (e.g. "n" and "e"
for RSA, "x" and "y" for EC).
3. Mutual TLS Client Certificate Bound Access Tokens 3. Mutual TLS Client Certificate Bound Access Tokens
When mutual TLS is used by the client on the connection to the token When mutual TLS is used by the client on the connection to the token
endpoint, the authorization server is able to bind the issued access endpoint, the authorization server is able to bind the issued access
token to the client certificate. Such a binding is accomplished by token to the client certificate. Such a binding is accomplished by
associating the certificate with the token in a way that can be associating the certificate with the token in a way that can be
accessed by the protected resource, such as embedding the certificate accessed by the protected resource, such as embedding the certificate
hash in the issued access token directly, using the syntax described hash in the issued access token directly, using the syntax described
in Section 3.1, or through token introspection as described in in Section 3.1, or through token introspection as described in
skipping to change at page 7, line 48 skipping to change at page 7, line 48
3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 3.1. X.509 Certificate Thumbprint Confirmation Method for JWT
When access tokens are represented as JSON Web Tokens (JWT)[RFC7519], When access tokens are represented as JSON Web Tokens (JWT)[RFC7519],
the certificate hash information SHOULD be represented using the the certificate hash information SHOULD be represented using the
"x5t#S256" confirmation method member defined herein. "x5t#S256" confirmation method member defined herein.
To represent the hash of a certificate in a JWT, this specification To represent the hash of a certificate in a JWT, this specification
defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" defines the new JWT Confirmation Method [RFC7800] member "x5t#S256"
for the X.509 Certificate SHA-256 Thumbprint. The value of the for the X.509 Certificate SHA-256 Thumbprint. The value of the
"x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint, "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash
fingerprint or digest) of the DER encoding of the X.509 certificate (a.k.a. thumbprint, fingerprint or digest) of the DER encoding of the
[RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=' X.509 certificate [RFC5280]. The base64url-encoded value MUST omit
characters omitted and without the inclusion of any line breaks, all trailing pad '=' characters and MUST NOT include any line breaks,
whitespace, or other additional characters. whitespace, or other additional characters.
The following is an example of a JWT payload containing an "x5t#S256" The following is an example of a JWT payload containing an "x5t#S256"
certificate thumbprint confirmation method. certificate thumbprint confirmation method.
{ {
"iss": "https://server.example.com", "iss": "https://server.example.com",
"sub": "ty.webb@example.com", "sub": "ty.webb@example.com",
"exp": 1493726400, "exp": 1493726400,
"nbf": 1493722800, "nbf": 1493722800,
skipping to change at page 17, line 24 skipping to change at page 17, line 24
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[X509Pitfalls] [X509Pitfalls]
Wong, D., "Common x509 certificate validation/creation Wong, D., "Common x509 certificate validation/creation
pitfalls", September 2016, pitfalls", September 2016,
<https://www.cryptologie.net/article/374/ <https://www.cryptologie.net/article/374/
common-x509-certificate-validationcreation-pitfalls>. common-x509-certificate-validationcreation-pitfalls>.
Appendix A. Relationship to Token Binding Appendix A. Example Certificate, JSON Web Key, and Confirmation Method
For reference, an "x5t#S256" value and the X.509 Certificate from
which it was calculated are provided in the following example
figures. A JWK representation of the certificate's public key along
with the "x5c" member is also provided.
"cnf":{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"}
Figure 3: x5t#S256 Confirmation Claim
-----BEGIN CERTIFICATE-----
MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTAx
ODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGByqG
SM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZjjJ
/Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0EAwID
SQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2eXZOV
bUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY=
-----END CERTIFICATE-----
Figure 4: PEM Encoded Self-Signed Certificate
{
"kty":"EC",
"x":"1yfLHCpXqFjxCeHHHMVDTcLscpb07KUxudBmOMn8C7Q",
"y":"8_coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8",
"crv":"P-256",
"x5c":[
"MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTA
xODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGBy
qGSM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZ
jjJ/Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0E
AwIDSQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2
eXZOVbUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY="
]
}
Figure 5: JSON Web Key
Appendix B. Relationship to Token Binding
OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the
application of Token Binding to the various artifacts and tokens application of Token Binding to the various artifacts and tokens
employed throughout OAuth. That includes binding of an access token employed throughout OAuth. That includes binding of an access token
to a Token Binding key, which bears some similarities in motivation to a Token Binding key, which bears some similarities in motivation
and design to the mutual TLS client certificate bound access tokens and design to the mutual TLS client certificate bound access tokens
defined in this document. Both documents define what is often called defined in this document. Both documents define what is often called
a proof-of-possession security mechanism for access tokens, whereby a a proof-of-possession security mechanism for access tokens, whereby a
client must demonstrate possession of cryptographic keying material client must demonstrate possession of cryptographic keying material
when accessing a protected resource. The details differ somewhat when accessing a protected resource. The details differ somewhat
skipping to change at page 18, line 6 skipping to change at page 19, line 4
little support for it in available application development platforms little support for it in available application development platforms
and tooling. Until better support for the underlying core Token and tooling. Until better support for the underlying core Token
Binding specifications exists, practical implementations of OAuth 2.0 Binding specifications exists, practical implementations of OAuth 2.0
Token Binding are infeasible. Mutual TLS, on the other hand, has Token Binding are infeasible. Mutual TLS, on the other hand, has
been around for some time and enjoys widespread support in web been around for some time and enjoys widespread support in web
servers and development platforms. As a consequence, OAuth 2.0 servers and development platforms. As a consequence, OAuth 2.0
Mutual TLS Client Authentication and Certificate Bound Access Tokens Mutual TLS Client Authentication and Certificate Bound Access Tokens
can be built and deployed now using existing platforms and tools. In can be built and deployed now using existing platforms and tools. In
the future, the two specifications are likely to be deployed in the future, the two specifications are likely to be deployed in
parallel for solving similar problems in different environments. parallel for solving similar problems in different environments.
Authorization servers may even support both specifications Authorization servers may even support both specifications
simultaneously using different proof-of-possession mechanisms for simultaneously using different proof-of-possession mechanisms for
tokens issued to different clients. tokens issued to different clients.
Appendix B. Acknowledgements Appendix C. Acknowledgements
Scott "not Tomlinson" Tomilson and Matt Peterson were involved in Scott "not Tomlinson" Tomilson and Matt Peterson were involved in
design and development work on a mutual TLS OAuth client design and development work on a mutual TLS OAuth client
authentication implementation, which predates this document. authentication implementation, which predates this document.
Experience and learning from that work informed some of the content Experience and learning from that work informed some of the content
of this document. of this document.
Additionally, the authors would like to thank the following people This specification was developed within the OAuth Working Group under
for their input and contributions to the specification: Sergey the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with
Beryozkin, Sophie Bremer, Vladimir Dzhuvinov, Samuel Erdtman, Leif Eric Rescorla and Benjamin Kaduk serving as Security Area Directors.
Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Additionally, the following individuals contributed ideas, feedback,
Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim and wording that helped shape this specification: Sergey Beryozkin,
Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and Sophie Bremer, Vladimir Dzhuvinov, Samuel Erdtman, Leif Johansson,
Hannes Tschofenig. Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean
Leonard, Kepeng Li, Neil Madden, James Manger, Jim Manico, Nov
Matake, Sascha Preibisch, Justin Richer, Filip Skokan, Dave Tonge,
and Hannes Tschofenig.
Appendix C. Document(s) History Appendix D. Document(s) History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
draft-ietf-oauth-mtls-12
o Add an example certificate, JWK, and confirmation method claim.
o Minor editorial updates based on implementer feedback.
o Additional Acknowledgements.
draft-ietf-oauth-mtls-11 draft-ietf-oauth-mtls-11
o Editorial updates. o Editorial updates.
o Mention/reference TLS 1.3 RFC8446 in the TLS Versions and Best o Mention/reference TLS 1.3 RFC8446 in the TLS Versions and Best
Practices section. Practices section.
draft-ietf-oauth-mtls-10 draft-ietf-oauth-mtls-10
o Update draft-ietf-oauth-discovery reference to RFC8414 o Update draft-ietf-oauth-discovery reference to RFC8414
draft-ietf-oauth-mtls-09 draft-ietf-oauth-mtls-09
o Change "single certificates" to "self-signed certificates" in the o Change "single certificates" to "self-signed certificates" in the
Abstract Abstract
draft-ietf-oauth-mtls-08
o Incorporate clarifications and editorial improvements from Justin o Incorporate clarifications and editorial improvements from Justin
Richer's WGLC review Richer's WGLC review
o Drop the use of the "sender constrained" terminology per WGLC o Drop the use of the "sender constrained" terminology per WGLC
feedback from Neil Madden (including changing the metadata feedback from Neil Madden (including changing the metadata
parameters from mutual_tls_sender_constrained_access_tokens to parameters from mutual_tls_sender_constrained_access_tokens to
tls_client_certificate_bound_access_tokens) tls_client_certificate_bound_access_tokens)
o Add a new security considerations section on X.509 parsing and o Add a new security considerations section on X.509 parsing and
validation per WGLC feedback from Neil Madden and Benjamin Kaduk validation per WGLC feedback from Neil Madden and Benjamin Kaduk
o Note that a server can terminate TLS at a load balancer, reverse o Note that a server can terminate TLS at a load balancer, reverse
proxy, etc. but how the client certificate metadata is securely proxy, etc. but how the client certificate metadata is securely
skipping to change at page 19, line 45 skipping to change at page 21, line 4
o Changed the title to be more descriptive o Changed the title to be more descriptive
o Move the Security Considerations section to before the IANA o Move the Security Considerations section to before the IANA
Considerations Considerations
o Elaborated on certificate bound access tokens a bit more in the o Elaborated on certificate bound access tokens a bit more in the
Abstract Abstract
o Update draft-ietf-oauth-discovery reference to -08 o Update draft-ietf-oauth-discovery reference to -08
draft-ietf-oauth-mtls-05 draft-ietf-oauth-mtls-05
o Editorial fixes o Editorial fixes
draft-ietf-oauth-mtls-04
o Change the name of the 'Public Key method' to the more accurate o Change the name of the 'Public Key method' to the more accurate
'Self-Signed Certificate method' and also change the associated 'Self-Signed Certificate method' and also change the associated
authentication method metadata value to authentication method metadata value to
"self_signed_tls_client_auth". "self_signed_tls_client_auth".
o Removed the "tls_client_auth_root_dn" client metadata field as o Removed the "tls_client_auth_root_dn" client metadata field as
discussed in https://mailarchive.ietf.org/arch/msg/oauth/ discussed in https://mailarchive.ietf.org/arch/msg/oauth/
swDV2y0be6o8czGKQi1eJV-g8qc swDV2y0be6o8czGKQi1eJV-g8qc
o Update draft-ietf-oauth-discovery reference to -07 o Update draft-ietf-oauth-discovery reference to -07
o Clarify that MTLS client authentication isn't exclusive to the o Clarify that MTLS client authentication isn't exclusive to the
token endpoint and can be used with other endpoints, e.g. RFC token endpoint and can be used with other endpoints, e.g. RFC
7009 revocation and 7662 introspection, that utilize client 7009 revocation and 7662 introspection, that utilize client
authentication as discussed in authentication as discussed in
https://mailarchive.ietf.org/arch/msg/oauth/ https://mailarchive.ietf.org/arch/msg/oauth/
bZ6mft0G7D3ccebhOxnEYUv4puI bZ6mft0G7D3ccebhOxnEYUv4puI
skipping to change at page 20, line 48 skipping to change at page 22, line 5
future, if hash function(s) other than SHA-256 need to be used for future, if hash function(s) other than SHA-256 need to be used for
certificate thumbprints certificate thumbprints
draft-ietf-oauth-mtls-02 draft-ietf-oauth-mtls-02
o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/
U46UMEh8XIOQnvXY9pHFq1MKPns U46UMEh8XIOQnvXY9pHFq1MKPns
o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is
better than "Mutual TLS Profiles for OAuth Clients"). better than "Mutual TLS Profiles for OAuth Clients").
draft-ietf-oauth-mtls-01
o Added more explicit details of using RFC 7662 token introspection o Added more explicit details of using RFC 7662 token introspection
with mutual TLS sender constrained access tokens. with mutual TLS sender constrained access tokens.
o Added an IANA OAuth Token Introspection Response Registration o Added an IANA OAuth Token Introspection Response Registration
request for "cnf". request for "cnf".
o Specify that tls_client_auth_subject_dn and o Specify that tls_client_auth_subject_dn and
tls_client_auth_root_dn are RFC 4514 String Representation of tls_client_auth_root_dn are RFC 4514 String Representation of
Distinguished Names. Distinguished Names.
o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
o Changed the text in the Section 3 to not be specific about using a o Changed the text in the Section 3 to not be specific about using a
hash of the cert. hash of the cert.
o Changed the abbreviated title to 'OAuth Mutual TLS' (previously o Changed the abbreviated title to 'OAuth Mutual TLS' (previously
was the acronym MTLSPOC). was the acronym MTLSPOC).
skipping to change at page 22, line 17 skipping to change at page 23, line 25
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/ URI: http://www.thread-safe.com/
Nat Sakimura Nat Sakimura
Nomura Research Institute Nomura Research Institute
Email: n-sakimura@nri.co.jp Email: n-sakimura@nri.co.jp
URI: https://nat.sakimura.org/ URI: https://nat.sakimura.org/
Torsten Lodderstedt Torsten Lodderstedt
YES Europe AG YES.com AG
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
 End of changes. 19 change blocks. 
36 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/