Internet DRAFT - draft-dvir-roll-security-authentication

draft-dvir-roll-security-authentication



 



INTERNET-DRAFT                                                   A. Dvir
Intended Status: Experimental                                 T. Holczer
Expires: July 11, 2012                                           L. Dora
                                                              L. Buttyan
                                                         January 8, 2012



                 Version Number and Rank Authentication
             draft-dvir-roll-security-authentication-01.txt

Abstract

   Designing a routing protocol for large low-power and lossy networks
   (LLNs), consisting of thousands of constrained nodes and unreliable
   links, presents new challenges.  The IPv6 Routing Protocol for Low-
   power and Lossy Networks (RPL), have been developed by the IETF ROLL
   Working Group as a preferred routing protocol to provide IPv6 routing
   functionality in LLNs.  Unfortunately, the currently available
   security services in RPL will not protect against a compromised
   internal node that can construct and disseminate fake messages.
   Therefore, in RPL special security care must be taken when the
   Destination Oriented Directed Acyclic Graph (DODAG) root is updating
   the Version Number by which reconstruction of the routing topology
   can be initiated.  The same care also must be taken to prevent an
   internal attacker (compromised DODAG node) to publish decreased Rank
   value, which causes a large part of the DODAG to connect to the DODAG
   root via the attacker and give it the ability to eavesdrop or
   manipulate a large part of the network traffic.  In this document, a
   new security service is described that prevents any misbehaving DODAG
   node from illegitimately increasing the Version Number or publish
   illegitimately decreased Rank values.

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."

 


Dvir, et al.                 July 11, 2012                      [Page 1]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   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
   http://www.ietf.org/shadow.html.

Copyright and License Notice

   Copyright (c) 2012 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.                 July 11, 2012                      [Page 2]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


Table of Contents

   1  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3  VeRA - Version Number and Rank Authentication  . . . . . . . . . 6
      3.1  Version Number Authentication . . . . . . . . . . . . . . . 8
      3.2  Rank Authentication . . . . . . . . . . . . . . . . . . .  10
      3.3  Format of the Authentication Option . . . . . . . . . . .  14
      3.4  The Security Scheme . . . . . . . . . . . . . . . . . . .  17
   4  Security Considerations  . . . . . . . . . . . . . . . . . . .  18
   5  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  18
      5.1  RPL Control Message Option  . . . . . . . . . . . . . . .  18
      5.2  New Registry for the Code Value Type  . . . . . . . . . .  19
      5.3  New Registry for the Algorithm Type . . . . . . . . . . .  20
   6  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  21
   7  References . . . . . . . . . . . . . . . . . . . . . . . . . .  21
      7.1  Normative References  . . . . . . . . . . . . . . . . . .  21
      7.2  Informative References  . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23





























 


Dvir, et al.                 July 11, 2012                      [Page 3]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


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].

   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.  This document
   introduces the following terminology:

   Compromised:  Taking control over a node. 

   h():  Cryptographic one-way hash function [PseuFun].

   r:  Random number.

   V:  Version Number hash chain.

   i:  Index of the Version Number hash chain.

   V_0:  Root of the Version Number hash chain.

   V_i:  The ith Version Number hash chain element.

   n+1:  Version Number hash chain length.

   x_i:  Random number.

   R:  Rank hash chain.

   j:  Index of the Rank hash chain.

   l+1:  Rank hash chain length.

   R_(i,j):  The jth Rank hash value associated with the ith Version
   Number hash chain element.

   R_mrh=R_(i,l):  Max Rank hash value associated with the ith Version
   Number hash chain element.

   R_sender:  Rank element value.

 


Dvir, et al.                 July 11, 2012                      [Page 4]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   Rank_root:  Rank value of the DODAG root. 

   Rank_sender:  Rank value of the parent.

   M:  Message.

   Init_VN:  Initial value of the Version Number.

   VN:  Current Version Number value.

   IP:  Integrity Protection value.

   MAC:  Message authentication code.

   MHRI:  MinHopRankIncrease [I-D.ietf-roll-rpl].

   OF:  Objective Function [I-D.ietf-roll-rpl].

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 nodes 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 and 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 security services that RPL
   currently provides natively are sufficient to protect the network
   against such an attack if only an external attacker is assumed. 
   However, native RPL security services will not protect against a
   compromised internal node.  Therefore, this document considers the
   case where the attacker is a compromised node, where the source of
   the compromise can be logical [FC_Code] or physical [Tamper] and the
 


