INTERNET-DRAFT A. Dvir Intended Status: Experimental T. Holczer Expires: June 25, 2011 L. Dora L. Buttyan January 14, 2011 Abstract Low power and Lossy Networks (LLNs) are a class of networks in which both the routers and their interconnects are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). LLN router supported traffic flows include point-to-point, point-to-multipoint, and multipoint-to- point. The IPv6 Routing Protocol for LLNs (RPL) provides the mechanisms to support those traffic flows. The currently available security services in RPL will not protect against a compromised internal node that can also construct and disseminate fake messages. In this document, a service is described that prevents an internal attacker from impersonating a Destination Oriented Directed Acyclic Graph (DODAG) root. Moreover, the establishment and maintenance of any cryptographic key is out of the scope of the current RPL proposal. In this document a service that allows nodes to agree on local keys with their neighborhood is also presented. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at Dvir, et al. June 25, 2011 [Page 1] INTERNET DRAFT Extension of Security Services January 14, 2011 http://www.ietf.org/shadow.html. Copyright and License Notice Copyright (c) 2011 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 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. Dvir, et al. June 25, 2011 [Page 2] INTERNET DRAFT Extension of Security Services January 14, 2011 Table of Contents 1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Security Services . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 DIO Message Authentication . . . . . . . . . . . . . . . . 5 3.1.1 Sequence Diagram . . . . . . . . . . . . . . . . . . 10 3.2 Local Key Agreement . . . . . . . . . . . . . . . . . . . 13 3.2.1 Pairwise Shared Key . . . . . . . . . . . . . . . . 13 3.2.1.1 Message Design Considerations List . . . . . . 16 3.2.1.2 Message Exchange Schemes . . . . . . . . . . . 16 3.2.1.3 Design Consideration vs. Message Exchange Scheme . . . . . . . . . . . . . . . . . . . . 18 3.2.2 Cluster Key . . . . . . . . . . . . . . . . . . . . 20 4 Security Considerations . . . . . . . . . . . . . . . . . . . 21 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.1 RPL Control Message Option . . . . . . . . . . . . . . . 22 5.2 New Registry for the Hash Value Type . . . . . . . . . . 22 5.3 New Registry for the Security Algorithm Type . . . . . . 23 5.4 New Registry for the Comp Algo Type . . . . . . . . . . . 24 5.5 New Registry for the MAC Function Type . . . . . . . . . 25 5.6 New Registry for the ENC Function . . . . . . . . . . . . 26 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1 Normative References . . . . . . . . . . . . . . . . . . 26 7.2 Informative References . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Dvir, et al. June 25, 2011 [Page 3] INTERNET DRAFT Extension of Security Services January 14, 2011 1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document adopts and conforms to the terminology defined in [I-D.ietf-roll-terminology] and in [RFC4949]. In this document, 'compromised' refers to taking control over a node. 'Potential DODAG roots' are grounded DODAG roots and a small set of capable nodes that could become floating DODAG roots. 'Data authenticity' is the assurance about the source of transmitted information (and, hereby, that information was not modified in transit). As they form networks, LLN devices often mix the roles of 'host' and 'router' when compared to traditional IP networks. In this document, 'host' refers to an LLN device that can generate but does not forward RPL [I-D.ietf-roll-rpl] traffic, 'router' refers to an LLN device that can forward as well as generate RPL traffic, and 'node' refers to any RPL device, either a host or a router. 2 Introduction Low power and Lossy Networks (LLNs) consist largely of constrained nodes with limited processing power, memory, and sometimes energy, when they are battery operated. These routers are interconnected by unstable lossy links, typically supporting only low packet and data delivery rates. Another characteristic of such networks is that point-to-point is not the typical traffic pattern, but point-to- multipoint or multipoint-to-point are. Furthermore, such networks may potentially comprise up to thousands of nodes. These characteristics offer unique challenges to a routing solution. The IETF ROLL Working Group has defined application-specific routing requirements for a Low power and Lossy Network (LLN) routing protocol, specified in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. Moreover, based on those standards, an IPv6 Routing Protocol for Low power and Lossy Networks (RPL) has been proposed [I-D.ietf-roll-rpl] and a security framework for RPL is described in [I-D-roll-security-framework]. Many LLN systems are deployed in unattended or remote locations, such as urban environments [RFC5548]. Hence, security mechanisms that provide confidentiality and authentication are critical for the operation of many applications. The currently available security services in RPL proposed in [I-D.ietf-roll-rpl] will not protect Dvir, et al. June 25, 2011 [Page 4] INTERNET DRAFT Extension of Security Services January 14, 2011 against a compromised internal node that can also construct and disseminate fake messages. Moreover, the establishment and maintenance of any cryptographic key is out of the scope of the current RPL proposal [I-D.ietf-roll-rpl]. Therefore, this document presents two new security services for RPL: o DIO Message Broadcast Authentication - secures the network from misbehaving nodes to become a DODAG root and to increase the Version Number. o Local Key Agreement - allows each node to agree on local keys with its neighborhood. The implementation of the security services described in this document are OPTIONAL. A given implementation MAY support a subset (including the empty set) of the described security services; for example, the implementation could support Local Key Agreement, but not DIO Message Authentication. An implementer SHOULD clearly specify which security services are supported, and it is RECOMMENDED that implementers carefully consider security requirements and the availability of security mechanisms in their network. 3 Security Services This section describes two protocols; the first enables nodes to authenticate DIO Messages. The second protocol enables nodes to a) agree on a pairwise key, with each of its neighbors; and b) generate and disseminate a cluster key, a shared key between a node and all of its neighbors. The hash functions, MAC functions, and the digital signatures used in the protocols are based on sections 10.1 and 10.9.2 of [I-D.ietf-roll-rpl], e. g., SHA-256 hash function specified in Section 6.2 of [FIPS180], message encoding rules of Section 8.1 of [RFC3447]. The elliptic curve cryptography (ECC) used in section 3.1 is based on section 2.7 of [SECG2]. The Counter with CBC-MAC (CCM) used in section 3.2, is described in [RFC3610]. Note that although [RFC3610] disallows the CCM mode with M=0, RPL explicitly allows the CCM mode with M=0 when used in conjunction with a signature, because the signature provides sufficient data authentication. Here, the CCM mode with M=0 is specified as in [RFC3610], but where the M field in Section 2.2 of [RFC3610] MUST be set to 0. The Hashed Message Authentication Mode (HMAC) in the protocols is described in [RFC4868]. 3.1 DIO Message Authentication A grounded DODAG offers connectivity to hosts that are required to satisfy the application-defined goal. An attacker may try to become a DODAG root by sending a well-constructed DIO message where the Dvir, et al. June 25, 2011 [Page 5] INTERNET DRAFT Extension of Security Services January 14, 2011 grounded flag is set. The scope of the current RPL security services is the link; therefore, the authenticity of the messages sent by the DODAG root relies on the trustworthiness of all intermediate nodes and the fact that none of the keys are compromised. Any key that is compromised allows an attacker to send an authentic DIO message that will be accepted by all the nodes. Therefore, a node that received the DIO message from the attacker will multicast to its neighbors the DIO message using uncompromised keys. The content of the message from the attacker will affect other nodes participating in the DODAG. RPL [I-D.ietf-roll-rpl] allows the Version Number to be increased regularly or occasionally. Moreover, the whole network can be reconstructed by sending a DIO message with an increased Version Number. Therefore, preventing any misbehaving node from impersonating the actual DODAG root by increasing the Version Number is essential. In particular, only those parts of the DIO message that do not need to be updated when the nodes forward the DIO message can be protected. The static fields are the following: o DIO Base Object: o RPLInstanceID o G|A|T|MOP|Prf o DODAGID o Version o Routing Information (option) o DODAG Configuration (option) By authenticating the DIO message, each node can securely forward the DIO message in order to bootstrap or update the DODAG. The Authentication procedure starts/updates from a DODAG root toward the nodes as follows: 1. The DODAG root first generates a random number r. 2. The DODAG root calculates h(h...(h(h(r)))), also denoted by h^n(r), where h() is a hash function and n is the length of the chain. This value is called the hash chain root [L1981]. 3. The DODAG root authenticates the h^n(r) value as well as the static fields using any supported integrity protection Dvir, et al. June 25, 2011 [Page 6] INTERNET DRAFT Extension of Security Services January 14, 2011 algorithm (e. g., digital signature or a MAC function). 4. The DODAG root sends a DIO message with the authenticated value. 5. Each node receiving a DIO message verifies the authenticity of the static fields of the message. 6. If the message is authentic, the node saves the Version Number value (init or update value), the hash chain value (root or current chain value), and the integrity protection data (MAC value or signature) for future use, and multicast to all neighbors the DIO message after updating the fields as described in section 6.3.1. of [I-D.ietf-roll-rpl]. 7. If the message is not authentic, the receiver MUST ignore the message. In case the implementer decides to authenticate the hash chain root with an integrity protection mechanism, steps 1-7 MUST be implemented. If not, only steps 1-2 MUST be implemented. When digital signature is used, each node has to know the public signature verification key. When symmetric keys are used, all nodes must have a preshared key K. In order to minimize the computation time and memory usage of the hash chain, the implementer can use the technique in [OptHash] on the DODAG root side. When the DODAG root increases the Version Number (by k from the initial Version Number value), the DODAG root reveals the value of h^(n-k)(r) and inserts this value in the DIO message with Broadcast Authentication Option. When node v receives the DIO message it can easily verify the message because, if the Version Number is increased by the DODAG root, h^k(h^(n-k)(r)) must be equal to h^n(r). For an attacker, computing the previous element h^(i-1)(r) knowing h^i(r) is hard when r is not known and h() is a cryptographic one-way function. In order to authenticate the static fields of a DIO message and the Version Number, a DIO MUST carry one or more "Broadcast Authentication" options. A Broadcast Authentication option consists of the following fields: Dvir, et al. June 25, 2011 [Page 7] INTERNET DRAFT Extension of Security Services January 14, 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=10 | Option Length |C| H |Resvd | Security Alg | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | : Authentication Data : | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the Broadcast Authentication Option Option Type: 0x0A (to be confirmed by IANA) Option Length: 8-bit unsigned integer, variable length of the option in octets excluding the Type and Length fields. C: Continues bit, the C bit is set whenever the signature/Hash/MAC output has length greater than maximum option data length; the receiver needs to merge it with the other Broadcast Authentication Options with the same H type until the C bit is unset. H: 2-bit field, indicating which part of the hash chain is in the Authentication data field. +----------+---------------------------+ |Bit Number| Hash Value Type | +----------+---------------------------+ | 0 | No Hash Value | | | | | 1 | Hash Root Chain Value | | | | | 2 | Current Hash Chain Value| | | | | 3 | Unassigned | | | | +----------+---------------------------+ Figure 2: Hash Value Type Resvd: 5-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Dvir, et al. June 25, 2011 [Page 8] INTERNET DRAFT Extension of Security Services January 14, 2011 Security Algorithm: The Security Algorithm field specifies the encryption, MAC, and signature scheme used by the network. The high order bit (0x80) of the code denotes whether Integrity Protection has been enabled. The second high order bit (0xC0) of the code denotes whether the Integrity Protection is using symmetric or asymmetric key algorithms. Supported values of this field are as follows: +----------+--------------------------+ |Bit Number| Security Algorithm | +----------+--------------------------+ | 0x00 | No Security Algorithm | | | | | 0x01 | SHA-256 | | | | | 0x02 | SHA-512 | | | | | 0x80 | HMAC-SHA-256 | | | | | 0x81 | HMAC-SHA-512 | | | | | 0xC0 | RSA with SHA-256 | | | | | 0xC1 |ECC-SECP256K1 with SHA-256| | | | | else | Unassigned | +----------+--------------------------+ Figure 3: Security Algorithm Authentication Data: Contains the authentication data compatible with the Hash and Protection Type fields. Unassigned bits of the Broadcast Authentication option are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. Dvir, et al. June 25, 2011 [Page 9] INTERNET DRAFT Extension of Security Services January 14, 2011 3.1.1 Sequence Diagram The sequence diagram of the DIO Message Authentication has three parts: authentication procedure, Version Number update, and, admission of a new node in the DODAG. Root Node v Node u New Node | VN=n, HR, IP | | | |-------------->M#1| | | | | VN=n, HR, IP | | | |----------->M#2| | | | | | : : : : | | | | | VN=n+i, CH | | | |-------------->M#3| VN=n+i, CH | | | |----------->M#4| | | | | | : : : : | | | | | | | Unicast DIS | | | |M#5<------------------| | | | | | | |VN=n+i, n, HR, CH, IP | | | |------------------>M#6| | | | | Figure 4: Sequence Diagram of DIO Message Authentication M - Message VN - Version Number n - Initial value of the Version Number HR - Hash root chain value CH - Node chain value IP - Integrity protection Messages #1 and #2 refer to the authentication procedure. The DIO messages (messages #1 and #2) consist of the following Broadcast Authentication Options (the format of the option is described in Figure 1): Dvir, et al. June 25, 2011 [Page 10] INTERNET DRAFT Extension of Security Services January 14, 2011 o The value of the chain root, HR value: +--+---+-+--+-+-------+ |10| 34|0|1 |0| 0x01 | +--+---+-+--+-+-------+ |Hash Root Chain Value| +---------------------+ o The integrity protection, IP value: +--+---+-+--+-+-------+ |10|255|1|0 |0| 0xC0 | +--+---+-+--+-+-------+ | IProt part 1 | +---------------------+ +--+---+-+--+-+-------+ |10|136|0|0 |0| 0xC0 | +--+---+-+--+-+-------+ | IProt part 2 | +---------------------+ The length of the integrity protection value (3096 bits in this example) can be larger than the maximum length of the Authentication data. Each DODAG node saves the IP value, Root value, and the initial Version Number (taken from the DIO message). Each DODAG node sends the DIO message to its neighbors. In the case when a root wants to update the Version Number, the DIO messages (messages #3 and #4) consist of the following Broadcast Authentication Option(the format of the option is described in Figure 1): o One of the node's value of the hash chain, CH value: +--+---+-+--+-+----------+ |10| 34|0|2 |0| 0x01 | +--+---+-+--+-+----------+ |Current Hash Chain Value| +------------------------+ Each DODAG node verifies the values as explained above and saves the current hash value and the current Version Number (taken from the DIO message). Dvir, et al. June 25, 2011 [Page 11] INTERNET DRAFT Extension of Security Services January 14, 2011 In the case when a new node (newcomer) wants to join the DODAG, a node receiving a unicast DIS message (message #5) from the new node (newcomer) must reply with a DIO message (message #6), consisting of the following Broadcast Authentication Options(the format of the option is described in Figure 1): o The root chain value (HR value, as sent in message #1 and #2): +--+---+-+--+-+-------+ |10| 34|0|1 |0| 0x01 | +--+---+-+--+-+-------+ |Hash Root Chain Value| +---------------------+ o The current hash value (CH value, as sent in messages #3, #4): +--+---+-+--+-+----------+ |10| 34|0|2 |0| 0x01 | +--+---+-+--+-+----------+ |Current Hash Chain Value| +------------------------+ o The integrity protection, IP value, as sent in message #1 and #2: +--+---+-+--+-+----+ |10|255|1|0 |0|0xC0| +--+---+-+--+-+----+ | IProt part 1 | +------------------+ +--+---+--+-+-+----+ |10|136|0|0 |0|0xC0| +--+---+-+--+-+----+ | IProt part 2 | +------------------+ o The initial Version Number, VN value as sent in message #1 and #2: +--+---+-+--+-+------+ |10| 3|0|0 |0|0x00 | +--+---+-+--+-+------+ |Init Version Number | +--------------------+ The new node saves the IP value, Root value, current Version Number (taken from the DIO message), and the initial Version Dvir, et al. June 25, 2011 [Page 12] INTERNET DRAFT Extension of Security Services January 14, 2011 Number. 3.2 Local Key Agreement Providing security is particularly challenging to LLN networks due to the resource limitations. If a group key is used for peer-to-peer communication, protection is provided only against outsider devices and not against potential malicious devices in the key-sharing group. However, local key agreements can be used despite the node limitation in order to authenticate MAC layer one-hop unicast and multicast for all neighbors' messages. The establishment and maintenance of any cryptographic key for security services is out of the scope of the current RPL proposal. This section describes two protocols, establishment of a pairwise key and establishment of a cluster key. Both protocols assume the following: o T is defined as the lower bound on the time for an adversary to compromise a node. T is measured from the boot/restart time of the node. o T is greater than the accumulated time required to construct a DODAG and the time to create local key agreements. o Each node has preshared key K at boot/restart. 3.2.1 Pairwise Shared Key This section describes a pairwise shared key agreement protocol based on the Localized Encryption and Authentication Protocol (LEAP) [LEAP]. This section does not provide results on LEAP's performance or behavior, nor does it explain the algorithm's design in detail. Interested readers should refer to [LEAP]. The pairwise key agreement consists of the following steps: o Each node sets the safe period timer; the pairwise key agreement protocol assumes that the nodes are not compromised before this timer expires. o Each u node derives its own key Ku=MAC(K,u), K is a preshared master key, and u is the IPv6 address of the node. o Each Node u multicasts its identifier to all neighbors. o Each node v receiving the identifier from u, responds with message (v, MAC(Kv, u|v)). Dvir, et al. June 25, 2011 [Page 13] INTERNET DRAFT Extension of Security Services January 14, 2011 o The pairwise key Kuv is generated as: Kuv=MAC(Kv,u). o After the safe period timer expires, each node deletes the preshared key K (from its memory). o Each node has a set of pairwise keys, one for each neighbor. o In case of conflict, a node chooses the pairwise key generated by the node with the lower id. Figure 5 presents the messages exchanged between two neighbors in the pairwise key agreement: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ u -> *, Multicast Message : u. v -> u, Response Message: v, MAC(Kv, u|v) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Messages Flow of Pairwise Key Agreement In order to realize the pairwise key agreement, the LEAP option is presented. A LEAP option consists of the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=11 | Option Length | Comp Algo | MAC Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | : Response MAC : | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | : Compressed Address : | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Format of the LEAP Response Option Option Type: 0x0B (to be confirmed by IANA) Dvir, et al. June 25, 2011 [Page 14] INTERNET DRAFT Extension of Security Services January 14, 2011 Option Length: Variable, length of the option in octets excluding the Type and Length fields. Comp Algo: 8-bit field. In order to store a short version of the id (IPv6) a collision resistant hash function or the method used in Prefix Information Option(as described in section 6.7.1. of [I-D.ietf-roll-rpl]) can be used. The Compression Algorithm field indicates which (if any) compression algorithm is being used. The Compression Algorithm is encoded as in the table below: +----------+-----------------------+ |Bit Number| Comp Algo | +----------+-----------------------+ | 0x00 | No Address | | | | | 0x01 | No Compression | | | | | 0x02 | SHA-1 | | | | | 0x03 | SHA-256 | | | | | 0x04 | Prefix Information | | | | | else | Unassigned | +----------+-----------------------+ Figure 7: Compression Algorithm MAC Function: 8-bit field, indicating which MAC function is being used (interested readers should refer to [PseuFun]). The length of the MAC Function is set by the algorithm. The MAC Function is encoded as in the table below: +----------+--------------------------+ |Bit Number| MAC Function | +----------+--------------------------+ | 0 | HMAC-SHA-256 | | | | | 1 | HMAC-SHA-512 | | | | | else | Unassigned | +----------+--------------------------+ Figure 8: MAC Function Response MAC: The message authentication code is computed on the address of the sender, address of the recipient, and the key Dvir, et al. June 25, 2011 [Page 15] INTERNET DRAFT Extension of Security Services January 14, 2011 of the sender. Compressed Address: Indicates the compressed IPv6 destination address. The sender truncates the compressed address from the Comp Algo result. The receiver can calculate the Compressed Address length by excluding the comp, MAC, and Response MAC fields from the Option length The pairwise key establishment can be based on RPL messages, by piggy-backing the key agreement message on RPL messages. Implementers may choose to use the LEAP option on any of the one-hop bi- directional message exchanges done in RPL based on the design considerations of their implementation. Below are lists of design considerations, possible message exchange schemes, and a matrix summarizing which design considerations are covered by each message exchange scheme. 3.2.1.1 Message Design Considerations List The design considerations are as follows: o RPLM: The scheme should not introduce a new RPL message type. o RPLF: The scheme should not change RPL functionality. o EFFI: The scheme should be efficient (low communication and computation overhead). o STP: The local key agreement must be completed before the safe time period expires. o BN: The scheme must work when the network boots and when a new node joins the DODAG. o NEI: The scheme must find all of a node's neighbors. o MAND: The scheme should prefer mandatory RPL message types (i. e., DIO, DIS). o RELY: The scheme should not rely on DODAG or DODAGID. 3.2.1.2 Message Exchange Schemes The possible message exchange schemes that can be used to implement the key agreement protocol are as follows: o S1: u -> * DAO Multicast v -> u DAO Unicast Ack Dvir, et al. June 25, 2011 [Page 16] INTERNET DRAFT Extension of Security Services January 14, 2011 o S2: u -> * DAO Multicast v -> u DAO Multicast Ack o S3: u -> * DAO Multicast v -> u DAO Multicast o S4: u -> * DIO Multicast v -> u DIO Unicast o S5: u -> * DIS Multicast v -> u DIO Unicast o S6: u -> * DIS Multicast or DIO Multicast v -> u DIO Multicast o S7: u -> * New RPL Base Message v -> u New RPL Base Message In case the response message is a Multicast, the sender may add a number of IPv6 addresses. In order to save overhead, any algorithm to compress the addresses can be used, e. g., a collision resistance hash function, the method used in Prefix Information Option. Selecting at least one is mandatory in order to use the LEAP option. Dvir, et al. June 25, 2011 [Page 17] INTERNET DRAFT Extension of Security Services January 14, 2011 3.2.1.3 Design Consideration vs. Message Exchange Scheme The following matrix analyzes the design considerations vs. the message exchange schemes. The implementer needs to choose which scheme is most appropriate for its application requirements: +--+------+-----+-----+-----+-----+-----+-----+-----+----+ |S |MES |RPLM |RPLF |EFFI |STP |BN |NEI |MAND |RELY| +--+------+-----+-----+-----+-----+-----+-----+-----+----+ |S1|DAO-M | + |- #0|+ #1|+ |+ |+ |- |+ | | |DAO-MA| | | | | | | | | | | | | | | | | | | | |S2|DAO-M | - #2|+ |+ #0|+ |+ |+ |- |+ | | |DAO-MA| | | | | | | | | | | | | | | | | | | | |S3|DAO-M | + |- #3|+ #4|+ |+ |+ |- |+ | | |DAO-M | | | | | | | | | | | | | | | | | | | | |S4|DIO-M | + |- #5|+ #6|+ |+ |+ |+ |- #8| | |DIO-U | | | | | | | | | | | | | | | | | | | | |S5|DIS-M | + |- #7|+ #6|+ |+ |+ |+ |- | | |DIO-U | | | | | | | | | | | | | | | | | | | | |S6|DIS-M | + |+ |+ #6|+ |+ |+ |+ |- #8| | |DIO-M | | | | | | | | | | | | | | | | | | | | |S7|NEW | - |+ |+ #9 |+ |+ |+ |- |- | | |NEW | | | | | | | | | +--+------+-----+-----+-----+-----+-----+-----+-----+----+ Figure 9: Design Consideration vs. Message Exchange #0 - Acknowledgement of DAO Multicast required, while the RPL [I-D.ietf-roll-rpl] states that Ack is sent to unicast messages. #1 - The number of extra Ack messages is proportional to the number of neighbors. Those messages may potentially cause congestion and collisions. #2 - DAO-Multi-Ack is a new type. #3 - According to the RPL specification [I-D.ietf-roll-rpl], DAO Multicast is not sent automatically as a response to DAO Multicast. #4 - The number of extra DAO Multicast messages is proportional to the number of neighbors. This number can be reduced with longer aggregated messages. Dvir, et al. June 25, 2011 [Page 18] INTERNET DRAFT Extension of Security Services January 14, 2011 #5 - According to the RPL [I-D.ietf-roll-rpl], DIO Unicast is not sent automatically to DIO Multicast. #6 - The number of extra DIO messages has an order of magnitude of the number of neighbors. Compared to other base messages, the length of a DIO message is longer. #7 - According to the RPL [I-D.ietf-roll-rpl], the response message to DIS Multicast is DIO Multicast and not DIO Unicast. #8 - Part of the DODAG construction. #9 - The number of the extra new RPL messages is proportional to the number of neighbors. For example, if S6 (using DIS Multicast and DIO Multicast) is selected for implementation, the following apply: 1. Each node periodically sends a DIS message before joining the DODAG (as described in section 17.2.1.1. of [I-D.ietf-roll-rpl]). 2. A non-DODAG node, a node that is not part of the DODAG, when receiving a DIS message, MUST ignore the message. 3. A non-DODAG node, when receiving a DIO message, follows the RPL. 4. A DODAG node, when receiving a DIS or DIO message during the Trickle interval, checks whether a pairwise key exists with the sender. 4a. If not, the node adds a new LEAP option with the compressed address to its next DIO message, and copies the pairwise key it generates. The node also initializes a retransmission value, a maximum number each node will try to retransmit to a neighbor (can be different for different neighbors). 4b. If a pairwise key exists, the node checks the retransmission value. I. If the retransmission value is greater than zero, the node adds a LEAP option to its next DIO message. II. Otherwise, it does not add a LEAP option. III. It always decreases the retransmission value. Dvir, et al. June 25, 2011 [Page 19] INTERNET DRAFT Extension of Security Services January 14, 2011 3.2.2 Cluster Key This section describes a cluster key agreement procedure based on the LEAP algorithm [LEAP]. This section does not provide results on LEAP's performance or behavior, nor does it explain the algorithm's design in detail. Interested readers should refer to [LEAP]. The cluster key establishment phase follows the pairwise key establishment phase. The cluster key agreement has the following steps: o Node u first generates a random key. o For each neighbor, node u encrypts this random key with the neighbor's pairwise key. o For each neighbor, node u sends the encrypted random key. The cluster key agreement can be realized with RPL messages; any RPL Unicast message is OPTIONAL. For example, a node sends a DAO unicast message with a Cluster Key Option that can carry the cluster key encrypted to each neighbor. In order to generate a cluster key, an RPL message MUST carry a "Cluster Key" option. A Cluster Key option consists of the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=12 | Option Length | Key Length | ENC Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | : Encrypted Cluster Key : | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Format of the LEAP Cluster Key Option Option Type: 0x0C (to be confirmed by IANA) Option Length: Variable, length of the option in octets excluding the Type and Length fields. Dvir, et al. June 25, 2011 [Page 20] INTERNET DRAFT Extension of Security Services January 14, 2011 Key Length: Variable, length of the Encrypted Cluster Key in octets. ENC Function: 8-bit field, indicating which encrypted function is being used. The ENC Function is encoded as in the table below: +----------+--------------------------+ |Bit Number| ENC Function | +----------+--------------------------+ | 0 | CCM with AES-128, M=0 | | | | | else | Unassigned | +----------+--------------------------+ Figure 11: Encryption Function Encrypted Cluster Key: The encrypted value of the cluster key computed on the random key and the neighbor pairwise key. 4 Security Considerations The security mechanisms in this standard extend the RPL security mechanisms, sections 6.1 and 10 of [I-D.ietf-roll-rpl]. Therefore, the security consideration described in section 18 of [I-D.ietf-roll-rpl] exists in this document. The scope of the current RPL security services is the link; the authenticity of the messages sent by the DODAG root relies on the trustworthiness of all intermediate nodes and the fact that none of the keys are compromised. The herein proposed DIO Message Authentication extends the data integrity and data origin authentication [RFC3552] into network level, by authenticating the static fields of the DIO message for all nodes in the DODAG. The security mechanisms in RPL [I-D.ietf-roll-rpl] are based on symmetric-key and public-key cryptography, and use keys that are to be provided by higher/lower layer processes. However, the establishment and maintenance of these keys are out of the scope of the current RPL. The proposed local key agreement gives new procedures in order to establish and maintain pairwise and cluster keys for peer entity authentication [RFC3552]. The cryptographic protection using pairwise and cluster keys allows some flexibility and application specific tradeoffs between key storage and key maintenance costs versus the cryptographic protection provided. The security services in this document are based on symmetric-key and public-key cryptography and assume a safe time interval after bootstrapping, during which an attacker cannot compromise a node. Dvir, et al. June 25, 2011 [Page 21] INTERNET DRAFT Extension of Security Services January 14, 2011 The current RPL security services [I-D.ietf-roll-rpl] assume that a node wishing to join a secured network has been preconfigured with a shared key; for example, each node MAY use a secure message with KIM=0. Moreover, to join a secure RPL network, a node either listens for secure DIO messages or triggers secure DIOs by sending a secure DIS. 5 IANA Considerations 5.1 RPL Control Message Option IANA is requested to create a registry for the RPL Control Message Options. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Value o Capability description o Defining RFC The following bits are currently defined: +----------+------------------------+---------------+ | Value | Description | Reference | +----------+------------------------+---------------+ | 0x0A |Broadcast Authentication| This document | | | | | | 0x0B |LEAP Response | This document | | | | | | 0x0C |Cluster Key | This Document | +----------+------------------------+---------------+ RPL Control Message Options 5.2 New Registry for the Hash Value Type IANA is requested to create a registry for the Hash Value Type Field, which is contained in the Broadcast Authentication option. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Value Dvir, et al. June 25, 2011 [Page 22] INTERNET DRAFT Extension of Security Services January 14, 2011 o Capability description o Defining RFC The following bits are currently defined: +----------+--------------------------+---------------+ | Value | Hash Value Type | Reference | +----------+--------------------------+---------------+ | 0 | No hash Value | This document | | | | | | 1 | Hash Root Chain Value | This document | | | | | | 2 | Current Hash Chain Value| This document | | | | | | 3 | Unassigned | This document | | | | | +----------+--------------------------+---------------+ Hash Field in Broadcast Authentication Option 5.3 New Registry for the Security Algorithm Type IANA is requested to create a registry for the Security Algorithm Field, which is contained in the Broadcast Authentication option. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Value o Capability description o Defining RFC Dvir, et al. June 25, 2011 [Page 23] INTERNET DRAFT Extension of Security Services January 14, 2011 The following bits are currently defined: +----------+--------------------------+---------------+ | Value | Security Algorithm | Reference | +----------+--------------------------+---------------+ | 0x00 |No Security Algorithm | This document | | | | | | 0x01 |SHA-256 | This document | | | | | | 0x02 |SHA-512 | This document | | | | | | 0x80 |HMAC-SHA-256 | This document | | | | | | 0x81 |HMAC-SHA-512 | This document | | | | | | 0xC0 |RSA with SHA-256 | This document | | | | | | 0xC1 |ECC-SECP256K1 with SHA-256| This document | | | | | | else |Unassigned | This document | +----------+--------------------------+---------------+ Security Algorithm Field in Broadcast Authentication Option 5.4 New Registry for the Comp Algo Type IANA is requested to create a registry for the Comp Algo Field, which is contained in the LEAP Response Option. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Value o Capability description o Defining RFC Dvir, et al. June 25, 2011 [Page 24] INTERNET DRAFT Extension of Security Services January 14, 2011 The following bits are currently defined: +----------+-----------------------+---------------+ | Value | Comp Algo | Reference | +----------+-----------------------+---------------+ | 0x00 | No Address | This document | | | | | | 0x01 | No Compression | This document | | | | | | 0x02 | SHA-1 | This document | | | | | | 0x03 | SHA-256 | This document | | | | | | 0x04 | Prefix Information | This document | | | | | | else | Unassigned | This document | +----------+-----------------------+---------------+ Comp Algo Field in LEAP Response Option 5.5 New Registry for the MAC Function Type IANA is requested to create a registry for the MAC Function Field, which is contained in the LEAP Response Option. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Value o Capability description o Defining RFC The following bits are currently defined: +----------+--------------------------+---------------+ | Value | MAC Function | Reference | +----------+--------------------------+---------------+ | 0 | HMAC-SHA-256 | This document | | | | | | 1 | HMAC-SHA-512 | This document | | | | | | else | Unassigned | This document | +----------+--------------------------+---------------+ MAC Function Field in LEAP Response Option Dvir, et al. June 25, 2011 [Page 25] INTERNET DRAFT Extension of Security Services January 14, 2011 5.6 New Registry for the ENC Function IANA is requested to create a registry for the ENC Function Field, which is contained in the LEAP Cluster Key Option. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Value o Capability description o Defining RFC The following bits are currently defined: +----------+--------------------------+---------------+ | Value | ENC Function | Reference | +----------+--------------------------+---------------+ | 0 | CCM with AES-128, M=0 | This document | | | | | | else | Unassigned | This document | +----------+--------------------------+---------------+ ENC Function Field in LEAP Cluster Key Option 6 Acknowledgements The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement no. 225186. The authors would also like to acknowledge the review and comments from Yoav Ben Yehezkel. 7 References 7.1 Normative References [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-17 (work in progress), December 2010. Dvir, et al. June 25, 2011 [Page 26] INTERNET DRAFT Extension of Security Services January 14, 2011 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3552] Rescorla E., and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, March 2003. [RFC3447] Jonsson, J., and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. 7.2 Informative References [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-04 (work in progress), September 2010. [I-D-roll-security-framework] Tsao T., Alexander R., Dohler M., Daza V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", |%draft-ietf-roll-security-framework-03, (work in progress) December 2010. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC4949] R. Shirey, "Internet Security Glossary", RFC 4949, FYI 36, August 2007. [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003. [RFC4868] Kelly, S., and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- Dvir, et al. June 25, 2011 [Page 27] INTERNET DRAFT Extension of Security Services January 14, 2011 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. [PseuFun] Goldreich, O., Goldwasser, S., and S. Micali, "How to Construct Random Functions", Journal of the ACM, Volume 33, Number. 4, 1986, pp 210-217. [L1981] Lamport L., "Password Authentication with Insecure Communication", ACM Journal of Communications Volume 24 Issue 11, pp 770-772, Nov. 1981. [LEAP] Zhu, S., Setia, S., and S. Jajodia, "LEAP: efficient security mechanisms for large-scale distributed sensor networks ", ACM conference on Computer and communications security, pp. 62-72, 2003. [SECG2] D. R. L. Brown, "Standards for Efficient Cryptography Group (SECG), "SEC 2: Recommended Elliptic Curve Domain Parameters version 2.0", Version 2.0, January 2010. [OptHash] Don, C., and M. Jakobsson, "Almost Optimal Hash Sequence Traversal", Fourth Conference on Financial Cryptography, 2002. [FIPS180] National Institute of Standards and Technology, "FIPS Pub 180-3, Secure Hash Standard (SHS)", US Department of Commerce , February 2008, . Authors' Addresses Amit Dvir Laboratory of Cryptography and Systems Security (CrySyS) Budapest University of Technology and Economics BME-HIT, PO Box 91, 1521 Budapest Hungary EMail: azdvir@gmail.com Tamas Holczer Laboratory of Cryptography and Systems Security (CrySyS) Budapest University of Technology and Economics BME-HIT, PO Box 91, 1521 Budapest Hungary EMail: tamas.holczer@crysys.hu Dvir, et al. June 25, 2011 [Page 28] INTERNET DRAFT Extension of Security Services January 14, 2011 Laszlo Dora Laboratory of Cryptography and Systems Security (CrySyS) Budapest University of Technology and Economics BME-HIT, PO Box 91, 1521 Budapest Hungary EMail: laszlo.dora@crysys.hu Levente Buttyan Laboratory of Cryptography and Systems Security (CrySyS) Budapest University of Technology and Economics BME-HIT, PO Box 91, 1521 Budapest Hungary EMail: buttyan@crysys.hu Dvir, et al. June 25, 2011 [Page 29]