Deprecating TLS 1.0 and TLS 1.1Center for Internet Security (CIS)East GreenbushNYUnited States of AmericaKathleen.Moriarty.ietf@gmail.comTrinity College DublinDublin2Ireland+353-1-896-2354stephen.farrell@cs.tcd.ie
Security Area
Internet Engineering Task ForceTLSdeprecateTLSv1.0TLSv1.1
This document formally deprecates Transport Layer
Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
Accordingly, those documents have been moved
to Historic status. These versions lack support for current
and recommended cryptographic algorithms and mechanisms, and
various government and industry profiles of applications using
TLS now mandate avoiding these old TLS versions. TLS version 1.2
became the recommended version for IETF protocols in 2008
(subsequently being obsoleted by TLS version 1.3 in 2018), providing
sufficient time to transition away from older versions.
Removing support for older versions from implementations reduces the
attack surface, reduces opportunity for misconfiguration, and
streamlines library and product maintenance.
This document also deprecates Datagram TLS (DTLS) version 1.0
(RFC 4347) but not DTLS version 1.2, and there is no DTLS
version 1.1.This document updates many RFCs that normatively refer to TLS version 1.0 or
TLS version 1.1, as described herein. This document also updates the best
practices for TLS usage in RFC 7525; hence, it is part of BCP 195.Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further information
on BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 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
. RFCs Updated
. Terminology
. Support for Deprecation
. SHA-1 Usage Problematic in TLS 1.0 and TLS 1.1
. Do Not Use TLS 1.0
. Do Not Use TLS 1.1
. Updates to RFC 7525
. Operational Considerations
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionTransport Layer Security (TLS) versions 1.0
and 1.1 were superseded by TLS 1.2 in 2008, which has now itself been superseded by
TLS 1.3 . Datagram Transport Layer Security
(DTLS) version 1.0 was superseded by DTLS 1.2
in 2012. Therefore, it is timely to further
deprecate TLS 1.0, TLS 1.1, and DTLS 1.0.
Accordingly, the aforementioned documents have been moved to Historic status.Technical reasons for deprecating these versions include:
They require the implementation of older cipher suites that are no
longer desirable for cryptographic reasons, e.g., TLS 1.0 makes
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement.
There is a lack of support for current recommended cipher suites, especially
authenticated encryption with associated data (AEAD) ciphers,
which were not supported prior to TLS 1.2. Note that
registry entries for no-longer-desirable ciphersuites remain in the
registries, but many TLS registries were updated by , which indicates that such entries are not
recommended by the IETF.
The integrity of the handshake depends on SHA-1 hash.
The authentication of the peers depends on SHA-1 signatures.
Support for four TLS protocol versions increases the likelihood of
misconfiguration.
At least one widely used library has plans to drop TLS 1.1 and
TLS 1.0 support in upcoming releases; products using such libraries
would need to use older versions of the libraries to support TLS 1.0
and TLS 1.1, which is clearly undesirable.
Deprecation of these versions is intended to assist developers as
additional justification to no longer support older (D)TLS versions and to
migrate to a minimum of (D)TLS 1.2. Deprecation also assists product teams
with phasing out support for the older versions, to reduce the attack
surface and the scope of maintenance for protocols in their
offerings.RFCs UpdatedThis document updates the following RFCs that normatively reference
TLS 1.0, TLS 1.1, or DTLS 1.0. The update is to obsolete usage of
these older versions. Fallback to these versions is prohibited
through this update. Specific references to mandatory minimum protocol
versions of TLS 1.0 or TLS 1.1 are replaced by TLS 1.2, and references
to minimum protocol version DTLS 1.0 are replaced by DTLS 1.2.
Statements that "TLS 1.0 is the most widely deployed version and will
provide the broadest interoperability" are removed without
replacement.The status of , ,
, ,
, and will be
updated with permission of the Independent Submissions Editor.
In addition, these RFCs normatively refer to TLS 1.0 or TLS 1.1 and
have already been obsoleted; they are still listed here and marked as
updated by this document in order to reiterate that any usage of the
obsolete protocol should use modern TLS:
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
, and
.Note that has already been
updated by , which makes an overlapping, but
not quite identical, update as this document. has a requirement for TLS 1.1 or later, although it
only makes an informative reference to .
This requirement is updated to be for TLS 1.2 or later., , and
are already Historic; they are still listed here and marked as
updated by this document in order to reiterate that any usage of the
obsolete protocol should use modern TLS.This document updates DTLS . had allowed for negotiating the use of DTLS 1.0,
which is now forbidden.The DES and International Data Encryption Algorithm (IDEA) cipher suites
specified in were specifically removed from TLS 1.2 by
; since the only versions of TLS for which
their usage is defined are now Historic, has been
moved to Historic as well.The version-fallback Signaling Cipher Suite Value specified in
was defined to detect when a given client
and server negotiate a lower version of (D)TLS than their highest
shared version. TLS 1.3 () incorporates a
different mechanism that achieves this purpose, via sentinel values in
the ServerHello.Random field. With (D)TLS versions prior to 1.2 fully
deprecated, the only way for (D)TLS implementations to negotiate a
lower version than their highest shared version would be to negotiate
(D)TLS 1.2 while supporting (D)TLS 1.3; supporting (D)TLS 1.3 implies
support for the ServerHello.Random mechanism. Accordingly, the
functionality from has been superseded, and
this document marks it as Obsolete.Terminology
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.
Support for DeprecationSpecific details on attacks against TLS 1.0 and TLS 1.1, as well as
their mitigations, are provided in ,
, and other
RFCs referenced therein. Although mitigations for the current known
vulnerabilities have been developed, any future issues discovered in old
protocol versions might not be mitigated in older library versions when
newer library versions do not support those old protocols.For example, NIST has provided the following rationale, copied with
permission from Section 1.1, "History of TLS", of :
TLS 1.1, specified in RFC 4346 [24], was developed to
address weaknesses discovered in TLS 1.0, primarily in the areas of
initialization vector selection and padding error processing.
Initialization vectors were made explicit to prevent a certain class
of attacks on the Cipher Block Chaining (CBC) mode of operation used
by TLS. The handling of padding errors was altered to treat a
padding error as a bad message authentication code rather than a
decryption failure. In addition, the TLS 1.1 RFC acknowledges
attacks on CBC mode that rely on the time to compute the message
authentication code (MAC). The TLS 1.1 specification states that to
defend against such attacks, an implementation must process records
in the same manner regardless of whether padding errors exist.
Further implementation considerations for CBC modes (which were not
included in RFC 4346 [24]) are discussed in
Section 3.3.2.TLS 1.2, specified in RFC 5246 [25], made
several cryptographic enhancements, particularly in the area of hash
functions, with the ability to use or specify the SHA-2 family of
algorithms for hash, MAC, and Pseudorandom Function (PRF)
computations. TLS 1.2 also adds authenticated encryption with
associated data (AEAD) cipher suites.TLS 1.3, specified in RFC 8446 [57],
represents a significant change to TLS that aims to address threats
that have arisen over the years. Among the changes are a new handshake protocol, a new key derivation process that uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) [37], and the removal of cipher suites that use RSA key transport or static Diffie-Hellman ( DH) [sic] key exchanges, the CBC mode of operation, or SHA-1. Many extensions defined for use with TLS 1.2 and previous versions cannot be used with TLS 1.3.
SHA-1 Usage Problematic in TLS 1.0 and TLS 1.1The integrity of both TLS 1.0 and TLS 1.1 depends on a running SHA-1
hash of the exchanged messages. This makes it possible to perform a
downgrade attack on the handshake by an attacker able to perform 277
operations, well below the acceptable modern security margin.Similarly, the authentication of the handshake depends on signatures
made using a SHA-1 hash or a concatenation of MD5 and SHA-1
hashes that is not appreciably stronger than a SHA-1 hash, allowing the attacker to impersonate a server when it is able to
break the severely weakened SHA-1 hash.Neither TLS 1.0 nor TLS 1.1 allows the peers to select a stronger hash
for signatures in the ServerKeyExchange or CertificateVerify messages,
making the only upgrade path the use of a newer protocol version.See for additional details.Do Not Use TLS 1.0TLS 1.0 MUST NOT be used.
Negotiation of TLS 1.0 from any version of TLS MUST NOT be
permitted.Any other version of TLS is more secure than TLS 1.0. While TLS 1.0 can be
configured to prevent some types of interception, using the highest version
available is preferred.Pragmatically, clients MUST NOT send a ClientHello with
ClientHello.client_version set to {03,01}. Similarly, servers MUST NOT
send a ServerHello with ServerHello.server_version set to {03,01}. Any
party receiving a Hello message with the protocol version set to {03,01}
MUST respond with a "protocol_version" alert message and close the
connection.Historically, TLS specifications were not clear on what the record
layer version number (TLSPlaintext.version) could contain when sending
a ClientHello message. notes that TLSPlaintext.version
could be selected to maximize interoperability, though no definitive
value is identified as ideal. That guidance is still applicable;
therefore, TLS servers MUST accept any value {03,XX} (including {03,00})
as the record layer version number for ClientHello, but they MUST NOT
negotiate TLS 1.0.Do Not Use TLS 1.1TLS 1.1 MUST NOT be used. Negotiation of TLS 1.1 from any version of
TLS MUST NOT be permitted.Pragmatically, clients MUST NOT send a ClientHello with
ClientHello.client_version set to {03,02}. Similarly, servers MUST NOT
send a ServerHello with ServerHello.server_version set to {03,02}. Any
party receiving a Hello message with the protocol version set to {03,02}
MUST respond with a "protocol_version" alert message and close the
connection.Any newer version of TLS is more secure than TLS 1.1. While TLS 1.1 can be
configured to prevent some types of interception, using the highest version
available is preferred. Support for TLS 1.1 is dwindling in libraries
and will impact security going forward if mitigations for attacks cannot
be easily addressed and supported in older libraries.Historically, TLS specifications were not clear on what the record
layer version number (TLSPlaintext.version) could contain when sending
a ClientHello message. notes that TLSPlaintext.version
could be selected to maximize interoperability, though no definitive
value is identified as ideal. That guidance is still applicable;
therefore, TLS servers MUST accept any value {03,XX} (including {03,00})
as the record layer version number for ClientHello, but they MUST NOT
negotiate TLS 1.1.Updates to RFC 7525"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" is BCP 195, which is the
most recent Best Current Practice for implementing TLS and was based on
TLS 1.2. At the time of publication, TLS 1.0 and TLS 1.1 had not yet
been deprecated. As such, BCP 195 is called out specifically to
update text implementing the deprecation recommendations of this
document.This document updates by
changing SHOULD NOT to MUST NOT as follows:
Implementations MUST NOT negotiate TLS version 1.0 . Rationale: TLS 1.0
(published in 1999) does not support many modern, strong cipher
suites. In addition, TLS 1.0 lacks a per-record Initialization
Vector (IV) for CBC-based cipher suites and does not warn against
common padding errors.
Implementations MUST NOT negotiate TLS version 1.1 . Rationale: TLS 1.1
(published in 2006) is a security improvement over TLS 1.0 but still
does not support certain stronger cipher suites.
This document updates by
changing SHOULD NOT to MUST NOT and adding a reference to RFC 6347 as follows:
Implementations MUST NOT negotiate DTLS version 1.0 . Version 1.0 of DTLS correlates to version 1.1 of
TLS (see above).
Operational Considerations
This document is part of BCP 195 and, as such, reflects the
understanding of the IETF (at the time of this document's publication) as to the
best practices for TLS and DTLS usage.
Though TLS 1.1 has been obsolete since the publication of
in 2008, and DTLS 1.0 has been obsolete since the publication of in 2012, there may remain some
systems in operation that do not
support (D)TLS 1.2 or higher. Adopting the practices recommended by
this document for any systems that need to communicate with the
aforementioned class of systems will cause failure to interoperate.
However, disregarding the recommendations of this document in order
to continue to interoperate with the aforementioned class of systems
incurs some amount of risk. The nature of the risks incurred by
operating in contravention to the recommendations of this document
are discussed in Sections and
, and knowledge of those risks
should be used along with any potential mitigating factors and the
risks inherent to updating the systems in question when deciding how
quickly to adopt the recommendations specified in this document.
Security ConsiderationsThis document deprecates two older TLS protocol versions and one older
DTLS protocol version for security
reasons already described. The attack surface is reduced when there are
a smaller number of supported protocols and fallback options are
removed.IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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 TLS Protocol Version 1.0This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]Security Mechanism Agreement for the Session Initiation Protocol (SIP)Transport Layer Security over Stream Control Transmission ProtocolThis document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK]Guidelines for the Use of Extensible Markup Language (XML) within IETF ProtocolsThe Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]Guidelines for Writing RFC Text on Security ConsiderationsAll RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Known Content Network (CN) Request-Routing MechanismsThis document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. This memo provides information for the Internet community.The Mailbox Update (MUPDATE) Distributed Mailbox Database ProtocolAs the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.Transport Layer Security Protocol Compression MethodsThe Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]Securely Available Credentials ProtocolThis document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]A Presence Event Package for the Session Initiation Protocol (SIP)This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]Operational Security Requirements for Large Internet Service Provider (ISP) IP Network InfrastructureThis document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. This memo provides information for the Internet community.Message Tracking Query ProtocolCustomers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS-TRACK]Session Initiation Protocol (SIP) Extension for Event State PublicationThis document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. [STANDARDS-TRACK]Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). [STANDARDS-TRACK]Middlebox Communications (MIDCOM) Protocol EvaluationThis document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. This memo provides information for the Internet community.Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This memo provides information for the Internet community.Addition of SEED Cipher Suites to Transport Layer Security (TLS)This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. [STANDARDS-TRACK]Securing FTP with TLSThis document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".This specification is in accordance with RFC 959, "File Transfer Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". [STANDARDS-TRACK]An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]Common Open Policy Service (COPS) Over Transport Layer Security (TLS)This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.This document also updates RFC 2748 by modifying the contents of the Client-Accept message. [STANDARDS-TRACK]Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.1This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.Interworking between the Session Initiation Protocol (SIP) and QSIGThis document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security MechanismsThis document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. [STANDARDS-TRACK]Lightweight Directory Access Protocol (LDAP) Turn OperationThis specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. This memo defines an Experimental Protocol for the Internet community.NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements. This memo defines an Experimental Protocol for the Internet community.The Binary Floor Control Protocol (BFCP)Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. [STANDARDS-TRACK]The PLAIN Simple Authentication and Security Layer (SASL) MechanismThis document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. [STANDARDS-TRACK]Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. [STANDARDS-TRACK]TLS Handshake Message for Supplemental DataThis specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. [STANDARDS-TRACK]TLS User Mapping ExtensionThis document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future. [STANDARDS-TRACK]Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)This memo specifies two transport mappings of the \%Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). [STANDARDS-TRACK]Internet Denial-of-Service ConsiderationsIABThis document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community.Using NETCONF over the Simple Object Access Protocol (SOAP)The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS-TRACK]Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS-TRACK]Calendaring Extensions to WebDAV (CalDAV)This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. [STANDARDS-TRACK]FTP Transport for Secure Peer-to-Peer Business Data Interchange over the InternetThis Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. This memo provides information for the Internet community.The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides information for the Internet community.The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over CellularThis document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application. This memo provides information for the Internet community.The Message Session Relay Protocol (MSRP)This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]Relay Extensions for the Message Sessions Relay Protocol (MSRP)Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS-TRACK]XML Pipelining with Chunks for the Internet Registry Information ServiceThis document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining. [STANDARDS-TRACK]Connection Establishment in the Binary Floor Control Protocol (BFCP)This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume EnvironmentsThis specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]The Atom Publishing ProtocolThe Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. [STANDARDS-TRACK]ODETTE File Transfer Protocol 2.0This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community.Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]Using the Secure Remote Password (SRP) Protocol for TLS AuthenticationThis memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. This memo provides information for the Internet community.Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 CryptosystemsThis document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document. This memo provides information for the Internet community.6to4 Reverse DNS Delegation SpecificationThis memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block. This memo provides information for the Internet community.The EAP-TLS Authentication ProtocolThe Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]Session Initiation Protocol (SIP) Extension for Partial Notification of Presence InformationBy default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. [STANDARDS-TRACK]Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community.Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource ListsIn certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. [STANDARDS-TRACK]Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP- FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. This memo provides information for the Internet community.DES and IDEA Cipher Suites for Transport Layer Security (TLS)Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. This memo provides information for the Internet community.Extensible Provisioning Protocol (EPP) Transport over TCPThis document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]Transport Layer Security (TLS) Authorization ExtensionsThis document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message. This document defines an Experimental Protocol for the Internet community.Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way.This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]Transport Layer Security (TLS) Authorization Using KeyNoteThis document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. This document is not an Internet Standards Track specification; it is published for informational purposes.Prohibiting Secure Sockets Layer (SSL) Version 2.0This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) ProtocolThe Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.The <mapping> element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service.This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping> element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. This document defines an Experimental Protocol for the Internet community.The OAuth 2.0 Authorization FrameworkThe OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]The OAuth 2.0 Authorization Framework: Bearer Token UsageThis specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]Enrollment over Secure TransportThis document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.Prohibiting RC4 Cipher SuitesThis document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246.TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade AttacksThis document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) CertificatesThis document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).Deprecating Secure Sockets Layer Version 3.0The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and EarlierThis document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.This document obsoletes RFC 4492.Informative ReferencesTranscript Collision Attacks: Breaking Authentication in TLS, IKE, and SSHINRIAINRIAGuidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations NIST SP800-52r2National Institute of Standards and TechnologyInternet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular HostsSTUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS-TRACK]Transport Layer Security (TLS) ExtensionsThis document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]Diameter Base ProtocolThe Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS-TRACK]Extensible Provisioning Protocol (EPP) Transport Over TCPThis document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. [STANDARDS-TRACK]Extensible Messaging and Presence Protocol (XMPP): CoreThis memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]Addition of Camellia Cipher Suites to Transport Layer Security (TLS)This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]An Extension to the Session Initiation Protocol (SIP) for Request History InformationThis document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. [STANDARDS-TRACK]Datagram Transport Layer SecurityThis document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.Transport Layer Security (TLS) ExtensionsThis document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. This memo provides information for the Internet community.Transport Layer Security (TLS) Session Resumption without Server-Side StateThis document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping \%per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. [STANDARDS-TRACK]Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.This document extends and updates RFC 4145. [STANDARDS-TRACK]Extensible Provisioning Protocol (EPP) Transport Over TCPThis document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734. [STANDARDS-TRACK]Transport Layer Security (TLS) Session Resumption without Server-Side StateThis document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]Using OpenPGP Keys for Transport Layer Security (TLS) AuthenticationThis memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo defines an Experimental Protocol for the Internet community.Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow InformationThis document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Control And Provisioning of Wireless Access Points (CAPWAP) Protocol SpecificationThis specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS-TRACK]IAX: Inter-Asterisk eXchange Version 2This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. This document is not an Internet Standards Track specification; it is published for informational purposes.Datagram Transport Layer Security (DTLS) Transport Mapping for SyslogThis document describes the transport of syslog messages over the Datagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired. [STANDARDS-TRACK]Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). This document defines an Experimental Protocol for the Internet community.Datagram Transport Layer Security Version 1.2This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]Suite B Profile for Transport Layer Security (TLS)The United States government has published guidelines for "NSA Suite B Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.Transport Layer Security (TLS) Encryption for RADIUSThis document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642.Datagram Transport Layer Security (DTLS) Encapsulation of SCTP PacketsThe Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single-homed.The Transport Layer Security (TLS) Protocol Version 1.3This 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.IANA Registry Updates for TLS and DTLSThis document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.AcknowledgementsThanks to those that provided usage data and reviewed and/or improved
this document, including: , , ,
, , , ,
, , , , , ,
, , , , ,
, , ,
, , , , , , , , , , , ,
, , , ,
, , and .
Authors' AddressesCenter for Internet Security (CIS)East GreenbushNYUnited States of AmericaKathleen.Moriarty.ietf@gmail.comTrinity College DublinDublin2Ireland+353-1-896-2354stephen.farrell@cs.tcd.ie