Dvir, et al.                 July 11, 2012                      [Page 5]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   attacker can intercept, forge, modify, inject, replay, and create
   messages (data or control) in order to interfere with the operation
   of entire network and exhaust nodes' batteries. 

   An internal adversary can attack RPL in many different ways. 
   However, some of these attacks have only a minor influence, while
   others may have a major influence in the network.  A consequence of
   an attack that will lead to reconstructing the entire DAG and exhaust
   the nodes' batteries, or eavesdropping a large part of the network
   traffic can have major or even critical influence.  One way for an
   internal adversary to achieve these goals is to change/modify the
   Version Number of the DODAG [I-D.ietf-roll-rpl], a sequential counter
   that is incremented by the DODAG root to form a new Version of a
   DODAG, or to change/modify the DODAG node Rank value
   [I-D.ietf-roll-rpl], representation of the location of that node
   within a DODAG.  Therefore, this document presents a security scheme
   to prevent the following attacks: 

      (i)   An internal attacker impersonating a DODAG root and
         illegitimately increasing the Version Number.

      (ii)  An internal attacker publishing an illegitimately decreased
         Rank value.

   Implementation of the security service described in this document is
   OPTIONAL.  It is RECOMMENDED that implementers carefully consider
   security requirements and the availability of security mechanisms in
   their network.  The hash functions, MAC functions, and digital
   signature algorithms 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) is
   based on section 2.7 of [SECG2].  The Hashed Message Authentication
   Mode (HMAC) is described in [RFC4868].  

3  VeRA - Version Number and Rank Authentication

   A grounded DODAG offers connectivity to hosts that are required to
   satisfy the application-defined goal.  An attacker may try to become
   a grounded DODAG root by sending a well-constructed DIO message.  The
   scope of the current RPL security services is the link; therefore, in
   RPL the authenticity of the messages sent by the DODAG root relies on
   the trustworthiness of all intermediate DODAG nodes and the fact that
   none of the keys are compromised.  However, because of to the lack of
   physical protection, DODAG nodes can be compromised (including their
   keys).  This allows an attacker to send an authentic DIO message that
   will be accepted by all the DODAG nodes.  Therefore, a node that
   receives a DIO message from the attacker will multicast it to its
 


Dvir, et al.                 July 11, 2012                      [Page 6]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   neighbors using uncompromised keys.  The content of the message from
   the attacker will affect other nodes participating in the DODAG.  

   Version number is an element of each DIO message and related to the
   network.  The Version Number is monotonically incremented by the root
   each time the DODAG root decides to form a new Version of the DODAG
   in order to revalidate the integrity and allow global repairs to
   occur.  The Version Number is propagated unchanged Down the DODAG as
   routers join the new DODAG.  The Version Number value is globally
   significant in a DODAG and indicates the Version of the DODAG that a
   router is operating in.   An older (lesser) value indicates that the
   originating router has not migrated to the new DODAG and cannot be
   used as a parent once the receiving node has migrated to the newer
   DODAG [I-D.ietf-roll-rpl].  RPL allows the Version Number to be
   increased regularly or occasionally.  Moreover, reconstruction of the
   routing topology can be initiated by sending a DIO message with an
   increased Version Number. 

   Therefore, preventing any misbehaving DODAG node from impersonating
   the actual DODAG root and increasing the Version Number is essential.
   Note that how often the Version Number is increased is out of scope
   of this draft (application dependent).  

   The Rank is a value that helps the nodes to determine at what level
   they are in the directed acyclic graph.  The lower the Rank is, the
   closer (in a sense of the hop numbers) the node is to the DODAG root.
   Each node must set the Rank such that the Rank of all the selected
   DODAG parents are lower.  The siblings of a node are those
   neighboring nodes whose Rank value is equal to the Rank value of the
   node.  MinHopRankIncrease (MHRI) is the minimum increase in Rank
   value between a node and any of its DODAG parents.  RPL allows the
   nodes to increase their Rank in order to become distant from the
   DODAG root.  This can be beneficial for the node, because the node
   has to forward fewer messages, the closer a node is placed to the
   DODAG root the more messages it has to forward.  In that case the
   DODAG parents and the siblings of the node may change, and also the
   nodes that set this node as a parent have to change the relation,
   otherwise a loop may be formed. RPL has some mechanisms to detect
   loops that may arise because of other reasons than described above. 
   If the network detects a loop that can be difficult to repair, it may
   reconstruct the whole graph.  The reconstruction, global repair, can
   be initiated by the DODAG root by sending DIO messages with an
   increased Version Number.

   By publishing a high Rank value, an attacker can move deeper in the
   DODAG in order to increase the size of the parent set or improve some
   other metric.  However, the most effective Rank attack is by
   decreasing the Rank.  By publishing a low Rank value, a large part of
 


