draft-ietf-oauth-token-binding-05.txt   draft-ietf-oauth-token-binding-06.txt 
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track B. Campbell Intended status: Standards Track B. Campbell
Expires: April 29, 2018 Ping Identity Expires: September 2, 2018 Ping Identity
J. Bradley J. Bradley
Yubico Yubico
W. Denniss W. Denniss
Google Google
October 26, 2017 March 1, 2018
OAuth 2.0 Token Binding OAuth 2.0 Token Binding
draft-ietf-oauth-token-binding-05 draft-ietf-oauth-token-binding-06
Abstract Abstract
This specification enables OAuth 2.0 implementations to apply Token This specification enables OAuth 2.0 implementations to apply Token
Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT
Authorization Grants, and JWT Client Authentication. This Authorization Grants, and JWT Client Authentication. This
cryptographically binds these tokens to a client's Token Binding key cryptographically binds these tokens to a client's Token Binding key
pair, possession of which is proven on the TLS connections over which pair, possession of which is proven on the TLS connections over which
the tokens are intended to be used. This use of Token Binding the tokens are intended to be used. This use of Token Binding
protects these tokens from man-in-the-middle and token export and protects these tokens from man-in-the-middle and token export and
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 29, 2018. This Internet-Draft will expire on September 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 41 skipping to change at page 3, line 41
Authentication. This cryptographically binds these tokens to a Authentication. This cryptographically binds these tokens to a
client's Token Binding key pair, possession of which is proven on the client's Token Binding key pair, possession of which is proven on the
TLS connections over which the tokens are intended to be used. This TLS connections over which the tokens are intended to be used. This
use of Token Binding protects these tokens from man-in-the-middle and use of Token Binding protects these tokens from man-in-the-middle and
token export and replay attacks. token export and replay attacks.
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in BCP
2119 [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology 1.2. Terminology
This specification uses the terms "Access Token", "Authorization This specification uses the terms "Access Token", "Authorization
Code", "Authorization Endpoint", "Authorization Server", "Client", Code", "Authorization Endpoint", "Authorization Server", "Client",
"Protected Resource", "Refresh Token", and "Token Endpoint" defined "Protected Resource", "Refresh Token", and "Token Endpoint" defined
by OAuth 2.0 [RFC6749], the terms "Claim" and "JSON Web Token (JWT)" by OAuth 2.0 [RFC6749], the terms "Claim" and "JSON Web Token (JWT)"
defined by JSON Web Token (JWT) [JWT], the term "User Agent" defined defined by JSON Web Token (JWT) [JWT], the term "User Agent" defined
by RFC 7230 [RFC7230], and the terms "Provided", "Referred", "Token by RFC 7230 [RFC7230], and the terms "Provided", "Referred", "Token
Binding" and "Token Binding ID" defined by Token Binding over HTTP Binding" and "Token Binding ID" defined by Token Binding over HTTP
skipping to change at page 23, line 26 skipping to change at page 23, line 26
refresh token, and those credentials should only ever be sent over refresh token, and those credentials should only ever be sent over
TLS server-to-server between the client and the Token Endpoint, there TLS server-to-server between the client and the Token Endpoint, there
is still value in token binding access tokens without token binding is still value in token binding access tokens without token binding
refresh tokens. Authorization servers SHOULD consider supporting refresh tokens. Authorization servers SHOULD consider supporting
access token binding without refresh token binding for confidential access token binding without refresh token binding for confidential
web clients as there are still security benefits to do so. web clients as there are still security benefits to do so.
Clients MUST declare through dynamic (Section 4.1) or static Clients MUST declare through dynamic (Section 4.1) or static
registration information what types of token bound tokens they registration information what types of token bound tokens they
support to enable the server to bind tokens accordingly, taking into support to enable the server to bind tokens accordingly, taking into
account any phase-in policies. Authorization MAY reject requests account any phase-in policies. Authorization servers MAY reject
from any client who does not support token binding (by returning an requests from any client who does not support token binding (by
OAuth error response) per their own security policies. returning an OAuth error response) per their own security policies.
8. IANA Considerations 8. IANA Considerations
8.1. OAuth Dynamic Client Registration Metadata Registration 8.1. OAuth Dynamic Client Registration Metadata Registration
This specification registers the following client metadata This specification registers the following client metadata
definitions in the IANA "OAuth Dynamic Client Registration Metadata" definitions in the IANA "OAuth Dynamic Client Registration Metadata"
registry [IANA.OAuth.Parameters] established by [RFC7591]: registry [IANA.OAuth.Parameters] established by [RFC7591]:
8.1.1. Registry Contents 8.1.1. Registry Contents
skipping to change at page 25, line 42 skipping to change at page 25, line 42
o Change controller: IESG o Change controller: IESG
o Specification Document: Section 6 of [[ this specification ]] o Specification Document: Section 6 of [[ this specification ]]
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-tokbind-https] [I-D.ietf-tokbind-https]
Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper,
N., and J. Hodges, "Token Binding over HTTP", draft-ietf- N., and J. Hodges, "Token Binding over HTTP", draft-ietf-
tokbind-https-10 (work in progress), July 2017. tokbind-https-12 (work in progress), January 2018.
[I-D.ietf-tokbind-negotiation] [I-D.ietf-tokbind-negotiation]
Popov, A., Nystrom, M., Balfanz, D., and A. Langley, Popov, A., Nystrom, M., Balfanz, D., and A. Langley,
"Transport Layer Security (TLS) Extension for Token "Transport Layer Security (TLS) Extension for Token
Binding Protocol Negotiation", draft-ietf-tokbind- Binding Protocol Negotiation", draft-ietf-tokbind-
negotiation-10 (work in progress), October 2017. negotiation-10 (work in progress), October 2017.
[I-D.ietf-tokbind-protocol] [I-D.ietf-tokbind-protocol]
Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
Hodges, "The Token Binding Protocol Version 1.0", draft- Hodges, "The Token Binding Protocol Version 1.0", draft-
skipping to change at page 26, line 21 skipping to change at page 26, line 21
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>. <http://www.iana.org/assignments/oauth-parameters>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://tools.ietf.org/html/rfc7519>. <http://tools.ietf.org/html/rfc7519>.
[OAuth.AuthorizationMetadata] [OAuth.AuthorizationMetadata]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", draft-ietf-oauth- Authorization Server Metadata", draft-ietf-oauth-
discovery-07 (work in progress), March 2017, discovery-09 (work in progress), March 2017,
<http://tools.ietf.org/html/ <http://tools.ietf.org/html/
draft-ietf-oauth-discovery-07>. draft-ietf-oauth-discovery-09>.
[OpenID.TokenBinding] [OpenID.TokenBinding]
Jones, M., Bradley, J., and B. Campbell, "OpenID Connect Jones, M., Bradley, J., and B. Campbell, "OpenID Connect
Token Bound Authentication 1.0", October 2017, Token Bound Authentication 1.0", October 2017,
<http://openid.net/specs/ <http://openid.net/specs/
openid-connect-token-bound-authentication-1_0-02.html>. openid-connect-token-bound-authentication-1_0-02.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 27, line 24 skipping to change at page 27, line 24
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016, RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>. <https://www.rfc-editor.org/info/rfc7800>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, March 2012, Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
11.2. Informative References 11.2. Informative References
[BCP212] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", [BCP212] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
<https://www.rfc-editor.org/info/rfc8252>. <https://www.rfc-editor.org/info/rfc8252>.
skipping to change at page 28, line 15 skipping to change at page 28, line 19
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank the following people for their The authors would like to thank the following people for their
contributions to the specification: Dirk Balfanz, Andrei Popov, contributions to the specification: Dirk Balfanz, Andrei Popov,
Justin Richer, and Nat Sakimura. Justin Richer, and Nat Sakimura.
Appendix B. Document History Appendix B. Document 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 ]]
-06
o Use the boilerplate from RFC 8174.
o Update reference for draft-ietf-tokbind-https to -12 and draft-
ietf-oauth-discovery to -09.
o Minor editorial fixes.
-05 -05
o State that authorization servers should not token bind refresh o State that authorization servers should not token bind refresh
tokens issued to a client that doesn't support bound refresh tokens issued to a client that doesn't support bound refresh
tokens, which can be indicated by the tokens, which can be indicated by the
"client_refresh_token_token_binding_supported" client metadata "client_refresh_token_token_binding_supported" client metadata
parameter. parameter.
o Add Token Binding for JWT Authorization Grants and JWT Client o Add Token Binding for JWT Authorization Grants and JWT Client
Authentication. Authentication.
 End of changes. 12 change blocks. 
13 lines changed or deleted 27 lines changed or added

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