TLS 1.3 Authentication and Integrity only Cipher Suites
draft-camwinget-tls-ts13-macciphersuites-08
|
Document |
Type |
|
Active Internet-Draft (individual)
|
|
Authors |
|
Nancy Cam-Winget
,
Jack Visoky
|
|
Last updated |
|
2021-02-07
(latest revision 2020-10-21)
|
|
Stream |
|
ISE
|
|
Intended RFC status |
|
Informational
|
|
Formats |
|
plain text
xml
pdf
htmlized (tools)
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
ISE state
|
|
Response to Review Needed
Revised I-D Needed
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
Adrian Farrel
|
IESG |
IESG state |
|
I-D Exists::Revised I-D Needed
|
|
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: April 24, 2021 ODVA
October 21, 2020
TLS 1.3 Authentication and Integrity only Cipher Suites
draft-camwinget-tls-ts13-macciphersuites-08
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 April 24, 2021.
Cam-Winget & Visoky Expires April 24, 2021 [Page 1]
Internet-Draft IoT Ciphers October 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 . . . . 7
7. Error Alerts . . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security and Privacy Considerations . . . . . . . . . . . . . 8
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 April 24, 2021 [Page 2]
Show full document text