SSE BOF R. Moskowitz
Internet-Draft Huawei
Intended status: Standards Track S. Hares
Expires: January 4, 2018 Hickory Hill Consulting
L. Xia
Huawei
July 3, 2017

Secure Session Layer Services KMP via HIP
draft-moskowitz-ssls-iot-00

Abstract

This memo addresses the need for secure, end-to-end communications from IoT devices to collectors, where the IoT devices many be too resource constrained for typical IETF solutions or may be deployed over non-IP networks (e.g. CAN FD, IEEE 802.15.6, serial SCADA). For such deployments, the Secure Session Layer Service [draft-hares-ssls-00] the needed, and sufficient features to ensure successful and safe communications.

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 4, 2018.

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.


Table of Contents

1. Introduction

The IETF has a plethora of security solutions targeted at IoT. Yet all too many IoT products are deployed with no or improperly configured security. In particular resource constrained IoT devices and non-IP IoT networks have not been well served in the IETF.

This effort focuses on a minimal-to-have set of security features and related communications functions for these special, yet rather common collection of IoT devices. This effort need not be restricted to these special cases; it will work for any IoT device on any network. The goal is that all are serviced and protected.

A IoT device can be resource constrained by its CPU, memory, and/or power. Any one of these could result in non-applicablity of common secure communications tools. All three together occurs in many devices. The IoT network can be constrained by bandwidth, MTU, and/or high packet loss. An additional set of constraints can be legal; in terms of mandated end-to-end privacy (e.g. HIPPA).

All this points to a need for a constrained solution for constrained environments.

2. Terms and Definitions

2.1. Requirements 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.

2.2. Notations

This section will contain notations

2.3. Definitions

TBD

3. Minimal feature set

Minimal still implies something done. In this case that something is:

Secure communications envelope:
The data on the 'wire' must at least have a cryptographic integrity check and optionally content privacy.
Security key management:
The keying material for securing the communications envelope must be fresh and unique.
Unique device Identity:
The device must have an Identity that uniquely identifies it in a trusted manner.

Minimal means the least amount of tools and one for each function, with perhaps one for many functions. Much of this is standard, but later will be shown how to minimize its size and performance impact.

ECC for Identity:
An Eliptic Curve public key can be the base of the Identity.
ECC key management:
ECC can be 'reused' for the key management protocol.
Symmetric cryptography for message protection:
Four functions are needed: privacy, integrity, hashing, randomness.
Message management:
Three functions are needed: data chunking, message fragmentation/reassembly, and receipt acknowledgment. Data compression is an optional fourth function.

ECC has been perceived as still too much. It does set a barrier of an 8-bit CPU, time and memory. ECDH based on ECC25519 [RFC7748] has been implemented on 8-bit CPUs, running 9 seconds.

HIP DEX [I-D.ietf-hip-dex] is a minimalist KMP and defined for application use in [I-D.moskowitz-ssls-hip].

The Secure Session Layer Services (SSLS) [draft-hares-ssls-00] provides a well defined session layer that can be implemented in any application to provide any or all of the following:

4. IANA Considerations

TBD. May be nothing for IANA.

5. Security Considerations

TBD.

6. Acknowledgments

TBD

7. References

7.1. Normative References

[I-D.hares-i2nsf-ssls] Hares, S. and R. Moskowitz, "Secure Session Layer Services", Internet-Draft draft-hares-i2nsf-ssls-00, March 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC7401] Moskowitz, R., Heer, T., Jokela, P. and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015.
[RFC7402] Jokela, P., Moskowitz, R. and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015.

7.2. Informative References

[I-D.ietf-hip-dex] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Internet-Draft draft-ietf-hip-dex-05, February 2017.
[I-D.moskowitz-ssls-hip] Moskowitz, R., Xia, L., Faynberg, I., Hares, S. and P. Giacomin, "Secure Session Layer Services KMP via HIP", Internet-Draft draft-moskowitz-ssls-hip-02, June 2017.
[RFC7748] Langley, A., Hamburg, M. and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016.

Authors' Addresses

Robert Moskowitz Huawei Oak Park, MI 48237 EMail: rgm@labs.htt-consult.com
Susan Hares Hickory Hill Consulting 7453 Hickory Hill Saline, MI 48176 USA EMail: shares@ndzh.com
Liang Xia Huawei No. 101, Software Avenue, Yuhuatai District Nanjing, China EMail: Frank.xialiang@huawei.com