[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 draft-tschofenig-ace-group-communication-security

ace                                                          A. Somaraju
Internet-Draft                                     Tridonic GmbH & Co KG
Intended status: Standards Track                                S. Kumar
Expires: January 7, 2016                                Philips Research
                                                           H. Tschofenig
                                                                ARM Ltd.
                                                            July 6, 2015


               Multicast Security for the Lighting Domain
                  draft-somaraju-ace-multicast-00.txt

Abstract

   Lighting systems have strict requirements on message latency and
   synchronization (typically latency less than 200 ms and jitter less
   than 50 ms).  There are several lighting use cases that require
   securing such communication between a (group of) senders and a group
   of receivers.  This draft describes initial ideas for authorization
   and key management required for the secure group communication within
   a lighting system.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Somaraju, et al.         Expires January 7, 2016                [Page 1]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Authorization Policy  . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Access Levels . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Application, multicast and security groups  . . . . . . .   4
   4.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Access Tokens . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.  Lighting Application Example  . . . . . . . . . . . . . . . .  14
     6.1.  Unicast Messages using the LWM2M Object Model . . . . . .  14
     6.2.  Multicast Communication using the LWM2M Object Model  . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     7.1.  Token Verification  . . . . . . . . . . . . . . . . . . .  19
     7.2.  Token Revocation  . . . . . . . . . . . . . . . . . . . .  19
     7.3.  Time  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  20
     8.1.  Persistence of State Information  . . . . . . . . . . . .  20
     8.2.  Provisioning in Small Networks  . . . . . . . . . . . . .  20
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     10.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   There are several lighting related use cases that require securing
   communication between a (group of) senders and a group of receivers.
   Often, a set of lighting nodes (e.g. luminaires, wall-switches,
   sensors) are grouped together into a single "Application Group".

   For such use-cases, three requirements need to be addressed:

   1.  Only authorized members of the application group must be able
       read and process messages.

   2.  Receivers of group messages must be able to verify the integrity
       of received messages as being generated within the group.






Somaraju, et al.         Expires January 7, 2016                [Page 2]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   3.  Usually, message transfer and processing must happen with low
       latency and in synchronous manner (typically latency less than
       200 ms and jitter less than 50 ms).

   This document discusses these three issues and describes initial
   ideas on how they can be addressed.

2.  Terminology

   This document uses the following terms from [I-D.gerdes-ace-actors]:
   Authorization Server, Resource Owner, Client, Resource Server.  The
   terms 'sender' and 'receiver' refer to the application layer
   messaging used for lighting control; other communication interactions
   with the supporting infrastructure uses unicast messaging.

   This document also assumes that the reader is familiar with the OMA
   Lightweight Machine-to-Machine (LWM2M) specifications [LWM2M] and the
   IPSO specification [IPSO].

3.  Authorization Policy

   When implementing an authorization policy two factors need to be
   considered:

   1.  The type of resource/service that is being offered by an end
       node, and

   2.  The group of nodes that are allowed to access a given type of
       resource.

   The type of resources in the lighting domain can be categorized into
   multiple (access) levels and these levels are described below.  For
   resources/services that belong to a category less than access level
   2, there are multiple clients that need to access the same resource/
   service with low latency.  The scope of this document is to determine
   how one can implement authorization policies for group communication
   for resources/services that belong to access level 2 and below.  We
   first introduce the different access levels and then examine the
   different types of groups that determine the authorization policy.

3.1.  Access Levels

   A characteristic of the lighting domain is that access control
   decisions are also impacted by the type of operation being performed
   and those categories are listed below.  The following access levels
   are pre-defined.

   Level 0: Service detection only



Somaraju, et al.         Expires January 7, 2016                [Page 3]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


      This is a service that is used with broadcast service detection
      methods.  No operational data is accessible at this level.

   Level 1: Reporting only

      This level allows access to sensor and other (relatively
      uncritical) operational data and the device error status.  The
      operation of the system cannot be influenced using this level.

   Level 2: Standard use

      This level allows access to all operational features, including
      access to operational parameters.  This is the highest level of
      access that can be obtained using (secure) multicast.

   Level 3: Commissioning use / Parametrization Services

      This level gives access to certain parameters that change the day-
      to-day operation of the system, but does not allow structural
      changes.

   Level 4: Commissioning use / Localization and Addressing Services

      (including Factory Reset) This level allows access to all services
      and parameters including structural settings.

   Level 5: Software Update and related Services

      This level allows the change and upgrade of the software of the
      devices.

   Note: The use of group security is disallowed for level higher than
   Level 2 and unicast communication is used instead.

3.2.  Application, multicast and security groups

   There are three types of groups that we need to consider:

   Application Group:

      A lighting application group that consists of the set of all
      lighting devices that have been configured by a commissioner to
      respond to events in a consistent manner.  For instance, a wall
      mounted switch and a set of luminaires in a single room might
      belong to a single group and the switch may be used to turn on/off
      all the luminaires in the group simultaneously with a single
      button press.  In the remainder of this document we will use GId
      to identify an application group.



Somaraju, et al.         Expires January 7, 2016                [Page 4]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   Multicast Group:

      A multicast group consists of the set of all nodes that subscribe
      to the same multicast IP address.

   Security Group:

      A security group consists of a set of sending and receiving nodes
      such that any sending node is able to securely send a message to
      all the receiving nodes.  For instance, if symmetric keys are used
      to secure such messages then every node that has access to the
      symmetric key is a part of the security group.  Every node in a
      security group can decrypt a message even if it is not addressed
      for its application group.

   Typically, the three groups might not coincide due to the memory
   constraints on the devices and also security considerations.  For
   instance, in a small room with windows, we may have three application
   groups: "room group", "luminaires close to the window group" and
   "luminaires far from the window group".  However, we may choose to
   use only one multicast group for all devices in the room and one
   security group for all the devices in the room.  At the other end of
   the spectrum, we may have an application group consisting of all the
   luminaires on a floor consisting of several smaller rooms.  In this
   case, due to security considerations we may choose to not distribute
   a single key to all the devices on the whole floor.  Therefore, the
   security group might be much smaller (e.g., one per room) and the
   application floor group is split up into smaller security groups.

   The authorization policy must ensure that all the members of a
   security group are allowed to exchange messages with each other for
   services which belong to access level less than equal to 2.  The
   services may be accessed via multicast or serial unicast messages
   between group members.  The procedure that is used to determine the
   security groups based on the availability of multicast groups and the
   requirements of the application group are out of scope of this
   document.

4.  Architecture

   Each node in a lighting application group might be a sender, a
   receiver or both sender and receiver within the group (even though in
   Figure 1 below, we show nodes that are only senders or receivers for
   clarity).  The requirement of low latency synchronous behaviour
   implies most of the communication between senders and receivers of
   lighting application messages are done using multicast IP messages.
   On some occasions, a sender in a group will be required to send
   unicast messages to unique receivers within the same group and the



Somaraju, et al.         Expires January 7, 2016                [Page 5]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   authorization procedure must also ensure security for such
   communications.  The procedure that is used to determine the security
   groups based on the availability of multicast groups and the
   requirements of the application group are out of scope of this
   document.

   Two logical entities are introduced and they have the following
   function:

   Key Distribution Center (KDC):  This logical entity is responsible
      for generating symmetric keys and distributing them to the nodes
      authorized to receive them.  The KDC ensures that nodes belonging
      to the same security group receive the same key and that the keys
      are rotated based on certain events, such as key expiry or change
      in group membership.

   Authorization Server (AS):  This logical entity stores authorization
      information about devices, meta-data about them, and their roles
      in the network.  For example, a luminare is associated with
      different groups, and may have meta-data about its location.  This
      entity may also need to perform user authentication and
      authorization since access rights may be associated to specific
      persons.  Directly or indirectly the resource owner specifies
      authorization policies that define which node is allowed to
      perform which actions.

   Note that we assume that nodes are pre-configured with device
   credentials (e.g., a certificate and the corresponding private key)
   during manufacturing.  These device credentials are used in the
   interaction with the authorization server.

   Figure 1 and Figure 2 provide an architectural overview.  The dotted
   lines illustrate the use of unicast DTLS messages for securing the
   message exchange between all involved parties.  The secured multicast
   messages between senders and receivers are indicated using lines with
   star/asterisk characters.  The security of the multicast messages can
   be achieved either at the transport level (e.g.
   [I-D.kumar-dice-multicast-security]) or at the application level with
   object security (e.g.  [I-D.selander-ace-object-security]).  The
   details on multicast security are outside the scope of this draft.

   Figure 1 illustrates the information flow between an authorization
   server and the nodes participating in the lighting network, which
   includes all nodes that exchange lighting application messages.  This
   step is typically executed during the commissioning phase for nodes
   that are fixed-mounted in buildings.  The authorization server, as a
   logical function, may in smaller deployments be included in a device
   carried by the commissioner and only be present during the



Somaraju, et al.         Expires January 7, 2016                [Page 6]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   commissioning phase.  In other use cases, employees using their
   smartphones to control lights may require an authorization server
   that dynamically executes access control decisions.

   Figure 1 shows the commissioning phase where the nodes obtain
   configuration information, which includes the AT-KDC.  The AT-KDC is
   an access token and includes authorization claims for consumption by
   the key distribution center.  We use the access token terminology
   from RFC 6749 [RFC6749] even though it is a solution-specific concept
   but familiar to many developers.  The AT-KDC in this architecture may
   be a bearer token or a proof-of-possession (PoP) token.  Note that a
   PoP token offers a fair amount of flexibility: with the use of
   symmetric key cryptography it is comparable to a Kerberos ticket and
   when used with asymmetric cryptography it can play the role of a
   certificate.  The bearer token concept is described in RFC 6750
   [RFC6750] and the PoP token concept is explained in
   [I-D.ietf-oauth-pop-architecture].  The AT-KDC is created by the
   authorization server after authenticating the requesting node and
   contains authorization relevant information.  The AT-KDC is protected
   against modifications using a digital signature or a message
   authentication code.  It is verified in Figure 2 by the KDC.






























Somaraju, et al.         Expires January 7, 2016                [Page 7]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


                 Config    +-------------+    Config
               +-----------+Authorization+------------+
               | .........>|   Server    |<.......... |
               | .  DTLS   +-------------+   DTLS   . |
               | .                ^^                . |
               | .                |.                . |
               | .                |.                . |
               v v                |.                v v
            +-----+         Config|.DTLS          +-----+
           +-----+|               |.             +-----+|
          +-----+|+               |.            +-----+|+
          |  A  |+                vv            |  C  |+
          +-----+               +-----+         +-----+
        .  E.g.                +-----+|           E.g.
           Light              +-----+|+        Luminaires
          Switches            |  B  |+
                              +-----+
                                E.g.
                              Presence
                              Sensors
   Legend:

   Config (Configuration Data): Includes configuration
   parameters, authorization information encapsulated
   inside the access token (AT-KDC) and other meta-
   data.


               Figure 1: Architecture: Commissioning Phase.

   In the simplified message exchange shown in Figure 2 a sender
   requests a security group key and the access token for use with the
   receivers (called AT-R).  The request contains information about
   resource it wants to access, such as the application group and other
   resource-specific information -- if applicable, and the previously
   obtained AT-KDC access token.  Once the sender has successfully
   obtained the requested information it starts communicating with
   receivers in that group using multicast messages.  The symmetric key
   obtained from the KDC is used to secure the multicast messages for
   the security group.  The AT-R is used to attached to the initial
   request to authorize the request.  The receivers on their side need
   to perform two steps, namely the receivers themselves need to obtain
   the necessary group key to verify the incoming messages and they also
   need information about what resource the sender is authorized to
   access.  Both information can be found in the AT-R access token.

   Multicast messages need to be protected such that replay and
   modification can be detected.  The integrity of the message is



Somaraju, et al.         Expires January 7, 2016                [Page 8]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   protected using a group key.  The use of symmetric keys is envisioned
   here due to latency requirements and the access level level concept
   is described in Section 3.1.  For secure unicast messaging between
   lighting application group members and the AS or KDC, a topic outside
   the scope of this document, the sender is assumed to use the DTLS
   handshake to establish the necessary security context for securing
   subsequent message interactions.


             Request
             +AT-KDC    +------------+
          +------------>|    Key     |
          |+------------|Distribution|
          ||Reply       |   Center   |
          ||+AT-R       +------------+
          ||+Group    ..^
          || Key    ..
          ||     ...DTLS
          |v    ..
        +-----+<.                              +-----+
       +-----+|                               +-----+|
      +-----+|+   Secure Multicast Msg       +-----+|+
      |  A  |+*****************************> |  B  |+
      +-----+                                +-----+
      Sender(s)                            Receiver(s)
   e.g. Light Switch                    e.g. Luminaries


           Figure 2: Architecture: Group Key Distribution Phase.

   Figure 3 describes the algorithm for obtaining the necessary
   credentials to transmit a secure multicast message based on the
   architectural description shown in Figure 1 and Figure 2.  When
   sender wants to send a message to the application group, it checks if
   it has the group key.  If no group key is available then it checks if
   it has an access token for use with the KDC (AT-KDC).  If no AT-KDC
   is found in the cache then it contacts the authorization server to
   obtain an access token.  Note that this assumes that the
   authorization server is online, which is only true in scenarios where
   granting authorization dynamically is supported.  In the other case
   where the AT-KDC is already available the sender contacts the KDC to
   obtain a group key.  If a group key is already available then the
   sender can transmit a message secured to the group immediately.








Somaraju, et al.         Expires January 7, 2016                [Page 9]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


                                     _______
                                    /       \
                                    | Start |
                                    \_______/
                                        |
                                        v
                                       /\
                                      /  \
                                     /    \
                                    /      \
                                   /        \
                         ___No____/Group Key \____
                        |         \Available?/    |
                        |          \        /     |
                        v           \      /     Yes
                       /\            \    /       |
                      /  \            \  /        v
                     /    \            \/   +-------------+
                    /      \            ^   |Transmit     |
                   /        \           |   |multicast    |
              ____/  AT+KDC  \__        |   |mesg to group|
             |    \Available?/  |       |   +-------------+
             |     \        /   |       |
            No      \      /   Yes      |
             |       \    /     |       |
             |        \  /      |       |
             v         \/       v       |
       +-----+-----+   ^  +----------+  |
       |Request    |   |  |Request   |  |
       |AT-KDC     |   |  |Group Key |  |
       |from       |---+  |from KDC  |--+
       |Auth Server|      |          |
       +-----------+      +----------+


    Figure 3: Steps to Transmit Multicast Message (w/o Failure Cases).

   Note that the sender does not have to wait until it has to transmit a
   message in order to request a group key; the sender is likely to be
   pre-configured with information about which lighting application
   group it belongs to and can therefore pre-fetch the required
   information.

   Group keys have a lifetime, which is configuration dependent, but
   mechanisms need to be provided to update the group keys either via
   the sender asking for a group key renewal or via the KDC pushing new
   keys to senders and receivers.  The lifetime can be based on time or
   on the number of transmitted messages.



Somaraju, et al.         Expires January 7, 2016               [Page 10]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


5.  Access Tokens

   Section 4 describes the architecture and makes use of access tokens,
   which is a generic concept to pass capabilities between entities in a
   distributed system.  To improve interoperability a token format needs
   to be standardized and this section outlines the use of an existing
   format based on the JSON Web Token (JWT).  These access tokens come
   in two flavors, namely as bearer tokens but also as proof-of-
   possession tokens.  The main difference between the two is that
   bearer tokens are not associated with a key while proof-of-possession
   (PoP) tokens are.  For a more detailed description of the security
   benefits of PoP tokens and the differences to bearer tokens please
   consult [I-D.ietf-oauth-pop-architecture].  In Section 1 we assume
   that the AT-KDC is a bearer token and the AT-R is a PoP token.

   In this section we provide more details of the access token concept.
   The capabilities, called claims in the JWT jargon, are included
   inside the token and, in this example, state that the granted access
   level is 2 and access to the application group 2 is allowed by the
   sender.  Most of the description focuses on the use of PoP tokens
   since they are more complex than bearer tokens.  For the use with
   multicast security we envision the PoP token to contain a symmetric
   key encapsulated inside the JSON Web Key (JWK).

   While JSON is a compact encoding format, standardization work is
   ongoing to define an even more efficient format for conveying the
   same information using a binary format (using CBOR as defined in RFC
   7049 [RFC7049]).  The corresponding security protection is currently
   being defined in the IETF COSE working group [COSE].

   The content of a JSON Web Token (JWT) is protected using a JSON Web
   Signature (JWS).  The JWS applies a message authentication code (MAC)
   to protect against forgery.  The actual MAC computation (and the
   result) is omitted in this example.  (Note that deployments may
   choose to use a digital signature to protect the JWT.  While the JWT
   access token offers this flexiblity we assume symmetric keys in our
   example.

   The JWT body is protected using the JWS.  The JWS wraps around the
   body with a header and the actual message authentication code, which
   is not shown below.










Somaraju, et al.         Expires January 7, 2016               [Page 11]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   JWS Header:

       {"alg":"HS256",
        "kid":"123"
       }

   Legend for JWS Header:
   - alg: Algorithm parameter indicating the type of cryptographic
          algorithm used to protect the structure. In this case
          HMAC-SHA 256 is used.
   - kid: Key Identifier used to select the appropriate key.


   The JWT body contains various claims and we included several of them
   in our example below.  The most interesting one is the (not-yet-
   defined) scope (scp) claim offering information about the
   capabilities.  In this example the scope ('scp') claim carries
   permissions described in Section 6.  The included capabilities will
   depend on the type of token, namely AT-R vs. AT-KDC, and of course on
   the specific deployment environment.


 JWT Body:
    {
       "iss": "coaps://as.example.com",
       "exp": "1361398824",
       "scp": ["l2,g0,IP_M_R1", "l2,g1,IP_M_R1","l2,g2,IP_M_R1"],
       "cnf":{
         "jwe":
           "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5Ijoi
            andrK2pzb24ifQ. ... (remainder of JWE omitted for brevity)"
         }
      }

 Legend for JWT Body:
 - iss: Issuer (which is the entity creating the access token). The
        content does not need to be a URI but can also be a string
        identifying the entity issuing the token.
 - exp: Expiry date of the access token. Claim can be omitted if
        tokens do not expire (for example, in a small enterprise
        environment).
 - scp: Scope denoting the capabilities of the token
 - cnf: Key confirmation element containing an encrypted JSON Web
        Key. The encryption being applied uses JSON Web
        Encryption (JWE).






Somaraju, et al.         Expires January 7, 2016               [Page 12]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   The content from here onward is only relevant to the AT-R, which is
   assumed to be a PoP token.  Note that a bearer token would not
   contain the key confirmation claim shown in the JWT body since there
   is no embedded key.

   Figure 4 shows the structure of the PoP token graphically:


   +-------------------------------+
   |JWS Header                     |
   +-------------------------------+
   +-------------------------------+
   |                               |
   | JWT Body                      |
   |              +------------+   |
   |  - iss       | JWE        |   |
   |  - cnf ----->|  +--------+|   |
   |  - exp       |  | JWK    ||   |
   |  - scp       |  +--------+|   |
   |  - ...       +------------+   |
   |                               |
   +-------------------------------+
   +-------------------------------+
   |JWS MAC/Signature              |
   +-------------------------------+


                      Figure 4: PoP Token Structure.

   The JSON Web Encryption (JWE) contains a header followed by the
   content that is encrypted.  Details about the JWE usage relevant for
   this example can be found in Appendix A.3 of RFC 7516 [RFC7516].


   JWE Header:

   {"alg":"A128KW",
    "enc":
    "A128CBC-HS256"
   }

   Legend for JWE Header:
   - alg: Algorithm parameter indicating the AES 128 Key Wrap algorithm
          being used for encrypting the included key and the
          AES_128_CBC_HMAC_SHA_256 algorithm is used for authenticated
          encryption.





Somaraju, et al.         Expires January 7, 2016               [Page 13]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


JWK to be encrypted by JWE:

 {"kty":"oct",
  "k":"GawgguFyGrWKav7AX4VKUg"
 }

Legend for the JWK to be encrypted:
- kty: Key type identifies the cryptographic algorithm family used with
       the key. In this example the JWK contains a symmetric key denoted
       as "oct" for octet sequence.
- k: Key parameter containing the actual key.


6.  Lighting Application Example

   In this Section, we look at a typical lighting application in which
   presence sensor(s) are used to actuate a group of light points via a
   control function based on a pre-specified set of rules.  The
   CoAP/LWMM2M/IPSO protocol stack can be used as a foundation for the
   design of a lighting system.  The architecture identifies three
   functions present in a lighting system:

   o  Sensor functions which detect a (physical) phenomenon like a light
      sensor, a presence detector or a push button.

   o  Actuator functions which cause action or change like setting a
      driver value of a light source.

   o  Control functions which link the inputs (from sensor functions) to
      outputs (from actuator functions) and enforce specific behaviour.

   In typical applications, a sensor output might be used by multiple
   control functions and a single control function might control many
   actuators and a single actuator may be controlled by multiple control
   functions.  Moreover, different functions (e.g. control and actuator)
   might be collocated on a single device.  In the example below, we
   show one method that may be used to implement the above architecture
   using the LWM2M object model.  We begin with the case of unicast
   communication (because the LWM2M model does not directly support
   multicast communication).  We then explain a possible way to extend
   to the multicast situation.

6.1.  Unicast Messages using the LWM2M Object Model

   The unicast scenario considers a deployment with a single (physical)
   presence sensor, a single (physical) luminaire and the desired
   control functionality is the following: dim the luminaire to 90% when
   presence is detected in the room and dim the luminaire to 10% when



Somaraju, et al.         Expires January 7, 2016               [Page 14]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   there is no presence.  In this situation, the sensor functionality is
   implemented on the presence sensor, the actuator functionality is
   implemented on the luminaire and the control functionality could be
   implemented on the presence sensor or the luminaire or on an
   independent physical control device.

   Using the LWM2M object model,

   o  the presence sensor function is implemented using the IPSO
      Presence object with Object ID 3302 [1].

   o  the actuator control function is implemented using the IPSO Light
      control object with Object ID 3311 [1].

   o  the control function is implemented by a LWM2M server to which the
      two LWM2M clients on the luminaire and presence sensor register.

   The IPSO Light Control Object supports the "Dimmer" resource (Res ID
   5851) which may be written to in order to change the light intensity
   output.  The IPSO Presence Object supports the "Digital Input State"
   resource (Res ID 5500) which is a boolean readable resource that
   reflects the current state of the presence sensor.  A method to
   implement the control functionality is the following:

   1.  The luminaire and the presence sensor register their objects with
       the control LWM2M server.  This registration step happens during
       commissioning phase, when the device reboots or whenever IP
       addresses change.

   2.  The control LWM2M server observes the "Digital Input State" of
       the presence sensor.

   3.  When the presence sensor state changes, the sensor notifies the
       control LWM2M server.

   4.  The control LWM2M server writes the correct output intensity to
       the "Dimmer" resource to change the luminaire light output.

   This sequence of messages is shown in Figure 5.  Here, [IP_C], [IP_L]
   and [IP_S] are the unicast IP addresses of the devices that implement
   the control function, light control object and sensor object,
   respectively.









Somaraju, et al.         Expires January 7, 2016               [Page 15]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   +---------------+    +--------------+     +--------------+
   |Presence Sensor|    | Control Unit |     |  Luminaire   |
   |(LWM2M client) |    |(LWM2M server)|     |(LWM2M client)|
   +---------------+    +--------------+     +--------------+
          |                     |                      |
          |  [IP_C]Register     |    [IP_C]Register    |
          |-------------------->|<---------------------|
          |     </3302/0>       |      </3311/0>       |
          |                     |                      |
          |  [IP_S]2.01 Created | [IP_L]2.01 Created   |
          |<--------------------|--------------------->|
          |                     |                      |
          |[IP_S]GET            |                      |
          |<--------------------|                      |
          |    /3302/0/5500 Obs.|                      |
          |                     |                      |
          |[IP_C]2.05 Content   |                      |
          |-------------------->|[IP_L]PUT /3311/0/5851|
          |     Obs. FALSE      |--------------------->|
          |                     |         10           |
          |   [IP_C]Notify      |                      |
          |-------------------->|[IP_L]PUT /3311/0/5851|
          |      TRUE           |--------------------->|
          |                     |         90           |
          |   [IP_C]Notify      |                      |
          |-------------------->|[IP_L]PUT /3311/0/5851|
          |       FALSE         |--------------------->|
          |                     |         10           |

      Figure 5: Unicast messaging between control unit and luminaire.

6.2.  Multicast Communication using the LWM2M Object Model

   We now see how the above unicast model may be extended to the group
   communication case and explain the security implications of the group
   communication case.  Let us now look at a typical lighting
   application that requires group communication: 1) A set of rooms are
   attached to a single corridor; 2) Each room consists of 8 luminaires
   with 4 luminaires close to a window and four luminaires close to a
   wall; 3) Every room has a presence sensor and the corridor also has a
   presence sensor. 4) Every room has an individual control function
   that maybe implemented on the room presence sensor device, one of the
   luminaries or an independent control device.

   The control functionality we wish to implement is the following:

   o  If presence is detected in the room, then dim-up the wall
      luminaires to 90% and window luminaires to 50%.



