TLS 1.3 Authentication and Integrity only Cipher Suites
draft-camwinget-tls-ts13-macciphersuites-07

Document Type Active Internet-Draft (individual)
Last updated 2020-08-28
Stream ISE
Intended RFC status Informational
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Reviews
Stream ISE state In ISE Review
Consensus Boilerplate Unknown
Document shepherd Adrian Farrel
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to Adrian Farrel <rfc-ise@rfc-editor.org>
TLS                                                        N. Cam-Winget
Internet-Draft                                             Cisco Systems
Intended status: Informational                                 J. Visoky
Expires: March 1, 2021                                              ODVA
                                                         August 28, 2020

        TLS 1.3 Authentication and Integrity only Cipher Suites
              draft-camwinget-tls-ts13-macciphersuites-07

Abstract

   There are use cases, specifically in Internet of Things (IoT) and
   constrained environments that do not require confidentiality, though
   message integrity for all communications and mutual authentication
   during tunnel establishment are both still mandated.  Examples of
   such use cases are given, although a threat model is necessary to
   determine whether or not a given situation falls into this catergory
   of use cases.  In order to serve these use cases, this document
   defines the use of HMAC only cipher suites for TLS 1.3, which
   provides mutual authentication and data authenticity, but not data
   confidentiality.  The approach described in this document is not
   endorsed by the IETF and does not have IETF consensus, but is
   presented here to enable interoperable implementation of a reduced
   security mechanism that provides authentication and message integrity
   without supporting confidentiality.

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 https://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 March 1, 2021.

Cam-Winget & Visoky       Expires March 1, 2021                 [Page 1]
Internet-Draft                 IoT Ciphers                   August 2020

Copyright Notice

   Copyright (c) 2020 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
   (https://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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   3
   4.  Cryptographic Negotiation Using Integrity only Cipher Suites    5
   5.  Record Payload Protection for Integrity only Cipher Suites  .   5
   6.  Key Schedule when using Integrity only Cipher Suites  . . . .   6
   7.  Error Alerts  . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security and Privacy Considerations . . . . . . . . . . . . .   7
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative Reference  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   There are several use cases in which communications privacy is not
   strictly needed, although authenticity of the communications
   transport is still very important.  For example, within the
   Industrial Automation space there could be TCP or UDP communications
   which command a robotic arm to move a certain distance at a certain
   speed.  Without authenticity guarantees, an attacker could modify the
   packets to change the movement of the robotic arm, potentially
   causing physical damage.  However, the motion control commands are
   not considered to be sensitive information and thus there is no
   requirement to provide confidentiality.  Another IoT example with no
   strong requirement for confidentiality is the reporting of weather
   information; however, message authenticity is required to ensure
   integrity of the message.

Cam-Winget & Visoky       Expires March 1, 2021                 [Page 2]
Show full document text