Atlanta GA USA sam@samwhited.com https://blog.samwhited.com/

Internet Transport Layer Security This document defines a channel binding type, tls-scram-exporter, that is compatible with SCRAM and TLS 1.3 in accordance with On Channel Binding.

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 . 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 3 November 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 () 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

• .  Introduction
  • .  Conventions and Terminology
• .  The 'tls-scram-exporter' Channel Binding Type
• .  Security Considerations
• .  IANA Considerations
  • .  Registration of Channel Binding Type
  • .  Registration of Channel Binding TLS Exporter Label
• .  References
  • .  Normative References
  • .  Informative References
• Author's Address

Introduction After problems were found with the channel binding types defined in they were not defined for TLS 1.3. To facilitate channel binding with TLS 1.3, a new channel binding type using keying material obtained from is needed.

Conventions and Terminology Throughout this document the acronym "EKM" is used to refer to Exported Keying Material as defined in . 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 BCP 14 when, and only when, they appear in all capitals, as shown here.

The 'tls-scram-exporter' Channel Binding Type IANA will register the 'tls-scram-exporter' channel binding type to match the description below. Description: The EKM value obtained from the current TLS connection. The EKM is obtained using the keying material exporters for TLS as defined in by supplying the following inputs. The definition of "client-first-message-bare" and "server-first-message" can be found in .

Label:

The ASCII string "EXPORTER-SCRAM-Channel-Binding" with no terminating NUL.

Context value:

client-first-message-bare + "," + server-first-message

Length:

32 bytes.

When TLS renegotiation is enabled channel binding using the "tls-scram-exporter" type is not define and MUST NOT be supported.

Security Considerations While it is possible to use this channel binding mechanism with TLS versions below 1.3, extra precaution must be taken to ensure that the chosen cipher suites always result in unique master secrets. For more information see the Security Considerations section of . The Security Considerations sections of , , , and apply to this document.

IANA Considerations

Registration of Channel Binding Type This document adds the following registration in the "Channel-Binding Types" registry:

Subject:

Registration of channel binding tls-scram-exporter

Channel binding unique prefix:

tls-scram-exporter

Channel binding type:

unique

Channel type:

TLS

Published specification:

draft-whited-tls-channel-bindings-for-tls13-00

Channel binding is secret:

no

Description:

<See specification>

Intended usage:

COMMON

Person and email address to contact for further information:

Sam Whited <sam@samwhited.com>.

Owner/Change controller name and email address:

IESG.

Expert reviewer name and contact information:

IETF TLS WG (tls@ietf.org, failing that, ietf@ietf.org).

Note:

See the published specification for advice on the applicability of this channel binding type.

Registration of Channel Binding TLS Exporter Label This document adds the following registration in the "TLS Exporter Labels" registry:

Value:

EXPORTER-SCRAM-Channel-Binding

DTLS-OK:

Y

Recommended:

N

Reference:

This document

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits. This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK] A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Informative References This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding). Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]

Author's Address

Atlanta GA USA sam@samwhited.com https://blog.samwhited.com/