idnits 2.17.1 draft-somaraju-ace-multicast-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 377: '... The KDC MUST maintain a table consi...' RFC 2119 keyword, line 392: '... The KDC MUST generate new group key...' RFC 2119 keyword, line 428: '...tribution center MUST have a unique cl...' RFC 2119 keyword, line 467: '...eceiving devices MUST maintain a table...' RFC 2119 keyword, line 485: '... The receiver MUST silently discard ...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2016) is 3024 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) == Unused Reference: 'RFC7252' is defined on line 740, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ace-actors (ref. 'I-D.ietf-ace-actors') == Outdated reference: A later version (-24) exists of draft-ietf-cose-msg-09 ** Downref: Normative reference to an Informational draft: draft-wahlstroem-ace-cbor-web-token (ref. 'I-D.wahlstroem-ace-cbor-web-token') == Outdated reference: A later version (-08) exists of draft-ietf-oauth-pop-architecture-07 == Outdated reference: A later version (-06) exists of draft-selander-ace-object-security-03 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ace A. Somaraju 3 Internet-Draft Tridonic GmbH & Co KG 4 Intended status: Standards Track S. Kumar 5 Expires: July 18, 2016 Philips Research 6 H. Tschofenig 7 ARM Ltd. 8 W. Werner 9 Werner Management Services e.U. 10 January 15, 2016 12 Security for Low-Latency Group Communication 13 draft-somaraju-ace-multicast-01.txt 15 Abstract 17 Some Internet of Things application domains, such as lighting, have 18 strict requirements on latency for group communication. From a user 19 experience point of view latency less than 200 ms is necessary from 20 an action triggered by a user to the visible effects. This draft 21 describes procedures for authorization, key management, and securing 22 group messages within a low latency application domain with a special 23 emphasis on lighting systems. We specify the usage of object 24 security at the application layer for group communication and assume 25 that CoAP is used as the application layer protocol. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 18, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. AT-KDC Access Tokens . . . . . . . . . . . . . . . . . . 8 66 3.3. AT-R Access Tokens . . . . . . . . . . . . . . . . . . . 9 67 3.4. Multicast Message Content . . . . . . . . . . . . . . . . 10 68 3.5. Receiver Algorithm . . . . . . . . . . . . . . . . . . . 11 69 3.6. Sender Algorithm . . . . . . . . . . . . . . . . . . . . 12 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 4.1. Token Verification . . . . . . . . . . . . . . . . . . . 14 72 4.2. Token Revocation . . . . . . . . . . . . . . . . . . . . 14 73 4.3. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5. Operational Considerations . . . . . . . . . . . . . . . . . 15 75 5.1. Persistence of State Information . . . . . . . . . . . . 15 76 5.2. Provisioning in Small Networks . . . . . . . . . . . . . 15 77 5.3. Client IDs . . . . . . . . . . . . . . . . . . . . . . . 15 78 5.4. Application Groups vs. Security Groups . . . . . . . . . 15 79 5.5. Lost/Stolen Device . . . . . . . . . . . . . . . . . . . 16 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 8.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Appendix A. Access Levels . . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 There are low latency group communication use cases that require 91 securing communication between a sender, or a group of senders, and a 92 group of receivers. In the lighting use case, a set of lighting 93 nodes (e.g., luminaires, wall-switches, sensors) are grouped together 94 into a single "Application Group" and the following three 95 requirements need to be addressed: 97 1. Only authorized members of the application group must be able to 98 read and process messages. 100 2. Receivers of group messages must be able to verify the integrity 101 of received messages as being generated within the group. 103 3. Message communication and processing must happen with a low 104 latency and in synchronous manner. 106 This document discusses a group communication security solution that 107 satisfies these three requirements. This write-up focuses on the 108 lighting use case but the content is equally applicable to other low- 109 latency application domains, such as blinds control. 111 2. Terminology 113 This document uses the following terms from [I-D.ietf-ace-actors]: 114 Authorization Server, Resource Owner, Client, Resource Server. The 115 terms 'sender' and 'receiver' refer to the application layer 116 messaging used for lighting control; other communication interactions 117 with the supporting infrastructure uses unicast messaging. 119 When nodes are combined into groups there are different layers of 120 those groups with unique characteristics. For clarity we introduce 121 terminology for three different groups: 123 Application Group: 125 An application group consists of the set of all nodes that have 126 been configured to respond to a single application layer request. 127 For example, a wall mounted switch and a set of luminaires in a 128 single room might belong to a single group and the switch may be 129 used to turn on/off all the luminaires in the group simultaneously 130 with a single button press. In the remainder of this document we 131 will use GId to identify an application group. 133 Multicast Group: 135 A multicast group consists of the set of all nodes that subscribe 136 to the same multicast IP address. 138 Security Group: 140 A security group consists of the set of all nodes that have been 141 provisioned with the same keying material. All the nodes within a 142 security group share a security association or a sequence of 143 security associations wherein a single association specifies the 144 keying material, algorithm-specific information, lifetime and a 145 key ID. 147 Typically, the three groups might not coincide due to the memory 148 constraints on the devices and also security considerations. For 149 instance, in a small room with windows, we may have three application 150 groups: "room group", "luminaires close to the window group" and 151 "luminaires far from the window group". However, we may choose to 152 use only one multicast group for all devices in the room and one 153 security group for all the devices in the room. Note that every 154 application group belongs to a unique security group. However, the 155 converse is not always true. This implies that the application group 156 ID maybe used to determine the associated security group but not vice 157 versa. 159 The fact that security groups may not coincide with application 160 groups implies that 162 (1) an application must be able to specify which resources on a 163 resource server are accessible by a client that has access to the 164 group key, and 166 (2) a method is required to associate the group key to the 167 application group(s) for which the group key may be used. 169 In this document we provide fields that may be used to specify the 170 "scope of the key" and "application groups for which the key may be 171 used". A commissioner has a lot of flexibility to assign nodes to 172 multicast groups and to security groups while the application groups 173 will be determined by the semantics of the application itself. The 174 exact partitioning of the nodes into security and multicast groups is 175 therefore deployment specific. 177 3. Architecture 179 Each node in a lighting application group might be a sender, a 180 receiver or both sender and receiver (even though in Figure 1, we 181 show nodes that are only senders or only receivers for clarity). The 182 low latency requirement implies that most of the communication 183 between senders and receivers of application layer messages is done 184 using multicast IP. On some occasions, a sender in a group will be 185 required to send unicast messages to unique receivers within the same 186 group and these unicast messages also need communication security. 188 Two logical entities are introduced and they have the following 189 function: 191 Key Distribution Center (KDC): This logical entity is responsible 192 for generating symmetric keys and distributing them to the nodes 193 authorized to receive them. The KDC ensures that nodes belonging 194 to the same security group receive the same key and that the keys 195 are renewed based on certain events, such as key expiry or change 196 in group membership. 198 Authorization Server (AS): This logical entity stores authorization 199 information about devices, meta-data about them, and their roles 200 in the network. For example, a luminaire is associated with 201 different groups, and may have meta-data about its location in a 202 building. 204 Note that we assume that nodes are pre-configured with device 205 credentials (e.g., a certificate and the corresponding private key) 206 during manufacturing or during an initial provisioning phase. These 207 device credentials are used in the interaction with the authorization 208 server. 210 Figure 1 and Figure 2 provide an architectural overview. The dotted 211 lines illustrate the use of unicast DTLS messages for securing the 212 message exchange between all involved parties. The secured group 213 messages between senders and receivers are indicated using lines with 214 star/asterisk characters. The security of the group messages is 215 accomplished at the application level using OSCOAP - Object Security 216 of CoAP (see [I-D.selander-ace-object-security]). 218 Figure 1 illustrates the information flow between an authorization 219 server and the nodes participating in the lighting network, which 220 includes all nodes that exchange lighting application messages. This 221 step is typically executed during the commissioning phase for nodes 222 that are fixed-mounted in buildings. The authorization server, as a 223 logical function, may in smaller deployments be included in a device 224 carried by the commissioner and only be present during the 225 commissioning phase. Other use cases, such as employees using their 226 smartphones to control lights, may require an authorization server 227 that dynamically executes access control decisions. 229 Figure 1 shows the commissioning phase where the nodes obtain 230 configuration information, which includes the AT-KDC. The AT-KDC is 231 an access token and includes authorization claims for consumption by 232 the key distribution center. We use the access token terminology 233 from [RFC6749]. The AT-KDC in this architecture may be a bearer 234 token or a proof-of-possession (PoP) token. The bearer token concept 235 is described in [RFC6750] and the PoP token concept is explained in 236 [I-D.ietf-oauth-pop-architecture]. The AT-KDC is created by the 237 authorization server after authenticating the requesting node and 238 contains authorization-relevant information. The AT-KDC is protected 239 against modifications using a digital signature or a message 240 authentication code. It is verified in Figure 2 by the KDC. 242 Config +-------------+ Config 243 +-----------+Authorization+------------+ 244 | .........>| Server |<.......... | 245 | . DTLS +-------------+ DTLS . | 246 | . ^^ . | 247 | . |. . | 248 | . |. . | 249 v v |. v v 250 +-----+ Config|.DTLS +-----+ 251 +-----+| |. +-----+| 252 +-----+|+ |. +-----+|+ 253 | A |+ vv | C |+ 254 +-----+ +-----+ +-----+ 255 . E.g. +-----+| E.g. 256 Light +-----+|+ Luminaires 257 Switches | B |+ 258 +-----+ 259 E.g. 260 Presence 261 Sensors 262 Legend: 264 Config (Configuration Data): Includes configuration 265 parameters, authorization information encapsulated 266 inside the access token (AT-KDC) and other meta- 267 data. 269 Figure 1: Architecture: Commissioning Phase. 271 In the simplified message exchange shown in Figure 2 a sender 272 requests a security group key and the access token for use with the 273 receivers (called AT-R). The request contains information about the 274 resource it wants to access, such as the application group and other 275 resource-specific information, if applicable, and the previously 276 obtained AT-KDC access token. Once the sender has successfully 277 obtained the requested information it starts communicating with 278 receivers in that group using group messages. The symmetric key 279 obtained from the KDC is used to secure the groups messages. The 280 AT-R may be attached to the initial request. 282 Receivers need to perform two steps, namely to obtain the necessary 283 group key to verify the incoming messages and to determine what 284 resource the requestor is authorized to access. Both pieces of 285 information can be found in the AT-R access token. 287 Group messages need to be protected such that replay and modification 288 can be detected. The integrity of the message is accomplished using 289 a keyed message digest in combination with the group key. The use of 290 symmetric keys is envisioned in this specification due to latency 291 requirements. For unicast messaging between the group members and 292 the AS or KDC, we assume the use of DTLS for transport security. 293 However, the use of TLS, and application layer security is possible 294 but is outside the scope of this document. 296 Request Request 297 +AT-KDC +------------+ +AT-KDC 298 +------------>| Key |<----------+ 299 |+------------|Distribution|----------+| 300 ||Reply | Center | Reply || 301 ||+AT-R +------------+ +AT-R || 302 ||+Group ..^ ^.. +Group || 303 || Key .. .. Key || 304 || ...DTLS DTLS .. || 305 |v .. .. v| 306 +-----+<. .>+-----+ 307 +-----+| +-----+| 308 +-----+|+ Secure Multicast Msg +-----+|+ 309 | A |+*****************************> | B |+ 310 +-----+ +-----+ 311 Sender(s) Receiver(s) 312 e.g. Light Switch e.g. Luminaires 314 Figure 2: Architecture: Group Key Distribution Phase. 316 3.1. Assumptions 318 1. The AT-KDC is a manifestation of the authorization granted to a 319 specific client (or user running a client). The AT-KDC is 320 longer-lived and can be used to request multiple AT-Rs. 322 2. Each AT-R is valid for use with one or multiple application 323 groups. 325 3. The AS and the KDC logical roles may reside in different physical 326 entities. 328 4. The AT-KDC as well as the AT-R may be self-contained tokens or 329 references. References are more efficient from a bandwidth point 330 of view but require an additional lookup. 332 5. The AT-KDC token is opaque to the client. Data that is meant for 333 processing by the client has to be conveyed to the client 334 separately. The AT-R token on the other hand is meant for 335 consumption by the client. 337 6. The client requests AT-Rs for different application groups by 338 including additional information in the request to the KDC for 339 what application groups the AT-R(s) have to be requested. The 340 KDC may return multiple AT-Rs in a single response (for 341 performance reasons). 343 7. The AT-KDC and the AT-R are encoded as CBOR Web Tokens 344 [I-D.wahlstroem-ace-cbor-web-token] and protected using COSE 345 [I-D.ietf-cose-msg]. 347 3.2. AT-KDC Access Tokens 349 The AT-KDC contains 351 1. Issuer: Entity creating the access token. This information needs 352 to be cryptographically bound to the digital signature/keyed 353 message digest protecting the content of the token, as provided 354 by the CBOR Web Token (CWT). 356 2. Expiry date: Information can be omitted if tokens do not expire 357 (for example, in a small enterprise environment). 359 3. Scope: Permissions of the entity holding the token. This 360 includes information about the resources that may be accessed 361 with the token (e.g., access level) and application layer group 362 IDs for the groups for which the tokens may be used. 364 4. Recipient/Audience: Indication to whom the AT-KDC was issued to. 365 In this case, it is the KDC. 367 5. Client ID: Information about the client that was authenticated by 368 the authorization server. 370 6. Issued at: Indicates date and time when the AT-KDC was created by 371 the authorization server. 373 3.3. AT-R Access Tokens 375 Clients send the AT-KDC to the KDC in order to receive an AT-R. 377 The KDC MUST maintain a table consisting of scope values, which 378 includes the application group id. These entries point to a sequence 379 of security associations. A security association specifies the key 380 material, algorithm-specific information, lifetime and a key ID and 381 the key ID may be used to identify this security association. 383 The AS/KDC must guarantee the uniqueness of the client ids for its 384 nodes. This may be accomplished by the AS/KDC assigning values to 385 the nodes or by using information that is already unique per device 386 (such as an EUI-64). 388 The KDC furthermore needs to be configured with information about the 389 authorization servers it trusts. This may include a provisioned 390 trust anchor store, or shared credentials (similar to a white list). 392 The KDC MUST generate new group keys after the validity period of the 393 current group key expires. 395 The AT-R contains 397 1. Issuer: Entity creating the access token. This information needs 398 to be cryptographically bound to the digital signature/keyed 399 message digest protecting the content of the token, as provided 400 by the CBOR Web Token (CWT). 402 2. Expiry date: Information can be omitted if tokens do not expire 403 (for example, in a small enterprise environment). 405 3. Scope: Permissions of the entity holding the token. This 406 includes information about the resources that may be accessed 407 with the token (e.g., access level) and application layer group 408 IDs for the groups for which the tokens may be used. 410 4. Security Group Key: Key to use for the group communication. 412 5. Algorithm: Used for secure group communication. 414 6. KID: Sequentially increasing ID of the key for the security group 415 (the devices may store an older key to help with key rolling.) 417 7. Issued at: Indicates date and time when the AT-R was created by 418 the KDC. 420 3.4. Multicast Message Content 422 The following information is needed for the cryptographic algorithm, 423 which is assumed to be in the COSE header: 425 1. Nonce value consisting of 427 * Client ID (unencrypted, integrity protected): Every sender 428 managed by a key distribution center MUST have a unique client 429 ID. 431 * Sequence Number (unencrypted, integrity protected): Used for 432 replay protection. 434 * An implicit IV that is either derived from the keys at the 435 end-points or fixed to a certain value by standard (not sent 436 in the message) 438 2. MAC (not integrity protected): For integrity protection. 440 The following information is additionally required to process the 441 secure message: 443 1. Destination IP address and port (not encrypted, integrity 444 protected): Integrity protection of the IP address and port 445 ensures that the message content cannot be replayed with a 446 different destination address or on a different port. 448 2. CoAP Path (encrypted, integrity protected): Uniquely identifies 449 the target resource of a CoAP request. 451 3. Application Group id in CoAP header (unencrypted, integrity 452 protected): Is used to identify a sequence of security 453 associations to use to decrypt the message. The CoAP header 454 option is TBD. 456 4. Key ID (unencrypted, integrity protected): Is used to select the 457 current security association from the sequence of security 458 associations identified by the application group id. 460 5. CoAP Header Options other than application group id (encrypted - 461 if desired, integrity protected) 463 6. CoAP Payload (encrypted, integrity protected). 465 3.5. Receiver Algorithm 467 All receiving devices MUST maintain a table consisting of mappings of 468 application group id, to a sequence of security associations. 470 When a node receives an incoming multicast message it looks up the 471 application group id and the key id (which are both found in the CoAP 472 header) to determine the correct security association. 474 The key id is used for situations where the group key is updated by 475 the KDC (for example in situations where a device in a group is lost 476 or stolen). 478 To check for replay attacks the receiver has to consult the state 479 stored with the security association to obtain the current sequence 480 number and to compare it against the sequence number found in the 481 request payload for that sender based on the Sender ID. The receiver 482 needs to store the latest correctly verified nonce values to detect 483 replay attacks 485 The receiver MUST silently discard an incoming message in the 486 following cases: 488 o Application Group ID lookup does not return any security 489 association. 491 o Key ID lookup among the previously retrieved sequence of security 492 associations does not identify a unique security association. 494 o Integrity check fails. 496 o Decryption fails. 498 o Replay protection check failed. The (client ID || sequence 499 number), which are both part of the nonce, have already been 500 received in an earlier message. 502 Once the cryptographic processing of the message is completed, the 503 receiver must check whether the sender is authorized to access the 504 protected resource, indicated by the CoAP request URI at the right 505 level. For this purpose the receiver consults the locally stored 506 authorization database that was populated with the information 507 obtained via the AT-R token and the static authorization levels 508 described in Appendix A. 510 Once all verification steps have been successful the receiver 511 executes the CoAP request and returns an appropriate response. Since 512 the response message will also be secured the message protection 513 processing described in Section 3.6 must be executed. Additionally, 514 the nonce value corresponding to the security association MUST be 515 updated to the nonce value in the message. 517 3.6. Sender Algorithm 519 Figure 3 describes the algorithm for obtaining the necessary 520 credentials to transmit a secure group message. When the sender 521 wants to send a message to the application group, it checks if it has 522 the respective group key. If no group key is available then it 523 determines whether it has an access token for use with the KDC (i.e., 524 AT-KDC). If no AT-KDC is found in the cache then it contacts the 525 authorization server to obtain that AT-KDC. Note that this assumes 526 that the authorization server is online, which is only true in 527 scenarios where granting authorization dynamically is supported. In 528 the other case where the AT-KDC is already available the sender 529 contacts the KDC to obtain a group key. If a group key is already 530 available then the sender can transmit a secured message to the group 531 immediately. 533 _______ 534 / \ 535 | Start | 536 \_______/ 537 | 538 v 539 /\ 540 / \ 541 / \ 542 / \ 543 / \ 544 ___No____/Group Key \____ 545 | \Available?/ | 546 | \ / | 547 v \ / Yes 548 /\ \ / | 549 / \ \ / v 550 / \ \/ +-------------+ 551 / \ ^ |Transmit | 552 / \ | |multicast | 553 ____/ AT+KDC \__ | |mesg to group| 554 | \Available?/ | | +-------------+ 555 | \ / | | 556 No \ / Yes | 557 | \ / | | 558 | \ / | | 559 v \/ v | 560 +-----+-----+ ^ +----------+ | 561 |Request | | |Request | | 562 |AT-KDC | | |Group Key | | 563 |from |---+ |from KDC |--+ 564 |Auth Server| | | 565 +-----------+ +----------+ 567 Figure 3: Steps to Transmit Multicast Message (w/o Failure Cases). 569 Note that the sender does not have to wait until it has to transmit a 570 message in order to request a group key; the sender is likely to be 571 pre-configured with information about which application group it 572 belongs to and can therefore pre-fetch the required information. 574 Group keys have a lifetime, which is configuration-dependent, but 575 mechanisms need to be provided to update the group keys either via 576 the sender asking for a group key renewal or via the KDC pushing new 577 keys to senders and receivers. The lifetime can be based on time or 578 on the number of transmitted messages. 580 4. Security Considerations 582 4.1. Token Verification 584 Due to the low latency requirements, token verification needs to be 585 done locally and cannot be outsourced to other parties. For this 586 reason a self-contained token must be used and the receivers are 587 required to follow the steps outlined in Section 7.2 of RFC 7519 588 [RFC7519]. This includes the verification of the message 589 authentication code protecting the contents of the token and the 590 encryption envelope protecting the contained symmetric group key. 592 4.2. Token Revocation 594 Tokens have a specific lifetime. Setting the lifetime is a policy 595 decision that involves making a trade-off decision. Allowing a 596 longer lifetime increases the need to introduce a mechanism for token 597 revocation (e.g., a real-time signal from the KDC/Authorization 598 Server to the receivers to blacklist tokens) but lowers the 599 communication overhead during normal operation since new tokens need 600 to be obtained only from time to time. Real-time communication with 601 the receivers to revoke tokens may not be possible in all cases 602 either, particularly when off-line operation is demanded or in small 603 networks where the AS or even the KDC is only present during 604 commissioning time. 606 We therefore recommend to issue short-lived tokens for dynamic 607 scenarios like users accessing the lighting infrastructure of 608 buildings using smartphones, tablets and alike to avoid potential 609 security problems when tokens are leaked or where authorization 610 rights are revoked. For senders that are statically mounted (like 611 traditional light switches) we recommend a longer lifetime since re- 612 configurations and token leakage is less likely to happen frequently. 614 To limit the authorization rights, tokens should contain an audience 615 restriction, scoping their use to the intended receivers and to their 616 access level. 618 4.3. Time 620 Senders and receivers are not assumed to be equipped with real-time 621 clocks but these devices are still assumed to interact with a time 622 server. The lack of accurate clocks is likely to lead to clock 623 drifts and limited ability to check for replays. For those cases 624 where no time server is available, such as in small network 625 installations, token verification cannot check for expired tokens and 626 hence it might be necessary to fall-back to tokens that do not 627 expire. 629 5. Operational Considerations 631 5.1. Persistence of State Information 633 Devices in the lighting system can often be powered down 634 intentionally or unintentionally. Therefore the devices may need to 635 store the authorization tokens and cryptographic keys (along with 636 replay context) in persistent storage like flash. This is especially 637 required if the authorization server is no more online because it was 638 removed after the commissioning phase. However the decision on the 639 data to be persistently stored is a trade-off between how soon the 640 devices can be back online to normal operational mode and the memory 641 wear caused due to limited program-erase cycles of flash over the 642 15-20 years life-time of the device. 644 The different data that may need to be stored are access tokens AT- 645 KDC, AT-R and last seen replay counter. 647 5.2. Provisioning in Small Networks 649 In small networks the authorization server and the KDC may be 650 available only temporarily during the commissioning process and are 651 not available afterwards. 653 5.3. Client IDs 655 A single device should not be managed by multiple KDCs. However, a 656 group of devices in a domain (such as a lighting installation within 657 an enterprise) should either be managed by a single KDC or, if there 658 are multiple KDCs serving the devices in a given domain, these KDCs 659 MUST exchange information so that the assigned client id and 660 application group id values are unique within the devices in that 661 domain. We assume that only devices within a given domain 662 communicate with each other using group messages. 664 5.4. Application Groups vs. Security Groups 666 Multiple application groups may use the same key for performance 667 reasons, reducing the number of keys needed to be stored - leading to 668 less RAM needed by each node. This is only a reasonable option if 669 the attack surface is not increased. For example, a room A is 670 configured to use three application groups to address a subset of the 671 device. In addition to configuring all nodes in room A with these 672 three application groups the nodes are configured with a special 673 group that allows them to access all devices in room A, referred as 674 the all-nodes-in-room-A group. In this case, having the nodes to use 675 the same key for the all-nodes-in-room group and the three groups 676 does not increase the attack surface since any node can already use 677 the all-nodes-in-room-A group to control other devices in that room. 678 The three application groups in room A are a subset of the larger 679 all-nodes-in-room-A group. 681 5.5. Lost/Stolen Device 683 The following procedure MUST be implemented if a device is stolen or 684 keys are lost. 686 1. The AS tells the KDC to invalidate the AT-KDC. 688 2. The KDC no longer returns a new group key if the invalidated AT- 689 KDC is presented to it. 691 3. The KDC generates new keys for all security groups to which the 692 compromised device belongs. 694 The KDC SHOULD inform all devices in the security group to update 695 their group key. This requires the KDC to maintain a list of all 696 devices that belong to the security group and to be able to contact 697 them reliably. 699 6. Acknowledgements 701 The author would like to thank Esko Dijk for his help with this 702 document. 704 Parts of this document are a byproduct of the OpenAIS project, 705 partially funded by the Horizon 2020 programme of the European 706 Commission. It is provided "as is" and without any express or 707 implied warranties, including, without limitation, the implied 708 warranties of fitness for a particular purpose. The views and 709 conclusions contained herein are those of the authors and should not 710 be interpreted as necessarily representing the official policies or 711 endorsements, either expressed or implied, of the OpenAIS project or 712 the European Commission. 714 7. IANA Considerations 716 This document defines one CoAP Header Option Application Group ID 717 that MUST be allocated in the Registry "CoAP Option Numbers" of 718 [RFC6749]. IANA is requested to allocation TBD option number to 719 application group ID in this specification. 721 8. References 723 8.1. Normative References 725 [I-D.ietf-ace-actors] 726 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 727 architecture for authorization in constrained 728 environments", draft-ietf-ace-actors-02 (work in 729 progress), October 2015. 731 [I-D.ietf-cose-msg] 732 Schaad, J., "CBOR Encoded Message Syntax", draft-ietf- 733 cose-msg-09 (work in progress), December 2015. 735 [I-D.wahlstroem-ace-cbor-web-token] 736 Wahlstroem, E., Jones, M., and H. Tschofenig, "CBOR Web 737 Token (CWT)", draft-wahlstroem-ace-cbor-web-token-00 (work 738 in progress), December 2015. 740 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 741 Application Protocol (CoAP)", RFC 7252, 742 DOI 10.17487/RFC7252, June 2014, 743 . 745 8.2. Informative References 747 [I-D.ietf-oauth-pop-architecture] 748 Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 749 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 750 Architecture", draft-ietf-oauth-pop-architecture-07 (work 751 in progress), December 2015. 753 [I-D.selander-ace-object-security] 754 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 755 "Object Security of CoAP (OSCOAP)", draft-selander-ace- 756 object-security-03 (work in progress), October 2015. 758 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 759 RFC 6749, DOI 10.17487/RFC6749, October 2012, 760 . 762 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 763 Framework: Bearer Token Usage", RFC 6750, 764 DOI 10.17487/RFC6750, October 2012, 765 . 767 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 768 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 769 . 771 Appendix A. Access Levels 773 A characteristic of the lighting domain is that access control 774 decisions are also impacted by the type of operation being performed 775 and those categories are listed below. The following access levels 776 are pre-defined. 778 Level 0: Service detection only 780 This is a service that is used with broadcast service detection 781 methods. No operational data is accessible at this level. 783 Level 1: Reporting only 785 This level allows access to sensor and other (relatively 786 uncritical) operational data and the device error status. The 787 operation of the system cannot be influenced using this level. 789 Level 2: Standard use 791 This level allows access to all operational features, including 792 access to operational parameters. This is the highest level of 793 access that can be obtained using (secure) multicast. 795 Level 3: Commissioning use / Parametrization Services 797 This level gives access to certain parameters that change the day- 798 to-day operation of the system, but does not allow structural 799 changes. 801 Level 4: Commissioning use / Localization and Addressing Services 803 (including Factory Reset) This level allows access to all services 804 and parameters including structural settings. 806 Level 5: Software Update and related Services 808 This level allows the change and upgrade of the software of the 809 devices. 811 Note: The use of group security is disallowed for level higher than 812 Level 2 and unicast communication is used instead. 814 Authors' Addresses 816 Abhinav Somaraju 817 Tridonic GmbH & Co KG 818 Farbergasse 15 819 Dornbirn 6850 820 Austria 822 Email: abhinav.somaraju@tridonic.com 824 Sandeep S. Kumar 825 Philips Research 826 High Tech Campus 34 827 Eindhoven 5656 AE 828 Netherland 830 Email: ietf.author@sandeep-kumar.org 832 Hannes Tschofenig 833 ARM Ltd. 834 Hall in Tirol 6060 835 Austria 837 Email: Hannes.tschofenig@gmx.net 838 URI: http://www.tschofenig.priv.at 840 Walter Werner 841 Werner Management Services e.U. 842 Josef-Anton-Herrburgerstr. 10 843 Dornbirn 6850 844 Austria 846 Email: werner@werner-ms.at