Somaraju, et al.         Expires January 7, 2016               [Page 16]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   o  If no presence is detected in the room or corridor, then turn off
      all luminaires.

   o  If no presence is detected in the room but presence is detected in
      the corridor, then turn all the luminaires to 10% (for all rooms
      attached to corridor).

   For multicast communication, we can not use the LWM2M model directly.
   However, we can make the following assumptions:

   o  All luminaires are CoAP servers whose resource tree supports the
      IPSO Light Control object.

   o  All presence sensors are CoAP servers whose resource tree supports
      the IPSO Presence Object.

   o  The control function is implemented using a CoAP client.

   o  All devices in the nth room subscribe to the multicast address
      [IP_M_Rn] and the device that implements the control function in
      this room has unicast address [IP_Cn].

   o  Every room has three application groups and only one security
      group.  The application groups are: "room group" (GId = 0),
      "window group" (GId = 1), "wall group" (GId = 2).  The security
      group is defined by the symmetric key that is shared with the
      members.

   o  The GId is carried as a CoAP header (query?) option.


+--------------+
|  Luminaire   |
|(CoAP Server) |
+--------------+
 ||| +---------------+       +---------------+
 ||| |Presence Sensor|       |Presense Sensor|          +--------------+
 ||| |Corridor       |       |Room           |          | Control Unit||
 ||| |(CoAP Server)  |       |(CoAP Server)  |          | (CoAP Client)|
 ||| +---------------+       +---------------+          +--------------+
 |||        |                         |                             |||
 |||        |            [IP_SC]GET /3302/0/5500 Obs.               |||
 |||        |<------------------------------------------------------|||
 |||        |                         |                             |||
 |||        |              [IP_C1] 2.05 Content Obs.                |||
 |||        |------------------------------------------------------>|||
 |||        |                       FALSE                           |||
 |||        |                         |                             |||



Somaraju, et al.         Expires January 7, 2016               [Page 17]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


 |||        |                         |[IP_SR]GET /3302/0/5500 Obs. |||
 |||        |                         |<----------------------------|||
 |||        |                         |                             |||
 |||        |                         |  [IP_C1] 2.05 Content Obs.  |||
 |||        |                         |---------------------------->|||
 |||        |                         |           FALSE             |||
 |||        |                         |                             |||
 |||        |                         |                             |||
 |||        |                  [IP_C1] Notify                       |||
 |||        |------------------------------------------------------>|||
 |||        |                       TRUE                            |||
 |||        |                         |                             |||
 |||        |       [IP_M_R1]PUT /3311/0/5851 ?gp=0                 |||
 |||<---------------------------------------------------------------+||
 |||        |                     10  |                             |||
 |||        |                         |                             |||
 |||        |                         |      [IP_C1] Notify         |||
 |||        |                         |---------------------------->|||
 |||        |                         |            TRUE             |||
 |||        |                         |                             |||
 |||        |       [IP_M_R1]PUT /3311/0/5851 ?gp=1                 |||
 |||<---------------------------------------------------------------|||
 |||        |                     50  |                             |||
 |||        |                         |                             |||
 |||        |       [IP_M_R1]PUT /3311/0/5851 ?gp=2                 |||
 |||<-------------------------------------------------------------->|||
 |||        |                     90  |                             |||
 |||        |                         |                             |||
 |||        |                         |                             |||



    Figure 6: Multicast messaging between control unit and luminaires.

   Figure 6 shows a typical sequence of messages that occur.  For,
   simplicity, we only show the messages exchanged with the control
   function in room 1 and luminaires in room 1 though the same exchange
   of messages applies to every room.  Initially, the control function
   in every room observes resource 5500 on the presence sensor in the
   corridor and also the presence sensor in it's own room.  When the
   presence state changes in the corridor, the corridor notifies the
   control function in every room using a sequence of unicast
   notification messages.  Once a controller in the room receives this
   notification, it sends out a multicast message to all luminaires in
   the group (GId = 0).  If presence is then detected in the room, then
   the room controller is notified and the room controller sends a
   multicast message to the window group (GId = 1) to dim-up to 50% and
   wall group (GID = 2) to dim-up to 90%. Note the separation of the two



