--- 1/draft-ietf-perc-srtp-ekt-diet-12.txt 2020-06-23 08:13:14.322448591 -0700 +++ 2/draft-ietf-perc-srtp-ekt-diet-13.txt 2020-06-23 08:13:14.374449900 -0700 @@ -1,25 +1,25 @@ Network Working Group C. Jennings Internet-Draft Cisco Systems Intended status: Standards Track J. Mattsson -Expires: December 20, 2020 Ericsson AB +Expires: December 25, 2020 Ericsson AB D. McGrew Cisco Systems D. Wing Citrix Systems, Inc. F. Andreason Cisco Systems - June 18, 2020 + June 23, 2020 Encrypted Key Transport for DTLS and Secure RTP - draft-ietf-perc-srtp-ekt-diet-12 + draft-ietf-perc-srtp-ekt-diet-13 Abstract Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and 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. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 20, 2020. + This Internet-Draft will expire on December 25, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -57,28 +57,28 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions Used In This Document . . . . . . . . . . . . . . 4 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5 4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8 4.3. Packet Processing and State Machine . . . . . . . . . . . 8 - 4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 + 4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 9 4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 4.6. Timing and Reliability Consideration . . . . . . . . . . 13 - 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14 + 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 15 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15 5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21 @@ -118,21 +118,21 @@ this method, SRTP entities are free to choose SSRC values as they see fit, and to start up new SRTP sources with new SRTP master keys within a session without coordinating with other entities via external signaling or other external means. EKT extends DTLS and SRTP to enable a common key encryption key (called an EKTKey) to be distributed to all endpoints, so that each endpoint can securely send its SRTP master key and current SRTP rollover counter to the other participants in the session. This data furnishes the information needed by the receiver to instantiate an - SRTP/SRTCP receiver context. + SRTP receiver context. EKT can be used in conferences where the central media distributor or conference bridge cannot decrypt the media, such as the type defined for [I-D.ietf-perc-private-media-framework]. It can also be used for large scale conferences where the conference bridge or media distributor can decrypt all the media but wishes to encrypt the media it is sending just once and then send the same encrypted media to a large number of participants. This reduces the amount of CPU time needed for encryption and can be used for some optimization to media sending that use source specific multicast. @@ -198,21 +198,22 @@ This document defines the use of EKT with SRTP. Its use with SRTCP would be similar, but is reserved for a future specification. SRTP is preferred for transmitting key material because it shares fate with the transmitted media, because SRTP rekeying can occur without concern for RTCP transmission limits, and because it avoids the need for SRTCP compound packets with RTP translators and mixers. 4.1. EKTField Formats The EKTField uses the format defined in Figure 1 for the FullEKTField - and ShortEKTField. + and ShortEKTField. The EKTField appended to an SRTP packet 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -222,43 +223,44 @@ Figure 1: FullEKTField format 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+ Figure 2: ShortEKTField format The following shows the syntax of the EKTField expressed in ABNF - [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP - packet. The EKTPlaintext is the concatenation of - SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The - EKTCiphertext is computed by encrypting the EKTPlaintext using the - EKTKey. Future extensions to the EKTField MUST conform to the syntax - of ExtensionEKTField. + [RFC5234]. The EKTField is added to the end of an SRTP packet. The + EKTPlaintext is the concatenation of SRTPMasterKeyLength, + SRTPMasterKey, SSRC, and ROC in that order. The EKTCiphertext is + computed by encrypting the EKTPlaintext using the EKTKey. Future + extensions to the EKTField MUST conform to the syntax of + ExtensionEKTField. BYTE = %x00-FF EKTMsgTypeFull = %x02 EKTMsgTypeShort = %x00 - EKTMsgTypeExtension = %x03-FF + EKTMsgTypeExtension = %x03-FF ; Message type %x01 is reserved, due to + ; usage by legacy implementations. EKTMsgLength = 2BYTE; SRTPMasterKeyLength = BYTE - SRTPMasterKey = 1*256BYTE + SRTPMasterKey = 1*242BYTE SSRC = 4BYTE; SSRC from RTP ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC - EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) + EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) Epoch = 2BYTE SPI = 2BYTE FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull ShortEKTField = EKTMsgTypeShort ExtensionData = 1*1024BYTE ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension @@ -284,23 +286,23 @@ SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This depends on the cipher suite negotiated for SRTP using SDP Offer/ Answer [RFC3264] for the SRTP. 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 tag MUST 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 rollover counter in the SRTP/SRTCP context - associated with the SSRC in the SRTP or SRTCP packet. The length of - this field is 32 bits. + current value of the SRTP rollover counter 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: o The EKT cipher used to process the packet. o The EKTKey used to process the packet. @@ -347,50 +349,49 @@ signaling, typically along with the EKTKey. Together, these data elements are called an "EKT parameter set". Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. The association of a given parameter set with a given SPI value is configured by some other protocol, e.g., the DTLS-SRTP extension defined in Section 5. 4.3. Packet Processing and State Machine - At any given time, each SRTP/SRTCP source has associated with it a - single EKT parameter set. This parameter set is used to process all + At any given time, 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 other - SRTP/SRTCP sources in the same session, including other SRTP/SRTCP - sources on the same endpoint (e.g., one endpoint with voice and video - might have two EKT parameter sets, or there might be multiple video - sources on an endpoint each with their own EKT parameter set). All - of the received EKT parameter sets SHOULD be stored by all of the - participants in an SRTP session, for use in processing inbound SRTP - and SRTCP traffic. If a participant deletes an EKT parameter set - (e.g., because of space limitations, then it will be unable to - process Full EKT Tags containing updated media keys, and thus unable - to receive media from a particpant that has changed its media key. + SRTP sources in the same session, including other SRTP sources on the + same endpoint (e.g., one endpoint with voice and video might have two + EKT parameter sets, or there might be multiple video sources on an + endpoint each with their own EKT parameter set). All of the received + EKT parameter sets SHOULD be stored by all of the participants in an + SRTP session, for use in processing inbound SRTP traffic. If a + participant deletes an EKT parameter set (e.g., because of space + limitations, then it will be unable to process Full EKT Tags + containing updated media keys, and thus unable to receive media from + a particpant that has changed its media key. Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets. The decision on which to send when is specified in Section 4.6. 4.3.1. Outbound Processing See Section 4.6 which describes when to send an SRTP packet with a FullEKTField. If a FullEKTField is not being sent, then a ShortEKTField is sent so the receiver can correctly determine how to process the packet. When an SRTP packet is sent with a FullEKTField, the EKTField for that packet is created as follows, or uses an equivalent set of - steps. The creation of the EKTField MUST precede the normal SRTP - packet processing. + steps. 1. The Security Parameter Index (SPI) field is set to the value of the Security Parameter Index that is associated with the outbound parameter set. 2. The EKTPlaintext field is computed from the SRTP Master Key, SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP Master Key, and SSRC used in EKT processing MUST be the same as the one used in the SRTP processing. @@ -421,32 +422,31 @@ value of 250ms is chosen to represent a reasonable upper bound on the amount of latency and jitter that is tolerable in a real-time context.) 4.3.2. Inbound Processing When receiving a packet on a RTP stream, the following steps are applied for each SRTP received packet. 1. The final byte is checked to determine which EKT format is in - use. When an SRTP or SRTCP packet contains a ShortEKTField, the - ShortEKTField is removed from the packet then normal SRTP or - SRTCP processing occurs. If the packet contains a FullEKTField, - then processing continues as described below. The reason for - using the last byte of the packet to indicate the type is that - the length of the SRTP or SRTCP part is not known until the - decryption has occurred. At this point in the processing, there - is no easy way to know where the EKTField would start. However, - the whole UDP packet has been received, so instead of the - starting at the front of the packet, the parsing works backwards - at the end of the packet and thus the type is placed at the very - end of the packet. + use. When an SRTP packet contains a ShortEKTField, the + ShortEKTField is removed from the packet then normal SRTP + processing occurs. If the packet contains a FullEKTField, then + processing continues as described below. The reason for using + the last byte of the packet to indicate the type is that the + length of the SRTP part is not known until the decryption has + occurred. At this point in the processing, there is no easy way + to know where the EKTField would start. However, the whole UDP + packet has been received, so instead of the starting at the front + of the packet, the parsing works backwards at the end of the + packet and thus the type is placed at the very end of the packet. 2. The Security Parameter Index (SPI) field is used to find the right EKT parameter set to be used for processing the packet. If there is no matching SPI, then the verification function MUST return an indication of authentication failure, and the steps described below are not performed. The EKT parameter set contains the EKTKey, EKTCipher, and the SRTP Master Salt. 3. The EKTCiphertext is authenticated and decrypted, as described in Section 4.4, using the EKTKey and EKTCipher found in the previous @@ -455,23 +455,24 @@ SHOULD discard the whole UDP packet. 4. The resulting EKTPlaintext is parsed as described in Section 4.1, to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP Master Salt that is associated with the EKTKey is also retrieved. If the value of the srtp_master_salt sent as part of the EKTkey is longer than needed by SRTP, then it is truncated by taking the first N bytes from the srtp_master_salt field. 5. If the SSRC in the EKTPlaintext does not match the SSRC of the - SRTP packet received, then all the information from this - EKTPlaintext MUST be discarded and the following steps in this - list are skipped. + SRTP packet received, then this FullEKTField MUST be discarded + and the following steps in this list skipped. After stripping + the FullEKTField, the remainder of the SRTP packet MAY be + processed as normal. 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous steps are saved in a map indexed by the SSRC found in the EKTPlaintext and can be used for any future crypto operations on the inbound packets with that SSRC. * Unless the transform specifies other acceptable key lengths, the length of the SRTP Master Key MUST be the same as the master key length for the SRTP transform in use. If this is not the case, then the receiver MUST abort EKT processing and @@ -480,21 +481,21 @@ * If the length of the SRTP Master Key is less than the master key length for the SRTP transform in use, and the transform specifies that this length is acceptable, then the SRTP Master Key value is used to replace the first bytes in the existing master key. The other bytes remain the same as in the old key. For example, the Double GCM transform [I-D.ietf-perc-double] allows replacement of the first, "end to end" half of the master key. 7. At this point, EKT processing has successfully completed, and the - normal SRTP or SRTCP processing takes place. + normal SRTP processing takes place. The value of the EKTCiphertext field is identical in successive packets protected by the same EKT parameter set and the same SRTP master key, and ROC. SRTP senders and receivers MAY cache an EKTCiphertext value to optimize processing in cases where the master key hasn't changed. Instead of encrypting and decrypting, senders can simply copy the pre-computed value and receivers can compare a received EKTCiphertext to the known value. Section 4.3.1 recommends that SRTP senders continue using an old key @@ -593,21 +594,22 @@ how it is processed when it is read. This field is opaque to the other aspects of EKT processing. EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input. The values of the parameters L, and T MUST be defined by each EKTCipher. The cipher MUST provide integrity protection. 4.5. Synchronizing Operation If a source has its EKTKey changed by the key management, it MUST also change its SRTP master key, which will cause it to send out a - new FullEKTField. This ensures that if key management thought the + new FullEKTField and eventually begin encrypting with it, as defined + in Section 4.3.1. This ensures that if key management thought the EKTKey needs changing (due to a participant leaving or joining) and communicated that to a source, the source will also change its SRTP master key, so that traffic can be decrypted only by those who know the current EKTKey. 4.6. Timing and Reliability Consideration A system using EKT learns the SRTP master keys distributed with the FullEKTField sent with the SRTP, rather than with call signaling. A receiver can immediately decrypt an SRTP packet, provided the SRTP @@ -622,57 +624,62 @@ master key which needs to be communicated to all the receivers. The third case is a new receiver joining a session already in progress which needs to know the sender's SRTP master key. The three cases are: New sender: A new sender SHOULD send a packet containing the FullEKTField as soon as possible, always before or coincident with sending its initial SRTP packet. To accommodate packet loss, it is - RECOMMENDED that three consecutive packets contain the - FullEKTField be transmitted. If the sender does not send a - FullEKTField in its initial packets and receivers have not - otherwise been provisioned with a decryption key, then decryption - will fail and SRTP packets will be dropped until the receiver - receives a FullEKTField from the sender. + RECOMMENDED that the FullEKTField be transmitted in three + consecutive packets. If the sender does not send a FullEKTField + in its initial packets and receivers have not otherwise been + provisioned with a decryption key, then decryption will fail and + SRTP packets will be dropped until the receiver receives a + FullEKTField from the sender. Rekey: By sending EKT tag over SRTP, the rekeying event shares fate with the SRTP packets protected with that new SRTP master key. To accommodate packet loss, it is RECOMMENDED that three consecutive packets contain the FullEKTField be transmitted. New receiver: When a new receiver joins a session it does not need to communicate its sending SRTP master key (because it is a receiver). When a new receiver joins a session, the sender is generally unaware of the receiver joining the session. Thus, senders SHOULD periodically transmit the FullEKTField. That interval depends on how frequently new receivers join the session, the acceptable delay before those receivers can start processing SRTP packets, and the acceptable overhead of sending the FullEKTField. If sending audio and video, the RECOMMENDED frequency is the same as the rate of intra coded video frames. If only sending audio, the RECOMMENDED frequency is every 100ms. + In general, sending EKT tags less frequently will consume less + bandwidth, but increase the time it takes for a join or rekey to take + effect. Applications should schedule the sending of EKT tags in a + way that makes sense for their bandwidth and latency requirements. + 5. Use of EKT with DTLS-SRTP This document defines an extension to DTLS-SRTP called SRTP EKTKey Transport which enables secure transport of EKT keying material from the DTLS-SRTP peer in the server role to the client. This allows - those peers to process EKT keying material in SRTP (or SRTCP) and - retrieve the embedded SRTP keying material. This combination of - protocols is valuable because it combines the advantages of DTLS, - which has strong authentication of the endpoint and flexibility, - along with allowing secure multiparty RTP with loose coordination and - efficient communication of per-source keys. + those peers to process EKT keying material in SRTP and retrieve the + embedded SRTP keying material. This combination of protocols is + valuable because it combines the advantages of DTLS, which has strong + authentication of the endpoint and flexibility, along with allowing + secure multiparty RTP with loose coordination and efficient + communication of per-source keys. In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT key material can allow EKT keys to be tunneled through an untrusted relay such as a centralized conference bridge. For more details, see [I-D.ietf-perc-private-media-framework]. 5.1. DTLS-SRTP Recap DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers