]> Cisco Systems

kydavis@cisco.com

Cisco Systems

jovalver@cisco.com

Cisco Systems

gsalguei@cisco.com

ART mmusic This document specifies additional cryptographic attributes for signaling additional Secure Real-time Transport Protocol (SRTP) cryptographic context information via the Session Description Protocol (SDP) in alongside those defined by RFC4568. The SDP extension defined in this document address situations where the receiver needs to quickly and robustly synchronize with a given sender. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization.

Introduction

Discussion Venues Source for this draft and an issue tracker can be found at https://github.com/kyzer-davis/srtp-assurance-rfc-draft.

Changelog draft-01

• Change contact name from IESG to IETF in IANA Considerations #2
• Discuss RFC4568 "Late Joiner" in problem statement: #3
• Split Serial forking scenario into its own section #4
• Add MIKEY considerations to Protocol Design section #6
• Change doc title #7
• Add SEQ abbreviation earlier #8
• Discuss why this can't be a RTP Header Extension #11
• Add Appendix further discussing why SDP Security Session Parameters extension not used #5
• Method to Convey Multiple SSRCs for a given stream #1
• Discuss why SEQ is signaled in the SDP #9

Problem Statement While provides most of the information required to instantiate an SRTP cryptographic context for RTP Packets, the state of a few crucial items in the SRTP cryptographic context are missing. One such item is the Rollover Counter (ROC) defined by Section 3.2.1 which is not signaled in any packet across the wire and shared between applications. The ROC is one item that is used to create the SRTP Packet Index along with the the transmitted sequence numbers (SEQ) for a given synchronization sources (SSRC). The Packet index is integral to the encryption, decryption and authentication process of SRTP key streams. Failure to synchronize the value properly at any point in the SRTP media exchange leads to encryption or decryption failures, degraded user experience and at cross-vendor interoperability issues with many hours of engineering time spent debugging a value that is never negotiated on the wire (and oftentimes not even logged in application logs.) The current method of ROC handling is to instantiate a new media stream's cryptographic context at 0 as per Section 3.3.1 of . Then track the state ROC for a given cryptographic context as the time continues on and the stream progresses. , states 'there is no concept of a "late joiner" in SRTP security descriptions' as the main reason for not conveying the ROC, SSRC, or SEQ via the key management protocol but as one will see below; this argument is not true in practice. When joining ongoing streams, resuming held/transferred streams, or devices without embedded application logic for clustering/high availability where a given cryptographic context is resumed; without any explicit signaling about the ROC state, devices must make an educated guess as defined by Section 3.3.1 of . The method specially estimates the received ROC by calculating ROC-1, ROC, ROC+1 to see which performs a successful decrypt. While this may work on paper, this process usually only done at the initial instantiation of a cryptographic context rather than at later points later during the session. Instead many applications take the easy route and set the value at 0 as if this is a new stream. While technically true from that receivers perspective, the sender of this stream may be encrypting packets with a ROC greater than 0. Further this does not cover scenarios where the ROC is greater than +1. Where possible the ROC state (and the rest of the cryptographic context) is usually synced across clustered devices or high availability pairs via proprietary methods rather than open standards. These problems detailed technically above lead to a few very common scenarios where the ROC may become out of sync. These are are briefly detailed below with the focus on the ROC Value. Joining an ongoing session:

• When a receiver joins an ongoing session, such as a broadcast conference, there is no signaling method which can quickly allow the new participant to know the state of the ROC assuming the state of the stream is shared across all participants.

Hold/Resume, Transfer Scenarios:

• A session is created between sender A and receiver B. ROC is instantiated at 0 normally and continues as expected.
• At some point the receiver is put on hold while the sender is connected to some other location such as music on hold or another party altogether.
• At some future point the receiver is reconnected to the sender and the original session is resumed.
• The sender may re-assume the original cryptographic context rather rather than create one net new.
• Here if the sender starts the stream from the last observed sequence number the receiver observed the ROC will be in sync.
• However there are scenarios where the sender may have been transmitting packets on the previous cryptographic context and if a ROC increment occurred; the receiver would never know. This can lead to problems when the streams are reconnected as the ROC is now out of sync between both parties.
• Further, a sender may be transferred to some upstream device transparently to them. If the sender does not reset their cryptographic context that new receiver will now be out of sync with possible ROC values.

Serial Forking Case:

• itself cites a problematic scenario in their own Appendix A, Scenario B, Problem 3 where a ROC out of sync scenario could occur.
• The proposed solution for problem 3 involves a method to convey the ROC however known the problem; the authors still did not include this in the base SDP Security specification.

Application Failover (without stateful syncs):

• In this scenario a cryptographic context was was created with Device A and B of a high availability pair.
• An SRTP stream was created and ROC of 0 was created and media streamed from the source towards Device A.
• Time continues and the sequence wraps from 65535 to 0 and the ROC is incremented to 1.
• Both the sender and device A are tracking this locally and the encrypt/decrypt process proceeds normally.
• Unfortunate network conditions arise and Device B must assume sessions of Device A transparently.
• Without any proprietary syncing logic between Device A and B which disclose the state of the ROC, Device B will likely instantiate the ROC at 0.
• Alternatively Device B may try to renegotiate the stream over the desired signaling protocol however this does not ensure the remote sender will change their cryptographic context and reset the ROC to 0.
• The transparent nature of the upstream failover means the local application will likely proceed using ROC 1 while upstream receiver has no method of knowing ROC 1 is the current value.

Secure SIPREC Recording:

• If a SIPREC recorder is brought into recording an ongoing session through some form of transfer or on-demand recording solution the ROC may have incremented.
• Without an SDP mechanism to share this information the SIPREC will be unaware of the full SRTP context required to ensure proper decrypt of media streams being monitored.

Improper SRTP context resets:

• As defined by Section 3.3.1 of an SRTP re-key MUST NOT reset the ROC within SRTP Cryptographic context.
• However, some applications may incorrectly use the re-key event as a trigger to reset the ROC leading to out-of-sync encrypt/decrypt operations.

Out of Sync Sliding Windows / Sequence Numbers:

• There is corner case situation where two devices communicating via a Back to Back User Agent (B2BUA) which is performing RTP-SRTP inter-working.
• In this scenario the B2BUA is also a session border controller (SBC) tasked with topology abstraction. That is, the signaling itself is abstracted from both parties.
• In this scenario a hold/resume where a sequence rolls can not only cause problems with the ROC; but can also cause sliding window issues.
• To be more specific, assume that both parties did have access to the cryptographic context and resumed the old ROC value after the hold thus ROC is not out of sync.
• What should the sliding window and sequence be set to in this scenario?
• The post-hold call could in theory have a problem where the sequence number of received packets is lower than what was originally observed before the hold.
• Thus the sliding window would drop packets until the sequence number gets back to the last known sequence and the sliding window advances.
• Advertising the Sequence in some capacity to reinitialize the sliding window (along with advertising the ROC) can ensure a remote application can properly re-instantiate the cryptographic context in this scenario.

This is a problem that other SRTP Key Management protocols (MIKEY, DTLS-SRTP, EKT-SRTP) have solved but SDP Security has lagged behind in solution parity. For a quick comparison of all SRTP Key Management negotiations refer to and .

Previous Solutions As per RFC3711, "Receivers joining an on-going session MUST be given the current ROC value using out-of-band signaling such as key-management signaling." aimed to solve the problem however this solution has a few technical shortcomings detailed below. First, this specifies the use of Multimedia Internet KEYing (MIKEY) defined by as the out-of-band signaling method. A proper MIKEY implementation requires more overhead than is needed to convey and solve this problem. By selecting MIKEY as the out-of-band signaling method the authors may have inadvertently inhibited significant adoption by the industry. Second, also transforms the SRTP Packet to include the four byte value after the encrypted payload and before an optional authentication tag. This data about the SRTP context is unencrypted on the wire and not covered by newer SRTP encryption protocols such as and . Furthermore this makes the approach incompatible with AEAD SRTP Cipher Suites which state that trimming/truncating the authentication tag weakens the security of the protocol in Section 13.2 of . Third, this is not in line with the standard method of RTP Packet modifications. The proposal would have benefited greatly from being an RTP Header Extension rather than a value appended after payload. But even an RTP header extension proves problematic in where modern SRTP encryption such as Cryptex defined by are applied. That is, the ROC is a required input to decrypt the RTP packet contents. It does not make sense to convey this data as an RTP Header Extension obfuscated by the very encryption it is required to decrypt. Lastly, there is no defined method for applications defined for applications to advertise the usage of this protocol via any signaling methods. also defined some SDP attributes namely the "a=SRTPROCTxRate" attribute however this does not cover other important values in the SRTP Cryptographic context and has not seen widespread implementation. solves the problem for DTLS-SRTP / implementations.

Conventions and Definitions 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.

Protocol Design A few points of note are below about this specifications relationship to other SRTP Key Management protocols or SRTP protocols as to leave no ambiguity.

Session Description Protocol (SDP) Security Descriptions for Media Streams:

The authors have chosen to avoid modifying RFC4568 a=crypto offers as to avoid backwards compatibility issues with a non-versioned protocol. Instead this specification adds to what is defined in SDP Security Framework by allowing applications to explicitly negotiate additional items from the cryptographic context such as the packet index ingredients: ROC, SSRC and Sequence Number via a new SDP Attribute. By coupling this information with the applicable "a=crypto" offers; a receiving application can properly instantiate an SRTP cryptographic context at the start of a session, later in a session, after session modification or when joining an ongoing session.

Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP):

This specifications makes no attempt to be compatible with the Key Management Extension for SDP "a=key-mgmt" defined by

ZRTP: Media Path Key Agreement for Unicast Secure RTP:

This specifications makes no attempt to be compatible with the Key Management via SDP for ZRTP "a=zrtp-hash" defined by .

MIKEY:

This specifications makes no attempt to be compatible with the SRTP Key Management via MIKEY .

DTLS-SRTP, EKT-SRTP, Privacy Enhanced Conferencing items (PERC):

All DTLS-SRTP items including Privacy Enhanced Conferencing items (PERC) [ and ] are out of scope for the purposes of this specification.

Secure Real Time Control Protocol (SRTCP):

This specification is not required by SRTCP since the packet index is carried within the SRTCP packet and does not need an out-of-band equivalent.

Source-Specific Media Attributes in the Session Description Protocol (SDP):

The authors of this specification vetted SSRC Attribute "a=ssrc" but felt that it would require too much modification and additions to the SSRC Attribute specification to allow unknown SSRC values and the other information which needs to be conveyed. Further, requiring implementation of the core SSRC Attribute RFC could pose as a barrier entry and separating the two into different SDP Attributes is the better option. An implementation SHOULD NOT send RFC5576 SSRC Attributes alongside SRTP Context SSRC Attributes. If both are present in SDP, a receiver SHOULD utilize prioritize the SRTP Context attributes over SSRC Attributes since these attributes will provide better SRTP cryptographic context initialization.

Completely Encrypting RTP Header Extensions and Contributing Sources:

SRTP Context is compatible with "a=cryptex" media and session level attribute.

SDP Considerations This specification introduces a new SRTP Context attribute defined as "a=srtpctx". The presence of the "a=srtpctx" attribute in the SDP (in either an offer or an answer) indicates that the endpoint is signaling explicit cryptographic context information and this data SHOULD be used in place of derived values such as those obtained from late binding or some other mechanism. The SRTP Context value syntax utilizes standard attribute field=value pairs separated by semi-colons as seen in . The implementation's goal is extendable allowing for additional vendor specific field=value pairs alongside the ones defined in this document or room for future specifications to add additional field=value pairs.

Base SRTP Context Syntax \ =;= ]]>

This specification specifically defines SRTP Context Attribute Fields of SSRC, ROC, and SEQ shown in .

Example SRTP Context Syntax \ ssrc=;roc=;seq= ]]>

Note that long lines in this document have been broken into multiple lines using the "The Single Backslash Strategy ('')" defined by . The formal definition of the SRTP Context Attribute, including custom extension field=value pairs is provided by the following ABNF : Leading 0s may be omitted and the alphanumeric hex may be upper or lowercase but at least one 0 must be present. Additionally the "0x" provided additional context that these values are hex and not integers. Thus as per these two lines are functionally identical:

Comparison with and without Leading 0s

When SSRC, ROC, or Sequence information needs to be conveyed about a given stream, the a=srtpctx attribute is coupled with the relevant a=crypto attribute in the SDP. In the sender has shares the usual cryptographic information as per a=crypto but has included other information such as the 32 bit SSRC, 32 bit ROC, and 16 bit Last Known Sequence number as Hex values within the a=srtpctx attribute. Together these two attributes provide better insights as to the state of the SRTP cryptographic context from the senders perspective.

