idnits 2.17.1 draft-seitz-ace-problem-description-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 (May 16, 2014) is 3633 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 Internet-Draft SICS Swedish ICT 4 Intended Status: Informational G. Selander 5 Expires: November 17, 2014 Ericsson 7 May 16, 2014 9 Problem Description for Authorization in Constrained Environments 10 draft-seitz-ace-problem-description-00 12 Abstract 14 We present a problem description for authentication and authorization 15 in constrained-node networks, i.e. networks which contain some 16 devices with severe constraints on power, memory, and processing 17 resources. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 63 3.3. Communication Security . . . . . . . . . . . . . . . . . . 8 64 3.4. Key Management . . . . . . . . . . . . . . . . . . . . . . 9 65 4. Assumptions and Requirements . . . . . . . . . . . . . . . . . 10 66 4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.2 Constrained Devices . . . . . . . . . . . . . . . . . . . . 10 68 4.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.4 Authorization information . . . . . . . . . . . . . . . . . 11 70 4.5 Access to authorization information . . . . . . . . . . . . 11 71 4.6 Resource access . . . . . . . . . . . . . . . . . . . . . . 12 72 4.7 Keys and cipher suites . . . . . . . . . . . . . . . . . . . 12 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 78 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Authorization is the process of deciding what an entity ought to be 84 allowed to do. This memo is about properties of security protocols 85 to enable explicit and dynamic authorization of clients to access a 86 resource at a server, in particular in constrained environments when 87 the client and/or server are constrained nodes. See section 1.1 for 88 terminology. 90 Relevant use cases are presented in [I-D.seitz-ace-usecases], which 91 also lists requirements derived from the use cases. That draft 92 provides a good setting for the scope of the problem area, but does 93 not present a detailed problem statement. 95 We present in this memo a problem description for authentication and 96 authorization in constrained environments with some more detailed 97 candidate assumptions and requirements (section 4). 99 1.1 Terminology 101 Certain security-related terms are to be understood in the sense 102 defined in [RFC4949]. These terms include, but are not limited to, 103 "authentication", "authorization", "confidentiality", "encryption", 104 "data integrity", "message authentication code", and "verify". 106 RESTful terms including "resource", "representation", etc. are to be 107 understood as used in RFC2616 and CoAP [I-D.ietf-core-coap]. 109 Terminology for constrained environments including "constrained 110 device", "constrained-node network", "class 1", etc. are defined in 111 [RFC7228]. 113 "Explicit" authorization is used here to describe the ability to 114 specify in some detail which entity has access to what and under what 115 conditions, as opposed to "implicit" authorization where an entity is 116 either allowed to access everything or nothing. 118 "Dynamic" authorization means that the access control polices and the 119 parameters on which they are evaluated may change during normal 120 operations, as opposed to "static" authorization meaning that access 121 control policies cannot be changed during normal operations and may 122 require some special procedure such as out-of-band provision. 124 2. Background 126 We assume a client-server setting, where a client wishes to access 127 some resource hosted by a server. Such resources may e.g. be sensor 128 data, configuration data, or actuator settings. Thus access to a 129 resource could be by different methods, some of which change the 130 state of the resource. In this memo, we consider the REST setting 131 i.e. GET, POST, PUT and DELETE, and application protocols in scope 132 are HTTP and CoAP [I-D.ietf-core-coap]. 134 We assume that the roles of client and server are not fixed, i.e. a 135 node which is client could very well be server in some other context 136 and vice-versa. Further we assume that in some cases, clients are 137 not previously known to servers, thus we cannot assume that the 138 server has access control policies specific to that client when the 139 client initiates communication. 141 Finally we also assume that in a significant number of cases, the 142 server and/or the client are too constrained to handle the 143 authorization decision procedure and related configuration on their 144 own. Many authorization solutions involve a centralized, trusted 145 third party, supporting the client and/or resource server. A trusted 146 third party provides a more scalable way to centrally manage 147 authorization policies, in order to ensure consistent authorization 148 decisions. Instead of having the client-server interaction 149 performing authentication, authorization, key establishment, etc. the 150 third party can be involved to offer support with one or several of 151 these tasks: 153 o One example of support is that the client is authenticated to 154 the third party instead of the server. To provide confidence to 155 the server that a certain client has indeed been authenticated, 156 some information identifying the authenticated client (in a 157 protected form) needs to be communicated from the third party 158 to the server, e.g. a secret key of the client. 160 o A second example is that the third party provides a shared 161 secret key to enable authentication and secure communication 162 between the client and server, instead of client and server 163 establishing this autonomously. The shared key needs to be 164 communicated (in a protected form) from the third party to 165 client and server, respectively. 167 o A third example is that the authorization decision is performed 168 by the third party instead of by the server. To provide 169 confidence to the server about a specific authorization 170 decision, some authorization information (in a protected form) 171 needs to be communicated from the third party to the server. 172 In addition, the server needs some information identifying the 173 client to verify that the requesting party is indeed the 174 authorized client, e.g. a secret key with which the server can 175 verify a message authentication code generated by the client. 177 Protecting information carried between third party and server, 178 requires some a priori established keys. How those keys are 179 established is out of scope for this problem. However, keys that are 180 used to protect information between third party and client are in 181 scope: The reason being that dynamic access control is one of the 182 use cases to be supported, and this may involve granting access to a 183 client previously unknown to the server. 185 Borrowing from OAuth 2.0 [RFC6749] terminology we have a client (C), 186 a resource server (RS), an authorization server (AS - the third 187 party), and a resource owner (RO). The RO does not need to be active 188 in an M2M access control setting, so interactions with the RO are out 189 of scope for this memo. In the target setting the RS is typically 190 constrained, C may be constrained, whereas the AS is not assumed to 191 be constrained. We also assume that keys are established between RS 192 and AS (potentially via the RO) before the protocol begins. 194 Since the RS is constrained, we assume that it needs to offload 195 authorization policy management and authorization decision making to 196 the AS. (NOTE: The physical separation of policy decision and policy 197 enforcement is an established principle in policy based management, 198 e.g. [RFC2748].) This means that authorization information needs to 199 be transferred from AS to RS. This information may be specific 200 access control decisions such as "client C has the right to access 201 this URI with this RESTful method, this payload value, under these 202 local conditions", "client C has the right to access these URIs" or 203 more indirect information "client C is in this access group". In the 204 latter it is assumed that the RS knows what rights are associated to 205 a particular access group. 207 The AS may for example be implemented as a cloud service, in a home 208 server, or in a smart phone. The client and the RS may or may not 209 have connectivity to AS (e.g. because the AS is switched off), or may 210 only have intermittent connectivity, where a connection at the time 211 of access request cannot be guaranteed. Another reason for 212 intermittent connectivity may be that constant connectivity is not 213 affordable (e.g. due to limited battery power, or a sensor mobility 214 business case for which cellular connectivity cost too much or is not 215 available). Obviously, in order for a client request to reach the 216 RS there must be connectivity between C and RS, but that could be a 217 short range technology such as NFC, ZigBee, Bluetooth etc. 218 Furthermore, if there is no previous authorization information in the 219 RS about the client, and neither can access the AS, access requests 220 will be denied. Therefore we assume that either the client or the RS 221 can access the AS at some point in time, prior to the client's 222 request. 224 As a summary, there are potentially a number of information flows 225 that needs to be secured: 227 a. The transfer of authorization information from AS to RS 229 b. The transfer of keys or credentials from AS to RS and C, 230 respectively 232 c. The access request/response procedure between C and RS 234 3. Problem Description 236 From the background described in the previous section, we see the 237 following problems that need to be solved in order to achieve 238 explicit and dynamic authorization: 240 o Authorization 242 The RS must have access to authorization information and client 243 information. 245 Given that the relevant information has been provided to the RS, 246 it must be able to handle an access request (match request 247 against the authorization information, grant or deny the 248 request, and in the case of grant perform what is requested). We 249 call this process authorization decision enforcement. 251 o Authentication 253 Some property of the client needs to be authenticated to bind 254 authorization information to it. 256 The RS needs to establish the authenticity of authorization 257 information, and that is comes for a trusted AS. 259 Finally some property of the RS needs to be authenticated to the 260 client, so that the client can verify that it is communicating 261 with the intended RS. 263 o Communication Security 265 Communication security is needed to protect the integrity, and 266 sometimes the secrecy of information flows between the parties. 267 This includes the flow of authentication and authorization 268 information, but also the actual request and response upon which 269 access control is performed. 271 o Key establishment 272 The client and the RS need to establish keys in order to set up 273 secure communications 275 These problems are interconnected. For example when authorization 276 information flows from the AS to the RS, this can be solved either by 277 a pull or push directly from AS to RS or via the client by using some 278 protected data object. The authorization information must be 279 integrity protected by the keys established between AS and RS, and 280 the RS must be able to authenticate the AS as the source of this 281 information. 283 Most importantly, all the above needs to take into account potential 284 constrained devices. 286 3.1. Authorization 288 The core problem we are trying to solve is authorization: 290 o The AS needs to transfer authorization information to the RS. 291 This can be done through three different message sequences: 292 Agent, Pull or Push [RFC2904]. 294 - In the agent sequence, the client submits its request to the 295 AS and the AS contacts the RS to execute the request on the 296 client's behalf. 298 - When using the pull sequence, the client contacts the RS and 299 the RS pulls authorization information directly from the AS 300 as a reaction to the client's request (as e.g. in RADIUS 301 [RFC2865]). 303 - In the push sequence, the client is used as intermediary 304 between the AS and the RS, and authorization information is 305 transferred in the form of some token (as e.g. in OAuth 306 [RFC6749]). 308 Each of these approaches has it's drawbacks and advantages in 309 constrained environments, which needs to be weighed against each 310 other. 312 o What does the transferred authorization information contain and 313 how should it be formatted/encoded? Again this must be efficient 314 for constrained devices, considering size of authorization 315 information and parser complexity. 317 o How does the RS verify the authenticity of the authorization 318 information? This strongly depends on the solution chosen for 319 the first bullet. 321 o How does the RS enforce authorization decisions of the AS? Does 322 the authorization information it obtained from the AS require 323 additional policy evaluation (e.g. matching against local access 324 control lists, evaluating local conditions)? What kind of policy 325 evaluation can we assume a constrained device to be capable of? 327 3.2. Authentication 329 The following problems need to be addressed, when considering 330 authentication: 332 o The RS needs to authenticate some property of the client, in 333 order to bind it to the authorization information. This could 334 e.g. be a digital signature or a message authentication codes 335 performed by the client where a corresponding key is contained 336 in the authorization information. 338 o In many use cases the client wants to authenticate the RS, in 339 order to ensure that it is interacting with the right 340 resources. 342 o The AS needs to authenticate its communication partner (either 343 client or RS) in order to avoid leaking access control policy 344 information. 346 o Since the AS has a trust relation to both client and RS, it 347 could also provide them with the means of mutual authentication 348 (similar to a Kerberos [RFC4120] server). This would make it 349 possible for the RS to authenticate previously unknown clients. 351 3.3. Communication Security 353 For communication security there are different alternatives that 354 offer various trade-offs, e.g. between performance and security. 356 o One is session-based security at transport layer such as DTLS 357 [RFC6347], which offers security, including integrity and 358 confidentiality protection, for the whole application layer 359 exchange. One cost of DTLS is the handshake protocol, which may 360 be expensive for constrained devices especially in terms of 361 wireless network communication. 363 o An alternative is data object security at application layer, 364 e.g. using JWE [I-D.ietf-jose-json-web-encryption]. Secure 365 objects can be stored in network nodes to handle security for a 366 more flexible communication model such as publish/subscribe 367 (compare e.g. CoRE Mirror Server [I-D.vial-core-mirror-proxy]). 368 However, data object security only would not provide 369 confidentiality for the message headers. For example, 370 information such as the RESTful method, the host address, and 371 the resource URI could be revealed. 373 There are other differences in security properties between session 374 based security and data object security, a detailed comparison is 375 beyond the scope of this memo. 377 A solution to the overall authorization problem may be based on 378 session-based security only, data object security only or a hybrid. 379 An example of a hybrid is where authorization information and keys 380 are provided by the AS in the format of secure objects, but where the 381 resource access is protected by session-based security. (For secure 382 objects containing authorization information, compare e.g. OAuth 2.0 383 MAC Tokens [I-D.ietf-oauth-v2-http-mac].) 385 A hybrid solution may also be useful to support a flexible trust 386 model, e.g. a resource representation wrapped in JWE sent over DTLS 387 hop-by-hop in a case where an intermediary is allowed to read the 388 header but not the payload. 390 There are no assumptions or requirements on communication security in 391 this version of the draft as there are ongoing discussions on this 392 topic. 394 3.4. Key Management 396 With respect to key management, we see the following problems that 397 need to be addressed: 399 o Symmetric vs Asymmetric 401 Do we want to support asymmetric or symmetric key solutions, or 402 both? The question applies both to protection of resource 403 access and transport of authentication and authorization 404 information. 406 There are classes of devices that can easily perform symmetric 407 cryptography, but consume considerably more time/battery for 408 asymmetric operations. On the other hand asymmetric 409 cryptography has benefits e.g. in terms of deployment. 411 o Key establishment 413 How are the corresponding keys established? Considering section 414 3.1 there must be a binding between these keys and the 415 authorization information, at least in the sense that the AS 416 must be able to specify a unique client identifier which the RS 417 can verify (using an associated key). 419 One of the use cases of [I-D.seitz-ace-usecases] describes 420 spontaneous change of access policies - e.g. giving a hitherto 421 unknown client the right to temporarily unlock your house door. 422 In this case the client key is not previously known to the RS 423 and must be provisioned by the AS. 425 o Revocation and Expiration 427 How are the keys renewed and how is a key that has been 428 compromised revoked in a manner that reaches all relying 429 parties, also keeping in mind scenarios with intermittent 430 connectivity? 432 4. Assumptions and Requirements 434 In this section we list a set of candidate assumptions and 435 requirements to make the problem description in the previous sections 436 more concise and precise. 438 The purpose of making this list is not to stipulate "the unique 439 problem description", but to stimulate an aligned discussion on what 440 assumptions and requirements the solution to the authorization 441 problem should be based on. 443 4.1 Architecture 445 The architecture consists of at least the following nodes: 447 o RS hosting resources, and responding to access requests 449 o C requesting access to resources 451 o AS supporting the access request/response procedure by providing 452 authorization information to RS. The AS may also provide other 453 services such as authenticating C on behalf of the RS or 454 providing keys or credentials to C and/or RS to secure the 455 request/response procedure. 457 o The architecture may contain intermediary nodes between any pair 458 of C, RS and AS, such as e.g. translation/reverse proxies. 460 4.2 Constrained Devices 461 o C and RS are class 1 or less constrained devices 463 o AS is not a constrained device 465 o All devices can process symmetric cryptography without incurring 466 an excessive performance penalty 468 o The performance penalty for asymmetric cryptography is high for 469 a significant set of constrained devices 471 o The performance penalty for handling public key certificates and 472 especially public key certificate chains is high for a 473 significant set of constrained devices. 475 o The performance penalty for handling revocation lists is high 476 for a significant set of constrained devices. 478 o Wireless communication has high performance penalty for a 479 significant set of constrained devices 481 o The RS may not be able to reliably measure time 483 4.3 Authorization 485 o The authorization decision may be taken either by AS or RS 487 o The authorization decision are enforced by RS 489 o There may be mechanisms for a client to look-up the 490 corresponding AS for an RS 492 4.4 Authorization information 494 o The authorization information shall contain either client 495 capability lists, client attributes or authorization decisions 497 o The authorization information shall contain information to allow 498 the RS to verify that a requesting client is authorized 500 4.5 Access to authorization information 502 o The RS shall authenticate the authorization information coming 503 from the AS. The authorization information may be communicated 504 via the client. 506 o The authorization information shall be integrity protected and 507 may be encrypted end-to-end between the AS and the RS 509 o The RS may not be able to communicate with the AS at the time of 510 the request from a client 512 o The RS may store authorization information 514 o Authorization information stored in RS shall be possible to 515 change. The change of such information shall be authorized 517 4.6 Resource access 519 o Resources are accessed in a RESTful manner using GET, PUT, POST, 520 DELETE 522 o By default, the resource request shall be integrity protected 523 and may be encrypted end-to-end from the client to the RS. It 524 shall be possible for the RS to detect a replayed request. 526 o By default, the response to a request shall be integrity 527 protected and may be encrypted end-to-end from the RS to the 528 client. 530 o By default, the client shall be able to verify that the response 531 to a request comes from the intended RS 533 o There may be resources whose access need not be protected 535 4.7 Keys and cipher suites 537 o The protection of access request/response between client and RS 538 shall support the use of symmetric and/or asymmetric keys 540 o The protection of authorization information shall support the 541 use of symmetric and asymmetric keys 543 o There may be a mechanism for the client to look-up the supported 544 cipher suites of a RS 546 5. Security Considerations 548 The entire document is about security considerations. 550 6. IANA Considerations 552 This document has no actions for IANA. 554 7. Acknowledgements 556 The authors would like to thank Vlasios Tsiatsis and John Mattson for 557 contributing to the discussion and giving helpful comments. 559 8. References 561 8.1 Normative References 563 [I-D.ietf-core-coap] 564 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 565 "Constrained Application Protocol (CoAP)", draft-ietf- 566 core-coap-18 (work in progress), June 2013. 568 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 569 4949, August 2007. 571 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 572 Security Version 1.2", RFC 6347, January 2012. 574 8.2 Informative References 576 [I-D.seitz-ace-usecases] 577 Seitz, L., Gerdes, S., and Selander, G., "ACE use cases", 578 draft-seitz-ace-usecases (work in progress), February 579 2014. 581 [I-D.ietf-jose-json-web-encryption] 582 Jones, M., Hildebrand, J., "JSON Web Encryption (JWE)", 583 draft-ietf-jose-json-web-encryption (work in progress), 584 April 2014. 586 [I-D.vial-core-mirror-proxy] 587 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 588 proxy (expired), July 2012. 590 [I-D.ietf-oauth-v2-http-mac] 591 Richter, J., Mills, W., Tschofenig, H. (Ed.), Hunt, P., 592 "OAuth 2.0 Message Authentication Code (MAC) Tokens", 593 draft-ietf-oauth-v2-http-mac (work in progress), January 594 2014. 596 [RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, 597 R., and A. Sastry, "The COPS (Common Open Policy Service) 598 Protocol", RFC 2748, January 2000. 600 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 601 "Remote Authentication Dial In User Service (RADIUS)", 602 RFC 2865, June 2000. 604 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 605 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 606 D. Spence, "AAA Authorization Framework", RFC 2904, August 607 2000. 609 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 610 Kerberos Network Authentication Service (V5)", RFC 4120, 611 July 2005. 613 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 614 Security Version 1.2", RFC 6347, January 2012. 616 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 617 RFC 6749, October 2012. 619 [RFC7228] Bormann, C., Ersue, M., and Keranen, A., "Terminology for 620 Constrained-Node Networks", RFC 7228, May 2014. 622 Authors' Addresses 624 Ludwig Seitz 625 SICS Swedish ICT AB 626 Scheelevagen 17 627 22370 Lund 628 SWEDEN 629 EMail: ludwig@sics.se 631 Goeran Selander 632 Ericsson 633 Farogatan 6 634 16480 Kista 635 SWEDEN 636 EMail: goran.selander@ericsson.com