idnits 2.17.1 draft-tschofenig-ace-group-communication-security-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 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 402: '... The KDC MUST maintain a table consi...' RFC 2119 keyword, line 417: '... The KDC MUST generate new group key...' RFC 2119 keyword, line 453: '...tribution center MUST have a unique cl...' RFC 2119 keyword, line 492: '...eceiving devices MUST maintain a table...' RFC 2119 keyword, line 510: '... The receiver MUST silently discard ...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2368 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 1117, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-05 ** Downref: Normative reference to an Informational draft: draft-ietf-ace-actors (ref. 'I-D.ietf-ace-actors') == Outdated reference: A later version (-15) exists of draft-ietf-ace-cbor-web-token-09 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ace H. Tschofenig 3 Internet-Draft ARM Ltd. 4 Intended status: Standards Track W. Werner 5 Expires: May 3, 2018 Werner Management Services e.U. 6 October 30, 2017 8 Security for Low-Latency Group Communication 9 draft-tschofenig-ace-group-communication-security-00.txt 11 Abstract 13 Some Internet of Things application domains require secure group 14 communication. This draft describes procedures for authorization, 15 key management, and securing group messages. We specify the usage of 16 object security at the application layer for group communication and 17 assume that CoAP is used as the application layer protocol. The 18 architecture allows the usage of symmetric and asymmetric keys to 19 secure the group messages. The asymmetric key solution provides the 20 ability to uniquely authenticate the source of all group messages and 21 this is the recommended architecture for most applications. However, 22 some applications have strict requirements on latency for group 23 communication (e.g. in non-emergency lighting applications) and it 24 may not always be feasible to use the secure source authenticated 25 architecture. In such applications we recommend the use of 26 dynamically generated symmetric group keys to secure group 27 communications. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Architecture - Group Authentication . . . . . . . . . . . . . 5 66 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.2. AT-KDC Access Tokens . . . . . . . . . . . . . . . . . . 9 68 3.3. AT-R Access Tokens . . . . . . . . . . . . . . . . . . . 9 69 3.4. Multicast Message Content . . . . . . . . . . . . . . . . 10 70 3.5. Receiver Algorithm . . . . . . . . . . . . . . . . . . . 11 71 3.6. Sender Algorithm . . . . . . . . . . . . . . . . . . . . 12 72 4. Architecture - source authentication . . . . . . . . . . . . 14 73 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.2. AT-R Access Tokens . . . . . . . . . . . . . . . . . . . 17 75 4.3. Multicast Message Content . . . . . . . . . . . . . . . . 17 76 4.4. Receiver Algorithm . . . . . . . . . . . . . . . . . . . 18 77 4.5. Sender Algorithm . . . . . . . . . . . . . . . . . . . . 19 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 5.1. Applicability statement . . . . . . . . . . . . . . . . . 20 80 5.2. Token Verification . . . . . . . . . . . . . . . . . . . 21 81 5.3. Token Revocation . . . . . . . . . . . . . . . . . . . . 21 82 5.4. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 6. Operational Considerations . . . . . . . . . . . . . . . . . 22 84 6.1. Persistence of State Information . . . . . . . . . . . . 22 85 6.2. Provisioning in Small Networks . . . . . . . . . . . . . 23 86 6.3. Client IDs . . . . . . . . . . . . . . . . . . . . . . . 23 87 6.4. Application Groups vs. Security Groups . . . . . . . . . 23 88 6.5. Lost/Stolen Device . . . . . . . . . . . . . . . . . . . 23 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 94 10.2. Informative References . . . . . . . . . . . . . . . . . 25 95 Appendix A. Access Levels . . . . . . . . . . . . . . . . . . . 25 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 98 1. Introduction 100 There are low latency group communication use cases that require 101 securing communication between a sender, or a group of senders, and a 102 group of receivers. In the lighting use case, a set of lighting 103 nodes (e.g., luminaires, wall-switches, sensors) are grouped together 104 into a single "Application Group" and the following three 105 requirements need to be addressed: 107 1. Only authorized members of the application group must be able to 108 read and process messages. 110 2. Receivers of group messages must be able to verify the integrity 111 of received messages as being generated within the group. 113 3. Message communication and processing must happen with a low 114 latency and in synchronous manner. 116 This document discusses a group communication security solution that 117 satisfies these three requirements. As discussed in Section 4, we 118 recommend the usage of an asymmetric key solution that allows unique 119 source authentication of all group messages. However, in situations 120 where the low latency requirements can not be met (e.g. in non- 121 emergency lighting applications), the alternative architecture 122 discussed in Section 3 based on symmetric keys is recommended. 124 2. Terminology 126 This document uses the following terms from [I-D.ietf-ace-actors]: 127 Authorization Server, Resource Owner, Client, Resource Server. The 128 terms 'sender' and 'receiver' refer to the application layer 129 messaging used for lighting control; other communication interactions 130 with the supporting infrastructure uses unicast messaging. 132 When nodes are combined into groups there are different layers of 133 those groups with unique characteristics. For clarity we introduce 134 terminology for three different groups: 136 Application Group: 138 An application group consists of the set of all nodes that have 139 been configured to respond to a single application layer request. 140 For example, a wall mounted switch and a set of luminaires in a 141 single room might belong to a single group and the switch may be 142 used to turn on/off all the luminaires in the group simultaneously 143 with a single button press. In the remainder of this document we 144 will use GId to identify an application group. 146 Multicast Group: 148 A multicast group consists of the set of all nodes that subscribe 149 to the same multicast IP address. 151 Security Group: 153 A security group consists of the set of all nodes that have been 154 provisioned with the same keying material. All the nodes within a 155 security group share a security association or a sequence of 156 security associations wherein a single association specifies the 157 keying material, algorithm-specific information, lifetime and a 158 key ID. 160 Source-authenticated Security Group: 162 A source-authenticated security group consists of the set of 163 receiver nodes that have been provisioned with the public 164 verification keying material of all the sender nodes and the set 165 of sender nodes that are provisioned with their unique private 166 signing keying material. All the nodes within a source- 167 authenticated security group share a security association or a 168 sequence of security associations wherein a single association 169 specifies the the public or private keying material, algorithm- 170 specific information, lifetime and a key ID. 172 Typically, the four groups might not coincide due to the memory 173 constraints on the devices and also security considerations. For 174 instance, in a small room with windows, we may have three application 175 groups: "room group", "luminaires close to the window group" and 176 "luminaires far from the window group". However, we may choose to 177 use only one multicast group for all devices in the room and one 178 security group for all the devices in the room. Note that every 179 application group belongs to a unique security group. However, the 180 converse is not always true. This implies that the application group 181 ID maybe used to determine the associated security group but not vice 182 versa. 184 The fact that security groups may not coincide with application 185 groups implies that 187 (1) an application must be able to specify which resources on a 188 resource server are accessible by a client that has access to the 189 group key, and 190 (2) a method is required to associate the group key to the 191 application group(s) for which the group key may be used. 193 In this document we provide fields that may be used to specify the 194 "scope of the key" and "application groups for which the key may be 195 used". A commissioner has a lot of flexibility to assign nodes to 196 multicast groups and to security groups while the application groups 197 will be determined by the semantics of the application itself. The 198 exact partitioning of the nodes into security and multicast groups is 199 therefore deployment specific. 201 3. Architecture - Group Authentication 203 Each node in a lighting application group might be a sender, a 204 receiver or both sender and receiver (even though in Figure 1, we 205 show nodes that are only senders or only receivers for clarity). The 206 low latency requirement implies that most of the communication 207 between senders and receivers of application layer messages is done 208 using multicast IP. On some occasions, a sender in a group will be 209 required to send unicast messages to unique receivers within the same 210 group and these unicast messages also need communication security. 212 Two logical entities are introduced and they have the following 213 function: 215 Key Distribution Center (KDC): This logical entity is responsible 216 for generating symmetric keys and distributing them to the nodes 217 authorized to receive them. The KDC ensures that nodes belonging 218 to the same security group receive the same key and that the keys 219 are renewed based on certain events, such as key expiry or change 220 in group membership. 222 Authorization Server (AS): This logical entity stores authorization 223 information about devices, meta-data about them, and their roles 224 in the network. For example, a luminaire is associated with 225 different groups, and may have meta-data about its location in a 226 building. 228 Note that we assume that nodes are pre-configured with device 229 credentials (e.g., a certificate and the corresponding private key) 230 during manufacturing or during an initial provisioning phase. These 231 device credentials are used in the interaction with the authorization 232 server. 234 Figure 1 and Figure 2 provide an architectural overview. The dotted 235 lines illustrate the use of unicast DTLS messages for securing the 236 message exchange between all involved parties. The secured group 237 messages between senders and receivers are indicated using lines with 238 star/asterisk characters. The security of the group messages is 239 accomplished at the application level using small modification to 240 OSCOAP - Object Security of CoAP (see 241 [I-D.selander-ace-object-security]) which are to be defined. 243 Figure 1 illustrates the information flow between an authorization 244 server and the nodes participating in the lighting network, which 245 includes all nodes that exchange lighting application messages. This 246 step is typically executed during the commissioning phase for nodes 247 that are fixed-mounted in buildings. The authorization server, as a 248 logical function, may in smaller deployments be included in a device 249 carried by the commissioner and only be present during the 250 commissioning phase. Other use cases, such as employees using their 251 smartphones to control lights, may require an authorization server 252 that dynamically executes access control decisions. 254 Figure 1 shows the commissioning phase where the nodes obtain 255 configuration information, which includes the AT-KDC. The AT-KDC is 256 an access token and includes authorization claims for consumption by 257 the key distribution center. We use the access token terminology 258 from [RFC6749]. The AT-KDC in this architecture may be a bearer 259 token or a proof-of-possession (PoP) token. The bearer token concept 260 is described in [RFC6750] and the PoP token concept is explained in 261 [I-D.ietf-oauth-pop-architecture]. The AT-KDC is created by the 262 authorization server after authenticating the requesting node and 263 contains authorization-relevant information. The AT-KDC is protected 264 against modifications using a digital signature or a message 265 authentication code. It is verified in Figure 2 by the KDC. 267 Config +-------------+ Config 268 +-----------+Authorization+------------+ 269 | .........>| Server |<.......... | 270 | . DTLS +-------------+ DTLS . | 271 | . ^^ . | 272 | . |. . | 273 | . |. . | 274 v v |. v v 275 +-----+ Config|.DTLS +-----+ 276 +-----+| |. +-----+| 277 +-----+|+ |. +-----+|+ 278 | A |+ vv | C |+ 279 +-----+ +-----+ +-----+ 280 . E.g. +-----+| E.g. 281 Light +-----+|+ Luminaires 282 Switches | B |+ 283 +-----+ 284 E.g. 285 Presence 286 Sensors 287 Legend: 289 Config (Configuration Data): Includes configuration 290 parameters, authorization information encapsulated 291 inside the access token (AT-KDC) and other meta- 292 data. 294 Figure 1: Architecture: Commissioning Phase. 296 In the simplified message exchange shown in Figure 2 a sender 297 requests a security group key and the access token for use with the 298 receivers (called AT-R). The request contains information about the 299 resource it wants to access, such as the application group and other 300 resource-specific information, if applicable, and the previously 301 obtained AT-KDC access token. Once the sender has successfully 302 obtained the requested information it starts communicating with 303 receivers in that group using group messages. The symmetric key 304 obtained from the KDC is used to secure the groups messages. The 305 AT-R may be attached to the initial request. 307 Receivers need to perform two steps, namely to obtain the necessary 308 group key to verify the incoming messages and to determine what 309 resource the requestor is authorized to access. Both pieces of 310 information can be found in the AT-R access token. 312 Group messages need to be protected such that replay and modification 313 can be detected. The integrity of the message is accomplished using 314 a keyed message digest in combination with the group key. The use of 315 symmetric keys is envisioned in this specification due to latency 316 requirements. For unicast messaging between the group members and 317 the AS or KDC, we assume the use of DTLS for transport security. 318 However, the use of TLS, and application layer security is possible 319 but is outside the scope of this document. 321 Request Request 322 +AT-KDC +------------+ +AT-KDC 323 +------------>| Key |<----------+ 324 |+------------|Distribution|----------+| 325 ||Reply | Center | Reply || 326 ||+AT-R +------------+ +AT-R || 327 ||+Group ..^ ^.. +Group || 328 || Key .. .. Key || 329 || ...DTLS DTLS .. || 330 |v .. .. v| 331 +-----+<. .>+-----+ 332 +-----+| +-----+| 333 +-----+|+ Secure Multicast Msg +-----+|+ 334 | A |+*****************************> | B |+ 335 +-----+ +-----+ 336 Sender(s) Receiver(s) 337 e.g. Light Switch e.g. Luminaires 339 Figure 2: Architecture: Group Key Distribution Phase. 341 3.1. Assumptions 343 1. The AT-KDC is a manifestation of the authorization granted to a 344 specific client (or user running a client). The AT-KDC is 345 longer-lived and can be used to request multiple AT-Rs. 347 2. Each AT-R is valid for use with one or multiple application 348 groups. 350 3. The AS and the KDC logical roles may reside in different physical 351 entities. 353 4. The AT-KDC as well as the AT-R may be self-contained tokens or 354 references. References are more efficient from a bandwidth point 355 of view but require an additional lookup. 357 5. The AT-KDC token is opaque to the client. Data that is meant for 358 processing by the client has to be conveyed to the client 359 separately. The AT-R token on the other hand is meant for 360 consumption by the client. 362 6. The client requests AT-Rs for different application groups by 363 including additional information in the request to the KDC for 364 what application groups the AT-R(s) have to be requested. The 365 KDC may return multiple AT-Rs in a single response (for 366 performance reasons). 368 7. The AT-KDC and the AT-R are encoded as CBOR Web Tokens 369 [I-D.ietf-ace-cbor-web-token] and protected using COSE 370 [I-D.ietf-cose-msg]. 372 3.2. AT-KDC Access Tokens 374 The AT-KDC contains 376 1. Issuer: Entity creating the access token. This information needs 377 to be cryptographically bound to the digital signature/keyed 378 message digest protecting the content of the token, as provided 379 by the CBOR Web Token (CWT). 381 2. Expiry date: Information can be omitted if tokens do not expire 382 (for example, in a small enterprise environment). 384 3. Scope: Permissions of the entity holding the token. This 385 includes information about the resources that may be accessed 386 with the token (e.g., access level) and application layer group 387 IDs for the groups for which the tokens may be used. 389 4. Recipient/Audience: Indication to whom the AT-KDC was issued to. 390 In this case, it is the KDC. 392 5. Client ID: Information about the client that was authenticated by 393 the authorization server. 395 6. Issued at: Indicates date and time when the AT-KDC was created by 396 the authorization server. 398 3.3. AT-R Access Tokens 400 Clients send the AT-KDC to the KDC in order to receive an AT-R. 402 The KDC MUST maintain a table consisting of scope values, which 403 includes the application group id. These entries point to a sequence 404 of security associations. A security association specifies the key 405 material, algorithm-specific information, lifetime and a key ID and 406 the key ID may be used to identify this security association. 408 The AS/KDC must guarantee the uniqueness of the client ids for its 409 nodes. This may be accomplished by the AS/KDC assigning values to 410 the nodes or by using information that is already unique per device 411 (such as an EUI-64). 413 The KDC furthermore needs to be configured with information about the 414 authorization servers it trusts. This may include a provisioned 415 trust anchor store, or shared credentials (similar to a white list). 417 The KDC MUST generate new group keys after the validity period of the 418 current group key expires. 420 The AT-R contains 422 1. Issuer: Entity creating the access token. This information needs 423 to be cryptographically bound to the digital signature/keyed 424 message digest protecting the content of the token, as provided 425 by the CBOR Web Token (CWT). 427 2. Expiry date: Information can be omitted if tokens do not expire 428 (for example, in a small enterprise environment). 430 3. Scope: Permissions of the entity holding the token. This 431 includes information about the resources that may be accessed 432 with the token (e.g., access level) and application layer group 433 IDs for the groups for which the tokens may be used. 435 4. Security Group Key: Key to use for the group communication. 437 5. Algorithm: Used for secure group communication. 439 6. KID: Sequentially increasing ID of the key for the security group 440 (the devices may store an older key to help with key rolling.) 442 7. Issued at: Indicates date and time when the AT-R was created by 443 the KDC. 445 3.4. Multicast Message Content 447 The following information is needed for the cryptographic algorithm, 448 which is assumed to be in the COSE header: 450 1. Nonce value consisting of 452 * Client ID (unencrypted, integrity protected): Every sender 453 managed by a key distribution center MUST have a unique client 454 ID. 456 * Sequence Number (unencrypted, integrity protected): Used for 457 replay protection. 459 * An implicit IV that is either derived from the keys at the 460 end-points or fixed to a certain value by standard (not sent 461 in the message) 463 2. MAC (not integrity protected): For integrity protection. 465 The following information is additionally required to process the 466 secure message: 468 1. Destination IP address and port (not encrypted, integrity 469 protected): Integrity protection of the IP address and port 470 ensures that the message content cannot be replayed with a 471 different destination address or on a different port. 473 2. CoAP Path (encrypted, integrity protected): Uniquely identifies 474 the target resource of a CoAP request. 476 3. Application Group id in CoAP header (unencrypted, integrity 477 protected): Is used to identify a sequence of security 478 associations to use to decrypt the message. The CoAP header 479 option is TBD. 481 4. Key ID (unencrypted, integrity protected): Is used to select the 482 current security association from the sequence of security 483 associations identified by the application group id. 485 5. CoAP Header Options other than application group id (encrypted - 486 if desired, integrity protected) 488 6. CoAP Payload (encrypted, integrity protected). 490 3.5. Receiver Algorithm 492 All receiving devices MUST maintain a table consisting of mappings of 493 application group id, to a sequence of security associations. 495 When a node receives an incoming multicast message it looks up the 496 application group id and the key id (which are both found in the CoAP 497 header) to determine the correct security association. 499 The key id is used for situations where the group key is updated by 500 the KDC (for example in situations where a device in a group is lost 501 or stolen). 503 To check for replay attacks the receiver has to consult the state 504 stored with the security association to obtain the current sequence 505 number and to compare it against the sequence number found in the 506 request payload for that sender based on the Sender ID. The receiver 507 needs to store the latest correctly verified nonce values to detect 508 replay attacks 510 The receiver MUST silently discard an incoming message in the 511 following cases: 513 o Application Group ID lookup does not return any security 514 association. 516 o Key ID lookup among the previously retrieved sequence of security 517 associations does not identify a unique security association. 519 o Integrity check fails. 521 o Decryption fails. 523 o Replay protection check failed. The (client ID || sequence 524 number), which are both part of the nonce, have already been 525 received in an earlier message. 527 Once the cryptographic processing of the message is completed, the 528 receiver must check whether the sender is authorized to access the 529 protected resource, indicated by the CoAP request URI at the right 530 level. For this purpose the receiver consults the locally stored 531 authorization database that was populated with the information 532 obtained via the AT-R token and the static authorization levels 533 described in Appendix A. 535 Once all verification steps have been successful the receiver 536 executes the CoAP request and returns an appropriate response. Since 537 the response message will also be secured the message protection 538 processing described in Section 3.6 must be executed. Additionally, 539 the nonce value corresponding to the security association MUST be 540 updated to the nonce value in the message. 542 3.6. Sender Algorithm 544 Figure 3 describes the algorithm for obtaining the necessary 545 credentials to transmit a secure group message. When the sender 546 wants to send a message to the application group, it checks if it has 547 the respective group key. If no group key is available then it 548 determines whether it has an access token for use with the KDC (i.e., 549 AT-KDC). If no AT-KDC is found in the cache then it contacts the 550 authorization server to obtain that AT-KDC. Note that this assumes 551 that the authorization server is online, which is only true in 552 scenarios where granting authorization dynamically is supported. In 553 the other case where the AT-KDC is already available the sender 554 contacts the KDC to obtain a group key. If a group key is already 555 available then the sender can transmit a secured message to the group 556 immediately. 558 _______ 559 / \ 560 | Start | 561 \_______/ 562 | 563 v 564 /\ 565 / \ 566 / \ 567 / \ 568 / \ 569 ___No____/Group Key \____ 570 | \Available?/ | 571 | \ / | 572 v \ / Yes 573 /\ \ / | 574 / \ \ / v 575 / \ \/ +-------------+ 576 / \ ^ |Transmit | 577 / \ | |multicast | 578 ____/ AT+KDC \__ | |mesg to group| 579 | \Available?/ | | +-------------+ 580 | \ / | | 581 No \ / Yes | 582 | \ / | | 583 | \ / | | 584 v \/ v | 585 +-----+-----+ ^ +----------+ | 586 |Request | | |Request | | 587 |AT-KDC | | |Group Key | | 588 |from |---+ |from KDC |--+ 589 |Auth Server| | | 590 +-----------+ +----------+ 592 Figure 3: Steps to Transmit Multicast Message (w/o Failure Cases). 594 Note that the sender does not have to wait until it has to transmit a 595 message in order to request a group key; the sender is likely to be 596 pre-configured with information about which application group it 597 belongs to and can therefore pre-fetch the required information. 599 Group keys have a lifetime, which is configuration-dependent, but 600 mechanisms need to be provided to update the group keys either via 601 the sender asking for a group key renewal or via the KDC pushing new 602 keys to senders and receivers. The lifetime can be based on time or 603 on the number of transmitted messages. 605 4. Architecture - source authentication 607 This section discusses the usage of asymmetric keys to achieve source 608 authentication of group messages and is the recommend architecture 609 for securing group messages. However, this solution may not meet the 610 low latency requirement without adequate hardware support but still 611 most of the group communication between senders and receivers of 612 application layer messages is done using multicast IP. 614 Unlike the previous architecture, the current architecture requires 615 only the Authorization Server (AS) logical entity as defined in the 616 previous section. 618 As in the previous case we assume that nodes are pre-configured with 619 device credentials (e.g., a certificate and the corresponding private 620 key) during manufacturing or during an initial provisioning phase. 621 These device credentials are used in the interaction with the 622 authorization server. 624 Figure 4 and Figure 5 provide an architectural overview for the 625 source authenticated case. The main differences from the previous 626 case is that the AS provides directly the AT-R tokens. Further no 627 KDC is required in this case since the senders and receivers can use 628 their public-private key pair credentials to secure messages. The AS 629 may provide authorization based on the pre-existing device 630 credentials or issue new credentials to the devices. The security of 631 the group messages is accomplished at the application level using 632 small modification to OSCOAP - Object Security of CoAP (see 633 [I-D.selander-ace-object-security]) but based on public key 634 signatures which are to be defined. 636 Figure 4 illustrates the information flow between an authorization 637 server and the nodes participating in the source-authenticated group 638 network. Like the previous case, this step is typically executed 639 during the commissioning phase for nodes that are fixed-mounted in 640 buildings. The authorization server, as a logical function, may in 641 smaller deployments be included in a device carried by the 642 commissioner and only be present during the commissioning phase. 643 Other use cases, such as employees using their smartphones to control 644 lights, may require an authorization server that dynamically executes 645 access control decisions. 647 Figure 4 shows the commissioning phase where the nodes obtain 648 configuration information, which includes directly the AT-R. The 649 AT-R is an access token and includes authorization claims for 650 consumption by the receivers. The AT-R may be a bearer token or a 651 proof-of-possession (PoP) token. The AT-R is created by the 652 authorization server after authenticating the requesting node and 653 contains authorization-relevant information. The AT-R is protected 654 against modifications using a digital signature. It is verified in 655 Figure 5 by the receivers. 657 Config +-------------+ Config 658 +-----------+Authorization+------------+ 659 | .........>| Server |<.......... | 660 | . DTLS +-------------+ DTLS . | 661 | . ^^ . | 662 | . |. . | 663 | . |. . | 664 v v |. v v 665 +-----+ Config|.DTLS +-----+ 666 +-----+| |. +-----+| 667 +-----+|+ |. +-----+|+ 668 | A |+ vv | C |+ 669 +-----+ +-----+ +-----+ 670 . E.g. +-----+| E.g. 671 Light +-----+|+ Luminaires 672 Switches | B |+ 673 +-----+ 674 E.g. 675 Presence 676 Sensors 677 Legend: 679 Config (Configuration Data): Includes configuration 680 parameters, authorization information encapsulated 681 inside the access token (AT-R) and other meta- 682 data. 684 Figure 4: Architecture - Source-authenticated: Commissioning Phase. 686 In the simplified message exchange shown in Figure 5 a sender starts 687 communicating with receivers in that source-authenticated group using 688 public-key signed group messages. The AT-R may be attached to the 689 initial request. 691 Receivers need to perform two steps, namely to obtain the necessary 692 public verification key of the senders (or a root verification key if 693 they are certified by the same authority) to verify the incoming 694 messages and the public verification key of the AS to determine what 695 resource the requestor is authorized to access. Both pieces of 696 information can either be found in the AT-R access token or 697 separately configured during the commissioning phase. 699 Source-authenticated Group messages also need to be protected such 700 that replay and modification can be detected. The integrity of the 701 message is accomplished using a public-key signature. This may not 702 achieve the latency requirements and used where source-authentication 703 is more important. For unicast messaging between the group members 704 and the AS , we assume the use of DTLS for transport security. 706 +-----+ +-----+ 707 +-----+| +-----+| 708 +-----+|+ Secure Multicast Msg +-----+|+ 709 | A |+*****************************> | B |+ 710 +-----+ +-----+ 711 Sender(s) Receiver(s) 712 e.g. Light Switch e.g. Luminaires 714 Figure 5: Architecture - Source-authenticated: Group communication. 716 4.1. Assumptions 718 1. The AT-R is a manifestation of the authorization granted to a 719 specific client (or user running a client). The AT-R is longer- 720 lived and can be used directly for source-authenticated group 721 communication until it is revoked or expired. 723 2. Each AT-R is valid for use with one or multiple application 724 groups. 726 3. The AT-R may be self-contained tokens or references. References 727 are more efficient from a bandwidth point of view but require an 728 additional lookup. 730 4. The AT-R token is not opaque to the client and is meant for 731 consumption by the client. 733 5. The client requests AT-Rs for different application groups by 734 including additional information in the request to the AS for 735 what application groups the AT-R(s) have to be requested. The AS 736 may return multiple AT-Rs in a single response (for performance 737 reasons). 739 6. The AT-R is encoded as CBOR Web Tokens 740 [I-D.ietf-ace-cbor-web-token] and protected using COSE 741 [I-D.ietf-cose-msg]. 743 4.2. AT-R Access Tokens 745 The AT-R contains 747 1. Issuer: Entity creating the access token. This information needs 748 to be cryptographically bound to the digital signature/keyed 749 message digest protecting the content of the token, as provided 750 by the CBOR Web Token (CWT). 752 2. Expiry date: Information can be omitted if tokens do not expire 753 (for example, in a small enterprise environment). 755 3. Scope: Permissions of the entity holding the token. This 756 includes information about the resources that may be accessed 757 with the token (e.g., access level) and application layer group 758 IDs for the groups for which the tokens may be used. 760 4. Recipient/Audience: Indication to whom the AT-R was issued to. 761 In this case, it is the receivers. 763 5. Client ID: Information about the client that was authenticated by 764 the authorization server. 766 6. Client public key: The public key to use for signing the source- 767 authenticated group communication. These public key may be 768 optionally certified using the AS key or a domain root key. This 769 reduces the need for additional per-device public key storage on 770 the receivers. 772 7. Algorithm: Used for source-authenticated secure group 773 communication. 775 8. Issued at: Indicates date and time when the AT-R was created by 776 the authorization server. 778 4.3. Multicast Message Content 780 The following information is needed for the cryptographic algorithm, 781 which is assumed to be in the COSE header: 783 1. Nonce value consisting of 784 * Client ID (unencrypted, integrity protected): Every sender 785 managed by the AS MUST have a unique client ID. 787 * Sequence Number (unencrypted, integrity protected): Used for 788 replay protection. 790 2. Signature (not integrity protected): For source-authenticated 791 integrity protection. 793 The following information is additionally required to process the 794 secure message: 796 1. Destination IP address and port (not encrypted, integrity 797 protected): Integrity protection of the IP address and port 798 ensures that the message content cannot be replayed with a 799 different destination address or on a different port. 801 2. CoAP Path (encrypted, integrity protected): Uniquely identifies 802 the target resource of a CoAP request. 804 3. Application Group id in CoAP header (unencrypted, integrity 805 protected): Is used to identify a sequence of security 806 associations to use to decrypt the message. The CoAP header 807 option is TBD. 809 4. Key ID (unencrypted, integrity protected): Is used to select the 810 correct security association containing the verification key from 811 the sequence of security associations identified by the 812 application group id. 814 5. CoAP Header Options other than application group id (encrypted - 815 if desired, integrity protected) 817 6. CoAP Payload (encrypted, integrity protected). 819 4.4. Receiver Algorithm 821 When a node receives an incoming multicast message it looks up the 822 application group id and the key id (which are both found in the CoAP 823 header) to determine the correct security association to use to 824 verify the message. 826 The key id is used for situations where the client may have different 827 keys for different applications. 829 To check for replay attacks the receiver has to consult the state 830 stored with the security association to obtain the current sequence 831 number and to compare it against the sequence number found in the 832 request payload for that sender based on the Sender ID. The receiver 833 needs to store the latest correctly verified nonce values to detect 834 replay attacks 836 The receiver MUST silently discard an incoming message in the 837 following cases: 839 o Application Group ID lookup does not return any security 840 association. 842 o Key ID lookup among the previously retrieved sequence of security 843 associations does not identify a unique security association. 845 o Integrity check fails. 847 o Replay protection check failed. The (client ID || sequence 848 number), which are both part of the nonce, have already been 849 received in an earlier message. 851 Once the cryptographic processing of the message is completed, the 852 receiver must check whether the sender is authorized to access the 853 protected resource, indicated by the CoAP request URI at the right 854 level. For this purpose the receiver consults the locally stored 855 authorization database that was populated with the information 856 obtained via the AT-R token and the static authorization levels 857 described in Appendix A. 859 Once all verification steps have been successful the receiver 860 executes the CoAP request and returns an appropriate response. Since 861 the response message will also be secured the message protection 862 processing described in Section 3.6 must be executed. Additionally, 863 the nonce value corresponding to the security association MUST be 864 updated to the nonce value in the message. 866 4.5. Sender Algorithm 868 Figure 6 describes the algorithm for obtaining the necessary 869 credentials to transmit a source-authenticated secure group message. 870 When the sender wants to send a message to the application group, it 871 checks if it has the respective signing key that matches the KID in 872 the AT-R. If no signing key is available then it contacts the 873 authorization server to obtain the AT-R and corresponding signing 874 keys. Note that this assumes that the authorization server is 875 online, which is only true in scenarios where granting authorization 876 dynamically is supported. 878 _______ 879 / \ 880 | Start | 881 \_______/ 882 | 883 v 884 / \ 885 / \ 886 / \ 887 / \ 888 / \ 889 ___No____/Signing Key\____ 890 | \Available? / | 891 | \ / | 892 | \ / Yes 893 | \ / | 894 | \ / v 895 v \ / +-------------+ 896 +-----------+ ^ |Transmit | 897 |Request | | |multicast | 898 |AT-R | | |mesg to group| 899 |from |------+ +-------------+ 900 |Auth Server| 901 +-----------+ 903 Figure 6: Steps to Transmit Source-authenticated Multicast Message 904 (w/o Failure Cases). 906 Note that the sender does not have to wait until it has to transmit a 907 message in order to request a AT-R; the sender is likely to be pre- 908 configured with information about which application group it belongs 909 to and can therefore pre-fetch the required information. 911 5. Security Considerations 913 5.1. Applicability statement 915 This document describes two architectures based on symmetric group 916 keys in Section 3 and asymmetric keys in Section 4. 918 The symmetric key solution is based on a group key that is shared 919 between all group members including senders and receivers. As all 920 members of the group posses the same key, it is only possible to 921 authenticate group membership for the source of a message. In 922 particular, it is not possible to authenticate the unique source of a 923 message and consequently it is not possible to authorize a single 924 node to control a group. Moreover, because the group key is shared 925 across multiple nodes, it may be easier for an attacker to determine 926 the group key by attacking any member of the group (note that this 927 group key is dynamically generated and is usually stored in volatile 928 memory which offers some addition protection). Subsequent to such an 929 attack, it is also difficult to determine which of the group members 930 was compromised and this makes it difficult to return the system to 931 normal operation after an attack. 933 The asymmetric key solution distinguishes between a sender in the 934 group and the receivers. In particular, the sender is in possession 935 of a private key and the receivers are in possession of the 936 corresponding public key. This allows the unique source of any group 937 message to be authenticated. Moreover, an attacker cannot compromise 938 the system by breaking into any of the receiving nodes. However, for 939 constrained devices, the asymmetric key solution comes at a 940 processing cost with cryptographic computations taking too long. 942 Therefore, it is recommended that whenever possible, the architecture 943 with source authentication SHOULD be used to secure all multicast 944 communication. However, in less sensitive applications (e.g. 945 controlling luminaires in non-emergency applications), the 946 architecture without source authentication MAY be used. When using 947 the symmetric key solution two mitigating factors could improve 948 system security. It is possible to achieve source authentication of 949 messages at lower layers by requiring unique MAC layer keys for all 950 devices within the network. The symmetric group keys are dynamically 951 generated and therefore SHOULD be stored in volatile memory. 953 5.2. Token Verification 955 Due to the low latency requirements, token verification needs to be 956 done locally and cannot be outsourced to other parties. For this 957 reason a self-contained token must be used and the receivers are 958 required to follow the steps outlined in Section 7.2 of RFC 7519 959 [RFC7519]. This includes the verification of the message 960 authentication code protecting the contents of the token and the 961 encryption envelope protecting the contained symmetric group key. 963 5.3. Token Revocation 965 Tokens have a specific lifetime. Setting the lifetime is a policy 966 decision that involves making a trade-off decision. Allowing a 967 longer lifetime increases the need to introduce a mechanism for token 968 revocation (e.g., a real-time signal from the KDC/Authorization 969 Server to the receivers to blacklist tokens) but lowers the 970 communication overhead during normal operation since new tokens need 971 to be obtained only from time to time. Real-time communication with 972 the receivers to revoke tokens may not be possible in all cases 973 either, particularly when off-line operation is demanded or in small 974 networks where the AS or even the KDC is only present during 975 commissioning time. 977 We therefore recommend to issue short-lived tokens for dynamic 978 scenarios like users accessing the lighting infrastructure of 979 buildings using smartphones, tablets and alike to avoid potential 980 security problems when tokens are leaked or where authorization 981 rights are revoked. For senders that are statically mounted (like 982 traditional light switches) we recommend a longer lifetime since re- 983 configurations and token leakage is less likely to happen frequently. 985 To limit the authorization rights, tokens should contain an audience 986 restriction, scoping their use to the intended receivers and to their 987 access level. 989 5.4. Time 991 Senders and receivers are not assumed to be equipped with real-time 992 clocks but these devices are still assumed to interact with a time 993 server. The lack of accurate clocks is likely to lead to clock 994 drifts and limited ability to check for replays. For those cases 995 where no time server is available, such as in small network 996 installations, token verification cannot check for expired tokens and 997 hence it might be necessary to fall-back to tokens that do not 998 expire. 1000 6. Operational Considerations 1002 6.1. Persistence of State Information 1004 Devices in the lighting system can often be powered down 1005 intentionally or unintentionally. Therefore the devices may need to 1006 store the authorization tokens and cryptographic keys (along with 1007 replay context) in persistent storage like flash. This is especially 1008 required if the authorization server is no more online because it was 1009 removed after the commissioning phase. However the decision on the 1010 data to be persistently stored is a trade-off between how soon the 1011 devices can be back online to normal operational mode and the memory 1012 wear caused due to limited program-erase cycles of flash over the 1013 15-20 years life-time of the device. 1015 The different data that may need to be stored are access tokens AT- 1016 KDC, AT-R and last seen replay counter. 1018 6.2. Provisioning in Small Networks 1020 In small networks the authorization server and the KDC may be 1021 available only temporarily during the commissioning process and are 1022 not available afterwards. 1024 6.3. Client IDs 1026 A single device should not be managed by multiple KDCs. However, a 1027 group of devices in a domain (such as a lighting installation within 1028 an enterprise) should either be managed by a single KDC or, if there 1029 are multiple KDCs serving the devices in a given domain, these KDCs 1030 MUST exchange information so that the assigned client id and 1031 application group id values are unique within the devices in that 1032 domain. We assume that only devices within a given domain 1033 communicate with each other using group messages. 1035 6.4. Application Groups vs. Security Groups 1037 Multiple application groups may use the same key for performance 1038 reasons, reducing the number of keys needed to be stored - leading to 1039 less RAM needed by each node. This is only a reasonable option if 1040 the attack surface is not increased. For example, a room A is 1041 configured to use three application groups to address a subset of the 1042 device. In addition to configuring all nodes in room A with these 1043 three application groups the nodes are configured with a special 1044 group that allows them to access all devices in room A, referred as 1045 the all-nodes-in-room-A group. In this case, having the nodes to use 1046 the same key for the all-nodes-in-room group and the three groups 1047 does not increase the attack surface since any node can already use 1048 the all-nodes-in-room-A group to control other devices in that room. 1049 The three application groups in room A are a subset of the larger 1050 all-nodes-in-room-A group. 1052 6.5. Lost/Stolen Device 1054 The following procedure MUST be implemented if a device is stolen or 1055 keys are lost. 1057 1. The AS tells the KDC to invalidate the AT-KDC. 1059 2. The KDC no longer returns a new group key if the invalidated AT- 1060 KDC is presented to it. 1062 3. The KDC generates new keys for all security groups to which the 1063 compromised device belongs. 1065 The KDC SHOULD inform all devices in the security group to update 1066 their group key. This requires the KDC to maintain a list of all 1067 devices that belong to the security group and to be able to contact 1068 them reliably. 1070 7. Acknowledgements 1072 The author would like to thank Esko Dijk for his help with this 1073 document. 1075 Parts of this document are a byproduct of the OpenAIS project, 1076 partially funded by the Horizon 2020 programme of the European 1077 Commission. It is provided "as is" and without any express or 1078 implied warranties, including, without limitation, the implied 1079 warranties of fitness for a particular purpose. The views and 1080 conclusions contained herein are those of the authors and should not 1081 be interpreted as necessarily representing the official policies or 1082 endorsements, either expressed or implied, of the OpenAIS project or 1083 the European Commission. 1085 8. IANA Considerations 1087 This document defines one CoAP Header Option Application Group ID 1088 that MUST be allocated in the Registry "CoAP Option Numbers" of 1089 [RFC6749]. IANA is requested to allocation TBD option number to 1090 application group ID in this specification. 1092 9. Contributors 1094 We would like to thank our former co-authors, Abhinav Somaraju and 1095 Sandeep Kumar for their contributions to earlier versions of the 1096 draft. 1098 10. References 1100 10.1. Normative References 1102 [I-D.ietf-ace-actors] 1103 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 1104 architecture for authorization in constrained 1105 environments", draft-ietf-ace-actors-05 (work in 1106 progress), March 2017. 1108 [I-D.ietf-ace-cbor-web-token] 1109 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1110 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-09 1111 (work in progress), October 2017. 1113 [I-D.ietf-cose-msg] 1114 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1115 draft-ietf-cose-msg-24 (work in progress), November 2016. 1117 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1118 Application Protocol (CoAP)", RFC 7252, 1119 DOI 10.17487/RFC7252, June 2014, 1120 . 1122 10.2. Informative References 1124 [I-D.ietf-oauth-pop-architecture] 1125 Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 1126 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 1127 Architecture", draft-ietf-oauth-pop-architecture-08 (work 1128 in progress), July 2016. 1130 [I-D.selander-ace-object-security] 1131 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1132 "Object Security of CoAP (OSCOAP)", draft-selander-ace- 1133 object-security-06 (work in progress), October 2016. 1135 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1136 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1137 . 1139 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1140 Framework: Bearer Token Usage", RFC 6750, 1141 DOI 10.17487/RFC6750, October 2012, 1142 . 1144 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1145 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1146 . 1148 Appendix A. Access Levels 1150 A characteristic of the lighting domain is that access control 1151 decisions are also impacted by the type of operation being performed 1152 and those categories are listed below. The following access levels 1153 are pre-defined. 1155 Level 0: Service detection only 1157 This is a service that is used with broadcast service detection 1158 methods. No operational data is accessible at this level. 1160 Level 1: Reporting only 1161 This level allows access to sensor and other (relatively 1162 uncritical) operational data and the device error status. The 1163 operation of the system cannot be influenced using this level. 1165 Level 2: Standard use 1167 This level allows access to all operational features, including 1168 access to operational parameters. This is the highest level of 1169 access that can be obtained using (secure) multicast. 1171 Level 3: Commissioning use / Parametrization Services 1173 This level gives access to certain parameters that change the day- 1174 to-day operation of the system, but does not allow structural 1175 changes. 1177 Level 4: Commissioning use / Localization and Addressing Services 1179 (including Factory Reset) This level allows access to all services 1180 and parameters including structural settings. 1182 Level 5: Software Update and related Services 1184 This level allows the change and upgrade of the software of the 1185 devices. 1187 Note: The use of group security is disallowed for level higher than 1188 Level 2 and unicast communication is used instead. 1190 Authors' Addresses 1192 Hannes Tschofenig 1193 ARM Ltd. 1194 Hall in Tirol 6060 1195 Austria 1197 Email: Hannes.tschofenig@gmx.net 1198 URI: http://www.tschofenig.priv.at 1200 Walter Werner 1201 Werner Management Services e.U. 1202 Josef-Anton-Herrburgerstr. 10 1203 Dornbirn 6850 1204 Austria 1206 Email: werner@werner-ms.at