Somaraju, et al.         Expires January 7, 2016               [Page 18]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   types of sensors in this problem: The presence sensor in a room is a
   part of the room group and therefore will receive the room group key
   which allows it to directly talk to the luminaires in the room to
   which the sensor belongs.  However, the corridor presence sensor is
   not a part of the room group and does not receive the room group key.
   The corridor presence sensor must only authorized to communicate with
   the room control function which then controls the luminaires.

   In this Example, there are three application groups per room and one
   multicast group per room.  There are two types of security groups:
   one security group per room and a security group that has the
   corridor presence sensor and all the control units attached to the
   corridor.  Therefore, the control unit in room 1 requires access
   tokens with the following scope, "l2,g0,IP_M_R1", "l2,g1,IP_M_R1",
   "l2,g2,IP_M_R1" for room control and also "l2,g0,IP_SC" for corridor
   presence sensor.  The KDC generates 2 keys - KeyRoom1 and KeyCor that
   need to be delivered to the control unit in room 1: KeyRoom1 is used
   to communicate with the room luminaire group for all three
   application groups - g0, g1, g2 and KeyCor is used to communicate
   with the corridor presence sensor.

7.  Security Considerations

7.1.  Token Verification

   Due to the low latency requirements, token verification needs to be
   done locally and cannot be outsourced to other parties.  For this
   reason self-contained token must be used and the receivers are
   required to follow the steps outlined in Section 7.2 of RFC 7519
   [RFC7519].  This includes the verification of the message
   authentication code protecting the contents of the token and the
   encryption envelope protecting the contained symmetric group key.

7.2.  Token Revocation

   Tokens have a specific lifetime.  Setting the lifetime is a policy
   decision that involves making a trade-off decision.  Allowing a
   longer lifetime increases the need to introduce a mechanism for token
   revocation (e.g., a real-time signal from the KDC/Authorization
   Server to the receivers to blacklist tokens) but lowers the
   communication overhead during normal operation since new tokens need
   to be obtained only from time to time.  Real-time communication with
   the receivers to revoke tokens may not be possible in all cases
   either, particularly when off-line operation is demanded or in small
   networks where the AS or even the KDC is only present during
   commissioning time.





Somaraju, et al.         Expires January 7, 2016               [Page 19]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   We therefore recommend to issue short-lived tokens for for dynamic
   scenarios like users accessing the lighting infrastructure of
   buildings using smartphones, tablets and alike to avoid potential
   security problems when tokens are leaked or where authorization
   rights are revoked.  For senders that are statically mounted (like
   traditional light switches) we recommend a longer lifetime since re-
   configurations and token leakage is less likely to happen frequently.

   To limit the authorization rights tokens should contain an audience
   restriction, scoping their use to the intended receivers and to their
   access level.

7.3.  Time

   Senders and receivers are not assumed to be equipped with real-time
   clocks but these devices are still assumed to interact with a time
   server.  The lack of accurate clocks is likely to lead to clock
   drifts and limited ability to check for replays.  For those cases
   where no time server is available, such as in small network
   installations, token verification cannot check for expired tokens and
   hence it might be necessary to fall-back to tokens that do not
   expire.

8.  Operational Considerations

8.1.  Persistence of State Information

   Devices in the lighting system can often be powered down
   intentionally or unintentionally.  Therefore the devices may need to
   store the authorization tokens and cryptographic keys (along with
   replay context) in persistence storage like flash.  This is
   especially required if the authorization server is no more online
   since it was removed after the commissioning phase.  However the
   decision on the data to be persistently stored is a trade-off between
   how soon the devices can be back online to normal operational mode
   and the memory wear caused due to limited program-erase cycles of
   flash over 15-20 years life-time of the device.

   The different data that may need to be stored are access tokens AT-
   KDC, AT-R and last seen replay counter.

8.2.  Provisioning in Small Networks

   In small networks the authorization server and the KDC may be
   available only temporarily during the commissioning process and are
   not available afterwards.





Somaraju, et al.         Expires January 7, 2016               [Page 20]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


9.  Acknowledgements

   The author would like to thank Walter Werner and Esko Dijk for his
   help with this document.

10.  References

10.1.  Normative References

   [I-D.gerdes-ace-actors]
              Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
              architecture for authorization in constrained
              environments", draft-gerdes-ace-actors-05 (work in
              progress), April 2015.

   [IPSO]     IPSO Alliance, "IPSO Smart Object Guidelines - Starter
              Pack 1.0", 2015.

   [LWM2M]    Open Mobile Alliance, "Lightweight Machine-to-Machine,
              Technical Specification, Candidate Version 1.0", December
              2013.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, May 2015.

