4.1.EKTField Formats

The EKTField uses the formats defined in Figures 1 and2 for theFullEKTField and ShortEKTField. The EKTField appended to an SRTPpacket can be referred to as an "EKT Tag".¶

 0                   1                   2                   3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+:                                                               ::                        EKT Ciphertext                         ::                                                               :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|   Security Parameter Index    |             Epoch             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|            Length             |0 0 0 0 0 0 1 0|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0 1 2 3 4 5 6 7+-+-+-+-+-+-+-+-+|0 0 0 0 0 0 0 0|+-+-+-+-+-+-+-+-+

Figure 3 shows the syntax of the EKTField, expressed in ABNF[RFC5234]. The EKTField is added to the end of an SRTPpacket. The EKTPlaintext is the concatenation of SRTPMasterKeyLength,SRTPMasterKey, SSRC, and ROC, in that order. The EKTCiphertext iscomputed by encrypting the EKTPlaintext using the EKTKey. Futureextensions to the EKTFieldMUST conform to the syntax of theExtensionEKTField.¶

BYTE = %x00-FFEKTMsgTypeFull = %x02EKTMsgTypeShort = %x00EKTMsgTypeExtension = %x03-FF ; Message Type %x01 is not available                              ; for assignment due to its usage by                              ; legacy implementations.EKTMsgLength = 2BYTESRTPMasterKeyLength = BYTESRTPMasterKey = 1*242BYTESSRC = 4BYTE ; SSRC from RTPROC = 4BYTE ; ROC from SRTP for the given SSRCEKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROCEKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)Epoch = 2BYTESPI = 2BYTEFullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFullShortEKTField = EKTMsgTypeShortExtensionData = 1*1024BYTEExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtensionEKTField = FullEKTField / ShortEKTField / ExtensionEKTField

These fields and data elements are defined as follows:¶

EKTPlaintext:

This is the data that is input to the EKT encryption operation. This data never appears on the wire; it is used only in computations internal to EKT. This is the concatenation of the SRTP master key and its length, the SSRC, and the ROC.¶

EKTCiphertext:

This is the data that is output from the EKT encryption operation (seeSection 4.4). This field is included in SRTP packets when EKT is in use. The length of the EKTCiphertext can be larger than the length of the EKTPlaintext that was encrypted.¶

SRTPMasterKey:

On the sender side, this is the SRTP master key associated with the indicated SSRC.¶

SRTPMasterKeyLength:

This is the length of the SRTPMasterKey in bytes. This depends on the cipher suite negotiated for SRTP using Session Description Protocol (SDP) Offer/Answer[RFC3264].¶

SSRC:

On the sender side, this is the SSRC for this SRTP source. The length of this field is 32 bits. The SSRC value in the EKT TagMUST be the same as the one in the header of the SRTP packet to which the tag is appended.¶

Rollover Counter (ROC):

On the sender side, this is set to the current value of the SRTP ROC in the SRTP context associated with the SSRC in the SRTP packet. The length of this field is 32 bits.¶

Security Parameter Index (SPI):

This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing the packet, within a given conference. The length of this field is 16 bits, representing a two-byte integer in network byte order. The parameters identified by this field are as follows:¶

• The EKT Cipher used to process the packet.¶
• The EKTKey used to process the packet.¶
• The SRTP master salt associated with any master key encrypted with this EKT Key.  The master salt is communicated separately, via signaling, typically along with the EKTKey. (Recall that the SRTP master salt is used in the formation of Initialization Vectors (IVs) / nonces.)¶

Epoch:

This field indicates how many SRTP keys have been sent for this SSRC under the current EKTKey, prior to the current key, as a two‑byte integer in network byte order. It starts at zero at the beginning of a session and resets to zero whenever the EKTKey is changed (i.e., when a new SPI appears). The epoch for an SSRC increments by one every time the sender transmits a new key. The recipient of a FullEKTFieldMUST reject any future FullEKTField for this SPI and SSRC that has an epoch value equal to or lower than an epoch already seen.¶

Together, these data elements are called an "EKT parameter set". To avoid ambiguity, each distinct EKT parameter set that is usedMUST be associated with a distinct SPI value.¶

EKTMsgLength:

All EKT Message Types other than the ShortEKTField include a length in octets (in network byte order) of either the FullEKTField or the ExtensionEKTField, including this length field and the EKT Message Type (as defined in the next paragraph).¶

Message Type:

The last byte is used to indicate the type of the EKTField. ThisMUST be 2 for the FullEKTField format and 0 for the ShortEKTField format. If a received EKT Tag has an unknown Message Type, then the receiverMUST discard the whole EKT Tag.¶

4.2.SPIs and EKT Parameter Sets

The SPI identifies the parameters for how the EKT Tag shouldbe processed:¶

• The EKTKey and EKT Cipher used to process the packet.¶
• The SRTP master salt associated with any master key encrypted with this EKT Key.  The master salt is communicated separately, via signaling, typically along with the EKTKey.¶

Together, these data elements are called an "EKT parameter set". To avoid ambiguity, each distinct EKT parameter set that is usedMUST be associated with a distinct SPI value. The association of a givenparameter set with a given SPI value is configured by some otherprotocol, e.g., the DTLS-SRTP extension defined inSection 5.¶

4.3.Packet Processing and State Machine

At any given time, the SSRC for each SRTP source has associated with it a single EKT parameter set. This parameter set is used to process all outbound packets and is called the "outbound parameter set" for that SSRC. There may be other EKT parameter sets that are used by otherSRTP sources in the same session, including other SRTPsources on the same endpoint (e.g., one endpoint with voice and videomight have two EKT parameter sets, or there might be multiple videosources on an endpoint, each with their own EKT parameter set). All ofthe received EKT parameter setsSHOULD be stored by all of theparticipants in an SRTP session, for use in processing inbound SRTPtraffic. If a participant deletes an EKT parameter set(e.g., because of space limitations), then it will be unable toprocess Full EKT Tags containing updated media keys and thus will be unableto receive media from a participant that has changed its media key.¶

Either the FullEKTField or ShortEKTField is appended at the tail endof all SRTP packets. The decision regarding which parameter to send and whenis specified inSection 4.6.¶

4.4.Ciphers

EKT uses an authenticated cipher to encrypt and authenticate theEKTPlaintext. This specification defines the interface to the cipher,in order to abstract the interface away from the details of thatfunction. This specification also defines the default cipher that isused in EKT. The default cipher described inSection 4.4.1MUSTbe implemented, but another cipher that conforms to this interfaceMAY be used. The cipher used for a given EKTCiphertext value isnegotiated using the supported_ekt_ciphers extension (seeSection 5.2) and indicated with theSPI value in the FullEKTField.¶

An EKTCipher consists of an encryption function and a decryptionfunction. The encryption function E(K, P) takes the following inputs:¶

• a secret key K with a length of L bytes, and¶
• a plaintext value P with a length of M bytes.¶

The encryption function returns a ciphertext value C whose length is Nbytes, where N may be larger than M. The decryption function D(K, C)takes the following inputs:¶

• a secret key K with a length of L bytes, and¶
• a ciphertext value C with a length of N bytes.¶

The decryption function returns a plaintext value P that is M byteslong, or it returns an indication that the decryption operation failedbecause the ciphertext was invalid (i.e., it was not generated by theencryption of plaintext with the key K).¶

These functions have the property that D(K, E(K, P)) = P for allvalues of K and P. Each cipher also has a limit T on the number oftimes that it can be used with any fixed key value. The EKTKeyMUST NOT be used for encryption more than T times. Note that if the sameFullEKTField is retransmitted three times, that only counts as oneencryption.¶

Security requirements for EKT Ciphers are discussed inSection 6.¶

4.5.Synchronizing Operation

If a source has its EKTKey changed by key management, itMUST alsochange its SRTP master key, which will cause it to send out a newFullEKTField and eventually begin encrypting with it, as described inSection 4.3.1.This ensures that if key management thought the EKTKeyneeds changing (due to a participant leaving or joining) andcommunicated that to a source, the source will also change its SRTPmaster key, so that traffic can be decrypted only by those who knowthe current EKTKey.¶

4.6.Timing and Reliability Considerations

A system using EKT learns the SRTP master keys distributed withthe FullEKTField sent with SRTP, rather than with call signaling. Areceiver can immediately decrypt an SRTP packet, provided the SRTPpacket contains a FullEKTField.¶

This section describes how to reliably and expediently deliver newSRTP master keys to receivers.¶

There are three cases to consider. In the first case, a new sender joins a session and needs to communicate its SRTP master key to all the receivers. In the second case, a sender changes its SRTP master key, which needs to be communicated to all the receivers. In the third case, a new receiver joins a session already in progress and needs to know the sender's SRTP master key.¶

The three cases are as follows:¶

New sender:

A new senderSHOULD send a packet containing theFullEKTField as soon as possible, ideally in its initial SRTP packet. To accommodate packet loss, it isRECOMMENDED that the FullEKTField be transmitted in three consecutive packets.If the sender does not send a FullEKTField in itsinitial packets and receivers have not otherwise been provisionedwith a decryption key, then decryption will fail and SRTP packetswill be dropped until the receiver receives a FullEKTField from thesender.¶

Rekey:

By sending an EKT Tag over SRTP, the rekeying event shares fate with theSRTP packets protected with that new SRTP master key. To accommodatepacket loss, it isRECOMMENDED that three consecutive packetscontaining the FullEKTField be transmitted.¶

New receiver:

When a new receiver joins a session, it does not need to communicateits sending SRTP master key (because it is a receiver). Also, when a newreceiver joins a session, the sender is generally unaware of thereceiver joining the session; thus, sendersSHOULD periodicallytransmit the FullEKTField. That interval depends on how frequently newreceivers join the session, the acceptable delay before thosereceivers can start processing SRTP packets, and the acceptableoverhead of sending the FullEKTField. If sending audio and video, theRECOMMENDED frequency is the same as the rate of intra-coded videoframes. If only sending audio, theRECOMMENDED frequency is every100 ms.¶

If none of the above three cases apply, a ShortEKTFieldSHOULD be sent.¶

In general, sending FullEKTField tags less frequently will consume lessbandwidth but will increase the time it takes for a join or rekey totake effect. Applications should schedule the sending of FullEKTField tags ina way that makes sense for their bandwidth and latency requirements.¶

5.1.DTLS-SRTP Recap

DTLS-SRTP[RFC5764] uses an extended DTLS exchange between twopeers to exchange keying material, algorithms, and parameters forSRTP. The SRTP flow operates over the same transport as theDTLS-SRTP exchange (i.e., the same 5-tuple). DTLS-SRTP combines theperformance and encryption flexibility benefits of SRTP with theflexibility and convenience of DTLS-integrated key and associationmanagement. DTLS-SRTP can be viewed in two equivalent ways: as a newkey management method for SRTP and as a new RTP-specific data formatfor DTLS.¶

5.2.SRTP EKT Key Transport Extensions to DTLS-SRTP

This document defines a new TLS negotiated extensioncalled "supported_ekt_ciphers" and a new TLS handshake message type called"ekt_key". The extension negotiates the cipher to be used inencrypting and decrypting EKTCiphertext values, and the handshakemessage carries the corresponding key.¶

Figure 4 shows a messageflow between a DTLS 1.3 client and serverusing EKT configured using the DTLS extensions described in thissection. (The initial cookie exchange and other normal DTLSmessages are omitted.) To be clear, EKT can be used with versionsof DTLS prior to 1.3. The only difference is that in pre-1.3 TLS,stacks will not have built-in support for generating and processingACK messages.¶

Client                                             ServerClientHello + use_srtp + supported_ekt_ciphers                        -------->                                               ServerHello                                     {EncryptedExtensions}                                                + use_srtp                                   + supported_ekt_ciphers                                            {... Finished}                        <--------{... Finished}          -------->                                                     [ACK]                        <--------                 [EKTKey][ACK]                   -------->|SRTP packets|          <------->           |SRTP packets|+ <EKT Tags>                                  + <EKT Tags>{} Messages protected using DTLS handshake keys[] Messages protected using DTLS application traffic keys<> Messages protected using the EKTKey and EKT Cipher|| Messages protected using the SRTP master key sent in   a Full EKT Tag

In the context of a multi-party SRTP session in which each endpointperforms a DTLS handshake as a client with a central DTLS server,the extensions defined in this document allow the DTLS server to seta common EKTKey for all participants. Each endpoint can then useEKT Tags encrypted with that common key to inform other endpoints ofthe keys it uses to protect SRTP packets. This avoids the needfor many individual DTLS handshakes among the endpoints, at the costof preventing endpoints from directly authenticating one another.¶

Client A                 Server                 Client B    <----DTLS Handshake---->    <--------EKTKey---------                            <----DTLS Handshake---->                            ---------EKTKey-------->    -------------SRTP Packet + EKT Tag------------->    <------------SRTP Packet + EKT Tag--------------

        enum {          reserved(0),          aeskw_128(1),          aeskw_256(2),        } EKTCipherType;        struct {            select (Handshake.msg_type) {                case client_hello:                    EKTCipherType supported_ciphers<1..255>;                case server_hello:                    EKTCipherType selected_cipher;                case encrypted_extensions:                    EKTCipherType selected_cipher;            };        } EKTCipher;

struct {  opaque ekt_key_value<1..256>;  opaque srtp_master_salt<1..256>;  uint16 ekt_spi;  uint24 ekt_ttl;} EKTKey;

5.3.Offer/Answer Considerations

When using EKT with DTLS-SRTP, the negotiation to use EKT is done atthe DTLS handshake level and does not change the SDP Offer⁠/Answer messaging[RFC3264].¶

5.4.Sending the DTLS EKTKey Reliably

The DTLS EKTKey message is sent using the retransmissions specified inSection 4.2.4 of DTLS [RFC6347]. Retransmission is finished with an ACK message, or an alert is received.¶

7.1.EKT Message Types

IANA has created a new table for "EKT Message Types" inthe "Real-Time Transport Protocol (RTP) Parameters" registry. Theinitial values in this registry are as follows:¶

New entries in this table can be added via "Specification Required" asdefined in[RFC8126]. To avoid conflicts withpre-standard versions of EKT that have been deployed, IANASHOULD give preference to the allocation of even values over odd values untilthe even code points are consumed. Allocated valuesMUST be in the range of 0 to 254.¶

All new EKT messagesMUST be defined to include a length parameter, as specified inSection 4.1.¶

7.2.EKT Ciphers

IANA has created a new table for "EKT Ciphers" in the"Real-Time Transport Protocol (RTP) Parameters" registry. The initialvalues in this registry are as follows:¶

New entries in this table can be added via "Specification Required" asdefined in[RFC8126]. The expertSHOULD ensure that the specificationdefines the values for L and T as required inSection 4.4 of this document. Allocated valuesMUST be in the range of 0 to 254.¶

7.3.TLS Extensions

IANA has added supported_ekt_ciphers as a new extensionname to the "TLS ExtensionType Values" table of the "Transport LayerSecurity (TLS) Extensions" registry:¶

Value:

39¶

Extension Name:

supported_ekt_ciphers¶

TLS 1.3:

CH, EE¶

Recommended:

Y¶

Reference:

RFC 8870¶

7.4.TLS Handshake Type

IANA has added ekt_key as a new entry in the "TLSHandshakeType" table of the "Transport Layer Security (TLS)Parameters" registry:¶

Value:

26¶

Description:

ekt_key¶

DTLS-OK:

Y¶

Reference:

RFC 8870¶

Comment: