doc: Add RFC documents

1 files changed, 1168 insertions, 0 deletions

diff --git a/doc/rfc/rfc8870.txt b/doc/rfc/rfc8870.txt
new file mode 100644
index 0000000..fcb0384
--- /dev/null
+++ b/doc/rfc/rfc8870.txt
@@ -0,0 +1,1168 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Jennings
+Request for Comments: 8870                                 Cisco Systems
+Category: Standards Track                                    J. Mattsson
+ISSN: 2070-1721                                              Ericsson AB
+                                                               D. McGrew
+                                                           Cisco Systems
+                                                                 D. Wing
+                                                                  Citrix
+                                                            F. Andreasen
+                                                           Cisco Systems
+                                                            January 2021
+
+
+            Encrypted Key Transport for DTLS and Secure RTP
+
+Abstract
+
+   Encrypted Key Transport (EKT) is an extension to DTLS (Datagram
+   Transport Layer Security) and the Secure Real-time Transport Protocol
+   (SRTP) that provides for the secure transport of SRTP master keys,
+   rollover counters, and other information within SRTP.  This facility
+   enables SRTP for decentralized conferences by distributing a common
+   key to all of the conference endpoints.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8870.
+
+Copyright Notice
+
+   Copyright (c) 2021 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
+   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.  Overview
+   3.  Conventions Used in This Document
+   4.  Encrypted Key Transport
+     4.1.  EKTField Formats
+     4.2.  SPIs and EKT Parameter Sets
+     4.3.  Packet Processing and State Machine
+       4.3.1.  Outbound Processing
+       4.3.2.  Inbound Processing
+     4.4.  Ciphers
+       4.4.1.  AES Key Wrap
+       4.4.2.  Defining New EKT Ciphers
+     4.5.  Synchronizing Operation
+     4.6.  Timing and Reliability Considerations
+   5.  Use of EKT with DTLS-SRTP
+     5.1.  DTLS-SRTP Recap
+     5.2.  SRTP EKT Key Transport Extensions to DTLS-SRTP
+       5.2.1.  Negotiating an EKTCipher
+       5.2.2.  Establishing an EKT Key
+     5.3.  Offer/Answer Considerations
+     5.4.  Sending the DTLS EKTKey Reliably
+   6.  Security Considerations
+   7.  IANA Considerations
+     7.1.  EKT Message Types
+     7.2.  EKT Ciphers
+     7.3.  TLS Extensions
+     7.4.  TLS Handshake Type
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The 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, if a participant joins a session that is already in
+   progress, that participant needs to be informed of the SRTP keys
+   along with the SSRC, rollover counter (ROC), and other details of the
+   other SRTP sources.
+
+   The inability of SRTP to work in the absence of central control was
+   well understood during the design of the protocol; the omission was
+   considered less important than optimizations such as bandwidth
+   conservation.  Additionally, in many situations, SRTP is used in
+   conjunction with a signaling system that can provide the central
+   control needed by SRTP.  However, there are several cases in which
+   conventional signaling systems cannot easily provide all of the
+   coordination required.
+
+   This document defines Encrypted Key Transport (EKT) for SRTP and
+   reduces the amount of external signaling control that is needed in an
+   SRTP session with multiple receivers.  EKT securely distributes the
+   SRTP master key and other information for each SRTP source.  With
+   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 ROC
+   to the other participants in the session.  This data furnishes the
+   information needed by the receiver to instantiate an 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
+   in [RFC8871].  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 encryption CPU time in general and is necessary when sending
+   multicast media.
+
+   EKT does not control the manner in which the SSRC is generated.  It
+   is only concerned with distributing the security parameters that an
+   endpoint needs to associate with a given SSRC in order to decrypt
+   SRTP packets from that sender.
+
+   EKT is not intended to replace external key establishment mechanisms.
+   Instead, it is used in conjunction with those methods, and it
+   relieves those methods of the burden of delivering the context for
+   each SRTP source to every SRTP participant.  This document defines
+   how EKT works with the DTLS-SRTP approach to key establishment, by
+   using keys derived from the DTLS-SRTP handshake to encipher the
+   EKTKey in addition to the SRTP media.
+
+2.  Overview
+
+   This specification defines a way for the server in a DTLS-SRTP
+   negotiation (see Section 5) to provide an EKTKey to the client during
+   the DTLS handshake.  The EKTKey thus obtained can be used to encrypt
+   the SRTP master key that is used to encrypt the media sent by the
+   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 packet 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 specification is described in the architecture
+   defined by [RFC8871].  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 its own
+   SRTP master key for the media it sends.  When sending media, the
+   endpoint may also include 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", "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 the "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 <From, To> [RFC3711], as those SRTP
+   features duplicate some of the functions of EKT.  Senders MUST NOT
+   include the MKI when using EKT.  Receivers SHOULD simply ignore any
+   MKI field received if EKT is in use.
+
+   This document defines the use of EKT with SRTP.  Its use with the
+   Secure Real-time Transport Control Protocol (SRTCP) would be similar,
+   but that topic is left for a future specification.  SRTP is preferred
+   for transmitting keying material because (1) it shares fate with the
+   transmitted media, (2) SRTP rekeying can occur without concern for
+   RTCP transmission limits, and (3) it avoids the need for SRTCP
+   compound packets with RTP translators and mixers.
+
+4.1.  EKTField Formats
+
+   The EKTField uses the formats defined in Figures 1 and 2 for the
+   FullEKTField 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             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |            Length             |0 0 0 0 0 0 1 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 1: FullEKTField Format
+
+                              0 1 2 3 4 5 6 7
+                             +-+-+-+-+-+-+-+-+
+                             |0 0 0 0 0 0 0 0|
+                             +-+-+-+-+-+-+-+-+
+
+                       Figure 2: ShortEKTField Format
+
+   Figure 3 shows the syntax of the EKTField, expressed in ABNF
+   [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 the
+   ExtensionEKTField.
+
+   BYTE = %x00-FF
+
+   EKTMsgTypeFull = %x02
+   EKTMsgTypeShort = %x00
+   EKTMsgTypeExtension = %x03-FF ; Message Type %x01 is not available
+                                 ; for assignment due to its usage by
+                                 ; legacy implementations.
+
+   EKTMsgLength = 2BYTE
+
+   SRTPMasterKeyLength = BYTE
+   SRTPMasterKey = 1*242BYTE
+   SSRC = 4BYTE ; SSRC from RTP
+   ROC = 4BYTE ; ROC from SRTP for the given SSRC
+
+   EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
+
+   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
+
+   EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
+
+                         Figure 3: EKTField Syntax
+
+   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
+      (see Section 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 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
+      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 FullEKTField MUST 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 used MUST 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.  This
+      MUST be 2 for the FullEKTField format and 0 for the ShortEKTField
+      format.  If a received EKT Tag has an unknown Message Type, then
+      the receiver MUST discard the whole EKT Tag.
+
+4.2.  SPIs and EKT Parameter Sets
+
+   The SPI identifies the parameters for how the EKT Tag should be
+   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 used MUST be
+   associated with a distinct SPI value.  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, 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
+   other 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 will be unable to
+   receive media from a participant that has changed its media key.
+
+   Either the FullEKTField or ShortEKTField is appended at the tail end
+   of all SRTP packets.  The decision regarding which parameter to send
+   and 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 per either the steps below or an equivalent
+   set of steps.
+
+   1.  The Security Parameter Index (SPI) field is set to the value of
+       the SPI 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 SRTP processing.
+
+   3.  The EKTCiphertext field is set to the ciphertext created by
+       encrypting the EKTPlaintext with the EKTCipher 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
+      |  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 appended to the end of the
+   SRTP packet, after the encrypted payload.
+
+   When a packet is sent with the ShortEKTField, the ShortEKTField 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 in a FullEKTField value.  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 specific
+   value of 250 ms 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 an RTP stream, the following steps are
+   applied for each received SRTP packet.
+
+   1.  The final byte is checked to determine which EKT format is in
+       use.  When an SRTP packet contains a ShortEKTField, the
+       ShortEKTField is removed from the packet and 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 SRTP
+       packet has been received, so instead of 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, the 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
+       step.  If the EKT decryption operation returns an authentication
+       failure, then EKT processing MUST be aborted.  The receiver
+       SHOULD discard the whole SRTP 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 (see Section 5.2.2) 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 this FullEKTField MUST be discarded
+       and the subsequent 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
+          SHOULD discard the whole SRTP 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 [RFC8723] 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 processing takes place.
+
+   The value of the EKTCiphertext field is identical in successive
+   packets protected by the same EKT parameter set, 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
+   precomputed 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
+   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
+   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 that it does not exceed the T value for that cipher (see
+   Section 4.4).  If either of these limits is exceeded, the key can no
+   longer be used for encryption.  At this point, implementations need
+   to either use call signaling to renegotiate a new session or
+   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.  The cipher used for a given EKTCiphertext
+   value is negotiated using the supported_ekt_ciphers extension (see
+   Section 5.2) and indicated with the SPI value in the FullEKTField.
+
+   An EKTCipher consists of an encryption function and a decryption
+   function.  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
+   N bytes, 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 bytes
+   long, or it returns an indication that the decryption operation
+   failed because the ciphertext was invalid (i.e., it was not generated
+   by the encryption of plaintext with the key K).
+
+   These functions have the property that D(K, E(K, P)) = P for all
+   values of K and P.  Each cipher also has a limit T on the number of
+   times that it can be used with any fixed key value.  The EKTKey MUST
+   NOT be used for encryption more than T times.  Note that if the same
+   FullEKTField is retransmitted three times, that only counts as one
+   encryption.
+
+   Security requirements for EKT Ciphers are discussed in Section 6.
+
+4.4.1.  AES Key Wrap
+
+   The default EKT Cipher is the Advanced Encryption Standard (AES) Key
+   Wrap with Padding algorithm [RFC5649].  It requires a plaintext
+   length M that is at least one octet, and it returns a ciphertext with
+   a length of N = M + (M mod 8) + 8 octets.  It can be used with key
+   sizes of L = 16 octets or 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, AESKW128
+   MUST be implemented for EKT.  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
+   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 key management, it MUST also
+   change its SRTP master key, which will cause it to send out a new
+   FullEKTField and eventually begin encrypting with it, as described 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 Considerations
+
+   A system using EKT learns the SRTP master keys distributed with the
+   FullEKTField sent with 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.  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 sender SHOULD send a packet containing the FullEKTField as
+      soon as possible, ideally in its initial SRTP packet.  To
+      accommodate packet loss, it is 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 an 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 containing 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).  Also, 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 100 ms.
+
+   If none of the above three cases apply, a ShortEKTField SHOULD be
+   sent.
+
+   In general, sending FullEKTField tags less frequently will consume
+   less bandwidth but will increase the time it takes for a join or
+   rekey to take effect.  Applications should schedule the sending of
+   FullEKTField 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 such a peer 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 multi-party 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 keying material
+   can allow EKT Keys to be tunneled through an untrusted relay such as
+   a centralized conference bridge.  For more details, see [RFC8871].
+
+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 as 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
+   "supported_ekt_ciphers" and a new TLS handshake message type called
+   "ekt_key".  The extension negotiates the cipher to be used in
+   encrypting and decrypting EKTCiphertext values, and the handshake
+   message carries the corresponding key.
+
+   Figure 4 shows a message flow between a 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.)  To be clear, EKT can be used with versions of 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 processing ACK
+   messages.
+
+        Client                                             Server
+
+        ClientHello
+         + 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
+
+                      Figure 4: DTLS 1.3 Message Flow
+
+   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 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 endpoints 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---------
+                                     <----DTLS Handshake---->
+                                     ---------EKTKey-------->
+
+             -------------SRTP Packet + EKT Tag------------->
+             <------------SRTP Packet + EKT Tag--------------
+
+5.2.1.  Negotiating an EKTCipher
+
+   To indicate its support for EKT, a DTLS-SRTP client includes in its
+   ClientHello an extension of type supported_ekt_ciphers listing the
+   ciphers used for EKT by the client, 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
+   EncryptedExtensions (or ServerHello for DTLS 1.2) 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 [RFC8446]:
+
+           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;
+
+5.2.2.  Establishing an EKT Key
+
+   Once a client and server have concluded a handshake that negotiated
+   an EKTCipher, the server MUST provide to the client a key to be used
+   when encrypting and decrypting EKTCiphertext values.  EKTKeys are
+   sent in encrypted handshake records, using handshake type
+   ekt_key(26).  The body of the handshake message contains an EKTKey
+   structure as follows:
+
+                    struct {
+                      opaque ekt_key_value<1..256>;
+                      opaque srtp_master_salt<1..256>;
+                      uint16 ekt_spi;
+                      uint24 ekt_ttl;
+                    } EKTKey;
+
+   The contents of the fields in this message are as follows:
+
+   ekt_key_value
+      The EKTKey that the recipient should use when generating
+      EKTCiphertext values
+
+   srtp_master_salt
+      The SRTP master salt to be used with any master key encrypted with
+      this EKT Key
+
+   ekt_spi
+      The SPI value to be used to reference this EKTKey and SRTP master
+      salt in EKT Tags (along with the EKT Cipher negotiated in the
+      handshake)
+
+   ekt_ttl
+      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 EncryptedExtensions (or ServerHello for DTLS 1.2), 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 message as described in Section 7 of
+   [TLS-DTLS13].  The EKTKey message and ACK MUST be retransmitted
+   following the rules of the negotiated version of DTLS.
+
+   EKT MAY be used with versions of DTLS prior to 1.3.  In such cases,
+   to provide reliability, the ACK message is still used.  Thus, DTLS
+   implementations supporting EKT with pre-1.3 versions of DTLS will
+   need to have explicit affordances for sending the ACK message in
+   response to an EKTKey message and for verifying that an ACK message
+   was received.  The retransmission rules for both sides are otherwise
+   defined by the negotiated version of DTLS.
+
+   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 SDP Offer/Answer
+   messaging [RFC3264].
+
+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 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 concerns over the
+   reuse 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
+   NOT be reused for any other purpose, and SRTP master keys MUST NOT be
+   derived from other SRTP master keys.
+
+   The EKT Cipher includes its own authentication/integrity check.
+
+   The presence of the SSRC in the EKTPlaintext ensures that an attacker
+   cannot substitute an EKTCiphertext from one SRTP stream into another
+   SRTP stream.  This mitigates the impact of cut-and-paste attacks that
+   arise due to the lack of a cryptographic binding between the EKT Tag
+   and the rest of the SRTP packet.  SRTP tags can only be cut-and-
+   pasted within the stream of packets sent by a given RTP endpoint; an
+   attacker cannot "cross the streams" and use an EKT Tag from one SSRC
+   to reset the key for another SSRC.  The Epoch field in the
+   FullEKTField also prevents an attacker from rolling back to a
+   previous key.
+
+   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 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.2 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.
+
+   The key encryption keys distributed with EKTKey messages are group
+   shared symmetric keys, which means they do not provide protection
+   within the group.  Group members can impersonate each other; for
+   example, any group member can generate an EKT Tag for any SSRC.  The
+   entity that distributes EKTKeys can decrypt any keys distributed
+   using EKT and thus any media protected with those keys.
+
+   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 Section 5.2.
+
+   The key length of the EKT Cipher MUST be at least as long as the SRTP
+   cipher and at least as long as the DTLS-SRTP ciphers.
+
+   Part of the EKTPlaintext is known or is 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 by an attacker querying both the
+   encryption and decryption functions.
+
+   In some systems, when a member of a conference leaves the conference,
+   that conference is rekeyed so that the member who left the conference
+   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 MUST be limited by using the ekt_ttl.
+
+7.  IANA Considerations
+
+7.1.  EKT Message Types
+
+   IANA has created a new table for "EKT Message Types" in the "Real-
+   Time Transport Protocol (RTP) Parameters" registry.  The initial
+   values in this registry are as follows:
+
+                 +==============+=======+===============+
+                 | Message Type | Value | Specification |
+                 +==============+=======+===============+
+                 | Short        |     0 | RFC 8870      |
+                 +--------------+-------+---------------+
+                 | Unassigned   |     1 |               |
+                 +--------------+-------+---------------+
+                 | Full         |     2 | RFC 8870      |
+                 +--------------+-------+---------------+
+                 | Unassigned   | 3-254 |               |
+                 +--------------+-------+---------------+
+                 | Reserved     |   255 | RFC 8870      |
+                 +--------------+-------+---------------+
+
+                        Table 2: EKT Message Types
+
+   New entries in this table can be added via "Specification Required"
+   as defined in [RFC8126].  To avoid conflicts with pre-standard
+   versions of EKT that have been deployed, IANA SHOULD give preference
+   to the allocation of even values over odd values until the even code
+   points are consumed.  Allocated values MUST be in the range of 0 to
+   254.
+
+   All new EKT messages MUST be defined to include a length parameter,
+   as specified in Section 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 initial values in
+   this registry are as follows:
+
+                  +============+=======+===============+
+                  | Name       | Value | Specification |
+                  +============+=======+===============+
+                  | AESKW128   |     0 | RFC 8870      |
+                  +------------+-------+---------------+
+                  | AESKW256   |     1 | RFC 8870      |
+                  +------------+-------+---------------+
+                  | Unassigned | 2-254 |               |
+                  +------------+-------+---------------+
+                  | Reserved   |   255 | RFC 8870      |
+                  +------------+-------+---------------+
+
+                        Table 3: EKT Cipher Types
+
+   New entries in this table can be added via "Specification Required"
+   as defined in [RFC8126].  The expert SHOULD ensure that the
+   specification defines the values for L and T as required in
+   Section 4.4 of this document.  Allocated values MUST be in the range
+   of 0 to 254.
+
+7.3.  TLS Extensions
+
+   IANA has added supported_ekt_ciphers as a new extension name to the
+   "TLS ExtensionType Values" table of the "Transport Layer Security
+   (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 "TLS HandshakeType"
+   table of the "Transport Layer Security (TLS) Parameters" registry:
+
+   Value:  26
+
+   Description:  ekt_key
+
+   DTLS-OK:  Y
+
+   Reference:  RFC 8870
+
+   Comment:
+
+8.  References
+
+8.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,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <https://www.rfc-editor.org/info/rfc3264>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc3711>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5649]  Housley, R. and M. Dworkin, "Advanced Encryption Standard
+              (AES) Key Wrap with Padding Algorithm", RFC 5649,
+              DOI 10.17487/RFC5649, September 2009,
+              <https://www.rfc-editor.org/info/rfc5649>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc5764>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+              January 2012, <https://www.rfc-editor.org/info/rfc6347>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+8.2.  Informative References
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC8723]  Jennings, C., Jones, P., Barnes, R., and A.B. Roach,
+              "Double Encryption Procedures for the Secure Real-Time
+              Transport Protocol (SRTP)", RFC 8723,
+              DOI 10.17487/RFC8723, April 2020,
+              <https://www.rfc-editor.org/info/rfc8723>.
+
+   [RFC8871]  Jones, P., Benham, D., and C. Groves, "A Solution
+              Framework for Private Media in Privacy-Enhanced RTP
+              Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871,
+              January 2021, <https://www.rfc-editor.org/info/rfc8871>.
+
+   [TLS-DTLS13]
+              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
+              Datagram Transport Layer Security (DTLS) Protocol Version
+              1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
+              dtls13-39, 2 November 2020,
+              <https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>.
+
+Acknowledgments
+
+   Thank you to Russ Housley, who provided a 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.
+
+Authors' Addresses
+
+   Cullen Jennings
+   Cisco Systems
+
+   Email: fluffy@iii.ca
+
+
+   John Mattsson
+   Ericsson AB
+
+   Email: john.mattsson@ericsson.com
+
+
+   David A. McGrew
+   Cisco Systems
+
+   Email: mcgrew@cisco.com
+
+
+   Dan Wing
+   Citrix Systems, Inc.
+
+   Email: dwing-ietf@fuggles.com
+
+
+   Flemming Andreasen
+   Cisco Systems
+
+   Email: fandreas@cisco.com