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]
