One document matched: draft-struik-6tisch-security-architecture-elements-00.txt
6TiSCH R. Struik
Internet-Draft Struik Security Consultancy
Intended status: Informational July 4, 2014
Expires: January 5, 2015
6TiSCH Security Architectural Elements
draft-struik-6tisch-security-architecture-elements-00
Abstract
This document describes security architectural elements that are
relevant for the design of the 6TiSCH security architecture. (Note:
this document is a work-in-progress and will provide more fine-tuned
information with updated versions.)
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
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 January 5, 2015.
Copyright Notice
Copyright (c) 2014 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
Struik Expires January 5, 2015 [Page 1]
Internet-Draft 6tisch-security-architecture July 2014
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. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Device Roles . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Initiator and Responder Model . . . . . . . . . . . . . . 3
1.3. Cautionary Note - on Limitations of Cryptography . . . . 3
1.4. Desired Protocol Properties . . . . . . . . . . . . . . . 3
1.5. Device Enrolment Phases . . . . . . . . . . . . . . . . . 4
1.6. Security Definitions . . . . . . . . . . . . . . . . . . 5
1.7. Deployment Scenarios . . . . . . . . . . . . . . . . . . 6
2. Security Considerations . . . . . . . . . . . . . . . . . . . 7
3. Other Related Protocols . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative references . . . . . . . . . . . . . . . . . . 7
6.2. Informative references . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Preliminaries
1.1. Device Roles
When discussing security operations, it is useful to distinguish
various device roles. Here, one should note that a device may assume
more than one device role at the same time and that a particular role
may be assumed by more than one device. Moreover, the mapping of
device roles to devices may change over time (along a device's or
network's lifecycle).
We distinguish the following roles:
1. Client. This device may move in and out of networks (that may be
alien to it) and may have little network management functionality
on board. Key words: nomadic, promiscuous, constrained.
2. Access point. This device may be more tied into a relatively
stable infrastructure and may have more support for network
management functionality or have reliable access hereto (e.g.,
via a back-end system). Key words: anchor, semi-stable
connectivity, access portal.
Struik Expires January 5, 2015 [Page 2]
Internet-Draft 6tisch-security-architecture July 2014
3. Server. This device provides stable infrastructure and network
management support, either intra-domain or inter domain (thereby,
offering homogeneous or even heterogeneous functionality). Key
words: core function, high availability, human-operator support.
4. CA. This device vouches for trust credentials, usually in
offline way. Key words: trust anchor.
1.2. Initiator and Responder Model
All peer-to-peer protocols are role-symmetrical (i.e., the role of
initiator/responder roles are interchangeable). Protocols involving
a third party assume communications with this third party to take
place via the access point (since being the device more tied into
infrastructure).
1.3. Cautionary Note - on Limitations of Cryptography
Cryptographic techniques may provide logical assurances as to a
device's identity, where and when communications originated, whom it
was intended for, whom this can be read by, etc.
Cryptographic techniques do, however, only provide mechanical
assurances and can generally not substitute human authorization
decision elements (unless the latter are not important, such as with
random, ad-hoc networks).
1.4. Desired Protocol Properties
Security-Related:
1. Parties executing a security protocol should be explicitly aware
of its security properties
2. Compromise of keys or devices should have limited effect on
security of other devices or services
3. Attacks should not have a serious impact beyond the time
interval/space during/in which these take place
4. Security protocols should minimize the impact of network outages,
denial of service attacks
Communication Flows:
1. Security protocols should allow to be run locally, without third
party involvement, if at all possible
Struik Expires January 5, 2015 [Page 3]
Internet-Draft 6tisch-security-architecture July 2014
2. The number of message exchanges for a joining client device
should be reduced
3. Message exchanges should be structured so as to allow parallel
execution of protocol steps, if possible
Computational Cost:
1. Security protocols should not impose an undue computational
burden, esp. on joining client devices (An exception here may
arise, when recovering from an event seriously impacting
availability of the network.)
Device Capabilities:
1. Dependency on an accurate time-keeping mechanism should be
reduced
2. Computational/time latency trade-offs should be tweaked to
benefit those of joining client, if possible
3. Dependency on "homogeneous trust models" should be reduced,
without jeopardizing security properties
4. Dependency on on-board trusted platforms and trusted I/O
interfaces should be reduced
1.5. Device Enrolment Phases
1. Device Authentication. Client A and Access Point B authenticate
each other and establish a shared key (so as to ensure on-going
authenticated communications). This may involve server KDC as
third party.
2. Authorization. Access Point B decides on whether/how to
authorize device A (if denied, this may result in loss of
bandwidth). Authorization decision may be delegated to server
KDC or other 3rd-party device.
3. Configuration/Parameterization. Access Point B distributes
configuration information to Client A, such as
* IP address assignment info;
* Bandwidth/usage constraints;
* Scheduling info (including on re-authentication policy
details)
Struik Expires January 5, 2015 [Page 4]
Internet-Draft 6tisch-security-architecture July 2014
This may originate from other network devices, for which it acts
as proxy. This step may also include distribution of information
from Client A to Access Point B and, more generally,
synchronization of information between these two entities.
The device enrollment process is depicted in Figure Figure 1, where
it is assumed that devices have access to certificates and where
entities have access to the root CA key of its communicating parties
(initial set-up requirement). Under these assumptions, the
authentication step of the device enrollment process does not require
online involvement of a third party.
{joining node} {neighbor} {server, etc.}
+---------+ +---------+ +---------+
| Client | | Access | +--| CA |e.g., certificate
| A | | Point B | | +---------+ issuance
+---------+ +---------+ | +---------+
| | +--|Authoriz.|e.g., membership
|<----Beaconing------| | +---------+ test
| | | +---------+
|<--Authentication-->| +--| Routing |e.g., IP address
| |<--Authorization-->| +---------+ assignment
|<-------------------| | +---------+
| | +--| Gateway |e.g., backbone,
|------------------->| | +---------+ cloud
| |<--Configuration-->| +---------+
|<-------------------| +--|Bandwidth|e.g., PCE schedule
. . . +---------+
. . .
Figure 1: Networking Joining, with Only Authorization by Third Party
Aggressive scheme: Initiate authorization/configuration processes as
soon as (presumed) device identity becomes available (invisible to
Client A). Access Point B can deny bandwidth if authorization
negative.
Note: Communication of configuration info depends on secure channel
with Client A.
1.6. Security Definitions
1. Key Establishment: Protocol whereby a shared secret becomes
available to two or more parties for subsequent cryptographic
use
Struik Expires January 5, 2015 [Page 5]
Internet-Draft 6tisch-security-architecture July 2014
2. Key Transport: Key establishment technique where one party
creates/obtains the secret and securely transfers it to other(s)
3. Key Agreement: Key establishment technique where the shared
secret is derived based on information contributed by each of
the parties involved, ideally so that no party can predetermine
this secret value
4. Implicit Key Authentication: Assurance as to which specifically
identified parties possibly may gain access to a specific key
5. Key Confirmation: Assurance that second (possibly unknown) party
has possession of a particular key
6. Explicit Key Authentication: Combination of implicit key
authentication and key confirmation
7. Unilateral Key Control: Key establishment protocol whereby one
party can influence the shared secret
8. Forward Secrecy: Assurance that compromise of long-term keys
does not compromise past session keys
9. Entity Authentication: Assurance of active involvement of second
explicitly identified party in protocol
10. Mutual vs. Unilateral: Adjective indicating symmetry, resp.
asymmetry, of assurances amongst parties
11. Identity Protection: Assurance as to which specifically
identified parties may gain access to identity info
12. Certificate ? Credential that vouches for authenticity of
binding between a public key and other information, including
the identity of the owner of the public key in question
13. Key Possession? Assurance that a specific (possibly unknown)
party has possession of a particular key
Esoteric properties: Unknown Key Share Resilience, Session Key
Retrieval, Key Compromise Impersonation
1.7. Deployment Scenarios
Deployment scenarios discussed with industrial control user
community:
1. Scenario #1: mix-and-match of nodes from different vendors
Struik Expires January 5, 2015 [Page 6]
Internet-Draft 6tisch-security-architecture July 2014
2. Scenario #2: addition of nodes to operational network
3. Scenario #3: security audit
4. Scenario #4: device repair and replacement (roaming in/out
different user sites)
5. Scenario #5: network separation (devices joining wrong network)
6. Scenario #6: thwarting malicious attacks by (former) insiders
7. Scenario #7: thwarting attacks by outsiders via insiders (held at
'gunpoint')
8. Scenario #8: addition of subsystem ('skid') assembled elsewhere
to operational network
2. Security Considerations
This document is all about security.
3. Other Related Protocols
4. IANA Considerations
5. Acknowledgements
Discussions amongst participants in the 6TiSCH security conference
calls to-date helped to shape this document.
6. References
6.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012.
Struik Expires January 5, 2015 [Page 7]
Internet-Draft 6tisch-security-architecture July 2014
[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Using Raw Public Keys in Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7250, June 2014.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
[I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-00 (work
in progress), May 2014.
[I-D.ietf-6tisch-architecture]
Thubert, P., Watteyne, T., and R. Assimiti, "An
Architecture for IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-architecture-02 (work in
progress), June 2014.
[I-D.wang-6tisch-6top-sublayer]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top)", draft-wang-6tisch-6top-
sublayer-00 (work in progress), February 2014.
[I-D.ietf-6tisch-6top-interface]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Interface", draft-ietf-6tisch-
6top-interface-00 (work in progress), March 2014.
6.2. Informative references
[I-D.garcia-core-security]
Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-garcia-core-security-06 (work
in progress), September 2013.
[I-D.ietf-dice-profile]
Hartke, K. and H. Tschofenig, "A DTLS 1.2 Profile for the
Internet of Things", draft-ietf-dice-profile-01 (work in
progress), May 2014.
[I-D.kumar-dice-dtls-relay]
Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay
for Constrained Environments", draft-kumar-dice-dtls-
relay-01 (work in progress), April 2014.
Struik Expires January 5, 2015 [Page 8]
Internet-Draft 6tisch-security-architecture July 2014
[I-D.thubert-6lowpan-backbone-router]
Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
6lowpan-backbone-router-03 (work in progress), February
2013.
[IEEE802.15.4-2011]
Institute for Electrical and Electronics Engineers, "IEEE
802.15.4-2011, IEEE Standard for Local and Metropolitan
Area Networks - Part 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs)", September 2011.
[IEEE802.15.4e-2012]
Institute for Electrical and Electronics Engineers, "IEEE
802.15.4e-2012, IEEE Standard for Local and Metropolitan
Area Networks - Part 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs), Amendment 1: MAC Sublayer", April
2012.
[Wireless-HART]
International Electrotechnical Commission, "IEC 62591, Ed.
2.0: Industrial Communication Networks - Wireless
Communication Network and Communication Profiles -
WirelessHART (Draft)", November 2013.
[ISA100.11a]
International Electrotechnical Commission, "IEC 62734, Ed.
1: Industrial Communication Networks - Wireless
Communication Network and Communication Profiles - ISA
100.11a (Draft)", May 2013.
[ZigBee-IP]
ZigBee Alliance, "ZigBee IP Specification (ZigBee Public
Document 13-002r00)", February 2013.
Author's Address
Rene Struik
Struik Security Consultancy
Email: rstruik.ext@gmail.com
Struik Expires January 5, 2015 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 03:58:30 |