Example SRTP Context attribute

The value of "unknown" MAY be used in place of any of the fields to indicate default behavior SHOULD be utilized by the receiving application (usually falling back to late binding or locally derived/stored cryptographic contact information for the packet index.) The example shown in indicates that only the SSRC of the stream is unknown to the sender at the time of the SDP exchange but values for ROC and Last Known Sequence are present. Alternatively, the attribute key and value MAY be omitted entirely. This MAY be updated via signaling at any later time but applications SHOULD ensure any offer/answer has the appropriate SRTP Context attribute. Applications SHOULD NOT include SRTP Context attribute if all three values are unknown or would be omitted. For example, starting a new sending session instantiation or for advertising potential cryptographic attributes that are part of a new offer. shows that tag 1 does not have any SRTP Context parameters rather than rather an SRTP Context attribute with all three values set to "unknown". This same example shows an unknown value carried with tag 2 and seq has been committed leaving only the ROC as a value shared with the second a=crypto tag.

Example SRTP Context with unknown mappings

The tag for an SRTP Context attribute MUST follow the peer SDP Security a=crypto tag for a given media stream (m=). The example in shown in the sender is advertising an explicit packet index mapping for a=crypto tag 2 for the audio stream and tag 1 for the video media stream. Note that some SDP values have been truncated for the sake of simplicity.

Example crypto and SRTP Context tag mapping

It is unlikely a sender will send SRTP Context attributes for every crypto attribute since many will be fully unknown (such as the start of a session.) However it is theoretically possible for every a=crypto tag to have a similar a=srtpctx attribute for additional details. For scenarios where RTP Multiplexing are concerned, EKT-SRTP () SHOULD be used in lieu of SDP Security as per Section 4.3.2. If SRTP Context attributes are to be used, multiple SSRC/ROC/SEQ values can be "bundled" in a list using parenthesis as a delimter. This can be observed in where three SSRC and the respective ROC/SEQ are provided as a list within the a=srtpctx attribute:

Example SRTP Context with Multiple SSRC

For scenarios where SDP Bundling are concerned, SRTP Context attributes follow the same bundling guidelines defined by , section 5.7 for SDP Securities a=crypto attribute.

Sender Behavior Senders utilizing SDP Security via "a=crypto" MUST make an attempt to signal any known packet index values to the peer receiver. The exception being when all values are unknown, such as at the very start of medias stream negotiation. For best results all sending parties of a given session stream SHOULD advertise known packet index values for all media streams. This should continue throughout the life of the session to ensure any errors or out of sync errors can be quickly corrected via new signaling methods. See for update frequency recommendations.

Receiver Behavior Receivers SHOULD utilize the signaled information in application logic to instantiate the SRTP cryptographic context. In the even there is no SRTP Context attributes present in SDP receivers MUST fallback to for guesting the ROC and logic for late binding to gleam the SSRC and sequence numbers (SEQ).

Update Frequency Senders SHOULD provide SRTP Context SDP when SDP Crypto attributes are negotiated. There is no explicit time or total number of packets in which a new update is required from sender to receiver. This specification will not cause overcrowding on the session establishment protocol's signaling channel if natural session updates, session changes, and session liveliness checks are followed.

Extendability As stated in , the SRTP Context SDP implementation's goal is extendability allowing for additional vendor specific field=value pairs alongside the ones defined in this document. This ensures that a=crypto SDP security may remain compatible with future algorithms that need to signal cryptographic context information outside of what is currently specified in . To illustrate, imagine a new example SRTP algorithm and crypto suite is created named "FOO_CHACHA20_POLY1305_SHA256" and the application needs to signal "Foo, "Bar", and "Nonce" values to properly instantiate the SRTP context. Rather than modify a=crypto SDP security or create a new unique SDP attribute, one can simply utilize SRTP Context SDP's key=value pairs to convey the information. Implementations MUST define how to handle default scenarios where the value is not present or set to "unknown". With this extendable method, all that is now required in the fictional RFC defining "FOO_CHACHA20_POLY1305_SHA256" is to include an "SDP parameters" section which details the expected "a=srtpctx" values and their usages. This approach is similar to how Media Format Parameter Capability ("a=fmtp") is utilized in modern SDP. An example is , Section 8.2.1 for H.264 video Media Format Parameters.