10.2.  Informative References

   [COSE]     IETF, "CBOR Object Signing and Encryption (cose) Working
              Group", https://datatracker.ietf.org/wg/cose/charter/,
              2015.

   [I-D.ietf-oauth-pop-architecture]
              Hunt, P., Richer, J., Mills, W., Mishra, P., and H.
              Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
              Architecture", draft-ietf-oauth-pop-architecture-01 (work
              in progress), March 2015.

   [I-D.kumar-dice-multicast-security]
              Kumar, S. and R. Struik, "Transport-layer Multicast
              Security for Low-Power and Lossy Networks (LLNs)", draft-
              kumar-dice-multicast-security-00 (work in progress), March
              2015.

   [I-D.selander-ace-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "June 29, 2015", draft-selander-ace-object-security-02
              (work in progress), June 2015.




Somaraju, et al.         Expires January 7, 2016               [Page 21]


Internet-Draft Multicast Security for the Lighting Domain      July 2015


   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
              6749, October 2012.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750, October 2012.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, October 2013.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, May 2015.

Authors' Addresses

   Abhinav Somaraju
   Tridonic GmbH & Co KG
   Farbergasse 15
   Dornbirn   6850
   Austria

   Email: abhinav.somaraju@tridonic.com


   Sandeep S. Kumar
   Philips Research
   High Tech Campus 34
   Eindhoven  5656 AE
   NL

   Email: ietf.author@sandeep-kumar.org


   Hannes Tschofenig
   ARM Ltd.
   110 Fulbourn Rd
   Cambridge  CB1 9NJ
   Great Britain

   Email: Hannes.tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at











Somaraju, et al.         Expires January 7, 2016               [Page 22]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/