--- 1/draft-ietf-perc-srtp-ekt-diet-05.txt 2017-10-30 16:13:34.519093070 -0700 +++ 2/draft-ietf-perc-srtp-ekt-diet-06.txt 2017-10-30 16:13:34.567094218 -0700 @@ -1,23 +1,23 @@ -PERC Working Group C. Jennings -Internet-Draft Cisco -Intended status: Standards Track J. Mattsson, Ed. -Expires: December 31, 2017 Ericsson +Network Working Group C. Jennings +Internet-Draft Cisco Systems +Intended status: Standards Track J. Mattsson +Expires: May 3, 2018 Ericsson AB D. McGrew D. Wing - F. Andreasen - Cisco - June 29, 2017 + F. Andreason + Cisco Systems + October 30, 2017 Encrypted Key Transport for DTLS and Secure RTP - draft-ietf-perc-srtp-ekt-diet-05 + draft-ietf-perc-srtp-ekt-diet-06 Abstract Encrypted Key Transport (EKT) is an extension to DTLS 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. @@ -29,21 +29,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 http://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 31, 2017. + This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -52,42 +52,44 @@ 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions Used In This Document . . . . . . . . . . . . . . 4 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 - 4.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4 + 4.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 5 4.2. Packet Processing and State Machine . . . . . . . . . . . 7 4.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 8 4.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 9 4.3. Implementation Notes . . . . . . . . . . . . . . . . . . 10 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12 4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4.7. Timing and Reliability Consideration . . . . . . . . . . 13 + 4.7. Timing and Reliability Consideration . . . . . . . . . . 12 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 13 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14 - 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 17 - 5.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 17 + 5.2.1. Negotiating an EKT Cipher . . . . . . . . . . . . . . 16 + 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 16 + 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18 + 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 19 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20 - 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 20 - 7.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 21 + 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 21 + 7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Real-time Transport Protocol (RTP) is designed to allow decentralized groups with minimal control to establish sessions, such as for @@ -174,21 +176,21 @@ EKT defines a new method of providing SRTP master keys to an endpoint. In order to convey the ciphertext corresponding to the SRTP master key, and other additional information, an additional EKT field is added to SRTP packets. The EKT field appears at the end of the SRTP packet. The EKT field appears after the optional authentication tag if one is present, otherwise the EKT field appears after the ciphertext portion of the packet. EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's [RFC3711], as those SRTP - features duplicate some of the functions of EKT. Senders MUST not + features duplicate some of the functions of EKT. Senders MUST NOT include MKI when using EKT. Receivers SHOULD simply ignore any MKI field received if EKT is in use. 4.1. EKT Field Formats The EKT Field uses the format defined below for the FullEKTField and ShortEKTField. 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 @@ -243,75 +245,75 @@ ExtensionData = 1*1024BYTE ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension EKTField = FullEKTField / ShortEKTField / ExtensionEKTField Figure 3: EKTField Syntax These fields and data elements are defined as follows: - EKTPlaintext: The data that is input to the EKT encryption - operation. This data never appears on the wire, and is used only - in computations internal to EKT. This is the concatenation of the - SRTP Master Key, the SSRC, and the ROC. + EKTPlaintext: The data that is input to the EKT encryption operation. + This data never appears on the wire, and is used only in computations + internal to EKT. This is the concatenation of the SRTP Master Key, + the SSRC, and the ROC. EKTCiphertext: The data that is output from the EKT encryption - operation, described in Section 4.4. This field is included in - SRTP packets when EKT is in use. The length of EKTCiphertext can - be larger than the length of the EKTPlaintext that was encrypted. + operation, described in Section 4.4. This field is included in SRTP + packets when EKT is in use. The length of EKTCiphertext can be + larger than the length of the EKTPlaintext that was encrypted. SRTPMasterKey: On the sender side, the SRTP Master Key associated with the indicated SSRC. SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This - depends on the cipher suite negotiated for SRTP using [RFC3264] - SDP Offer/Answer for the SRTP. + depends on the cipher suite negotiated for SRTP using SDP Offer/ + Answer [RFC3264] for the SRTP. SSRC: On the sender side, this field is the SSRC for this SRTP source. The length of this field is 32 bits. Rollover Counter (ROC): On the sender side, this field is set to the current value of the SRTP rollover counter in the SRTP context - associated with the SSRC in the SRTP or SRTCP packet. The length - of this field is 32 bits. + associated with the SSRC in the SRTP or SRTCP packet. The length of + this field is 32 bits. Security Parameter Index (SPI): This field indicates the appropriate - EKT Key and other parameters for the receiver to use when - processing the packet. The length of this field is 16 bits. The - parameters identified by this field are: + EKT Key and other parameters for the receiver to use when processing + the packet. The length of this field is 16 bits. The parameters + identified by this field are: - * The EKT cipher used to process the packet. + o The EKT cipher used to process the packet. - * The EKT Key used to process the packet. + o The EKT Key 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. + o 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. - Each distinct EKT parameter set that is used MUST be associated - with a distinct SPI value to avoid ambiguity. + 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. EKTMsgLength: All EKT message other that ShortEKTField have a length as second from the last element. This is the length in octets of - either the FullEKTField/ExtensionEKTField including this length - field and the following message type. + either the FullEKTField/ExtensionEKTField including this length field + and the following message type. Message Type: The last byte is used to indicate the type of the EKTField. This MUST be 2 in the FullEKTField format and 0 in ShortEKTField format. Values less than 64 are mandatory to - understand while other values are optional to understand. A - receiver SHOULD discard the whole EKTField if it contains any - message type value that is less than 64 and that is not - understood. Message type values that are 64 or greater but not - implemented or understood can simply be ignored. + understand while other values are optional to understand. A receiver + SHOULD discard the whole EKTField if it contains any message type + value that is less than 64 and that is not understood. Message type + values that are 64 or greater but not implemented or understood can + simply be ignored. 4.2. 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 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 @@ -347,21 +349,21 @@ 3. The EKTCiphertext field is set to the ciphertext created by encrypting the EKTPlaintext with the EKT cipher, using the EKTKey as the encryption key. The encryption process is detailed in Section 4.4. 4. Then the FullEKTField is formed using the EKTCiphertext and the SPI associated with the EKTKey used above. Also appended are the Length and Message Type using the FullEKTField format. - Note: the value of the EKTCiphertext field is identical in + * Note: the value of the EKTCiphertext field is identical in successive packets protected by the same EKTKey and SRTP master key. This value MAY be cached by an SRTP sender to minimize computational effort. The computed value of the FullEKTField is written into the packet. When a packet is sent with the Short EKT Field, the ShortEKFField is simply appended to the packet. @@ -500,28 +502,27 @@ a length of N = M + (M mod 8) + 8 octets. It can be used with key sizes of L = 16, and L = 32 octets, and its use with those key sizes is indicated as AESKW128, or AESKW256, respectively. The key size determines the length of the AES key used by the Key Wrap algorithm. With this cipher, T=2^48. +----------+----+------+ | Cipher | L | T | +----------+----+------+ | AESKW128 | 16 | 2^48 | - | | | | | AESKW256 | 32 | 2^48 | +----------+----+------+ Table 1: EKT Ciphers - As AES-128 is the mandatory to implement transform in SRTP [RFC3711], - AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented. + As AES-128 is the mandatory to implement transform in SRTP, AESKW128 + MUST be implemented for EKT and AESKW256 MAY be implemented. 4.4.2. Defining New EKT Ciphers Other specifications may extend this document by defining other EKTCiphers as described in Section 7. This section defines how those ciphers interact with this specification. An EKTCipher determines how the EKTCiphertext field is written, and 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 @@ -559,198 +560,231 @@ There are three cases to consider. The first case is a new sender joining a session which needs to communicate its SRTP master key to all the receivers. The second case is a sender changing its SRTP 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 Full EKT + 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 Full EKT Field be transmitted. - Rekey: By sending EKT over SRTP, the rekeying event shares fate with - the SRTP packets protected with that new SRTP master key. To + Rekey: + By sending EKT 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 + 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 FullEKT Field. 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. 5. Use of EKT with DTLS-SRTP This document defines an extension to DTLS-SRTP called SRTP EKT Key Transport which enables secure transport of EKT keying material from - one DTLS-SRTP peer to another. 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. + 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. 5.1. DTLS-SRTP Recap DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers to exchange keying material, algorithms, and parameters for SRTP. The SRTP flow operates over the same transport as the DTLS-SRTP exchange (i.e., the same 5-tuple). DTLS-SRTP combines the performance and encryption flexibility benefits of SRTP with the flexibility and convenience of DTLS-integrated key and association management. DTLS-SRTP can be viewed in two equivalent ways: as a new key management method for SRTP, and a new RTP-specific data format for DTLS. 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP - This document defines a new TLS negotiated extension called - "srtp_ekt_key_transport"and a new TLS content type called EKTMessage. + This document defines a new TLS negotiated extension + supported_ekt_ciphers and a new TLS handshake message type ekt_key. + The extension negotiates the cipher to be used in encrypting and + decrypting EKTCiphertext values, and the handshake message carries + the corresponding key. - Using the syntax described in DTLS [RFC6347], the following - structures are used: + The diagram below shows a message flow of DTLS 1.3 client and server + using EKT configured using the DTLS extensions described in this + section. (The initial cookie exchange and other normal DTLS messages + are omitted.) + Client Server + + ClientHello + + use_srtp + + supported_ekt_ciphers + --------> + + ServerHello + {EncryptedExtensions} + + use_srtp + + supported_ekt_ciphers + {... Finished} + <-------- + + {... Finished} --------> + + [Ack] + <-------- [EKTKey] + + [Ack] --------> + + |SRTP packets| <-------> |SRTP packets| + + + + + {} 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 + + Figure 4 + + In the context of a multi-party SRTP session in which each endpoint + performs a DTLS handshake as a client with a central DTLS server, the + extensions defined in this session allow the DTLS server to set a + common EKT key among all participants. Each endpoint can then use + EKT tags encrypted with that common key to inform other endpoint of + the keys it is using to protect SRTP packet. This avoids the need + for many individual DTLS handshakes among the endpoints, at the cost + of 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-------------- + +5.2.1. Negotiating an EKT Cipher + + To indicate its support for EKT, a DTLS-SRTP client includes in its + ClientHello an extension of type supported_ekt_ciphers listing the + EKT ciphers the client supports in preference order, with the most + preferred version first. If the server agrees to use EKT, then it + includes a supported_ekt_ciphers extension in its ServerHello + containing a cipher selected from among those advertised by the + client. + + The extension_data field of this extension contains an "EKTCipher" + value, encoded using the syntax defined in [RFC5246]: enum { reserved(0), aeskw_128(1), aeskw_256(2), } EKTCipherType; struct { - EKTCipherType ekt_ciphers<1..255>; - } SupportedEKTCiphers; + select (Handshake.msg_type) { + case client_hello: + EKTCipherType supported_ciphers<1..255>; - struct { - EKTCipherType ekt_cipher; - uint ekt_key_value<1..256>; - uint srtp_master_salt<1..256>; - uint16 ekt_spi; - uint24 ekt_ttl; - } EKTkey; + case server_hello: + EKTCipherType selected_cipher; + }; + } EKTCipher; - enum { - ekt_key(0), - ekt_key_ack(1), - ekt_key_error(254), - (255) - } EKTMessageType; +5.2.2. Establishing an EKT Key - struct { - EKTMessageType ekt_message_type; - select (EKTMessage.ekt_message_type) { - case ekt_key: - EKTKey; - } message; - } EKTMessage; + Once a client and server have concluded a handshake that negotiated + an EKT cipher, the server MUST provide to the client a key to be used + when encrypting and decrypting EKTCiphertext values. EKT keys are + sent in encrypted handshake records, using handshake type + ekt_key(TBD). The body of the handshake message contains an EKTKey + structure: - Figure 4: Additional TLS Data Structures + [[ NOTE: RFC Editor, please replace "TBD" above with the code point + assigend by IANA ]] - If a DTLS client includes "srtp_ekt_key_transport" in its - ClientHello, then a DTLS server that supports this extensions will - includes "srtp_ekt_key_transport" in its ServerHello message. If a - DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but - does not receive "srtp_ekt_key_transport" in the ServerHello, the - DTLS client MUST NOT send DTLS EKTMessage messages. Also, the - "srtp_ekt_key_transport" in the ServerHello MUST select one and only - one EKTCipherType from the list provided by the client in the - "srtp_ekt_key_transport" in the ClientHello. + struct { + opaque ekt_key_value<1..256>; + opaque srtp_master_salt<1..256>; + uint16 ekt_spi; + uint24 ekt_ttl; + } EKTKey; - When a DTLS client sends the "srtp_ekt_key_transport" in its - ClientHello message, it MUST include the SupportedEKTCiphers as the - extension_data for the extension, listing the EKTCipherTypes the - client is willing to use in preference order, with the most preferred - version first. When the server responds in the - "srtp_ekt_key_transport" in its ServerHello message, it MUST include - a SupportedEKTCiphers list that selects a single EKTCipherType to use - (selected from the list provided by the client) or it returns an - empty list to indicate there is no matching EKTCipherType in the - clients list that the server is also willing to use. The value to be - used in the EKTCipherType for future extensions that define new - ciphers is the value from the "EKT Ciphers Type" IANA registry - defined in Section 7.2. + The contents of the fields in this message are as follows: - The figure above defines the contents for a new TLS content type - called EKTMessage which is registered in Section 7.4. The EKTMessage - above is used as the opaque fragment in the TLSPlaintext structure - defined in Section 6.2.1 of [RFC5246] and the "srtp_ekt_message" as - the content type. The "srtp_ekt_message" content type is defined and - registered in Section 7.3. + ekt_key_value + The EKT Key that the recipient should use when generating + EKTCiphertext values - ekt_ttl: The maximum amount of time, in seconds, that this - ekt_key_value can be used. The ekt_key_value in this message MUST - NOT be used for encrypting or decrypting information after the TTL - expires. + srtp_master_salt + The SRTP Master Salt to be used with any Master Key encrypted with + this EKT Key - When the Server wishes to provide a new EKT Key, it can send - EKTMessage containing an EKTKey with the new key information. The - client MUST respond with an EKTMessage of type ekt_key_ack, if the - EKTKey was successfully processed and stored or respond with the the - ekt_key_error EKTMessage otherwise. + ekt_spi + The SPI value to be used to reference this EKT Key and SRTP Master + Salt in EKT tags (along with the EKT cipher negotiated in the + handshake) - The diagram below shows a message flow of DTLS client and DTLS server - using the DTLS-SRTP Key Transport extension. + ekt_ttl + The maximum amount of time, in seconds, that this EKT Key can be + used. The ekt_key_value in this message MUST NOT be used for + encrypting or decrypting information after the TTL expires. - Client Server + If the server did not provide a supported_ekt_ciphers extension in + its ServerHello, then EKTKey messages MUST NOT be sent by either the + client or the server. - ClientHello + use_srtp + srtp_ekt_key_trans - --------> - ServerHello+use_srtp+srtp_ekt_key_trans - Certificate* - ServerKeyExchange* - CertificateRequest* - <-------- ServerHelloDone - Certificate* - ClientKeyExchange - CertificateVerify* - [ChangeCipherSpec] - Finished --------> - [ChangeCipherSpec] - <-------- Finished - ekt_key <-------- - ekt_key_ack --------> - SRTP packets <-------> SRTP packets - SRTP packets <-------> SRTP packets - ekt_key (rekey) <------- - ekt_key_ack --------> - SRTP packets <-------> SRTP packets - SRTP packets <-------> SRTP packets + When an EKTKey is received and processed successfully, the recipient + MUST respond with an Ack handshake message as described in Section 7 + of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack must be + retransmitted following the rules in Secton 4.2.4 of [RFC6347]. - Figure 5: DTLS/SRTP Message Flow + Note: To be clear, EKT can be used with versions of DTLS prior to + 1.3. The only difference is that in a pre-1.3 TLS stacks will not + have built-in support for generating and processing Ack messages. - Note that when used in PERC [I-D.ietf-perc-private-media-framework], - the Server is actually split between the Media Distrbutor and Key - Distributor. The messages in the above figure that are "SRTP - packets" will not got to the Key Distributor but the oter packets - will be relayed by the Media Distributor to the Key Distributor. + If an EKTKey message is received that cannot be processed, then the + recipient MUST respond with an appropriate DTLS alert. 5.3. Offer/Answer Considerations When using EKT with DTLS-SRTP, the negotiation to use EKT is done at the DTLS handshake level and does not change the [RFC3264] Offer / Answer messaging. -5.4. Sending the DTLS EKT_Key Reliably +5.4. Sending the DTLS EKTKey Reliably - The DTLS ekt_key is sent using the retransmissions specified in - Section 4.2.4. of DTLS [RFC6347]. + The DTLS EKTKey message is sent using the retransmissions specified + in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished + with an Ack message or an alert is received. 6. Security Considerations EKT inherits the security properties of the DTLS-SRTP (or other) keying it uses. With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This property avoids any security concern over the re- use of keys, by empowering the SRTP layer to create keys on demand. Note that the inputs of EKT are the same as for SRTP with key- @@ -787,21 +821,21 @@ attempt to consume additional CPU resources of the receiving system by causing the receiving system will decrypt the EKT ciphertext and detect an authentication failure. In some cases, caching the previous values of the Ciphertext as described in Section 4.3 helps mitigate this issue. Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT encrypt more than T different Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL - described in Section 5.2. + described in Figure 4. The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher and at least as strong as the DTLS-SRTP ciphers. Part of the EKTPlaintext is known, or easily guessable to an attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. In practice, this requirement does not impose any restrictions on our choices, since the ciphers in use provide high security even when much plaintext is known. @@ -823,25 +857,22 @@ 7.1. EKT Message Types IANA is requested to create a new table for "EKT Messages Types" in the "Real-Time Transport Protocol (RTP) Parameters" registry. The initial values in this registry are: +--------------+-------+---------------+ | Message Type | Value | Specification | +--------------+-------+---------------+ | Short | 0 | RFCAAAA | - | | | | | Full | 2 | RFCAAAA | - | | | | | Reserved | 63 | RFCAAAA | - | | | | | Reserved | 255 | RFCAAAA | +--------------+-------+---------------+ Table 2: EKT Messages Types Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification. New entries to this table can be added via "Specification Required" as defined in [RFC5226]. When requesting a new value, the requestor @@ -858,173 +889,161 @@ 7.2. EKT Ciphers IANA is requested to create a new table for "EKT Ciphers" in the "Real-Time Transport Protocol (RTP) Parameters" registry. The initial values in this registry are: +----------+-------+---------------+ | Name | Value | Specification | +----------+-------+---------------+ | AESKW128 | 1 | RFCAAAA | - | | | | | AESKW256 | 2 | RFCAAAA | - | | | | | Reserved | 255 | RFCAAAA | +----------+-------+---------------+ Table 3: EKT Cipher Types Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification. New entries to this table can be added via "Specification Required" as defined in [RFC5226]. The expert SHOULD ensure the specification defines the values for L and T as required in Section 4.4 of RFCAAA. Allocated values MUST be in the range of 1 to 254. 7.3. TLS Extensions - IANA is requested to add "srtp_ekt_key_transport" as an new extension + IANA is requested to add supported_ekt_ciphers as a new extension name to the "ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this - specification and allocate a value of TBD to for this. Note to RFC - Editor: TBD will be allocated by IANA. + specification and allocate a value of TBD to for this. + + [[ Note to RFC Editor: TBD will be allocated by IANA. ]] Considerations for this type of extension are described in Section 5 of [RFC4366] and requires "IETF Consensus". -7.4. TLS Content Type +7.4. TLS Handshake Type - IANA is requested to add "srtp_ekt_message" as an new descriptions - name to the "TLS ContentType Registry" table of the "Transport Layer - Security (TLS) Extensions" registry with a reference to this - specification, a DTLS-OK value of "Y", and allocate a value of TBD to - for this content type. Note to RFC Editor: TBD will be allocated by - IANA. + IANA is requested to add ekt_key as a new entry in the "TLS + HandshakeType Registry" table of the "Transport Layer Security (TLS) + Parameters" registry with a reference to this specification, a DTLS- + OK value of "Y", and allocate a value of TBD to for this content + type. + + [[ Note to RFC Editor: TBD will be allocated by IANA. ]] This registry was defined in Section 12 of [RFC5246] and requires "Standards Action". 8. Acknowledgements Thank you to Russ Housley provided detailed review and significant help with crafting text for this document. Thanks to David Benham, Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, comments, and contributions to this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . + DOI 10.17487/RFC2119, March 1997, . + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, - . - - [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC 4086, - DOI 10.17487/RFC4086, June 2005, - . + . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 5226, - DOI 10.17487/RFC5226, May 2008, - . + IANA Considerations Section in RFCs", RFC 5226, + DOI 10.17487/RFC5226, May 2008, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, - DOI 10.17487/RFC5234, January 2008, - . + DOI 10.17487/RFC5234, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, - DOI 10.17487/RFC5246, August 2008, - . + DOI 10.17487/RFC5246, August 2008, . [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, - DOI 10.17487/RFC5649, September 2009, - . + DOI 10.17487/RFC5649, September 2009, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, - DOI 10.17487/RFC5764, May 2010, - . + DOI 10.17487/RFC5764, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, - January 2012, . + January 2012, . 9.2. Informative References [I-D.ietf-perc-double] - Jennings, C., Jones, P., and A. Roach, "SRTP Double - Encryption Procedures", draft-ietf-perc-double-02 (work in - progress), October 2016. + Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP + Double Encryption Procedures", draft-ietf-perc-double-07 + (work in progress), September 2017. [I-D.ietf-perc-private-media-framework] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy Enhanced RTP - Conferencing", draft-ietf-perc-private-media-framework-02 - (work in progress), October 2016. + Conferencing", draft-ietf-perc-private-media-framework-04 + (work in progress), July 2017. - [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model - with Session Description Protocol (SDP)", RFC 3264, - DOI 10.17487/RFC3264, June 2002, - . + [I-D.ietf-tls-dtls13] + Rescorla, E., Tschofenig, H., and N. Modadugu, "The + Datagram Transport Layer Security (DTLS) Protocol Version + 1.3", draft-ietf-tls-dtls13-02 (work in progress), October + 2017. + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, . [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, - . + . Authors' Addresses Cullen Jennings Cisco Systems - Calgary, AB - Canada Email: fluffy@iii.ca - John Mattsson (editor) + John Mattsson Ericsson AB - SE-164 80 Stockholm - Sweden - Phone: +46 10 71 43 501 Email: john.mattsson@ericsson.com David A. McGrew Cisco Systems - 510 McCarthy Blvd. - Milpitas, CA 95035 - US - Phone: (408) 525 8651 Email: mcgrew@cisco.com - URI: http://www.mindspring.com/~dmcgrew/dam.htm Dan Wing Cisco Systems - 510 McCarthy Blvd. - Milpitas, CA 95035 - US - Phone: (408) 853 4197 Email: dwing@cisco.com - Flemming Andreason Cisco Systems - 499 Thornall Street - Edison, NJ 08837 - US Email: fandreas@cisco.com