idnits 2.17.1 draft-sakimura-oauth-rjwtprof-03.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 (March 26, 2015) is 3291 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: 0 errors (**), 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 March 26, 2015 5 Expires: September 27, 2015 7 Sender Constrained JWT for OAuth 2.0 8 draft-sakimura-oauth-rjwtprof-03 10 Abstract 12 This discussion document describes a method to indicate a sender 13 constraint within JWT. It could potentially be incorporated into POP 14 spec. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 September 27, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Sender Constraint Representation . . . . . . . . . . . . . . 3 60 4. Client Authentication . . . . . . . . . . . . . . . . . . . . 3 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 5.1. JSON Web Token Claim Registration . . . . . . . . . . . . 4 63 5.2. Registry Request Contents . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Appendix A. Document History . . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture [POPA] 75 identifies Sender Constraint and Key Confirmation as a possible 76 threat mitigation against the use of token by an unauthorized 77 presenter. While Proof-Of-Possession Semantics for JSON Web Tokens 78 (JWTs) [POPS] touches briefly on the Sender Constraint, it is only 79 one paragraph within a introductory text and does not discuss it in 80 detail. Instead, it devotes much of the discussion to the Key 81 Confirmation method. It also is making the usage of such token 82 against the resource out of scope. 84 This discussion draft describes a way to express the Sender 85 Constraint in the JWT, as well as one possible way of using it to 86 access a protected resource. 88 1.1. Notational Conventions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in RFC 93 2119 [RFC2119]. 95 Unless otherwise noted, all the protocol parameter names and values 96 are case sensitive. 98 2. Terminology 100 For the purpose of this document, the terms defined in RFC6749 101 [RFC6749] is used. In addition, following term is defined. 103 Authorized Presenter Party that the token is intended to be used by. 105 3. Sender Constraint Representation 107 Sender Constraint is expressed by including the following member at 108 the top level of JWT payload. 110 azp The Client ID of the Authorized Presenter. 112 Follwoing is an example of such JWT payload. 114 { 115 "iss": "https://server.example.com", 116 "sub": "joe@example.com", 117 "azp": "clientID-1342050", 118 "aud": "https://client.example.org", 119 "exp": "1361398824", 120 "nbf": "1360189224", 121 } 123 Figure 3-1 Example of Sender Constrained JWT. 125 4. Client Authentication 127 The resource that supports this specification MUST authenticate the 128 Client. In this document a possible method is proposed as follows: 130 1. The authorized presenter issues a HEAD or GET request to the 131 resource. 133 GET /resource/1234 HTTP/1.0 134 Host: server.example.com 136 2. The resource returns a HTTP 401 response with "WWW-Authenticate" 137 header with "Named" scheme, whcih includes nonce. 139 HTTP/1.0 401 Unauthorized 140 Server: HTTPd/0.9 141 Date: Wed, 14 March 2015 09:26:53 GMT 142 WWW-Authenticate: Named nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093" 144 3. The client creates JWS compact seriarization over the nonce. 146 4. The client sends the request to the resource, this time with 147 Authorize: header with Named scheme and access token and the JWS. 149 GET /resource/1234 HTTP/1.0 150 Host: server.example.com 151 Authorization: Named at="access.token.jwt", s="jws.of.nonce" 153 5. The resource server finds the client key corresponding to the 154 value of "azp" in the access token. It may have been obtained 155 through client registration at the Issuer. 157 6. The resource server creates the JWS of the nonce and compare it 158 with the value of "s" of the Authorization header. If it fails, the 159 process stops here and the resource access MUST be denied. 161 7. The resource server MUST verify the access token. If it is 162 valid, the resource SHOULD be returned as HTTP resonse. 164 5. IANA Considerations 166 5.1. JSON Web Token Claim Registration 168 This specification registers the Destination Claim defined herein in 169 the IANA JSON Web Token Claims registry defined in [I-D.ietf-oauth- 170 json-web-token]. 172 5.2. Registry Request Contents 174 o Claim Name: "azp" 176 o Claim Description: The Client ID of the Authorized Presenter 178 o Change Controller: IESG 180 o Specification Document(s): Section 3 of this document 182 6. Security Considerations 184 Needless to say, the client's secret key must be kept securely. 186 7. Acknowledgements 188 TBD 190 8. References 192 8.1. Normative References 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997. 197 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 198 6749, October 2012. 200 8.2. Informative References 202 [POPA] Hunt, P., Ed., "OAuth 2.0 Proof-of-Possession (PoP) 203 Security Architecture", March 2015. 205 [POPS] Jones, M., "Proof-Of-Possession Semantics for JSON Web 206 Tokens (JWTs)", March 2015. 208 Appendix A. Document History 210 -03 Removed most of the duplication with [POPS] 212 -02 Included key confirmation method etc. The first version on the 213 tools.ietf.org. (Prevous versions were sent just as email 214 attachements.) 216 Author's Address 218 Nat Sakimura 219 Nomura Research Institute 221 Email: sakimura@gmail.com