Minimal Security rekeying mechanism for 6TiSCH
draft-richardson-6tisch-minimal-rekey-01
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2017-02-25
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
xml
pdf
html
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
6TiSCH Working Group M. Richardson
Internet-Draft Sandelman Software Works
Intended status: Standards Track February 25, 2017
Expires: August 29, 2017
Minimal Security rekeying mechanism for 6TiSCH
draft-richardson-6tisch-minimal-rekey-01
Abstract
This draft describes a mechanism to rekey the networks used by 6TISCH
nodes. It leverages the security association created during an
enrollment protocol. The rekey mechanism permits incremental
deployment of new sets of keys, followed by a rollover to a new key.
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 August 29, 2017.
Copyright Notice
Copyright (c) 2017 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.
Richardson Expires August 29, 2017 [Page 1]
Internet-Draft 6tisch-minimal-rekey February 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. An approach to rekeying . . . . . . . . . . . . . . . . . . . 3
4. YANG model for keys . . . . . . . . . . . . . . . . . . . . . 4
5. YANG model for short-address . . . . . . . . . . . . . . . . 6
6. Security of CoMI link . . . . . . . . . . . . . . . . . . . . 8
7. Rekey of master connection . . . . . . . . . . . . . . . . . 8
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
6TiSCH networks of nodes often use a pair of keys, K1/K2 to
authenticate beacons (K1), encrypt broadcast traffic (K1) and encrypt
unicast traffic (K2). These keys need to occasionally be refreshed
for a number of reasons:
o cryptographic hygiene: the keys must be replaced before the ASN
roles over or there could be repeated use of the same key.
o to remove nodes from the group: replacing the keys excludes any
nodes that are suspect, or which are known to have left the
network
o to recover short-addresses: if the JRC is running out of short
(2-byte) addresses, it can rekey the network in order to garbage
collect the set of addresses.
This protocol uses the CoMI [I-D.ietf-core-comi] to present the set
of 127 key pairs.
In addition to providing for rekey, this protocol includes access to
the allocated short-address.
2. 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 [RFC2119]. These
Richardson Expires August 29, 2017 [Page 2]
Internet-Draft 6tisch-minimal-rekey February 2017
Show full document text