Dvir, et al.                 July 11, 2012                      [Page 7]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   the DODAG will connect to the DODAG root via the attacker, and give
   it the ability to eavesdrop and manipulate a large part of the
   network traffic.

3.1  Version Number Authentication

   By authenticating the Version Number, each DODAG node can securely
   forward the DIO message in order to bootstrap or update the DODAG
   Version.  

   Upon initialization, a DODAG root generates a random number r and
   calculates a hash chain [L1981], named as Version Number hash chain,
   of size n+1: V_n, V_(n-1)..., V_1, V_0 where V_n=h(r),
   V_i=h(V_(i+1)), with the random number r, where h() is a
   cryptographic hash function.   

   Then the DODAG root reveals the root of the Version Number hash chain
   V_0 and using any supported integrity protection algorithm (e. g.,
   digital signature or MAC) the DODAG root binds the root value to a
   particular DODAG,  {V_0}_sign/mac.  Finally, the DODAG root
   multicasts the DIO message (M#1, in Figure 1) with V_0, the initial
   value Init_VN of the Version Number and the integrity protection
   data; the DODAG root can resend the signed DIO message until the
   first Version Number update occurs.

   Upon receiving the signed DIO message, each intermediate DODAG node
   verifies the authentication data and in case of success saves the
   integrity protection data, the root V_0 of the Version Number hash
   chain, and the initial value Init_VN of the Version Number.  When the
   trickle timer [RFC6206] expires, it multicasts to all neighbors the
   DIO message (M#2) according to [I-D.ietf-roll-rpl].  If the message
   is not authentic, the intermediate DODAG node MUST ignore the
   message.

   Upon Version Number update, the DODAG root reveal the next Version
   Number hash chain element V_i and sends a DIO message (M#3) with a
   new Version Number VN and V_i.  Upon receiving a DIO message with a
   new Version Number, an intermediate DODAG node can easily verify the
   message because, if the Version Number is increased by the DODAG
   root, h^{i}(V_i) must be equal to V_0. Upon success, the intermediate
   DODAG node saves the current Version Number value.  When the trickle
   timer [RFC6206] expires, it multicasts to all neighbors the DIO
   message (M#4) after updating according to section 6.3.1. of
   [I-D.ietf-roll-rpl].  

   If an attacker wants to increase the Version Number, then it has to
   compute a pre-image of the last revealed hash chain element of the
   Version Number hash chain. However, computing the next element
 


Dvir, et al.                 July 11, 2012                      [Page 8]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   V_(i+1) knowing V_i is hard when r is not known and h() is a
   cryptographic one-way hash function. 

   In the case when a new node wants to join the DODAG, any DODAG node
   receiving a unicast DIS message (M#5) from the new node (Non DODAG
   node), MUST reply with a DIO message (M#6) containing the current
   Version Number value VN, the initial Version Number value Init_VN,
   the root of the Version Number hash chain V_0, the current Version
   Number hash chain element V_i, and the integrity protection data IP. 
   Note that all these data is stored by every DODAG node in the network
   following our scheme.

   It is RECOMMENDED to use the integrity protection mechanism.  When a
   digital signature is used, each node has to know the public signature
   verification key.  For a normal node it is very costly to digitally
   sign and verify; therefore it is RECOMMENDED to use the sign
   procedure only for bootstrapping or in case the DODAG root revealed
   all the hash chain elements of the current hash chain and need to
   generate a new hash chain.  The first DIO message which contains the
   new hash chain root, MUST be signed.  Moreover, it is OPTIONAL to
   resend the first DIO message with the hash chain root and the
   signature till the first Version Number update.  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.  In case the implementer decides to authenticate the hash chain
   root using MAC function, the Version Number hash chain root needs to
   be transported reliably.

   The sequence diagram of the Version Number Authentication algorithm
   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=Init_VN, V_0, IP|                 |                       |
     |---------------->M#1|                 |                       |
     |                    |VN=Init_VN,V_0,IP|                       |
     |                    |----------->M#2  |                       |                    
     |                    |                 |                       |
     :                    :                 :                       :
     |                    |                 |                       |
     | VN=Init_VN+i, V_i  |                 |                       |
     |---------------->M#3|VN=Init_VN+i, V_i|                       |
     |                    |----------->M#4  |                       |
     |                    |                 |                       |
     :                    :                 :                       :
     |                    |                 |                       |
     |                    |                 | Unicast DIS           |
 


Dvir, et al.                 July 11, 2012                      [Page 9]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


     |                    |                |M#5<-------------------|
     |                    |                |                       |
     |                    |                | VN,Init_VN,V_0,V_i,IP |
     |                    |                |------------------->M#6|
     |                    |                |                       |

   Figure 1: Sequence Diagram of Version Number Authentication Algorithm

3.2  Rank Authentication

   By authenticating the Rank value, each DODAG node can conclude that
   its Rank value is greater than its parent Rank value and from the
   DODAG root towards the current DODAG node, the Rank values are
   monotonically increasing.

   Upon initialization, a DODAG root generates a random number r and
   calculates a hash chain[L1981], named as Version Number hash chain,
   of size n+1: V_n, V_(n-1)..., V_1, V_0 where V_n=h(r),
   V_i=h(V_(i+1)), with the random number r.  For each element V_i of
   the Version Number hash chain the DODAG root generates a new random
   number x_i and calculates a new hash chain, named as Rank hash chain,
   of size l+1: R_(i,0), R_(i,1)..., R_(i,l-1), R_(i,l) where R_(i,0)=
   h(x_i), R_(i,j)=h(R_(i,j-1)), with the new random number x_i.  In
   theory, l should be 65535 to have a different value for each possible
   Rank value (Rank is 16 bits long [I-D.ietf-roll-rpl]).  In practice,
   256 is large enough as for most of the operations DAGRank
   [I-D.ietf-roll-rpl] is used (the DAG Rank of a node is the upper 8
   bits of the Rank), which is 8 bits long.  If DAGRank is used when
   defining the hash chain, then all occurrences of Rank must be
   substituted by DAGRank in the sequel.  Figure 2 illustrates the hash
   chains'.  Note that, in order to decrease the size of Rank hash
   chain, in any case we are using the Rank value as the indicator to
   the number of times to hash (h^{}()) we divided the Rank value by
   MinHopRankIncrease (Rank/MinHopRankIncrease).

   Then the DODAG root reveals the root of the Version Number hash chain
   V_0, computes MAC_{V_1}(R_(mrh)) a message authentication code (MAC)
   value computed over the Max Rank hash (mrh) value R_(mrh)=R_(1,l) of
   the next Rank Hash chain with the next Version Number hash chain
   element V_1 as the key.  Finally, the DODAG root multicast a DIO
   message with V_0,  MAC_{V_1}(R_(mrh)); the DODAG root can resend the
   DIO message till the DODAG needs to update its Rank value or update
   the Version Number.  

   Upon receiving the DIO message, each intermediate DODAG node saves
   the root V_0 of the Version Number hash chain, and the MAC value
   MAC_{V_1}(R_(mrh)).  When the trickle timer [RFC6206] expires, it
   multicasts to all neighbors the DIO message according to
 


Dvir, et al.                 July 11, 2012                     [Page 10]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   [I-D.ietf-roll-rpl].  Figure 3 illustrates the initialization of the
   Rank Authentication algorithm.

   Upon Version Number update, the DODAG root sends a DIO message with
   the following parameters: next Version Number value VN as described
   in [I-D.ietf-roll-rpl], next Version Number hash chain element V_i, a
   message authentication code (MAC) value MAC_{V_(i+1)}(R_(mrh))
   computed over the Max Rank hash value R_mrh=R_(i+1,l) with the next
   Version Number hash chain element V_(i+1) as the key, and a Rank
   element value R_sender=h^{Rank_root}(x_i), where Rank_root is the new
   Rank value of the DODAG root.

   Upon receiving a DIO message with a new Version Number or new Rank
   value, an intermediate DODAG node use the revealed key V_i, the MAC
   value from the previous update MAC_{V_(i)}(R_(mrh)) and the Rank
   element R_sender, to verify whether the Rank value of its parent is
   monotonically increasing as follows:

         o  It generates R_check= h^{l-Rank_sender}(R_sender), where
         Rank_sender is the Rank value of the parent.

         o  It checks if MAC_{V_(i)}(R_mrh), from the previous update,
         is equal to MAC_{V_(i)}(R_check).

         o  If so, intermediate DODAG node v can conclude that the Rank
         is monotonically increasing and:

            o  It calculates its Rank value regarding its Objective
            Function, Rank_v.

            o  It calculates delta= Rank_v - Rank_(sender), the
            difference between the DODAG node Rank value and its parent
            Rank value. Node v has the parent Rank from the DIO message.

            o  It calculates R_sender= h^{delta}(R_sender).

            o  When the trickle timer [RFC6206] expires, it multicasts
            to all neighbors the DIO message according to
            [I-D.ietf-roll-rpl] with the new R_sender value.

   If an attacker wants to decrease the Rank [I-D.ietf-roll-rpl], then
   it has to compute a pre-image of the last R_sender.  However,
   computing the previous R_(i-1) knowing R_(i) is hard when x_i is not
   known and h() is a cryptographic one-way hash function.  Figure 4
   illustrates the Rank update algorithm. 

   In the case when a new node wants to join the DODAG, any node
   receiving a unicast DIS message from the new node MUST reply with a
 


Dvir, et al.                 July 11, 2012                     [Page 11]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   DIO message containing the last MAC value.





               Version Number Hash Chain, V_i=h(V_(i+1))
                    h         h        h           h     h
       r=random  V_n=h(r)->V_(n-1)-->...V_i-->....->V_2-->V_1-->V_0

                                           |
                                           V

                                       x_i=random

                                        R_(i,0)=h(x_i)        
                                            |
                                         h  |
                                            v
                                        R_(i,1)
                                            |
                                         h  |
                                            v
                                        R_(i,2)

                                            .
                                            .
                                         h  .
                                            v
                                        R_(i,l-1)
                                            |
                                         h  |
                                            v
                                        R_(i,l), Max Rank hash value

                  Rank Hash Chain, R_(i,j) = h(R_(i,j-1))

            Figure 2: The Hash Chains.


         DODAG root                             DODAG node v

   Generate Random Number r                         Get 
               |                            DIO: V_o, MAC_{V_1}(R_mrh)
               |                                  signature
               v                                     |  
   Calculate hash chain                              v            
     h(h(...h(r)))),V_0                       Verify ? -- No-> Delete 
 


Dvir, et al.                 July 11, 2012                     [Page 12]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


               |                                      |
               |                                      |
               |                                     Yes
               |                                      |
               |                                      v
               |                   Save V_o, MAC_{V_1}(R_mrh), signature
               |                                     |
               v                                     |
   For each V_i generate                             v     
   random number x_i                                Send
               |                   DIO: V_o, MAC_{V_1}(R_mrh), signature
               |                                   
               v
   For each V_i calculate hash chain
    h(h(...h(x_i)))),R_mrh
               |
               |
               v
   Rank= OF(root)
               |
               |
               v
   Signature = Sign (V_0, MAC_{V_1}(R_mrh))
               |
               |
               v
   Send 
   DIO: V_o, MAC_{V_1}(R_mrh)
   signature


            Figure 3: Rank Authentication Algorithm - Initialization






         DODAG root                             DODAG node v

   Version Number Update                          Get 
             |                 DIO:V_i, MAC_{V_(i+1)}(R_mrh), R_sender
             |                                     |
             v                                     v
   Rank= OF(root)                  R_check=h^{l-Rank_parent}(R_sender)
             |                                     |
             |                                     |
             v                                     v
 


Dvir, et al.                 July 11, 2012                     [Page 13]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   R_sender=h^{Rank}(x_i)                      Calculate 
             |                            MAC_check=MAC_{V_i}(R_mrh)
             |                                     |
             |                                     |
             v                                     v
   R_mrh= h(h(...h(x_(i+1)))))               MAC_check == MAC_i
             |                                     |
             |                                     |
             |                                     v
             v                          Rank Monotonically increase
            Send                               Rank=OF(v)
   DIO: V_i, MAC_{V_(i+1)}(R_mrh), R_sender        |
                                                   |
                                                   v
                                         delta= Rank_v - Rank_Parent
                                                   |
                                                   |
                                                   v
                                         R_sender=h^{delta}(R_sender)
                                                   |
                                                   |
                                                   v
                                                 Send
                              DIO: V_i, MAC_{V_(i+1)}(R_mrh), R_sender 


            Figure 4: Rank Authentication Algorithm -  Update

3.3  Format of the Authentication Option  

   In order to authenticate the Version Number or/and the Rank, a DIO
   MUST carry one "Authentication" option.  An Authentication 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=10     | Option Length |Code |  Flags  |   Algorithm   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       :                    Authentication Data                        :
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 


Dvir, et al.                 July 11, 2012                     [Page 14]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


             Figure 5:  Format of the 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.

   Code: 3-bit unsigned integer, identifies the type of Authentication
         option.  This document defines codes for the following
         Authentication types (all codes are to be confirmed by IANA
         Section):

             +-----+-------------------------------+
             |Value|      Code Value Type          |
             +-----+-------------------------------+
             |   0 |Version Number Hash Chain Value|
             |     |                               |               
             |   1 |Version Number Hash Chain Root |
             |     |                               |               
             |   2 |Rank Hash Chain Value          |
             |     |                               |               
             |   3 |MAC of Max Rank Hash Value     |
             |     |                               |               
             |   4 |Integrity Protection Value     |
             |     |                               |               
             | else|Unassigned                     |
             |     |                               |               
             +-----+-------------------------------+
             Figure 6:  Code Type

   Flags:  5-bit unused field.  The field MUST be initialized to zero by
         the sender and MUST be ignored by the receiver.

   Algorithm:  8-bit field, indicating which algorithm is being used. 
         The type of the algorithm is set by the Code field:

         o  Code Field = 0: Hash Function.

         o  Code Field = 1: Hash Function.

         o  Code Field = 2: Hash Function.


             +----------+--------------------------+
             |Bit Number|     Hash Function        |
             +----------+--------------------------+
             |    0     |   SHA-256                |
             |          |                          |
 


Dvir, et al.                 July 11, 2012                     [Page 15]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


             |    1     |   SHA-512                |
             |          |                          |
             |   else   |   Unassigned             |
             +----------+--------------------------+

             Figure 7:  Hash Function

             fi
         o  Code Field = 3: MAC Function.


             +----------+--------------------------+
             |Bit Number|     MAC Function         |
             +----------+--------------------------+
             |    0     |   HMAC-SHA-256           |
             |          |                          |
             |    1     |   HMAC-SHA-512           |
             |          |                          |
             |   else   |   Unassigned             |
             +----------+--------------------------+

             Figure 8:  MAC Function  

         o  Code Field = 4: Integrity Protection algorithm (Digital
         Signature/MAC).

             +----------+--------------------------+
             |Bit Number|   Integrity Protection   |
             +----------+--------------------------+
             |    0     |   HMAC-SHA-256           |
             |          |                          |
             |    1     |   HMAC-SHA-512           |
             |          |                          |
             |    2     |   RSA with SHA-256       |
             |          |                          |
             |    3     |ECC-SECP256K1 with SHA-256|
             |          |                          |
             |   else   |   Unassigned             |
             +----------+--------------------------+

             Figure 9:  Integrity Protection 

   Authentication Data:  Contains the authentication data compatible
         with the Code and Function Type fields.

   Unassigned bits of the Authentication option are reserved. They MUST
   be set to zero on transmission and MUST be ignored on reception.

 


Dvir, et al.                 July 11, 2012                     [Page 16]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


3.4  The Security Scheme

   Using the two algorithms described above in one Security Scheme
   prevents an internal attacker from impersonating a DODAG root,
   illegitimately increasing the Version Number and compromise an
   illegitimately decreased Rank value.  The following tables describe
   which Authentication option types to use in each step of the
   algorithms to prevent both Version Number and Rank attacks:

   VNHA:  Version Number Hash Chain Value.

   VNR:  Version Number Hash Chain Root.

   RHV:  Rank Hash Chain Value.

   MRHM:  MAC of Max Rank Hash Value.

                  +------+-------+---------+
                  | Init | Update| New Node|
             -----+------+-------+---------+
             |VNHV|   -  |   +   |    +    | 
             -----+------+-------+---------+
             |VNR |   +  |   -   |    +    |
             -----+------+-------+---------+
             |RHV |   -  |   -   |    -    |
             -----+------+-------+---------+
             |MRHM|   -  |   -   |    -    |
             -----+------+-------+---------+      
             |IP  |   +  |   -   |    +    |
             -----+------+-------+---------+
             Figure 10:  Version Number Authentication 


                  +------+-------+---------+
                  | Init | Update| New Node|
             -----+------+-------+---------+
             |VNHV|   -  |   -   |    -    | 
             -----+------+-------+---------+
             |VNR |   -  |   -   |    -    |
             -----+------+-------+---------+
             |RHV |   -  |   +   |    +    |
             -----+------+-------+---------+
             |MRHM|   +  |   +   |    +    |
             -----+------+-------+---------+      
             |IP  |   -  |   -   |    -    |
             -----+------+-------+---------+
             Figure 11:  Rank Authentication 

 


Dvir, et al.                 July 11, 2012                     [Page 17]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


                  +------+-------+---------+
                  | Init | Update| New Node|
             -----+------+-------+---------+
             |VNHV|   -  |   +   |    +    | 
             -----+------+-------+---------+
             |VNR |   +  |   -   |    +    |
             -----+------+-------+---------+
             |RHV |   -  |   +   |    +    |
             -----+------+-------+---------+
             |MRHM|   +  |   +   |    +    |
             -----+------+-------+---------+      
             |IP  |   +  |   -   |    +    |
             -----+------+-------+---------+
             Figure 12:  Version Number and Rank Authentication 

4  Security Considerations

   The security mechanism in this draft 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 Authentication scheme extends the
   data integrity and data origin authentication [RFC3552] to network
   level by authenticating Version Number and the Rank.  Note that when
   using the Version Number authentication, only the root can increase
   the Version Number, so it can control exhaustion of the chain.  

   This draft prevents two powerful attacks: a)  An internal attacker
   impersonating a DODAG root and updating the Version Number; and b) 
   An internal attacker publishing decreased Rank in order to be on the
   path to the DODAG root for the majority of the nodes and by that to
   be able to eavesdrop a large part of network traffic. 

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

 