Security Considerations When SDP carries SRTP Context attributes additional insights are present about the SRTP cryptographic context. Due to this an intermediary MAY be able to analyze how long a session has been active by the ROC value. Since the SRTP Context attribute is carried in plain-text (alongside existing values like the SRTP Master Key for a given session) care MUST be taken as per the that keying material must not be sent over unsecure channels unless the SDP can be both private (encrypted) and authenticated.

IANA Considerations This document updates the "attribute-name (formerly "att-field")" sub-registry of the "Session Description Protocol (SDP) Parameters" registry (see Section 8.2.4 of ). Specifically, it adds the SDP "a=srtpctx" attribute for use at the media level. IANA SDP Registration Form

Form	Value
Contact name	IETF
Contact email address	kydavis@cisco.com
Attribute name	srtpctx
Attribute value	srtpctx
Attribute syntax	Provided by ABNF found in
Attribute semantics	Provided by sub-sections of
Usage level	media
Charset dependent	No
Purpose	Provide additional insights about SRTP context information not conveyed required by a receiver to properly decrypt SRTP.
O/A procedures	SDP O/A procedures are described in , specifically sections and of this document.
Mux Category	TRANSPORT

Acknowledgements Thanks to Paul Jones for reviewing early draft material and providing valuable feedback.

References Normative References This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK] The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. 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. 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. Informative References This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. [STANDARDS-TRACK] This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. [STANDARDS-TRACK] This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS-TRACK] This document provides descriptions of Session Description Protocol (SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. This memo provides information for the Internet community. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. This memo provides information for the Internet community. The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK] This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK] This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK] This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK] This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes. The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted. The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism. This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP). In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and the Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end to end within the context of a switched conferencing environment where Media Distributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the Real-time Transport Protocol (RTP). The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations. This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment.

Protocol Design Overview This appendix section is included to details some important itmes integral to the decision process of creating this specification. This section may be removed by the editors or left for future generations to understand why specific things were done as they are. In general, the overall design for this protocol tends to follow the phrase found in RFC6709, Section 1. "Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity. Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs."

Why not an RTP Header Extension? In order to be compatible with "a=cryptex", a protocol which extends the SRTP encryption over the RTP Extension Headers, the designed specification must ensure that information about the SRTP context is not within these RTP extension headers. Thus one has to provide this information in an out of band mechanism.

Why not an SDP Security Session Parameter? While analyzing SDP Security's Session Parameter feature number of interesting details were found. That is sections 6.3.7, 7.1.1, 9.2, and 10.3.2.2 of specifically. A few illustrative examples below detail what this could look like are provided below, though these MUST NOT be used. To analyze the faults of this method: First, a unknown and/or unsupported SDP Security Session Parameter is destructive. If one side where to advertise the ROC value as an SDP Security Session Parameter and the remote party does not understand that specific SDP Security Session Parameter, that entire crypto line is to be considered invalid. If this is the only a=crypto entry then the entire session may fail. The solution in this document allows for a graceful fallback to known methods to determine these value. Implementations could get around this by duplicating the a=crypto SDP attribute into two values: one with the postfix and one without to create to potential offers; but at this point we have a second SDP attribute. Instead this specification decided to cut to the chase and format the second attribute in a standardized way and avoid endless duplication (and potentially other harmful issues, see the final item in this document.) Second, there is a method to advertise "optional" SDP Security Session Parameters. However, upon further scrutiny, the document contradicts itself in many sections. To be specific, Section 6.3.7 states that an SDP Security Session Parameter prefixed with a dash character "-" MAY be ignored. Subsequent sections (9.2 and 10.3.2.2) state that a dash character is illegal and MUST NOT be used. It is not very well defined as such pursuit of this method has been dropped. Further, we know how applications will handle unknown SDP attributes; we do not know how applications will handle new mandatory (or optional) SDP Security Session Parameter values as none have ever been created. See IANA registry which only details those from the original RFC. (https://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml#sdp-security-descriptions-4) Including these could cause larger application issues and are the reason modern protocols use logic like Generate Random Extensions And Sustain Extensibility (GREASE) to catch bad implementation behavior and correct it before it leads to problems like those described in this section. In closing, this method has too many challenges but a lot has been learned. These items have influenced the protocol design and sections like which aim to avoid making the same mistakes.