Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: From Already fixed on master . I think the idea here is to forbid the use of 0x01 , treating it as a reserved value ( due to legacy , pre - standard implementations ) . I think you 're looking in the wrong place , actually . There are two levels of constraint here : len(EKTCiphertext ) < 256 - len(Epoch ) - len(SPI ) len(SRTPMasterKey ) < len(EKTCiphertext ) - len(SSRC ) - len(ROC ) - len(SRTPMasterKeyLength ) - Cipher . Overhead So we can make the following bounds ...  = 1251BYTE ; 255 - 2 - 2 SRTPMasterKey = 1 * 242BYTE ; 251 - 1 - 4 - 4 - Overhead=0 ... but the maximum SRTPMasterKey will never be maximized in practice because the crypto overhead will be non - zero . And we ca n't really nail it down here in the ABNF because different ciphers will have different overhead . In any case , I have the above constraints . I agree . In fact , the natural order of operations is to form the SRTP packet , then compute and append the EKT tag . I have made this change . Already fixed on master . I do n't think this is unclear , but I have adapted the text to say that the implementation MAY continue normal SRTP / SRTCP processing . I have a definition in { { EKT } } . Already fixed on master . The word " immediately " appears nowhere here . The sequencing seems clear :  of a new EKTKey should trigger an update to the SRTP Master Key , but you do n't start using that for 250ms . I have edited to clarify . I have removed the remaining mentions of SRTCP . Edited to : " it is RECOMMENDED that the FullEKTField be transmitted in three consecutive packets " This is covered by the " new receiver " and " rekey " cases . I have left this as - is . As noted above , the statement in § 4.5 is not inconsistent . And your notion of " fate sharing " is pretty strict here . The intent is that the keying packets are following the same general path ( in terms of media servers , etc . ) as the media . It 's not a perfect match . I have left this as - is . I do n't know the answer on the merits , but it 's an application decision anyway . I have a note that applications will need to decide what latency / bandwidth tradeoff they want to make . On master , this table has been shifted down by one , so this change is no longer needed .
Paragraph (version A):
EKT extends DTLS and SRTP to enable a common key encryption key
(called an EKTKey) to be distributed to all endpoints, so that each
endpoint can securely send its SRTP master key and current SRTP
rollover counter to the other participants in the session.  This data
furnishes the information needed by the receiver to instantiate an
SRTP/SRTCP receiver context.
Paragraph (version B):
EKT extends DTLS and SRTP to enable a common key encryption key
(called an EKTKey) to be distributed to all endpoints, so that each
endpoint can securely send its SRTP master key and current SRTP
rollover counter to the other participants in the session.  This data
furnishes the information needed by the receiver to instantiate an
SRTP receiver context.
Paragraph (version A):
The EKTField uses the format defined in tag-format-base for the
FullEKTField and ShortEKTField.
Paragraph (version A):
The following shows the syntax of the EKTField expressed in ABNF
RFC5234.  The EKTField is added to the end of an SRTP or SRTCP
packet.  The EKTPlaintext is the concatenation of
SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order.  The
EKTCiphertext is computed by encrypting the EKTPlaintext using the
EKTKey.  Future extensions to the EKTField MUST conform to the syntax
of ExtensionEKTField.
Paragraph (version B):
The EKTField uses the format defined in tag-format-base for the
FullEKTField and ShortEKTField.  The EKTField appended to an SRTP
packet can be referred to as an "EKT tag".
Paragraph (version B):
The following 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
ExtensionEKTField.
Paragraph (version A):
Rollover Counter (ROC): On the sender side, this is set to the
current value of the SRTP rollover counter in the SRTP/SRTCP context
associated with the SSRC in the SRTP or SRTCP packet.  The length of
this field is 32 bits.
Paragraph (version B):
Rollover Counter (ROC): On the sender side, this is set to the
current value of the SRTP rollover counter in the SRTP context
associated with the SSRC in the SRTP packet.  The length of this
field is 32 bits.
Paragraph (version A):
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
sources on an endpoint each with their own EKT parameter set).  All
of the received EKT parameter sets SHOULD be stored by all of the
participants in an SRTP session, for use in processing inbound SRTP
and SRTCP traffic.  If a participant deletes an EKT parameter set
(e.g., because of space limitations, then it will be unable to
process Full EKT Tags containing updated media keys, and thus unable
to receive media from a particpant that has changed its media key.
Paragraph (version B):
At any given time, each SRTP source has associated with it a single
EKT parameter set.  This parameter set is used to process all
outbound packets, and is called the outbound parameter set for that
SSRC.  There may be other EKT parameter sets that are used by other
SRTP sources in the same session, including other SRTP sources on the
same endpoint (e.g., one endpoint with voice and video might have two
EKT parameter sets, or there might be multiple video sources on an
endpoint each with their own EKT parameter set).  All of the received
EKT parameter sets SHOULD be stored by all of the participants in an
SRTP session, for use in processing inbound SRTP traffic.  If a
participant deletes an EKT parameter set (e.g., because of space
limitations, then it will be unable to process Full EKT Tags
containing updated media keys, and thus unable to receive media from
a particpant that has changed its media key.
Paragraph (version A):
When an SRTP packet is sent with a FullEKTField, the EKTField for
that packet is created as follows, or uses an equivalent set of
steps.  The creation of the EKTField MUST precede the normal SRTP
packet processing.
Paragraph (version B):
When an SRTP packet is sent with a FullEKTField, the EKTField for
that packet is created as follows, or uses an equivalent set of
steps.
Paragraph (version A):
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.
Paragraph (version B):
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 and eventually begin encrypting with it, as defined
in outbound-processing.  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.
Paragraph (version A):
This document defines an extension to DTLS-SRTP called SRTP EKTKey
Transport which enables secure transport of EKT keying material from
the DTLS-SRTP peer in the server role to the client.  This allows
those peers to process EKT keying material in SRTP (or SRTCP) and
retrieve the embedded SRTP keying material.  This combination of
protocols is valuable because it combines the advantages of DTLS,
which has strong authentication of the endpoint and flexibility,
along with allowing secure multiparty RTP with loose coordination and
efficient communication of per-source keys.
Paragraph (version B):
In general, sending EKT tags less frequently will consume less
bandwidth, but increase the time it takes for a join or rekey to take
effect.  Applications should schedule the sending of EKT tags in a
way that makes sense for their bandwidth and latency requirements.
Paragraph (version B):
This document defines an extension to DTLS-SRTP called SRTP EKTKey
Transport which enables secure transport of EKT keying material from
the DTLS-SRTP peer in the server role to the client.  This allows
those peers to process EKT keying material in SRTP 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.