Dvir, et al.                 July 11, 2012                     [Page 18]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   o  Capability description

   o  Defining RFC

   The following bits are currently defined:

             +----------+------------------------+---------------+
             |  Value   |   Description          | Reference     |
             +----------+------------------------+---------------+
             |   0x0A   |   Authentication       | This document |
             +----------+------------------------+---------------+
                   RPL Control Message Option


5.2  New Registry for the Code Value Type 

   IANA is requested to create a registry for the Code Value Type Field,
   which is contained in the Authentication option.

   New values may be allocated only by an IETF Review.  Each value
   should be tracked with the following qualities:

   o  Value

   o  Code Value Type

   o  Defining RFC

   The following bits are currently defined:

             +-----+-------------------------------+---------------+
             |Value|      Code Value Type          |  Reference    |
             +-----+-------------------------------+---------------+
             |   0 |Version Number Hash Chain Value| This document |
             |     |                               |               |
             |   1 |Version Number Hash Chain Root | This document |
             |     |                               |               |
             |   2 |Rank Hash Chain Value          | This document |
             |     |                               |               |
             |   3 |MAC of Max Rank Hash Value     | This document |
             |     |                               |               |
             |   4 |Integrity Protection Value     | This document |
             |     |                               |               |
             | else|Unassigned                     | This document |
             |     |                               |               |
             +-----+-------------------------------+---------------+

                   Code Field in  Authentication Option
 


