6TSCH S. Chasko
Internet-Draft L+G
Intended status: Informational S. Das
Expires: December 26, 2013 ACS
R. Marin-Lopez
University of Murcia
Y. Ohba, Ed.
Toshiba
P. Thubert
cisco
A. Yegin
Samsung
June 24, 2013
Security Framework and Key Management Protocol Requirements for 6TSCH
draft-ohba-6tsch-security-00
Abstract
Since 6TSCH forms layer 3 meshes over IPv6, PANA model matches the
target architecture so PANA can apply for the process by a new device
of joining the mesh to extend it. This document details that
particular operation within the whole 6TSCH architecture.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chasko, et al. Expires December 26, 2013 [Page 1]
Internet-Draft 6tsch-security June 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Framework . . . . . . . . . . . . . . . . . . . . . 3
4. KMP requirements . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Phase-1 KMP requirements . . . . . . . . . . . . . . . . 6
4.2. Phase-2 KMP requirements . . . . . . . . . . . . . . . . 6
5. KMP candidates . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Phase-1 KMP candidates . . . . . . . . . . . . . . . . . 7
5.2. Phase-2 KMP candidates . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
8.3. External Informative References . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The emergence of radio technology enabled a large variety of new
types of devices to be interconnected, at a very low marginal cost
compared to wire, at any range from Near Field to interplanetary
distances, and in circumstances where wiring could be less than
practical, for instance rotating devices.
At the same time, a new breed of Time Sensitive Networks is being
developed to enable traffic that is highly sensitive to jitter and
quite sensitive to latency. Such traffic is not limited to voice and
video, but also includes command and control operations such as found
in industrial automation or in-vehicular sensors and actuators.
Chasko, et al. Expires December 26, 2013 [Page 2]
Internet-Draft 6tsch-security June 2013
6TSCH builds on a series of semi-proprietary wireless protocols that
provide adequate Time Sensitive behaviors for low speed control
loops, protocols that are rapidly gaining acceptance in the
automation industry for mission critical Process Control
applications. For such applications, security is not an option and a
power efficient authentication mechanism is strictly required.
Following Metcalf's law, value of using radios augments with the
square of the number of devices connected, and this implies the
capability to form autonomic mesh networks be it only for reasons of
spatial reuse of the spectrum. Since 6TSCH forms layer 3 meshes over
IPv6, the PANA model matches the target architecture so PANA can
apply for the process by a new device of joining the mesh to extend
it.
ZigBee IP [ZigBeeIP] ("ZigBee" is a registered trademark of the
ZigBee Alliance) is a standard for IPv6-based wireless mesh networks
using PANA for network access authentication and secure distribution
of a link-layer group key called Network Key to authenticated mesh
nodes. Each mesh node in the same ZigBee IP network derives the same
MAC key from the Network Key to protect IEEE 802.15.4 MAC frames
exchanged between adjacent mesh nodes. While sharing the same MAC
key among all mesh nodes can make the required key state maintained
by each mesh node compact, a compromise of a mesh node can lead to
MAC key leakage in the entire ZigBee IP network. Also, the cost of
updating the MAC key can be high as the key needs to be updated at
all mesh nodes whenever the frame counter at any single node wraps up
or the key is considered to be weak.
This document introduces a more secure and scalable key management
framework for 6TSCH networks using PANA as the boostrapping mechansim
and identifies requirements for key management protocols to be used
in the framework.
2. Acronyms
6TSCH: TBD (Editor's note: what is the expansion of 6TSCH?)
KMP: Key Managment Protocol
PANA: Protocol for carrying Authentication for Network Access
SA: Security Association
MAC: Media Access Control
3. Security Framework
Chasko, et al. Expires December 26, 2013 [Page 3]
Internet-Draft 6tsch-security June 2013
This section describes a security framework consisting of three
phases as shown in Figure 1. The architecture is applicable to not
only 6TSCH networks but also non-time synchronized mesh networks.
Each node in a mesh network runs through the following phases:
o Phase-1 (Bootstrapping Phase): In this phase, a node (re)installs
credentials used for subsequent phases from an authentication
server. The credentials include Phase-2 credentials and Phase-3
credentials, and may also include long-term Phase-1 credentials if
the initial Phase-1 credentials are intended for one-time use such
as a temporal PIN. An authentication and key establishment
protocol called a Phase-1 KMP is conducted between the node and
the authentication server using Phase-1 credentials. The Phase-1
credentials have longer lifetime than Phase-2 and Phase-3
credentials so that Phase-2 and Phase-3 credentials can be renewed
using the Phase-1 credentials. Both symmetric and asymmetric key
credentials can be used as Phase-1 credentials. A symmetric key
that is established as a result of successful Phase-1 KMP is used
for encrypting the Phase-2 and Phase-3 credentials distributed
from the authentication server to the node. When the
authentication server is multiple hops away from the node, mutual
authentication between the node and the authentication server is
conducted via a neighboring node acting as an authentication
relay. There may be no link-layer security available between the
node and its neighboring node in this phase. An authentication
server is typically (but is not necessarily) located in the
coordinator of the mesh network.
o Phase-2 (Link Establishment Phase): In this phase, the node
performs mutual authentication with its neighboring node using the
Phase-2 credentials to establish SAs between adjacent nodes for
protecting 802.15.4 MAC frames. The authentication and key
establishment protocol used in this phase is referred as a Phase-2
KMP or a link establishment KMP. For highly scalable mesh
networks consisting of thousands of mesh nodes, asymmetric key
credentials are used as the Phase-2 credentials. The SA of a link
between node i and node j maintains MAC keys. K_i denotes a MAC
key for protecting broadcast MAC frames originated at node i.
K_ij denotes a MAC key for protecting unicast MAC frames
originated at node i and destined for node j. There are several
variations of forming MAC keys.
1. K_ij=K_i for all j, K_i!=K_j for all i, j (i!=j)
2. K_ij=K_ji, K_i!=K_j for all i,j (i!=j)
3. K_ij!=K_ji, K_i!=K_j for all i,j (i!=j)
Chasko, et al. Expires December 26, 2013 [Page 4]
Internet-Draft 6tsch-security June 2013
In model 1, unicast and broadcast keys for protecting MAC frames
originated at a given node are the same. In models 2 and 3,
unicast and broadcast keys originated at a given node are
distinct. The difference between models 2 and 3 is that unicast
keys are bi-directinal in model 2 while they are uni-directinal in
model 3. One model may be chosen among three depending on
required security level and the number of keys maintained by each
node.
o Phase-3 (Operational Phase): In this phase, the node is able to
run various higher-layer protocols over IP over an established
secure link. Additional authentication and key establishment may
take place for the higher-layer protocols using Phase-3
credentials. A node in Phase-3 is able to process Phase-1 and
Phase-2 KMPs. Example use cases are:
* A Phase-3 node can initiate a Phase-1 KMP to update its Phase-2
or Phase-3 credentials.
* A Phase-3 node can forward Phase-1 KMP messages originated from
or destined for a Phase-1 node that is joining the mesh network
through the Phase-3 node.
* A Phase-3 node can initiate a Phase 2 KMP to establish a new
link with a newly discovered neighbor node.
+---------------------------------+
| Phase-1 (Bootstrap) |
+---------------------------------+
|
v
+---------------------------------+
| Phase-2 (Link Establishment) |
+---------------------------------+
|
v
+---------------------------------+
| Phase-3 (Operational) |
+---------------------------------+
Figure 1: 3-Phase Key Management Model
N)s - Node N is running Phase-1 KMP as a server
N)c - Node N is running Phase-1 KMP as a client
N)r - Node N is running Phase-1 KMP as a relay
N)) - Node N is running Phase-2 KMP
. .. ...
N, N, N - Node N is in Phase-1, -2 and -3, respectively
Chasko, et al. Expires December 26, 2013 [Page 5]
Internet-Draft 6tsch-security June 2013
. . .. ... ... ...
A A)s A)) A)s A A
/ \ / \ / \ / \ / \
. . . . .. .. ... ... ... ... ... ...
B C B)c C)c B)) C)) B)r C B)) C)) B C
/ \ / / \ / / \ /
. . . . . . . . .. .. ... ...
D E D E D E D)c E)c D)) E)) D E
(0) -> (1) -> (2) -> (3) -> (4) -> (5)
(0) Initially all nodes but Node A (i.e., the authentication server)
are in Phase-1. (1) Nodes B and C run Phase-1 KMP with Node A to
obtain Phase-2 and Phase-3 credentials. (2) Nodes B and C run
Phase-2 KMP with Node A. (3) Nodes D and E run Phase-1 KMP using
Node B as an authentication relay. (Alternatively, Node E may use
Node C as an authentication relay.) (4) Node D runs Phase-2 KMP with
Node B. Node E runs Phase-2 KMP with Nodes B and C. (5) All nodes
are operational.
Figure 2: Example Sequence
Since we already identified PANA as the Phase-1 KMP due to its
authentication relay and secure credential distribution capabilities,
and Phase-3 KMP requirements would depend on application protocols,
we focus on Phase-2 KMP requirements in the next seciton.
4. KMP requirements
4.1. Phase-1 KMP requirements
Requirements on Phase-1 KMP are listed below.
R1-1: Phase-1 KMP MUST support mutual authentication.
R1-2: Phase-1 KMP MUST support stateless authentication relay
operation.
R1-3:s Phase-1 KMP MUST support secure credential distribution.
4.2. Phase-2 KMP requirements
Requirements on Phase-2 KMP are listed below.
R2-1: Phase-2 KMP Nodes MUST mutually authenticate each other before
establishing a link and forming a mesh network. No authentication
server is involved in the Phase-2 authentication.
Chasko, et al. Expires December 26, 2013 [Page 6]
Internet-Draft 6tsch-security June 2013
R2-2: Phase-2 KMP authentication credentials MAY be pre-provisioned
or MAY be obtained via Phase-1 KMP.
R2-3: Phase-2 KMP authentication credentials MUST have a lifetime.
R2-4: Phase-2 KMP MUST support asymmetric key-based credentials for
scalable operation.
R2-5: Phase-2 KMP message exchanges MUST be integrity and reply
protected after successful authentication.
R2-6: Phase-2 KMP MUST have the capability to establish security
association and unicast session keys after successful authentication
to protect unicast MAC frames between nodes.
R2-7: Phase-2 KMP MUST have the capability to establish security
association and broadcast session keys after successful
authentication to protect broadcast MAC frames between nodes.
R2-8: Phase-2 KMP MUST have the capability to distribute the
broadcast session keys securely.
5. KMP candidates
5.1. Phase-1 KMP candidates
PANA [RFC5191] is the Phase-1 KMP candidate since it supports mutual
authenticatio, stateless authentication relay function [RFC6345] and
encrypted distribution of attributes [RFC6786]. The PANA
Authentication Agent (PAA) is located in the coordinator of the mesh
network.
5.2. Phase-2 KMP candidates
Once Phase-1 is complete by using PANA, it is assumed that node will
have a certified public key (and associated private key). A candiate
Phase 2 KMP must use this certified public key to perform an
authentication process. As a consequence of a successful
authentication some cryptographic material for unicast and multicast
link protection between nodes must be generated.
A list of candidate protocols may provide the requirements defined in
Section 4.2 (this is a preliminary list that may be extended in the
future):
o HIP DEX [I-D.moskowitz-hip-rg-dex]. The Host Identity Protocol
Diet EXchange (HIP DEX) is a lighter version of the HIP Base
Exchange (HIP BEX) [I-D.ietf-hip-rfc5201-bis] specifically
Chasko, et al. Expires December 26, 2013 [Page 7]
Internet-Draft 6tsch-security June 2013
designed to be used in constrained devices (e.g sensor networks).
In particular, HIP DEX may be used to authenticate two IEEE
802.15.4 nodes and provide key material for a MAC layer security
protocol as supported in IEEE 802.15.4. However, by just using
the value of the public key and the private key is not enough to
carry out the authentication between nodes. In particular, a node
A and node B should not be able to successfully finish HIP DEX
execution if they both have not been authenticated in Phase-1.
Thus, HIP DEX will require the inclusion of the certificate of
each node to achieve full mutual authentication. The information
in the certificate must ensure that the node was authenticated in
Phase-1. In consequence, HIP DEX must include a CERT parameter
for carrying this certificate. Once the HIP DEX protocol has
succesfully finished a Pair-Wise Key SA is derived. This SA is
used to secure and authenticate user data, thus it can be used to
provide the required keys for protecting IEEE 802.15.4 unicast MAC
frames. The same message is used to refresh the Pair-Wise Key SA.
So far HIP DEX only specifies how this key material is used for
protecting data traffic with ESP. To distribute multicast keys
HIP DEX may also use UPDATE message. For less resource-
constrained devices, HIP-BEX (Basic Exchange) is more suitable
than HIP-DEX since HIP-BEX has better security properties (such as
use of ephemeral Diffie-Hellman) than HIP-DEX at the cost of
increased complexity.
o PANA [RFC5191] and some certificate-based EAP method. Another
candidate is to use PANA between node A and node B. In this case,
one of the nodes (e.g. node A) acts as PaC while the other (e.g.
node B) is acting as PAA. Moreover the PAA will operate in
standalone mode [RFC4137]. That is, the EAP server is placed on
the PAA and not in a backend authentication server. Finally, the
selected EAP method must work with public key/private key
cryptography. Once the PAA authentication is complete, the PaC
and PAA can derive cryptographic material (for instance, from the
MSK) which can be used to protect unicast MAC frames. Futhermore,
by using the extension defined in [RFC6345] is possible to
distribute a multicast key encrypted with the PANA SA. It is
worth noting that, though this candidate solution leverages the
PaC implementation from Phase-1, each node needs to deploy a PAA
implementation, an EAP server and a specific EAP method, which may
be different from the one used for Phase-1.
o DTLS[RFC6347]. Datagram Transport Layer Security (DTLS) is being
considered in constrained devices for protecting application data
traffic (e.g. CoAP). It is not only being considered for unicast
application data traffic but also for multicast data traffic
[I-D.keoh-tls-multicast-security]. In particular, a multicast key
is distributed over an unicast DTLS channel established between
Chasko, et al. Expires December 26, 2013 [Page 8]
Internet-Draft 6tsch-security June 2013
two nodes (node A and node B). This multicast key is used to
protect multicast traffic by using TLS records. The Phase2-KMP
should be able to export this key material to the IEEE 802.15.4
MAC layer so that the protection is carried out at link layer. In
[RFC5705], a mechanism for exporting key material after a TLS/DTLS
execution is defined. Nevertheless, the exported key material is
intended to be used in unicast communications for upper layers or
protocols at upper layers. However, multicast key exportation is
not specified. In principle, this exported key material may be
used for protecting unicast IEEE 802.15.4 MAC frames. However,
this usage and the multicast key exportation for multicast IEEE
802.15.4 protection need further investigation.
6. Security Considerations
In this section, security issues that can potentially impact the
operation of IEEE 802.15.4e TSCH MAC are described.
In TSCH MAC, time synchronization and channel hopping information are
advertised in Enhanced Beacon (EB) frames. The advertised
information is used by mesh nodes to determine the timeslots
available for transmission and reception of MAC frames. A rogue node
can inject forged EB frames and can cause replay and DoS attacks to
TSCH MAC operation. To mitigate such attacks, all EB frames MUST be
integrity protected. While it is possible to use a pre-installed
static key for protecting EB frames to every node, the static key
becomes vulnerable when the associated MAC frame counter continues to
be used after the frame counter wraps. Therefore, the 6TSCH solution
MUST provide a mechanism by which mesh nodes can use the available
time slots to run an authentication and key exchange protocol and
provide intergrity protection to EB frames.
7. IANA Considerations
There is no IANA action required for this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
Chasko, et al. Expires December 26, 2013 [Page 9]
Internet-Draft 6tsch-security June 2013
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA) Relay Element", RFC 6345, August 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for
Carrying Authentication for Network Access (PANA)
Attribute-Value Pairs", RFC 6786, November 2012.
[I-D.moskowitz-hip-rg-dex]
Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-
hip-rg-dex-06 (work in progress), May 2012.
8.2. Informative References
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[I-D.keoh-tls-multicast-security]
Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast
Security for Low-Power and Lossy Networks (LLNs)", draft-
keoh-tls-multicast-security-00 (work in progress), October
2012.
[I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-11 (work in progress), February 2013.
[I-D.draft-palattella-6tsch-terminology]
Chasko, et al. Expires December 26, 2013 [Page 10]
Internet-Draft 6tsch-security June 2013
Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q.
Wang, "Terminology in IPv6 over Time Slotted Channel
Hopping. draft-palattella-6tsch-terminology-00 (work in
progress) ", March 2013.
[I-D.draft-thubert-6tsch-architecture]
Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An
Architecture for IPv6 over Time Synchronized Channel
Hopping. draft-thubert-6tsch-architecture-00 (work in
progress) ", March 2013.
8.3. External Informative References
[IEEE802154e]
IEEE standard for Information Technology, "IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendament 1: MAC sublayer", April
2012.
[IEEE802154]
IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks", June 2011.
[ZigBeeIP]
ZigBee Public Document 15-002r00, "ZigBee IP
Specification", 2013.
Authors' Addresses
Stephen Chasko
Landis+Gyr
3000 Mill Creek Ave.
Alpharetta, GA 30022
USA
Email: Stephen.Chasko@landisgyr.com
Subir Das
Applied Communication Sciences
1 Telcordia Drive
Piscataway, NJ 08854
USA
Email: sdas@appcomsci.com
Chasko, et al. Expires December 26, 2013 [Page 11]
Internet-Draft 6tsch-security June 2013
Rafa Marin-Lopez
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia 30100
Spain
Phone: +34 868 88 85 01
Email: rafa@um.es
Yoshihiro Ohba (editor)
Toshiba Corporate Research and Development Center
1 Komukai-Toshiba-cho
Saiwai-ku, Kawasaki, Kanagawa 212-8582
Japan
Phone: +81 44 549 2127
Email: yoshihiro.ohba@toshiba.co.jp
Pascal Thubert
Cisco Systems, Inc
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@yegin.org
Chasko, et al. Expires December 26, 2013 [Page 12]