--- 1/draft-ietf-perc-srtp-ekt-diet-08.txt 2018-10-17 15:13:09.155020374 -0700 +++ 2/draft-ietf-perc-srtp-ekt-diet-09.txt 2018-10-17 15:13:09.203021526 -0700 @@ -1,99 +1,101 @@ Network Working Group C. Jennings Internet-Draft Cisco Systems Intended status: Standards Track J. Mattsson -Expires: January 16, 2019 Ericsson AB +Expires: April 20, 2019 Ericsson AB D. McGrew + Cisco Systems D. Wing + F. Andreason Cisco Systems - July 15, 2018 + October 17, 2018 Encrypted Key Transport for DTLS and Secure RTP - draft-ietf-perc-srtp-ekt-diet-08 + draft-ietf-perc-srtp-ekt-diet-09 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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/. + 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 January 16, 2019. + This Internet-Draft will expire on April 20, 2019. Copyright Notice Copyright (c) 2018 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 + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 12 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 12 - 4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Timing and Reliability Consideration . . . . . . . . . . 13 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 14 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 14 5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 20 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 20 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 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 9.2. Informative References . . . . . . . . . . . . . . . . . 23 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 multimedia conferences. Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many minimal-control scenarios, because it requires that synchronization source (SSRC) values and other data be coordinated among all of the participants in a session. For example, @@ -154,51 +156,53 @@ endpoint. This specification also defines a way to send the encrypted SRTP master key (with the EKTKey) along with the SRTP packet, see Section 4. Endpoints that receive this and know the EKTKey can use the EKTKey to decrypt the SRTP master key which can then be used to decrypt the SRTP packet. One way to use this is described in the architecture defined by [I-D.ietf-perc-private-media-framework]. Each participant in the conference forms a DTLS-SRTP connection to a common key distributor that distributes the same EKTKey to all the endpoints. Then each - endpoint picks their own SRTP master key for the media they send. - When sending media, the endpoint also includes the SRTP master key + endpoint picks its own SRTP master key for the media they send. When + sending media, the endpoint also includes the SRTP master key encrypted with the EKTKey in the SRTP packet. This allows all the endpoints to decrypt the media. 3. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 4. Encrypted Key Transport 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 field, called EKTField, is added to the SRTP packets. The EKTField appears at the end of the SRTP packet. It appears after the optional authentication tag if one is present, otherwise the EKTField 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 include MKI when using EKT. Receivers SHOULD simply ignore any MKI field received if EKT is in use. 4.1. EKTField Formats - The EKTField uses the format defined below for the FullEKTField and - ShortEKTField. + The EKTField uses the format defined in Figure 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : EKT Ciphertext : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameter Index | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -361,20 +365,25 @@ 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 SRTP packet. When a packet is sent with the ShortEKTField, the ShortEKFField is simply appended to the packet. + Outbound packets SHOULD continue to use the old SRTP Master Key for + 250 ms after sending any new key. This gives all the receivers in + the system time to get the new key before they start receiving media + encrypted with the new key. + 4.2.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 @@ -387,82 +396,90 @@ 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 authentication is checked and is decrypted, as - described in Section 4.4, using the EKTKey and EKTCipher found in - the previous step. If the EKT decryption operation returns an - authentication failure, then the packet processing stops. + 3. The EKTCiphertext is authenticated and decrypted, as described in + Section 4.4, using the EKTKey and EKTCipher found in the previous + step. If the EKT decryption operation returns an authentication + failure, then EKT processing MUST be aborted. The receiver + 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. 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. If the SRTP Master Key - recovered from the EKTPlaintext is longer than needed by SRTP - transform in use, the first bytes are used. If the SRTP Master - Key recovered from the EKTPlaintext is shorter than needed by - SRTP transform in use, then the bytes received replace the first - bytes in the existing key but the other bytes after that remain - the same as the old key. This applies in transforms such as - [I-D.ietf-perc-double] for replacing just half the key, but - SHOULD return a processing error otherwise. Outbound packets - SHOULD continue to use the old SRTP Master Key for 250 ms after - sending any new key. This gives all the receivers in the system - time to get the new key before they start receiving media - encrypted with the new key. + 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 + SHOULD discared the whole UDP packet. + + * 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 including replay - protection. + normal SRTP or SRTCP processing takes place. 4.3. Implementation Notes 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. This ciphertext value MAY be cached by an SRTP - receiver to minimize computational effort by noting when the SRTP - master key is unchanged and avoiding repeating the steps defined in . + 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. - The receiver may want to have a sliding window to retain old SRTP - Master Keys (and related context) for some brief period of time, so - that out of order packets can be processed as well as packets sent - during the time keys are changing. + Section 4.2.1 recommends that SRTP senders continue using an old key + for some time after sending a new key in an EKT tag. Receivers that + wish to avoid packet loss due to decryption failures MAY perform + trial decryption with both the old key and the new key, keeping the + result of whichever decryption succeeds. Note that this approach is + only compatible with SRTP transforms that include integrity + protection. When receiving a new EKTKey, implementations need to use the ekt_ttl - to create a time after which this key cannot be used and they also - need to create a counter that keeps track of how many times the key - has been used to encrypt data to ensure it does not exceed the T - value for that cipher (see ). If either of these limits are - exceeded, the key can no longer be used for encryption. At this - point implementation need to either use the call signaling to - renegotiate a new session or need to terminate the existing session. - Terminating the session is a reasonable implementation choice because - these limits should not be exceeded except under an attack or error - condition. + field (see Section 5.2.2) to create a time after which this key + cannot be used and they also need to create a counter that keeps + track of how many times the key has been used to encrypt data to + ensure it does not exceed the T value for that cipher (see ). If + either of these limits are exceeded, the key can no longer be used + for encryption. At this point implementation need to either use the + call signaling to renegotiate a new session or need to terminate the + existing session. Terminating the session is a reasonable + implementation choice because these limits should not be exceeded + except under an attack or error condition. 4.4. Ciphers EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext. This specification defines the interface to the cipher, in order to abstract the interface away from the details of that function. This specification also defines the default cipher that is used in EKT. The default cipher described in Section 4.4.1 MUST be implemented, but another cipher that conforms to this interface MAY be used. @@ -538,51 +555,56 @@ 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 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. Transport - EKT SHOULD be used over SRTP, and other specification MAY define how - to use it over SRTCP. SRTP is preferred because it shares fate with - the transmitted media, because SRTP rekeying can occur without - concern for RTCP transmission limits, and to avoid SRTCP compound - packets with RTP translators and mixers. + 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.7. 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 packet contains a FullEKTField. This section describes how to reliably and expediently deliver new SRTP master keys to receivers. 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 + 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 - FullEKTField be transmitted. + 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 the 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 @@ -621,24 +643,23 @@ for DTLS. 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP 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. - 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.) + Figure 4 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 @@ -662,21 +683,21 @@ <> 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 allows the DTLS server to set a + extensions defined in this document allow the DTLS server to set a common EKTKey for all participants. Each endpoint can then use EKT tags encrypted with that common key to inform other endpoint of the keys it uses to protect SRTP packets. 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--------- @@ -753,21 +774,21 @@ The maximum amount of time, in seconds, that this EKTKey can be used. The ekt_key_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires. If the server did not provide a supported_ekt_ciphers extension in its ServerHello, then EKTKey messages MUST NOT be sent by the client or the server. 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 + of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be retransmitted following the rules in Section 4.2.4 of [RFC6347]. 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. 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 @@ -777,22 +798,23 @@ Answer messaging. 5.4. Sending the DTLS EKTKey Reliably 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. + EKT inherits the security properties of the the key management + protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP + extension defined in this document. 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- sharing: a single key is provided to protect an entire SRTP session. However, EKT remains secure even when SSRC values collide. SRTP master keys MUST be randomly generated, and [RFC4086] offers some guidance about random number generation. SRTP master keys MUST @@ -815,52 +837,62 @@ the packet. The FullEKTField would correctly decode and pass integrity checks. However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail. Note that the FullEKTField only changes the decryption key and does not change the encryption key. None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. An attacker could send packets containing a FullEKTField, in an attempt to consume additional CPU resources of the receiving system - by causing the receiving system will decrypt the EKT ciphertext and + by causing the receiving system to 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. + In a similar vein, EKT has no replay protection, so an attacker could + implant improper keys in receivers by capturing EKTCiphertext values + encrypted with a given EKTKey and replaying them in a different + context, e.g., from a different sender. When the underlying SRTP + transform provides integrity protection, this attack will just result + in packet loss. If it does not, then it will result in random data + being fed to RTP payload processing. An attacker that is in a + position to mount these attacks, however, could achieve the same + effects more easily without attacking EKT. + 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 FullEKTField values using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by - the TTL described in Figure 4. + the TTL described in Section 5.2. 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. An EKT cipher MUST resist attacks in which both ciphertexts and plaintexts can be adaptively chosen and adversaries that can query both the encryption and decryption functions adaptively. In some systems, when a member of a conference leaves the conferences, the conferences is rekeyed so that member no longer has the key. When changing to a new EKTKey, it is possible that the attacker could block the EKTKey message getting to a particular endpoint and that endpoint would keep sending media encrypted using - the old key. To mitigate that risk, the lifetime of the EKTKey - SHOULD be limited using the ekt_ttl. + the old key. To mitigate that risk, the lifetime of the EKTKey MUST + be limited using the ekt_ttl. 7. IANA Considerations 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: +--------------+-------+---------------+ @@ -915,122 +947,115 @@ 7.3. TLS Extensions IANA is requested to add supported_ekt_ciphers as a new extension name to the "TLS 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. ]] - Considerations for this type of extension are described in Section 5 - of [RFC4366] and requires "IETF Consensus". - 7.4. TLS Handshake Type 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, . + Requirement Levels", BCP 14, RFC 2119, + 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, . + 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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ - RFC5234, January 2008, . + Specifications: ABNF", STD 68, RFC 5234, + 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, . + (TLS) Protocol Version 1.2", RFC 5246, + 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, . + (AES) Key Wrap with Padding Algorithm", RFC 5649, + 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, . + Real-time Transport Protocol (SRTP)", RFC 5764, + 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, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 9.2. Informative References [I-D.ietf-perc-double] Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Double Encryption Procedures", draft-ietf-perc-double-09 (work in progress), May 2018. [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-06 - (work in progress), March 2018. + Conferencing", draft-ietf-perc-private-media-framework-07 + (work in progress), September 2018. [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-28 (work in progress), July 2018. [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, - . + DOI 10.17487/RFC4086, June 2005, + . Authors' Addresses Cullen Jennings Cisco Systems Email: fluffy@iii.ca John Mattsson Ericsson AB @@ -1034,19 +1059,18 @@ John Mattsson Ericsson AB Email: john.mattsson@ericsson.com David A. McGrew Cisco Systems Email: mcgrew@cisco.com - Dan Wing - Cisco Systems - Email: dwing@cisco.com + Email: dwing-ietf@fuggles.com + Flemming Andreason Cisco Systems Email: fandreas@cisco.com