Dvir, et al.                 July 11, 2012                     [Page 19]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


5.3  New Registry for the Algorithm Type

   IANA is requested to create one registry for the Algorithm Field per
   allocated Code value

   New values may be allocated only by an IETF Review.  Each value
   should be tracked with the following qualities:

   o  Code Value

   o  Algorithm Value

   o  Capability description

   o  Defining RFC

   The following bits are currently defined:

             +------+-----+--------------------------+--------------+
             | Code |Algo |       Description        |  Reference   |
             +------+-----+--------------------------+--------------+
             | 0    |   0 |SHA-256                   | This document|
             |      |     |                          |              |
             | 0    |   1 |SHA-512                   | This document|
             |      |     |                          |              |
             | 1    |   0 |SHA-256                   | This document|
             |      |     |                          |              |
             | 1    |   1 |SHA-512                   | This document|
             |      |     |                          |              |
             | 2    |   0 |SHA-256                   | This document|
             |      |     |                          |              |
             | 2    |   1 |SHA-512                   | This document|
             |      |     |                          |              |
             | 3    |   0 |HMAC-SHA-256              | This document|
             |      |     |                          |              |
             | 3    |   1 |HMAC-SHA-512              | This document|
             |      |     |                          |              |
             | 4    |   0 |HMAC-SHA-256              | This document|
             |      |     |                          |              |
             | 4    |   1 |HMAC-SHA-512              | This document|
             |      |     |                          |              |
             | 4    |   2 |RSA with SHA-256          | This document|
             |      |     |                          |              |
             | 4    |   3 |ECC-SECP256K1 with SHA-256| This document|
             |      |     |                          |              |
             |else  |else |Unassigned                | This document|
             +------+-----+--------------------------+--------------+

 


Dvir, et al.                 July 11, 2012                     [Page 20]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


             Security Algorithm Field in Authentication Option

6  Acknowledgements

   The work described in this paper is based on results of the WSAN4CIP
   project, which receives research funding from the European
   Community's 7th Framework Programme.  Apart from this, the European
   Commission has no responsibility for the content of this document. 
   Amit Dvir has also been supported by the Marie Curie Mobility Grant,
   OTKA-HUMAN-MB08-B 81654 and Levente Buttyan has been supported by the
   Hungarian Academy of Sciences through the Bolyai Janos Research
   Fellowship.  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-19 (work in 
              progress), Sept 2011.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, March  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-06 (work
              in progress), March 2012.

 


Dvir, et al.                 July 11, 2012                     [Page 21]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


   [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-06,
              (work in progress) December 2011.

   [draft-ietf-roll-minrank-hysteresis]
              Gnawali, O., and P. Levis, "The Minimum Rank Objective 
              Function with Hysteresis", draft-ietf-roll-minrank
              -hysteresis-of-04 (work in progress), Nov 2011.

   [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.

   [RFC4868]  Kelly, S., and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.

   [FC_Code]  Francillon, A., C. Castelluccia, "Code injection attacks
              on harvard-architecture devices", ACM conference on
              Computer and communications security, pp. 15-25, 2008,
              Virginia, USA. 

   [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.

   [Tamper]   Anderson, R., and M. Kuhn, "Tamper Resistance - a
              Cautionary Note", USENIX Workshop on Electronic Commerce
              Proceedings, pp 1-11, 1996, Oakland, California.

   [L1981]    Lamport L., "Password Authentication with Insecure
              Communication", ACM Journal of Communications Volume 24
 


Dvir, et al.                 July 11, 2012                     [Page 22]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


              Issue 11, pp 770-772, Nov. 1981.

   [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,
              <http://www.nist.gov/itl/upload/fips180-3_final.pdf>.

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

              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

 


Dvir, et al.                 July 11, 2012                     [Page 23]

INTERNET DRAFT   Version Number and Rank Authentication  January 8, 2012


              EMail: buttyan@crysys.hu


















































Dvir, et al.                 July 11, 2012                     [Page 24]