idnits 2.17.00 (12 Aug 2021) /tmp/idnits65503/draft-gerdes-ace-c3dc-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 23, 2018) is 1299 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-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 ACE Working Group S. Gerdes 3 Internet-Draft O. Bergmann 4 Intended status: Standards Track C. Bormann 5 Expires: April 26, 2019 Universitaet Bremen TZI 6 October 23, 2018 8 C3DC -- Constrained Client/Cross-Domain Capable Authorization Profile 9 for Authentication and Authorization for Constrained Environments (ACE) 10 draft-gerdes-ace-c3dc-00 12 Abstract 14 Resource-constrained nodes come in various sizes and shapes and often 15 have constraints on code size, state memory, processing capabilities, 16 user interface, power and communication bandwidth (RFC 7228). 18 This document specifies a profile that describes how two autonomous 19 resource-constrained devices, a client and a server, obtain the 20 required keying material and authorization information to securely 21 communicate with each other. Each of the devices is coupled with a 22 less-constrained device, the authorization manager, that helps with 23 difficult authentication and authorization tasks. The constrained 24 devices do not need to register with authorization managers from 25 other security domains. The profile specifically targets constrained 26 clients and servers. It is designed to consider the security 27 objectives of the owners on the server and the client side. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 26, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2. Details for the C3DC profile as an instance of the DTLS 68 profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.3. Details for the C3DC profile as an instance of the OSCORE 70 profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 6.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The ACE framework [I-D.ietf-ace-oauth-authz] describes how a client 82 obtains authorization to access a (probably constrained [RFC7228]) 83 server from the server's authorization manager. Without additional 84 support, constrained clients will have difficulties to communicate 85 with authorization managers from other security domains. They need 86 to be configured with the necessary keying material to securely 87 communicate with the AS. Manual configuration is not a feasible 88 solution for the Internet of Things where the large number of nodes 89 makes scalability a special concern. Also, constrained devices often 90 lack user interfaces and displays and have slow response times, which 91 make their configuration tedious. Therefore, the configuration of 92 the client is best done using a less-constrained device that mediates 93 between the constrained device and its overseeing principal, i.e., 94 the human being that is configuring the device (such as its owner or 95 user). 97 In the Constrained Client Cross-Domain Authorization Profile (C3DC), 98 each constrained device initially only requires a security 99 association with its own authorization manager; it does not need to 100 register with authorization managers from other security domains. 101 The constrained device and its authorization manager belong to the 102 same security domain, which makes their security association easier 103 to maintain. As the managers are less-constrained, they can perform 104 more difficult authentication and authorization tasks such as storing 105 large numbers of keys, using less-constrained-level protocols such as 106 HTTP or TLS, processing TLS certificates, etc. In this way, the 107 authorization managers authenticate each other and validate each 108 other's authorization. They vouch for their own constrained devices' 109 attributes and keying material and negotiate the details of the 110 secure communication between client and server. If the overseeing 111 principals of both security domains approve of the communication, the 112 managers provide the necessary keying material and authorization 113 information to their respective constrained devices: The client is 114 provided with a claim set from its authorization manager (CAS) that 115 contains the necessary keying material, and, if necessary, the 116 resources and actions it may perform on the server. The server is 117 provided with a claim set from its manager (AS) that contains the 118 keying material and the client's access permissions. The effort for 119 clients and servers is thereby minimized. 121 Summarizing, the role that is termed "Client" in 122 [I-D.ietf-ace-oauth-authz] is split into the actual constrained 123 client, "C", and its authorization manager, "CAS". This is 124 summarized in Figure 1. 126 ------- ------- 127 | RqP | | RO | Principal Level 128 ------- ------- 129 | | 130 controls controls 131 | | 132 V V 133 -------- ------- 134 | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level 135 -------- ------- 136 | | 137 controls and supports controls and supports 138 authentication authentication 139 and authorization and authorization 140 | | 141 V V 142 ------- ------- 143 | C | -- requests resource --> | RS | Constrained Level 144 ------- <-- provides resource-- ------- 146 Figure 1: Overall architecture 148 Authorization Managers may be responsible for large numbers of 149 devices. The overseeing principals only need to configure the 150 authorization manager which will then provide the respective 151 authentication and authorization information to the constrained 152 devices it manages. The management of constrained devices thereby 153 becomes much more comfortable. 155 The benefits of the C3DC profile include: 157 o Constrained devices only require a security association with their 158 own authorization manager. 160 o Constrained clients are not required to authenticate authorization 161 servers from other security domains. 163 o Authentication and authorization on the client side can be 164 dynamic. 166 o Both RqP's and RO's interests are considered. 168 o Constrained devices without a real-time clock that are not time- 169 synchronized can be supported. 171 1.1. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in 176 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 Readers are assumed to be familiar with the terms and concepts 180 defined in [I-D.ietf-ace-actors]. 182 The official pronunciation of "C3DC" rhymes with "curtsy". 184 2. Protocol 186 The C3DC profile comprises three parts: 188 1. transfer of authentication and, if necessary, authorization 189 information between AS and RS; 191 2. transfer of authentication and, if necessary, authorization 192 information between CAS and C; 194 3. establishment of a security association between C and RS. 196 2.1. Overview 198 Figure 2 depicts the C3DC protocol flow (messages in square brackets 199 are optional): 201 CAS C RS AS 202 | <== DTLS chan. ==> | | <== DTLS chan. ==> | 203 | | [Resource Req.-->] | | 204 | | | | 205 | | [<-- AS Info.] | | 206 | | | | 207 | <-- Access Req. | | | 208 | | | | 209 | <==== TLS/DTLS channel (CAS/AS Mutual Authn+Authz) ====> | 210 | | | | 211 | Token Request ------------------------------------------> | 212 | | | | 213 | <------------------------------------------ Token Grant | 214 | | | | 215 | Token Transf. --> | | | 216 | | | | 217 | | <== DTLS chan. ==> | | 218 | | Auth. Res. Req. -> | | 220 Figure 2: Protocol Overview 222 As in the ACE framework, the client (C) may send an unauthorized 223 resource request to the resource server (RS) to obtain the address of 224 the authorization server (AS) that is responsible for the server. 225 The client then contacts its own authorization manager (CAS) with 226 which it already has a security association. As described in 227 [I-D.ietf-ace-actors], C and CAS are expected to belong to the same 228 security domain. 230 The requesting party (RqP), i.e., the human being that is responsible 231 for C and CAS, provisions CAS with authorization information. This 232 enables CAS to decide which resource servers the client is allowed to 233 communicate with, and which authorization servers are allowed to 234 provide information about the RS. If CAS has information that RqP 235 approves of the communication, CAS and AS authenticate each other. 236 As they are less-constrained devices, they may use less-constrained 237 level protocols such as TLS to authenticate each other. AS obtains 238 from its overseeing principal, the resource owner (RO) if CAS is 239 authorized to provide information (e.g., keying material) about C and 240 if CAS's client is authorized to communicate with RS. 242 After AS and CAS thus validated each others' authorization, AS 243 generates an access token for RS. In the response to CAS, the AS may 244 also specify access information that contains the keying material 245 meant for C. The access token and access information must securely 246 be provided to CAS. 248 RqP may further specify the resources and actions that C may perform 249 on RS. In this case, CAS adds this information to the access 250 information. It then securely provides the access token and access 251 information to C. Since C has a security association with CAS, it 252 can authenticate the message. Also, CAS can provide C with validity 253 information that even a constrained C is able to interpret. 255 As in the usual ACE framework protocol flow, the client keeps the 256 access information and provides the access token to the resource 257 server. The resource server already has a security association with 258 its AS and thus can validate that the token actually stems from an 259 authorization server that is authorized by its overseeing principal 260 RO. The client and the server then use the obtained information to 261 communicate securely. 263 2.2. Details for the C3DC profile as an instance of the DTLS profile 265 2.3. Details for the C3DC profile as an instance of the OSCORE profile 267 3. IANA Considerations 269 TBD 271 4. Security Considerations 273 TBD 275 5. Acknowledgements 277 6. References 279 6.1. Normative References 281 [I-D.ietf-ace-oauth-authz] 282 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 283 H. Tschofenig, "Authentication and Authorization for 284 Constrained Environments (ACE) using the OAuth 2.0 285 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 286 (work in progress), October 2018. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 294 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 295 May 2017, . 297 6.2. Informative References 299 [I-D.ietf-ace-actors] 300 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 301 architecture for authorization in constrained 302 environments", draft-ietf-ace-actors-07 (work in 303 progress), October 2018. 305 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 306 Constrained-Node Networks", RFC 7228, 307 DOI 10.17487/RFC7228, May 2014, 308 . 310 Authors' Addresses 312 Stefanie Gerdes 313 Universitaet Bremen TZI 314 Postfach 330440 315 Bremen D-28359 316 Germany 318 Phone: +49-421-218-63906 319 Email: gerdes@tzi.org 321 Olaf Bergmann 322 Universitaet Bremen TZI 323 Postfach 330440 324 Bremen D-28359 325 Germany 327 Phone: +49-421-218-63904 328 Email: bergmann@tzi.org 330 Carsten Bormann 331 Universitaet Bremen TZI 332 Postfach 330440 333 Bremen D-28359 334 Germany 336 Phone: +49-421-218-63921 337 Email: cabo@tzi.org