idnits 2.17.1 draft-schaad-cnf-cwt-id-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 (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-ace-cwt-proof-of-possession-03 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-16 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft August Cellars 4 Intended status: Experimental October 22, 2018 5 Expires: April 25, 2019 7 Use of a CWT identifier as a Confirmation Method 8 draft-schaad-cnf-cwt-id-00 10 Abstract 12 TBD 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at https://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on April 25, 2019. 31 Copyright Notice 33 Copyright (c) 2018 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. CWT Id Confirmation Method . . . . . . . . . . . . . . . . . 3 52 4. CWT Id in AS Response . . . . . . . . . . . . . . . . . . . . 3 53 5. Processing Rules for the Issuer of a CWT Id Confirmation 54 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Processing Rules for the CWT Id Confirmation Method . . . . . 4 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 In many cases an authorization in the form of a COSE Web Token (CWT) 64 [RFC8392] will be issued in the ACE OAuth [I-D.ietf-ace-oauth-authz] 65 framework with a minimal set of privileges and a Proof-of-Possession 66 claim [I-D.ietf-ace-cwt-proof-of-possession]. It may then become 67 necessary to issue a new token for a shorter period with more 68 capabilities, but use the same information for validation. In these 69 cases it makes sense to issue a new authorization token which refers 70 the the first token to provide the additional capabilities. This 71 document defines a new confirmation type that allows this type of 72 referencing to be done. 74 This differs from the refresh token in that the new token will be 75 limited to the duration of the existing CWT, while a new POP CWT 76 would be issued when using a refresh token. 78 1.1. Conventions Used in This Document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document are to be interpreted as described in BCP 83 14 [RFC2119] [RFC8174] when, and only when, they appear in all 84 capitals, as shown here. 86 2. Terminology 88 o "Relying Party" is used in this document to refer to the party 89 which is relying on the contents of a CWT in order to make a 90 security decision. In other OAuth documents, this is normally 91 referred to as the XXXXXX. 93 o "Referenced CWT" is used to denote the CWT which is referred to or 94 referenced by a referencing CWT. The referenced CWT has a 95 confirmation type with the POP keying information in it. 97 o "Referencing CWT" is used to denote the CWT which is making a 98 reference to a second CWT. The referencing CWT contains the 99 confirmation type defined in this document. 101 3. CWT Id Confirmation Method 103 The CWT Id confirmation method is identified by TBD1 in the 'cnf' 104 element (defined in [I-D.ietf-ace-cwt-proof-of-possession]. For use 105 in documentation the string value of 'cwtid' is to be used to refer 106 to this confirmation type. 108 The CWT Id confirmation method uses the type of CBOR map and has the 109 following fields: 111 o Issuer is an optional field in the map. If present the issuer 112 field contains the 'iss' field of CWT which is being referenced. 113 If absent, the issuer is the same entity which issued the 114 referencing CWT. When encoded, this field uses TBD2 as the map 115 key. 117 o CWT Id is a required field in the map. The field contains the 118 'cwtid' field of the referenced CWT. When encoded, this field 119 uses TBD3 as the map key. 121 An example of what this would look like is: 123 / cnf /: { 124 / cwtid /: 'CWTID 1234', 125 / iss /: "Entry-Level AS" 126 } 128 4. CWT Id in AS Response 130 Since the CWT Id is currently only provided to the RS as part of the 131 token, for an AS which supports this option the CWT Id additionally 132 needs to be provided to the Client. This document therefore defines 133 two new fields to go into C-AS response messages: 135 "iss" provides the issuer name of the CWT. This field is only 136 present for an AS which would allow a second AS to refer to the 137 CWT. 139 "cwtid" contains the CWT Id for the issued token. 141 5. Processing Rules for the Issuer of a CWT Id Confirmation Method 143 When an AS is going to issue a CWT it MUST perform the following 144 steps or their equivalent: 146 1. If the issued CWT will refer to a CWT issued by a different AS, 147 the issuing AS MUST be configured to permit this. 149 2. The AS MUST validate that the entity for which this CWT is being 150 issued for is the same entity that is the subject of the 151 referenced CWT. This can be done by causing the client to 152 perform a POP operation with the referenced CWTs POP key 153 information or by querying the AS which issued the referenced 154 CWT. If the same AS is being used for both CWTs, then the AS can 155 consult a database of clients and CWTs to check for identity 156 matching. 158 3. The issued CWT should refer to the original POP CWT. The chain 159 of trust SHOULD NOT be transitive through another CWT. 161 6. Processing Rules for the CWT Id Confirmation Method 163 When a relying party receives a referencing CWT it MUST perform the 164 following steps or their equivalent as part of making a security 165 decision: 167 1. The referencing CWT MUST have the authentication checked on it. 168 If the authentication fails, the CWT MUST be rejected. 170 2. If the CWT Id confirmation type contains an issuer field, 171 configuration information MUST be checked that the referencing 172 CWT issuer is permitted to use the referenced CWT issuer. If the 173 reference is not permitted, then the CWT MUST be rejected. 175 3. If the referenced CWT is expired, the referencing CWT MUST be 176 rejected. 178 4. The claims in the referenced CWT are copied from the referenced 179 CWT to the referencing CWT if the claim does not exist in the 180 referencing CWT. 182 5. The modified CWT is then processed in a normal manner. 184 7. Security Considerations 186 As the security of the set of CWTs is going rest on the underlying 187 POP CWT, loss of the key will allow any CWT which references the 188 orignal CWT to be used by a third party. All entities which have the 189 secret portion of the key need to protect that portion of the key. 191 The use of this feature assumes a specific model of evaluating the 192 rules for access control. Specifically, it assumes that if there are 193 multiple access tokens, satisfying the conditions for any of the 194 tokens means that access is going to be granted. This model is in 195 contrast to one where if any of the access tokens was a deny, then 196 access to to the resource would be denied. 198 8. IANA Considerations 200 There are some items that need to be registered. Figure out what 201 they are and put them here. 203 9. Normative References 205 [I-D.ietf-ace-cwt-proof-of-possession] 206 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 207 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 208 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 209 possession-03 (work in progress), June 2018. 211 [I-D.ietf-ace-oauth-authz] 212 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 213 H. Tschofenig, "Authentication and Authorization for 214 Constrained Environments (ACE) using the OAuth 2.0 215 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 216 (work in progress), October 2018. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, 220 DOI 10.17487/RFC2119, March 1997, 221 . 223 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 224 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 225 May 2017, . 227 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 228 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 229 May 2018, . 231 Author's Address 232 Jim Schaad 233 August Cellars 235 Email: ietf@augustcellars.com