idnits 2.17.1 draft-sakimura-oauth-rjwtprof-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([POPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2015) is 3218 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group N. Sakimura 3 Internet-Draft Nomura Research Institute 4 Intended status: Standards Track K. Li 5 Expires: December 31, 2015 Alibaba Group 6 June 29, 2015 8 Sender Constrained JWT for OAuth 2.0 9 draft-sakimura-oauth-rjwtprof-04 11 Abstract 13 This discussion document describes a method to indicate a sender 14 constraint within JWT. It could potentially be incorporated into 15 POPS spec [POPS]. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 31, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Sender Constraint Representation . . . . . . . . . . . . . . 3 62 5. Client Authentication . . . . . . . . . . . . . . . . . . . . 4 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Named Authentication Scheme . . . . . . . . . . . . . . . 5 65 6.2. JSON Web Token Claim Registration . . . . . . . . . . . . 5 66 6.2.1. Registry Request Contents . . . . . . . . . . . . . . 5 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 9.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Appendix A. Document History . . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture [POPA] 78 identifies Sender Constraint and Key Confirmation as possible threat 79 mitigation methods against the use of token by an unauthorized 80 presenter. While Proof-Of-Possession Semantics for JSON Web Tokens 81 (JWTs) [POPS] touches briefly on the Sender Constraint, it is only 82 one paragraph within a introductory text and does not discuss it in 83 detail. Instead, it devotes much of the discussion to the Key 84 Confirmation method. It also is making the usage of such token 85 against the resource server out of scope. 87 This discussion draft describes a way to express the Sender 88 Constraint in the JWT, as well as one possible way of using it to 89 access a protected resource. 91 1.1. Notational Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in RFC 96 2119 [RFC2119]. 98 Unless otherwise noted, all the protocol parameter names and values 99 are case sensitive. 101 2. Terminology 103 For the purpose of this document, the terms defined in RFC6749 104 [RFC6749] is used. In addition, following term is defined. 106 Authorized Presenter Party that the token is intended to be used by. 108 3. Justification 110 There are scenarios that the bearer token may be stolen, modified, 111 reused or replayed. To prevent these threats, resource servers need 112 to obtain additional assurance that the client is indeed authorized 113 to present an access token. The detailed use cases can be found in 114 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture [POPA] 115 specificaiton. 117 As described in OAuth 2.0 Proof-of-Possession (PoP) Security 118 Architecture [POPA] specificaiton, there are several ways to prevent 119 these bearer token threats: Confidentiality Protection, Sender 120 Constraint and Key Confirmation. Key Confirmation mechanism is 121 desribed in OAuth 2.0 Proof-Of-Possession Semantics for JSON Web 122 Tokens (JWTs) [POPS] specification in detail, but Sender Constraint 123 mechanism is not explained in detail. 125 In fact, Key Confirmation mechanism increased a lot of complexity, 126 and a complete key distribution protocol has to be defined. Sender 127 Confirmation mechanism can be relatively easier to implement in some 128 cases, for example, when the client identity informaiton is easy to 129 be accessed through APIs, when the client authentication is easy to 130 achieve. So, Sender Confirmation mechanism should also be specified, 131 and it can work as an alternative mechanism to mitigate the bearer 132 token threats. 134 4. Sender Constraint Representation 136 Sender Constraint is expressed by including the following member at 137 the top level of JWT payload. 139 azp The Client ID of the Authorized Presenter. 141 Following is an example of such JWT payload. 143 { 144 "iss": "https://server.example.com", 145 "sub": "joe@example.com", 146 "azp": "clientID-1342050", 147 "aud": "https://client.example.org", 148 "exp": "1361398824", 149 "nbf": "1360189224", 150 } 152 Figure 1 Example of Sender Constrained JWT. 154 5. Client Authentication 156 The resource server that supports this specification MUST 157 authenticate the Client. In this document a possible method is 158 proposed as follows: 160 1. The authorized presenter issues a HEAD or GET request to the 161 resource server. 163 GET /resource/1234 HTTP/1.0 164 Host: server.example.com 166 2. The resource server returns a HTTP 401 response with "WWW- 167 Authenticate" header with "Named" scheme, whcih includes nonce. 169 HTTP/1.0 401 Unauthorized 170 Server: HTTPd/0.9 171 Date: Wed, 14 March 2015 09:26:53 GMT 172 WWW-Authenticate: Named nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093" 174 3. The client creates JWS compact seriarization over the nonce. 176 4. The client sends the request to the resource server, this time 177 with Authorization: header with Named scheme and access token and the 178 JWS. 180 GET /resource/1234 HTTP/1.0 181 Host: server.example.com 182 Authorization: Named at="access.token.jwt", s="jws.of.nonce" 184 5. The resource server finds the client key corresponding to the 185 value of "azp" in the access token. It may have been obtained 186 through client registration at the Issuer. 188 6. The resource server creates the JWS of the nonce and compares it 189 with the value of "s" of the Authorization header. If it fails, the 190 process stops here and the resource access MUST be denied. 192 7. The resource server MUST verify the access token. If it is 193 valid, the resource SHOULD be returned as HTTP resonse. 195 6. IANA Considerations 197 6.1. Named Authentication Scheme 199 A new scheme has been registered in the HTTP Authentication Scheme 200 Registry as follows: 202 Authentication Scheme Name: Named 204 Reference: Section xx of this specification 206 Notes (optional): Tha Named Authentication scheme is inteded to be 207 used only with OAuth Resource Access, and thus does not support proxy 208 authentication. 210 6.2. JSON Web Token Claim Registration 212 This specification registers the Destination Claim defined herein in 213 the IANA JSON Web Token Claims registry defined in [I-D.ietf-oauth- 214 json-web-token]. 216 6.2.1. Registry Request Contents 218 o Claim Name: "azp" 220 o Claim Description: The Client ID of the Authorized Presenter 222 o Change Controller: IESG 224 o Specification Document(s): Section 3 of this document 226 7. Security Considerations 228 Needless to say, the client's secret key must be kept securely. 230 8. Acknowledgements 232 TBD 234 9. References 236 9.1. Normative References 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, March 1997. 241 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 242 6749, October 2012. 244 9.2. Informative References 246 [POPA] Hunt, P., Ed., "OAuth 2.0 Proof-of-Possession (PoP) 247 Security Architecture", March 2015. 249 [POPS] Jones, M., "Proof-Of-Possession Semantics for JSON Web 250 Tokens (JWTs)", March 2015. 252 Appendix A. Document History 254 -04 Added justification section 256 -03 Removed most of the duplication with [POPS] 258 -02 Included key confirmation method etc. The first version on the 259 tools.ietf.org. (Prevous versions were sent just as email 260 attachements.) 262 Authors' Addresses 264 Nat Sakimura 265 Nomura Research Institute 267 Email: sakimura@gmail.com 269 Kepeng Li 270 Alibaba Group 272 Email: kepeng.lkp@alibaba-inc.com