idnits 2.17.1 draft-somaraju-ace-multicast-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3217 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) -- Looks like a reference, but probably isn't: '1' on line 636 ** Downref: Normative reference to an Informational draft: draft-gerdes-ace-actors (ref. 'I-D.gerdes-ace-actors') -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSO' -- Possible downref: Non-RFC (?) normative reference: ref. 'LWM2M' == Outdated reference: A later version (-08) exists of draft-ietf-oauth-pop-architecture-01 == Outdated reference: A later version (-06) exists of draft-selander-ace-object-security-02 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). 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: January 7, 2016 Philips Research 6 H. Tschofenig 7 ARM Ltd. 8 July 6, 2015 10 Multicast Security for the Lighting Domain 11 draft-somaraju-ace-multicast-00.txt 13 Abstract 15 Lighting systems have strict requirements on message latency and 16 synchronization (typically latency less than 200 ms and jitter less 17 than 50 ms). There are several lighting use cases that require 18 securing such communication between a (group of) senders and a group 19 of receivers. This draft describes initial ideas for authorization 20 and key management required for the secure group communication within 21 a lighting system. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 7, 2016. 40 Copyright Notice 42 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Authorization Policy . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Access Levels . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Application, multicast and security groups . . . . . . . 4 62 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Access Tokens . . . . . . . . . . . . . . . . . . . . . . . . 11 64 6. Lighting Application Example . . . . . . . . . . . . . . . . 14 65 6.1. Unicast Messages using the LWM2M Object Model . . . . . . 14 66 6.2. Multicast Communication using the LWM2M Object Model . . 16 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 68 7.1. Token Verification . . . . . . . . . . . . . . . . . . . 19 69 7.2. Token Revocation . . . . . . . . . . . . . . . . . . . . 19 70 7.3. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 8. Operational Considerations . . . . . . . . . . . . . . . . . 20 72 8.1. Persistence of State Information . . . . . . . . . . . . 20 73 8.2. Provisioning in Small Networks . . . . . . . . . . . . . 20 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 77 10.2. Informative References . . . . . . . . . . . . . . . . . 21 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 There are several lighting related use cases that require securing 83 communication between a (group of) senders and a group of receivers. 84 Often, a set of lighting nodes (e.g. luminaires, wall-switches, 85 sensors) are grouped together into a single "Application Group". 87 For such use-cases, three requirements need to be addressed: 89 1. Only authorized members of the application group must be able 90 read and process messages. 92 2. Receivers of group messages must be able to verify the integrity 93 of received messages as being generated within the group. 95 3. Usually, message transfer and processing must happen with low 96 latency and in synchronous manner (typically latency less than 97 200 ms and jitter less than 50 ms). 99 This document discusses these three issues and describes initial 100 ideas on how they can be addressed. 102 2. Terminology 104 This document uses the following terms from [I-D.gerdes-ace-actors]: 105 Authorization Server, Resource Owner, Client, Resource Server. The 106 terms 'sender' and 'receiver' refer to the application layer 107 messaging used for lighting control; other communication interactions 108 with the supporting infrastructure uses unicast messaging. 110 This document also assumes that the reader is familiar with the OMA 111 Lightweight Machine-to-Machine (LWM2M) specifications [LWM2M] and the 112 IPSO specification [IPSO]. 114 3. Authorization Policy 116 When implementing an authorization policy two factors need to be 117 considered: 119 1. The type of resource/service that is being offered by an end 120 node, and 122 2. The group of nodes that are allowed to access a given type of 123 resource. 125 The type of resources in the lighting domain can be categorized into 126 multiple (access) levels and these levels are described below. For 127 resources/services that belong to a category less than access level 128 2, there are multiple clients that need to access the same resource/ 129 service with low latency. The scope of this document is to determine 130 how one can implement authorization policies for group communication 131 for resources/services that belong to access level 2 and below. We 132 first introduce the different access levels and then examine the 133 different types of groups that determine the authorization policy. 135 3.1. Access Levels 137 A characteristic of the lighting domain is that access control 138 decisions are also impacted by the type of operation being performed 139 and those categories are listed below. The following access levels 140 are pre-defined. 142 Level 0: Service detection only 143 This is a service that is used with broadcast service detection 144 methods. No operational data is accessible at this level. 146 Level 1: Reporting only 148 This level allows access to sensor and other (relatively 149 uncritical) operational data and the device error status. The 150 operation of the system cannot be influenced using this level. 152 Level 2: Standard use 154 This level allows access to all operational features, including 155 access to operational parameters. This is the highest level of 156 access that can be obtained using (secure) multicast. 158 Level 3: Commissioning use / Parametrization Services 160 This level gives access to certain parameters that change the day- 161 to-day operation of the system, but does not allow structural 162 changes. 164 Level 4: Commissioning use / Localization and Addressing Services 166 (including Factory Reset) This level allows access to all services 167 and parameters including structural settings. 169 Level 5: Software Update and related Services 171 This level allows the change and upgrade of the software of the 172 devices. 174 Note: The use of group security is disallowed for level higher than 175 Level 2 and unicast communication is used instead. 177 3.2. Application, multicast and security groups 179 There are three types of groups that we need to consider: 181 Application Group: 183 A lighting application group that consists of the set of all 184 lighting devices that have been configured by a commissioner to 185 respond to events in a consistent manner. For instance, a wall 186 mounted switch and a set of luminaires in a single room might 187 belong to a single group and the switch may be used to turn on/off 188 all the luminaires in the group simultaneously with a single 189 button press. In the remainder of this document we will use GId 190 to identify an application group. 192 Multicast Group: 194 A multicast group consists of the set of all nodes that subscribe 195 to the same multicast IP address. 197 Security Group: 199 A security group consists of a set of sending and receiving nodes 200 such that any sending node is able to securely send a message to 201 all the receiving nodes. For instance, if symmetric keys are used 202 to secure such messages then every node that has access to the 203 symmetric key is a part of the security group. Every node in a 204 security group can decrypt a message even if it is not addressed 205 for its application group. 207 Typically, the three groups might not coincide due to the memory 208 constraints on the devices and also security considerations. For 209 instance, in a small room with windows, we may have three application 210 groups: "room group", "luminaires close to the window group" and 211 "luminaires far from the window group". However, we may choose to 212 use only one multicast group for all devices in the room and one 213 security group for all the devices in the room. At the other end of 214 the spectrum, we may have an application group consisting of all the 215 luminaires on a floor consisting of several smaller rooms. In this 216 case, due to security considerations we may choose to not distribute 217 a single key to all the devices on the whole floor. Therefore, the 218 security group might be much smaller (e.g., one per room) and the 219 application floor group is split up into smaller security groups. 221 The authorization policy must ensure that all the members of a 222 security group are allowed to exchange messages with each other for 223 services which belong to access level less than equal to 2. The 224 services may be accessed via multicast or serial unicast messages 225 between group members. The procedure that is used to determine the 226 security groups based on the availability of multicast groups and the 227 requirements of the application group are out of scope of this 228 document. 230 4. Architecture 232 Each node in a lighting application group might be a sender, a 233 receiver or both sender and receiver within the group (even though in 234 Figure 1 below, we show nodes that are only senders or receivers for 235 clarity). The requirement of low latency synchronous behaviour 236 implies most of the communication between senders and receivers of 237 lighting application messages are done using multicast IP messages. 238 On some occasions, a sender in a group will be required to send 239 unicast messages to unique receivers within the same group and the 240 authorization procedure must also ensure security for such 241 communications. The procedure that is used to determine the security 242 groups based on the availability of multicast groups and the 243 requirements of the application group are out of scope of this 244 document. 246 Two logical entities are introduced and they have the following 247 function: 249 Key Distribution Center (KDC): This logical entity is responsible 250 for generating symmetric keys and distributing them to the nodes 251 authorized to receive them. The KDC ensures that nodes belonging 252 to the same security group receive the same key and that the keys 253 are rotated based on certain events, such as key expiry or change 254 in group membership. 256 Authorization Server (AS): This logical entity stores authorization 257 information about devices, meta-data about them, and their roles 258 in the network. For example, a luminare is associated with 259 different groups, and may have meta-data about its location. This 260 entity may also need to perform user authentication and 261 authorization since access rights may be associated to specific 262 persons. Directly or indirectly the resource owner specifies 263 authorization policies that define which node is allowed to 264 perform which actions. 266 Note that we assume that nodes are pre-configured with device 267 credentials (e.g., a certificate and the corresponding private key) 268 during manufacturing. These device credentials are used in the 269 interaction with the authorization server. 271 Figure 1 and Figure 2 provide an architectural overview. The dotted 272 lines illustrate the use of unicast DTLS messages for securing the 273 message exchange between all involved parties. The secured multicast 274 messages between senders and receivers are indicated using lines with 275 star/asterisk characters. The security of the multicast messages can 276 be achieved either at the transport level (e.g. 277 [I-D.kumar-dice-multicast-security]) or at the application level with 278 object security (e.g. [I-D.selander-ace-object-security]). The 279 details on multicast security are outside the scope of this draft. 281 Figure 1 illustrates the information flow between an authorization 282 server and the nodes participating in the lighting network, which 283 includes all nodes that exchange lighting application messages. This 284 step is typically executed during the commissioning phase for nodes 285 that are fixed-mounted in buildings. The authorization server, as a 286 logical function, may in smaller deployments be included in a device 287 carried by the commissioner and only be present during the 288 commissioning phase. In other use cases, employees using their 289 smartphones to control lights may require an authorization server 290 that dynamically executes access control decisions. 292 Figure 1 shows the commissioning phase where the nodes obtain 293 configuration information, which includes the AT-KDC. The AT-KDC is 294 an access token and includes authorization claims for consumption by 295 the key distribution center. We use the access token terminology 296 from RFC 6749 [RFC6749] even though it is a solution-specific concept 297 but familiar to many developers. The AT-KDC in this architecture may 298 be a bearer token or a proof-of-possession (PoP) token. Note that a 299 PoP token offers a fair amount of flexibility: with the use of 300 symmetric key cryptography it is comparable to a Kerberos ticket and 301 when used with asymmetric cryptography it can play the role of a 302 certificate. The bearer token concept is described in RFC 6750 303 [RFC6750] and the PoP token concept is explained in 304 [I-D.ietf-oauth-pop-architecture]. The AT-KDC is created by the 305 authorization server after authenticating the requesting node and 306 contains authorization relevant information. The AT-KDC is protected 307 against modifications using a digital signature or a message 308 authentication code. It is verified in Figure 2 by the KDC. 310 Config +-------------+ Config 311 +-----------+Authorization+------------+ 312 | .........>| Server |<.......... | 313 | . DTLS +-------------+ DTLS . | 314 | . ^^ . | 315 | . |. . | 316 | . |. . | 317 v v |. v v 318 +-----+ Config|.DTLS +-----+ 319 +-----+| |. +-----+| 320 +-----+|+ |. +-----+|+ 321 | A |+ vv | C |+ 322 +-----+ +-----+ +-----+ 323 . E.g. +-----+| E.g. 324 Light +-----+|+ Luminaires 325 Switches | B |+ 326 +-----+ 327 E.g. 328 Presence 329 Sensors 330 Legend: 332 Config (Configuration Data): Includes configuration 333 parameters, authorization information encapsulated 334 inside the access token (AT-KDC) and other meta- 335 data. 337 Figure 1: Architecture: Commissioning Phase. 339 In the simplified message exchange shown in Figure 2 a sender 340 requests a security group key and the access token for use with the 341 receivers (called AT-R). The request contains information about 342 resource it wants to access, such as the application group and other 343 resource-specific information -- if applicable, and the previously 344 obtained AT-KDC access token. Once the sender has successfully 345 obtained the requested information it starts communicating with 346 receivers in that group using multicast messages. The symmetric key 347 obtained from the KDC is used to secure the multicast messages for 348 the security group. The AT-R is used to attached to the initial 349 request to authorize the request. The receivers on their side need 350 to perform two steps, namely the receivers themselves need to obtain 351 the necessary group key to verify the incoming messages and they also 352 need information about what resource the sender is authorized to 353 access. Both information can be found in the AT-R access token. 355 Multicast messages need to be protected such that replay and 356 modification can be detected. The integrity of the message is 357 protected using a group key. The use of symmetric keys is envisioned 358 here due to latency requirements and the access level level concept 359 is described in Section 3.1. For secure unicast messaging between 360 lighting application group members and the AS or KDC, a topic outside 361 the scope of this document, the sender is assumed to use the DTLS 362 handshake to establish the necessary security context for securing 363 subsequent message interactions. 365 Request 366 +AT-KDC +------------+ 367 +------------>| Key | 368 |+------------|Distribution| 369 ||Reply | Center | 370 ||+AT-R +------------+ 371 ||+Group ..^ 372 || Key .. 373 || ...DTLS 374 |v .. 375 +-----+<. +-----+ 376 +-----+| +-----+| 377 +-----+|+ Secure Multicast Msg +-----+|+ 378 | A |+*****************************> | B |+ 379 +-----+ +-----+ 380 Sender(s) Receiver(s) 381 e.g. Light Switch e.g. Luminaries 383 Figure 2: Architecture: Group Key Distribution Phase. 385 Figure 3 describes the algorithm for obtaining the necessary 386 credentials to transmit a secure multicast message based on the 387 architectural description shown in Figure 1 and Figure 2. When 388 sender wants to send a message to the application group, it checks if 389 it has the group key. If no group key is available then it checks if 390 it has an access token for use with the KDC (AT-KDC). If no AT-KDC 391 is found in the cache then it contacts the authorization server to 392 obtain an access token. Note that this assumes that the 393 authorization server is online, which is only true in scenarios where 394 granting authorization dynamically is supported. In the other case 395 where the AT-KDC is already available the sender contacts the KDC to 396 obtain a group key. If a group key is already available then the 397 sender can transmit a message secured to the group immediately. 399 _______ 400 / \ 401 | Start | 402 \_______/ 403 | 404 v 405 /\ 406 / \ 407 / \ 408 / \ 409 / \ 410 ___No____/Group Key \____ 411 | \Available?/ | 412 | \ / | 413 v \ / Yes 414 /\ \ / | 415 / \ \ / v 416 / \ \/ +-------------+ 417 / \ ^ |Transmit | 418 / \ | |multicast | 419 ____/ AT+KDC \__ | |mesg to group| 420 | \Available?/ | | +-------------+ 421 | \ / | | 422 No \ / Yes | 423 | \ / | | 424 | \ / | | 425 v \/ v | 426 +-----+-----+ ^ +----------+ | 427 |Request | | |Request | | 428 |AT-KDC | | |Group Key | | 429 |from |---+ |from KDC |--+ 430 |Auth Server| | | 431 +-----------+ +----------+ 433 Figure 3: Steps to Transmit Multicast Message (w/o Failure Cases). 435 Note that the sender does not have to wait until it has to transmit a 436 message in order to request a group key; the sender is likely to be 437 pre-configured with information about which lighting application 438 group it belongs to and can therefore pre-fetch the required 439 information. 441 Group keys have a lifetime, which is configuration dependent, but 442 mechanisms need to be provided to update the group keys either via 443 the sender asking for a group key renewal or via the KDC pushing new 444 keys to senders and receivers. The lifetime can be based on time or 445 on the number of transmitted messages. 447 5. Access Tokens 449 Section 4 describes the architecture and makes use of access tokens, 450 which is a generic concept to pass capabilities between entities in a 451 distributed system. To improve interoperability a token format needs 452 to be standardized and this section outlines the use of an existing 453 format based on the JSON Web Token (JWT). These access tokens come 454 in two flavors, namely as bearer tokens but also as proof-of- 455 possession tokens. The main difference between the two is that 456 bearer tokens are not associated with a key while proof-of-possession 457 (PoP) tokens are. For a more detailed description of the security 458 benefits of PoP tokens and the differences to bearer tokens please 459 consult [I-D.ietf-oauth-pop-architecture]. In Section 1 we assume 460 that the AT-KDC is a bearer token and the AT-R is a PoP token. 462 In this section we provide more details of the access token concept. 463 The capabilities, called claims in the JWT jargon, are included 464 inside the token and, in this example, state that the granted access 465 level is 2 and access to the application group 2 is allowed by the 466 sender. Most of the description focuses on the use of PoP tokens 467 since they are more complex than bearer tokens. For the use with 468 multicast security we envision the PoP token to contain a symmetric 469 key encapsulated inside the JSON Web Key (JWK). 471 While JSON is a compact encoding format, standardization work is 472 ongoing to define an even more efficient format for conveying the 473 same information using a binary format (using CBOR as defined in RFC 474 7049 [RFC7049]). The corresponding security protection is currently 475 being defined in the IETF COSE working group [COSE]. 477 The content of a JSON Web Token (JWT) is protected using a JSON Web 478 Signature (JWS). The JWS applies a message authentication code (MAC) 479 to protect against forgery. The actual MAC computation (and the 480 result) is omitted in this example. (Note that deployments may 481 choose to use a digital signature to protect the JWT. While the JWT 482 access token offers this flexiblity we assume symmetric keys in our 483 example. 485 The JWT body is protected using the JWS. The JWS wraps around the 486 body with a header and the actual message authentication code, which 487 is not shown below. 489 JWS Header: 491 {"alg":"HS256", 492 "kid":"123" 493 } 495 Legend for JWS Header: 496 - alg: Algorithm parameter indicating the type of cryptographic 497 algorithm used to protect the structure. In this case 498 HMAC-SHA 256 is used. 499 - kid: Key Identifier used to select the appropriate key. 501 The JWT body contains various claims and we included several of them 502 in our example below. The most interesting one is the (not-yet- 503 defined) scope (scp) claim offering information about the 504 capabilities. In this example the scope ('scp') claim carries 505 permissions described in Section 6. The included capabilities will 506 depend on the type of token, namely AT-R vs. AT-KDC, and of course on 507 the specific deployment environment. 509 JWT Body: 510 { 511 "iss": "coaps://as.example.com", 512 "exp": "1361398824", 513 "scp": ["l2,g0,IP_M_R1", "l2,g1,IP_M_R1","l2,g2,IP_M_R1"], 514 "cnf":{ 515 "jwe": 516 "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5Ijoi 517 andrK2pzb24ifQ. ... (remainder of JWE omitted for brevity)" 518 } 519 } 521 Legend for JWT Body: 522 - iss: Issuer (which is the entity creating the access token). The 523 content does not need to be a URI but can also be a string 524 identifying the entity issuing the token. 525 - exp: Expiry date of the access token. Claim can be omitted if 526 tokens do not expire (for example, in a small enterprise 527 environment). 528 - scp: Scope denoting the capabilities of the token 529 - cnf: Key confirmation element containing an encrypted JSON Web 530 Key. The encryption being applied uses JSON Web 531 Encryption (JWE). 533 The content from here onward is only relevant to the AT-R, which is 534 assumed to be a PoP token. Note that a bearer token would not 535 contain the key confirmation claim shown in the JWT body since there 536 is no embedded key. 538 Figure 4 shows the structure of the PoP token graphically: 540 +-------------------------------+ 541 |JWS Header | 542 +-------------------------------+ 543 +-------------------------------+ 544 | | 545 | JWT Body | 546 | +------------+ | 547 | - iss | JWE | | 548 | - cnf ----->| +--------+| | 549 | - exp | | JWK || | 550 | - scp | +--------+| | 551 | - ... +------------+ | 552 | | 553 +-------------------------------+ 554 +-------------------------------+ 555 |JWS MAC/Signature | 556 +-------------------------------+ 558 Figure 4: PoP Token Structure. 560 The JSON Web Encryption (JWE) contains a header followed by the 561 content that is encrypted. Details about the JWE usage relevant for 562 this example can be found in Appendix A.3 of RFC 7516 [RFC7516]. 564 JWE Header: 566 {"alg":"A128KW", 567 "enc": 568 "A128CBC-HS256" 569 } 571 Legend for JWE Header: 572 - alg: Algorithm parameter indicating the AES 128 Key Wrap algorithm 573 being used for encrypting the included key and the 574 AES_128_CBC_HMAC_SHA_256 algorithm is used for authenticated 575 encryption. 577 JWK to be encrypted by JWE: 579 {"kty":"oct", 580 "k":"GawgguFyGrWKav7AX4VKUg" 581 } 583 Legend for the JWK to be encrypted: 584 - kty: Key type identifies the cryptographic algorithm family used with 585 the key. In this example the JWK contains a symmetric key denoted 586 as "oct" for octet sequence. 587 - k: Key parameter containing the actual key. 589 6. Lighting Application Example 591 In this Section, we look at a typical lighting application in which 592 presence sensor(s) are used to actuate a group of light points via a 593 control function based on a pre-specified set of rules. The 594 CoAP/LWMM2M/IPSO protocol stack can be used as a foundation for the 595 design of a lighting system. The architecture identifies three 596 functions present in a lighting system: 598 o Sensor functions which detect a (physical) phenomenon like a light 599 sensor, a presence detector or a push button. 601 o Actuator functions which cause action or change like setting a 602 driver value of a light source. 604 o Control functions which link the inputs (from sensor functions) to 605 outputs (from actuator functions) and enforce specific behaviour. 607 In typical applications, a sensor output might be used by multiple 608 control functions and a single control function might control many 609 actuators and a single actuator may be controlled by multiple control 610 functions. Moreover, different functions (e.g. control and actuator) 611 might be collocated on a single device. In the example below, we 612 show one method that may be used to implement the above architecture 613 using the LWM2M object model. We begin with the case of unicast 614 communication (because the LWM2M model does not directly support 615 multicast communication). We then explain a possible way to extend 616 to the multicast situation. 618 6.1. Unicast Messages using the LWM2M Object Model 620 The unicast scenario considers a deployment with a single (physical) 621 presence sensor, a single (physical) luminaire and the desired 622 control functionality is the following: dim the luminaire to 90% when 623 presence is detected in the room and dim the luminaire to 10% when 624 there is no presence. In this situation, the sensor functionality is 625 implemented on the presence sensor, the actuator functionality is 626 implemented on the luminaire and the control functionality could be 627 implemented on the presence sensor or the luminaire or on an 628 independent physical control device. 630 Using the LWM2M object model, 632 o the presence sensor function is implemented using the IPSO 633 Presence object with Object ID 3302 [1]. 635 o the actuator control function is implemented using the IPSO Light 636 control object with Object ID 3311 [1]. 638 o the control function is implemented by a LWM2M server to which the 639 two LWM2M clients on the luminaire and presence sensor register. 641 The IPSO Light Control Object supports the "Dimmer" resource (Res ID 642 5851) which may be written to in order to change the light intensity 643 output. The IPSO Presence Object supports the "Digital Input State" 644 resource (Res ID 5500) which is a boolean readable resource that 645 reflects the current state of the presence sensor. A method to 646 implement the control functionality is the following: 648 1. The luminaire and the presence sensor register their objects with 649 the control LWM2M server. This registration step happens during 650 commissioning phase, when the device reboots or whenever IP 651 addresses change. 653 2. The control LWM2M server observes the "Digital Input State" of 654 the presence sensor. 656 3. When the presence sensor state changes, the sensor notifies the 657 control LWM2M server. 659 4. The control LWM2M server writes the correct output intensity to 660 the "Dimmer" resource to change the luminaire light output. 662 This sequence of messages is shown in Figure 5. Here, [IP_C], [IP_L] 663 and [IP_S] are the unicast IP addresses of the devices that implement 664 the control function, light control object and sensor object, 665 respectively. 667 +---------------+ +--------------+ +--------------+ 668 |Presence Sensor| | Control Unit | | Luminaire | 669 |(LWM2M client) | |(LWM2M server)| |(LWM2M client)| 670 +---------------+ +--------------+ +--------------+ 671 | | | 672 | [IP_C]Register | [IP_C]Register | 673 |-------------------->|<---------------------| 674 | | | 675 | | | 676 | [IP_S]2.01 Created | [IP_L]2.01 Created | 677 |<--------------------|--------------------->| 678 | | | 679 |[IP_S]GET | | 680 |<--------------------| | 681 | /3302/0/5500 Obs.| | 682 | | | 683 |[IP_C]2.05 Content | | 684 |-------------------->|[IP_L]PUT /3311/0/5851| 685 | Obs. FALSE |--------------------->| 686 | | 10 | 687 | [IP_C]Notify | | 688 |-------------------->|[IP_L]PUT /3311/0/5851| 689 | TRUE |--------------------->| 690 | | 90 | 691 | [IP_C]Notify | | 692 |-------------------->|[IP_L]PUT /3311/0/5851| 693 | FALSE |--------------------->| 694 | | 10 | 696 Figure 5: Unicast messaging between control unit and luminaire. 698 6.2. Multicast Communication using the LWM2M Object Model 700 We now see how the above unicast model may be extended to the group 701 communication case and explain the security implications of the group 702 communication case. Let us now look at a typical lighting 703 application that requires group communication: 1) A set of rooms are 704 attached to a single corridor; 2) Each room consists of 8 luminaires 705 with 4 luminaires close to a window and four luminaires close to a 706 wall; 3) Every room has a presence sensor and the corridor also has a 707 presence sensor. 4) Every room has an individual control function 708 that maybe implemented on the room presence sensor device, one of the 709 luminaries or an independent control device. 711 The control functionality we wish to implement is the following: 713 o If presence is detected in the room, then dim-up the wall 714 luminaires to 90% and window luminaires to 50%. 716 o If no presence is detected in the room or corridor, then turn off 717 all luminaires. 719 o If no presence is detected in the room but presence is detected in 720 the corridor, then turn all the luminaires to 10% (for all rooms 721 attached to corridor). 723 For multicast communication, we can not use the LWM2M model directly. 724 However, we can make the following assumptions: 726 o All luminaires are CoAP servers whose resource tree supports the 727 IPSO Light Control object. 729 o All presence sensors are CoAP servers whose resource tree supports 730 the IPSO Presence Object. 732 o The control function is implemented using a CoAP client. 734 o All devices in the nth room subscribe to the multicast address 735 [IP_M_Rn] and the device that implements the control function in 736 this room has unicast address [IP_Cn]. 738 o Every room has three application groups and only one security 739 group. The application groups are: "room group" (GId = 0), 740 "window group" (GId = 1), "wall group" (GId = 2). The security 741 group is defined by the symmetric key that is shared with the 742 members. 744 o The GId is carried as a CoAP header (query?) option. 746 +--------------+ 747 | Luminaire | 748 |(CoAP Server) | 749 +--------------+ 750 ||| +---------------+ +---------------+ 751 ||| |Presence Sensor| |Presense Sensor| +--------------+ 752 ||| |Corridor | |Room | | Control Unit|| 753 ||| |(CoAP Server) | |(CoAP Server) | | (CoAP Client)| 754 ||| +---------------+ +---------------+ +--------------+ 755 ||| | | ||| 756 ||| | [IP_SC]GET /3302/0/5500 Obs. ||| 757 ||| |<------------------------------------------------------||| 758 ||| | | ||| 759 ||| | [IP_C1] 2.05 Content Obs. ||| 760 ||| |------------------------------------------------------>||| 761 ||| | FALSE ||| 762 ||| | | ||| 763 ||| | |[IP_SR]GET /3302/0/5500 Obs. ||| 764 ||| | |<----------------------------||| 765 ||| | | ||| 766 ||| | | [IP_C1] 2.05 Content Obs. ||| 767 ||| | |---------------------------->||| 768 ||| | | FALSE ||| 769 ||| | | ||| 770 ||| | | ||| 771 ||| | [IP_C1] Notify ||| 772 ||| |------------------------------------------------------>||| 773 ||| | TRUE ||| 774 ||| | | ||| 775 ||| | [IP_M_R1]PUT /3311/0/5851 ?gp=0 ||| 776 |||<---------------------------------------------------------------+|| 777 ||| | 10 | ||| 778 ||| | | ||| 779 ||| | | [IP_C1] Notify ||| 780 ||| | |---------------------------->||| 781 ||| | | TRUE ||| 782 ||| | | ||| 783 ||| | [IP_M_R1]PUT /3311/0/5851 ?gp=1 ||| 784 |||<---------------------------------------------------------------||| 785 ||| | 50 | ||| 786 ||| | | ||| 787 ||| | [IP_M_R1]PUT /3311/0/5851 ?gp=2 ||| 788 |||<-------------------------------------------------------------->||| 789 ||| | 90 | ||| 790 ||| | | ||| 791 ||| | | ||| 793 Figure 6: Multicast messaging between control unit and luminaires. 795 Figure 6 shows a typical sequence of messages that occur. For, 796 simplicity, we only show the messages exchanged with the control 797 function in room 1 and luminaires in room 1 though the same exchange 798 of messages applies to every room. Initially, the control function 799 in every room observes resource 5500 on the presence sensor in the 800 corridor and also the presence sensor in it's own room. When the 801 presence state changes in the corridor, the corridor notifies the 802 control function in every room using a sequence of unicast 803 notification messages. Once a controller in the room receives this 804 notification, it sends out a multicast message to all luminaires in 805 the group (GId = 0). If presence is then detected in the room, then 806 the room controller is notified and the room controller sends a 807 multicast message to the window group (GId = 1) to dim-up to 50% and 808 wall group (GID = 2) to dim-up to 90%. Note the separation of the two 809 types of sensors in this problem: The presence sensor in a room is a 810 part of the room group and therefore will receive the room group key 811 which allows it to directly talk to the luminaires in the room to 812 which the sensor belongs. However, the corridor presence sensor is 813 not a part of the room group and does not receive the room group key. 814 The corridor presence sensor must only authorized to communicate with 815 the room control function which then controls the luminaires. 817 In this Example, there are three application groups per room and one 818 multicast group per room. There are two types of security groups: 819 one security group per room and a security group that has the 820 corridor presence sensor and all the control units attached to the 821 corridor. Therefore, the control unit in room 1 requires access 822 tokens with the following scope, "l2,g0,IP_M_R1", "l2,g1,IP_M_R1", 823 "l2,g2,IP_M_R1" for room control and also "l2,g0,IP_SC" for corridor 824 presence sensor. The KDC generates 2 keys - KeyRoom1 and KeyCor that 825 need to be delivered to the control unit in room 1: KeyRoom1 is used 826 to communicate with the room luminaire group for all three 827 application groups - g0, g1, g2 and KeyCor is used to communicate 828 with the corridor presence sensor. 830 7. Security Considerations 832 7.1. Token Verification 834 Due to the low latency requirements, token verification needs to be 835 done locally and cannot be outsourced to other parties. For this 836 reason self-contained token must be used and the receivers are 837 required to follow the steps outlined in Section 7.2 of RFC 7519 838 [RFC7519]. This includes the verification of the message 839 authentication code protecting the contents of the token and the 840 encryption envelope protecting the contained symmetric group key. 842 7.2. Token Revocation 844 Tokens have a specific lifetime. Setting the lifetime is a policy 845 decision that involves making a trade-off decision. Allowing a 846 longer lifetime increases the need to introduce a mechanism for token 847 revocation (e.g., a real-time signal from the KDC/Authorization 848 Server to the receivers to blacklist tokens) but lowers the 849 communication overhead during normal operation since new tokens need 850 to be obtained only from time to time. Real-time communication with 851 the receivers to revoke tokens may not be possible in all cases 852 either, particularly when off-line operation is demanded or in small 853 networks where the AS or even the KDC is only present during 854 commissioning time. 856 We therefore recommend to issue short-lived tokens for for dynamic 857 scenarios like users accessing the lighting infrastructure of 858 buildings using smartphones, tablets and alike to avoid potential 859 security problems when tokens are leaked or where authorization 860 rights are revoked. For senders that are statically mounted (like 861 traditional light switches) we recommend a longer lifetime since re- 862 configurations and token leakage is less likely to happen frequently. 864 To limit the authorization rights tokens should contain an audience 865 restriction, scoping their use to the intended receivers and to their 866 access level. 868 7.3. Time 870 Senders and receivers are not assumed to be equipped with real-time 871 clocks but these devices are still assumed to interact with a time 872 server. The lack of accurate clocks is likely to lead to clock 873 drifts and limited ability to check for replays. For those cases 874 where no time server is available, such as in small network 875 installations, token verification cannot check for expired tokens and 876 hence it might be necessary to fall-back to tokens that do not 877 expire. 879 8. Operational Considerations 881 8.1. Persistence of State Information 883 Devices in the lighting system can often be powered down 884 intentionally or unintentionally. Therefore the devices may need to 885 store the authorization tokens and cryptographic keys (along with 886 replay context) in persistence storage like flash. This is 887 especially required if the authorization server is no more online 888 since it was removed after the commissioning phase. However the 889 decision on the data to be persistently stored is a trade-off between 890 how soon the devices can be back online to normal operational mode 891 and the memory wear caused due to limited program-erase cycles of 892 flash over 15-20 years life-time of the device. 894 The different data that may need to be stored are access tokens AT- 895 KDC, AT-R and last seen replay counter. 897 8.2. Provisioning in Small Networks 899 In small networks the authorization server and the KDC may be 900 available only temporarily during the commissioning process and are 901 not available afterwards. 903 9. Acknowledgements 905 The author would like to thank Walter Werner and Esko Dijk for his 906 help with this document. 908 10. References 910 10.1. Normative References 912 [I-D.gerdes-ace-actors] 913 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 914 architecture for authorization in constrained 915 environments", draft-gerdes-ace-actors-05 (work in 916 progress), April 2015. 918 [IPSO] IPSO Alliance, "IPSO Smart Object Guidelines - Starter 919 Pack 1.0", 2015. 921 [LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine, 922 Technical Specification, Candidate Version 1.0", December 923 2013. 925 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 926 RFC 7516, May 2015. 928 10.2. Informative References 930 [COSE] IETF, "CBOR Object Signing and Encryption (cose) Working 931 Group", https://datatracker.ietf.org/wg/cose/charter/, 932 2015. 934 [I-D.ietf-oauth-pop-architecture] 935 Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 936 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 937 Architecture", draft-ietf-oauth-pop-architecture-01 (work 938 in progress), March 2015. 940 [I-D.kumar-dice-multicast-security] 941 Kumar, S. and R. Struik, "Transport-layer Multicast 942 Security for Low-Power and Lossy Networks (LLNs)", draft- 943 kumar-dice-multicast-security-00 (work in progress), March 944 2015. 946 [I-D.selander-ace-object-security] 947 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 948 "June 29, 2015", draft-selander-ace-object-security-02 949 (work in progress), June 2015. 951 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 952 6749, October 2012. 954 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 955 Framework: Bearer Token Usage", RFC 6750, October 2012. 957 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 958 Representation (CBOR)", RFC 7049, October 2013. 960 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 961 (JWT)", RFC 7519, May 2015. 963 Authors' Addresses 965 Abhinav Somaraju 966 Tridonic GmbH & Co KG 967 Farbergasse 15 968 Dornbirn 6850 969 Austria 971 Email: abhinav.somaraju@tridonic.com 973 Sandeep S. Kumar 974 Philips Research 975 High Tech Campus 34 976 Eindhoven 5656 AE 977 NL 979 Email: ietf.author@sandeep-kumar.org 981 Hannes Tschofenig 982 ARM Ltd. 983 110 Fulbourn Rd 984 Cambridge CB1 9NJ 985 Great Britain 987 Email: Hannes.tschofenig@gmx.net 988 URI: http://www.tschofenig.priv.at