idnits 2.17.1 draft-palombini-ace-oscore-profile-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 (September 21, 2020) is 1310 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) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track September 21, 2020 5 Expires: March 25, 2021 7 Identifier Negotiation for the OSCORE Profile of ACE 8 draft-palombini-ace-oscore-profile-id-00 10 Abstract 12 This document defines a mechanism to negotiate OSCORE security 13 material identifiers for the OSCORE profile of ACE. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on March 25, 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Identifiers Negotiation . . . . . . . . . . . . . . . . . . . 4 53 3.1. C-to-AS: . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.2. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 4 55 3.3. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 4 56 3.4. Not Supported . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 5 60 5.2. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 6 61 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 In the OSCORE profile, the client and resource server receive the 68 OSCORE Sender and Recipient Identifiers from the AS. This has some 69 limitations, especially if the OSCORE profile is used in conjuction 70 with other mechamisms that also derive identifiers, in which case 71 either collisions would happen, or longer identifiers need to be used 72 as a result. This document describes a way to negotiate the 73 identifiers so that collisions does not happen even if other 74 authentication mechanisms are used. 76 1.1. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 80 "OPTIONAL" in this document are to be interpreted as described in BCP 81 14 [RFC2119] [RFC8174] when, and only when, they appear in all 82 capitals, as shown here. 84 Readers are expected to be familiar with the terms and concepts 85 described in [I-D.ietf-ace-oauth-authz] 86 [I-D.ietf-ace-oscore-profile], such as Authorization Server (AS) and 87 Resource Server (RS). 89 Readers are expected to be familiar with the terms and concepts 90 described in [RFC8613], especially on the use of Sender, Recipient 91 and Context Identifiers. 93 2. Background 95 TODO: introduce OSCORE Sender and Recipient Identifiers and how they 96 are used in OSCORE. 98 The OSCORE profile specifies that the AS assigns and sends the OSCORE 99 Sender and Recipient Identifiers to both Client and RS, together with 100 the rest of the input material to derive the complete OSCORE Security 101 Context. That is done by including these identifiers in the Access 102 Token and Access Information response to the Client. The access 103 token containing these identifiers is also forwarded to the RS by the 104 Client. 106 C RS AS 107 | | | 108 | ----- POST /token ----------------------------> | 109 | | | 110 | <---------------------------- Access Token ----- | 111 | + Access Information | 112 | ---- POST /authz-info ---> | | 113 | (access_token, N1) | | 114 | | | 115 | <--- 2.01 Created (N2) --- | | 116 | | | 117 /Sec Context /Sec Context | 118 Derivation/ Derivation/ | 119 | | | 120 | ---- OSCORE Request -----> | | 121 | | | 122 | /proof-of-possession | 123 | Sec Context storage/ | 124 | | | 125 | <--- OSCORE Response ----- | | 126 | | | 127 /proof-of-possession | | 128 Sec Context storage/ | | 129 | | | 130 | ---- OSCORE Request -----> | | 131 | ... | | 133 Figure 1: OSCORE Profile Overview 135 This works with a number of requirements: the OSCORE profile states 136 that if other authentication mechanisms are used to set up OSCORE 137 between the same client and RS, that do not rely on an AS assigning 138 identifiers, collisions may happen and need to be mitigated. Such 139 mitigation mechanism also need to be used if a different AS (not 140 sinchronized with the first AS) or authentication protocol is used to 141 set up OSCORE between the same RS and other clients. A mitigation 142 example would be to use distinct namespaces of context identifiers 143 for different authentication mechanisms or authentication servers. 144 Another solution would be to use longer random identifiers. A third 145 possible solution, acceptable if collisions are not expected to be 146 numerous, would be to rely on trial and error of security contexts 147 when receiving a message. 149 These solutions have the drawback of requiring longer identifiers to 150 be used in general, which leads to larger message sizes, or 151 additional processing on the RS. 153 This document specifies a different mechanism to assign identifiers 154 that works on top of the current OSCORE profile, and that allows to 155 set up identifiers without collisions, even when other authentication 156 mechanisms or non-syncrhonized AS are used. 158 3. Identifiers Negotiation 160 This section details the message exchange. 162 3.1. C-to-AS: 164 3.2. C-to-RS: POST to authz-info endpoint 166 The client generates its own Recipient Id for the OSCORE Security 167 Context that it is establishing with the RS. By generating its own 168 Recipient Id, the client makes sure that it does not collide with any 169 other Recipient Identifiers stored in memory. The client posts it 170 together with what is described in Section 4.1 of 171 [I-D.ietf-ace-oscore-profile]. The Client includes the Recipient Id 172 in the POST to authz-info request, as a ace_client_recipientid 173 parameter, as registered in Section 5.1 and Section 5.2. 175 When receiving the POST to authz-info request including the 176 ace_client_recipientid parameter, the RS MUST set its own Sender 177 Identifier to the value of the ace_client_recipientid and discard any 178 ServerId present in the access token. 180 3.3. RS-to-C: 2.01 (Created) 182 The RS generates its own Recipient Id for the OSCORE Security Context 183 that it is establishing with the client. The Recipient Id MUST be 184 different than the ace_client_recipientid received from the client. 185 By generating its own Recipient Id, the RS makes sure that it does 186 not collide with any other Recipient Identifiers stored in memory. 187 The RS sends it to the Client together with what is described in 188 Section 4.2 of [I-D.ietf-ace-oscore-profile]. The RS includes the 189 Recipient Id in the 2.01 (Created) response, as a 190 ace_server_recipientid parameeter, as registered in Section 5.1 and 191 Section 5.2. 193 When receiving the response including the ace_server_recipientid 194 parameter, the Client MUST set its own Sender Identifier to the value 195 of the ace_server_recipientid and discard any ClientId present in the 196 access token. 198 3.4. Not Supported 200 If the RS does not support this specification, and the client sends 201 its Recipient Id in the ace_client_recipientid, the server will not 202 recognize the parameter and either respond with an error response or 203 discard the parameter. 205 If the RS replies with an error response or if the RS replies with a 206 2.01 (Created) not including the ace_server_recipientid parameter the 207 Client MUST assume the server uses the identifiers in the token and 208 do the same. 210 TODO: so it is possible for anybody in the middle to revert back to 211 OSCORE profile, without this addition, and therefore create 212 collisions without identifiers. 214 4. Security Considerations 216 TODO 218 5. IANA Considerations 220 This document has the following actions for IANA. 222 5.1. OAuth Parameters Registry 224 The following registrations are done for the OAuth ParametersRegistry 225 following the procedure specified in section 11.2 of [RFC6749]: 227 o Parameter name: ace_client_recipientid o Parameter usage location: 228 client-rs request o Change Controller: IESG o Specification 229 Document(s): [[This specification]] 231 o Parameter name: ace_server_recipientid o Parameter usage location: 232 rs-client response o Change Controller: IESG o Specification 233 Document(s): [[This specification]] 235 5.2. OAuth Parameters CBOR Mappings Registry 237 The following registrations are done for the OAuth Parameters CBOR 238 Mappings Registry following the procedure specified in section 8.9 of 239 [I-D.ietf-ace-oauth-authz]: 241 * Name: ace_client_recipientid 242 * CBOR Key: TBD (range -256 to 255) 243 * Value Type: byte string 244 * Reference: \[\[This specification\]\] 246 * Name: ace_server_recipientid 247 * CBOR Key: TBD (range -256 to 255) 248 * Value Type: byte string 249 * Reference: \[\[This specification\]\] 251 Acknowledgments 253 This document was started from comments and discussion with the 254 following individuals: John Mattsson, Jim Schaad, Goeran Selander. 256 7. Normative References 258 [I-D.ietf-ace-oauth-authz] 259 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 260 H. Tschofenig, "Authentication and Authorization for 261 Constrained Environments (ACE) using the OAuth 2.0 262 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 263 (work in progress), June 2020. 265 [I-D.ietf-ace-oscore-profile] 266 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 267 "OSCORE profile of the Authentication and Authorization 268 for Constrained Environments Framework", draft-ietf-ace- 269 oscore-profile-11 (work in progress), June 2020. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 277 RFC 6749, DOI 10.17487/RFC6749, October 2012, 278 . 280 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 281 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 282 May 2017, . 284 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 285 "Object Security for Constrained RESTful Environments 286 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 287 . 289 Author's Address 291 Francesca Palombini 292 Ericsson AB 293 Torshamnsgatan 23 294 Kista SE-16440 Stockholm 295 Sweden 297 Email: francesca.palombini@ericsson.com