idnits 2.17.1 draft-richer-oauth-httpsig-00.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 (21 June 2021) is 1039 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) == Unused Reference: 'I-D.ietf-oauth-dpop' is defined on line 222, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-oauth-rar' is defined on line 230, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-oauth-signed-http-request' is defined on line 237, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-secevent-subject-identifiers' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC3230' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC5646' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'RFC6749' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'RFC6750' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC7234' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC7468' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'RFC7515' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC8259' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'RFC8705' is defined on line 304, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BCP195' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-message-signatures-05 == Outdated reference: A later version (-16) exists of draft-ietf-oauth-dpop-03 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-rar-05 == Outdated reference: A later version (-18) exists of draft-ietf-secevent-subject-identifiers-08 ** Obsolete normative reference: RFC 3230 (Obsoleted by RFC 9530) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Downref: Normative reference to an Informational RFC: RFC 8792 Summary: 3 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAUTH J. Richer, Ed. 3 Internet-Draft Bespoke Engineering 4 Intended status: Standards Track 21 June 2021 5 Expires: 23 December 2021 7 OAuth Proof of Possession Tokens with HTTP Message Signatures 8 draft-richer-oauth-httpsig-00 10 Abstract 12 This extension to the OAuth 2.0 authorization framework defines a 13 method for using HTTP Message Signatures to bind access tokens to 14 keys held by OAuth 2.0 clients. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 23 December 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Token Response . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Presenting an HTTP Message Signature Bound Access Token . . . 3 53 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 57 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 58 Appendix A. Document History . . . . . . . . . . . . . . . . . . 7 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 The OAuth 2.0 framework provides methods for clients to get delegated 64 access tokens from an authorization server for accessing protected 65 resources. The access tokens at the center of OAuth 2.0 can be bound 66 to a variety of different mechanisms, including bearer tokens, mutual 67 TLS, or other presentation mechanisms. 69 Bearer tokens are simple to implement but also have the significant 70 security downside of allowing anyone who sees the access token to use 71 that token. This extension defines a token type that binds the token 72 to a presentation key known to the client. The client uses HTTP 73 Message Signatures (I-D.ietf-httpbis-message-signatures) to sign 74 requests using its key, thereby proving its right to present the 75 associated access token. 77 1.1. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in 82 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 This document contains non-normative examples of partial and complete 86 HTTP messages, JSON structures, URLs, query components, keys, and 87 other elements. Some examples use a single trailing backslash '' to 88 indicate line wrapping for long values, as per [RFC8792]. The "\" 89 character and leading spaces on wrapped lines are not part of the 90 value. 92 2. Token Response 94 When the client makes an access token request, the AS associates the 95 generated access token with the client's registered key from the 96 client's "jwks" or "jwks_uri" field. All presentations of this token 97 at any RS MUST contain an HTTP message signature as described in 98 Section 3. 100 A bound access token MUST have a "token_type" value of "httpsig". 101 The response MUST contain a "keyid" value which indicates the key the 102 client MUST use when presenting the access token Section 3. The 103 value of this "keyid" field MUST uniquely identify a key from the 104 client's registered key set by its "kid" value. 106 { 107 "access_token": "2340897.34j123-134uh2345n", 108 "token_type": "httpsig", 109 "keyid": "test-key-rsa-pss" 110 } 112 [[ Editor's note: while this document deals only with using a pre- 113 registered key, it would be possible to have different key binding 114 mechanisms, such as the client presenting an ephemeral key during the 115 token request or the AS generating and assigning a key alongside the 116 token. The WG needs to decide if this is in scope of this document 117 or not. The presentation mechanisms would be the same. ]] 119 3. Presenting an HTTP Message Signature Bound Access Token 121 The algorithm and key used for the HTTP Message Signature are derived 122 from the client's registered information. The key is taken from the 123 client's registered "jwks" or "jwks_uri" field, identified by the 124 "keyid" field of the token response Section 2. The signature 125 algorithm is determined by the "alg" field of the identified key, 126 following the method for JSON Web Algorithm selection described in 127 [I-D.ietf-httpbis-message-signatures]. 129 The client MUST include the access token value in an "Authorization" 130 header using scheme "HTTPSig". Note that the scheme value "HTTPSig" 131 is not case sensitive. 133 Authorization: HTTPSig 2340897.34j123-134uh2345n 135 The client MUST include an HTTP Message Signature that covers, at 136 minimum: 138 * The request target of the RS being called 139 * The "Host" header of the RS being called 141 * The "Authorization" header containing the access token value. 143 The signature parameters MUST include a "created" signature 144 parameter. The RS SHOULD use this field to ensure freshness of the 145 signed request, appropriate to the API being protected. 147 The client MUST NOT include an "alg" signature parameter, since the 148 algorithm is determined by the client's registered key. The client 149 MUST include the "keyid" signature parameter set to the value 150 returned in the token response Section 2. 152 In this example, the client has a key with the "kid" value of "test- 153 key-rsa-pss" which uses the JWA "alg" value of "PS512". The 154 signature input string is: 156 "@request-target": get /foo 157 "host": example.org 158 "authorization": HTTPSig 2340897.34j123-134uh2345n 159 "@signature-params": ("@request-target" "host" "authorization")\ 160 ;created=1618884475;keyid="test-key-rsa-pss" 162 This results in the following signed HTTP message, including the 163 access token. 165 GET /foo HTTP/1.1 166 Host: example.com 167 Date: Tue, 20 Apr 2021 02:07:55 GMT 168 Authorization: HTTPSig 2340897.34j123-134uh2345n 169 Signature-Input: sig1=("@request-target" "host" "authorization")\ 170 ;created=1618884475;keyid="test-key-rsa-pss" 171 Signature: sig1=:o+Fy/a6IIWhHwnMFhsHqfXEpheWGBMOU3pheT50zA8rL5F8Nur\ 172 xBKAPylMGBWYCKH5Bd+TB0Co6vqANlXyOCM9Zr5c/UmR5WGex5/OgJJmfN7gOVOH5\ 173 pB2Zxa233xsohfwo9liBlctukN5//E3F04rKjIkoeTFJiS+hMcOzn29esgFSEl4Jy\ 174 oO5Q8snMIsC56ZAPYwU7rJis1Wvl6Y9/9tpW6gIn/SHwArhPQSAb0zZy6mCiw654n\ 175 CaKw5NYJ9S0DZlnV4T7nJtdZsHOkddF6kH4WVka3ev0xONI5kYkEdR1Gw0VAE9thi\ 176 p+3/aFoUVTJ/1J6JfehZpXqehwv3KNoQ==: 178 An RS receiving such a signed message and a bound access token MUST 179 verify the HTTP Message Signature as described in 180 [I-D.ietf-httpbis-message-signatures]. The RS MUST verify that all 181 required portions of the HTTP request are covered by the signature by 182 examining the contents of the signature parameters. 184 [[ Editor's note: we should define confirmation methods for access 185 tokens here, including JWT values and introspection response values 186 to allow the RS to verify the signature w/o the client's registration 187 information. ]] 189 4. Acknowledgements 191 5. IANA Considerations 193 [[ TBD: register the token type and new parameters into their 194 appropriate registries, as well as the JWT and introspection 195 parameters. ]] 197 6. Security Considerations 199 [[ TBD: There are a lot of security considerations to add. ]] 201 All requests have to be over TLS or equivalent as per [BCP195]. 203 7. Privacy Considerations 205 [[ TBD: There are a lot of privacy considerations to add. ]] 207 8. Normative References 209 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 210 "Recommendations for Secure Use of Transport Layer 211 Security (TLS) and Datagram Transport Layer Security 212 (DTLS)", May 2015, 213 . 215 [I-D.ietf-httpbis-message-signatures] 216 Backman, A., Richer, J., and M. Sporny, "Signing HTTP 217 Messages", Work in Progress, Internet-Draft, draft-ietf- 218 httpbis-message-signatures-05, 8 June 2021, 219 . 222 [I-D.ietf-oauth-dpop] 223 Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., 224 Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof- 225 of-Possession at the Application Layer (DPoP)", Work in 226 Progress, Internet-Draft, draft-ietf-oauth-dpop-03, 7 227 April 2021, . 230 [I-D.ietf-oauth-rar] 231 Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 232 Rich Authorization Requests", Work in Progress, Internet- 233 Draft, draft-ietf-oauth-rar-05, 15 May 2021, 234 . 237 [I-D.ietf-oauth-signed-http-request] 238 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 239 Signing HTTP Requests for OAuth", Work in Progress, 240 Internet-Draft, draft-ietf-oauth-signed-http-request-03, 8 241 August 2016, . 244 [I-D.ietf-secevent-subject-identifiers] 245 Backman, A. and M. Scurtescu, "Subject Identifiers for 246 Security Event Tokens", Work in Progress, Internet-Draft, 247 draft-ietf-secevent-subject-identifiers-08, 24 May 2021, 248 . 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, 253 DOI 10.17487/RFC2119, March 1997, 254 . 256 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 257 RFC 3230, DOI 10.17487/RFC3230, January 2002, 258 . 260 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 261 Resource Identifier (URI): Generic Syntax", STD 66, 262 RFC 3986, DOI 10.17487/RFC3986, January 2005, 263 . 265 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 266 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 267 September 2009, . 269 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 270 RFC 6749, DOI 10.17487/RFC6749, October 2012, 271 . 273 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 274 Framework: Bearer Token Usage", RFC 6750, 275 DOI 10.17487/RFC6750, October 2012, 276 . 278 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 279 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 280 RFC 7234, DOI 10.17487/RFC7234, June 2014, 281 . 283 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 284 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 285 April 2015, . 287 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 288 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 289 2015, . 291 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 292 DOI 10.17487/RFC7517, May 2015, 293 . 295 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 296 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 297 May 2017, . 299 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 300 Interchange Format", STD 90, RFC 8259, 301 DOI 10.17487/RFC8259, December 2017, 302 . 304 [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. 305 Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication 306 and Certificate-Bound Access Tokens", RFC 8705, 307 DOI 10.17487/RFC8705, February 2020, 308 . 310 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 311 "Handling Long Lines in Content of Internet-Drafts and 312 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 313 . 315 Appendix A. Document History 317 * -00 319 - Initial individual draft. 321 Author's Address 323 Justin Richer (editor) 324 Bespoke Engineering 325 Email: ietf@justin.richer.org 326 URI: https://bspk.io/