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

Commentary: This PR includes editorial fixes from  ' first review
Paragraph (version A):
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 ( 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 told the SRTP keys along with the SSRC, roll
over counter (ROC) and other details of the other SRTP sources.
Paragraph (version B):
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 ( 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 told the SRTP keys along with the SSRC,
rollover counter (ROC) and other details of the other SRTP sources.
Paragraph (version A):
EKT defines a new method of providing SRTP master keys to an
endpoint.  In order to convey the ciphertext corresponding to the
SRTP master key, and other additional information, an additional EKT
field is added to SRTP packets.  When added to SRTP, the EKT field
appears at the end of the SRTP packet, after the authentication tag
(if that tag is present), or after the ciphertext of the encrypted
portion of the packet otherwise.
Paragraph (version B):
EKT defines a new method of providing SRTP master keys to an
endpoint.  In order to convey the ciphertext corresponding to the
SRTP master key, and other additional information, an additional EKT
field is added to SRTP packets.  The EKT field appears at the end of
the SRTP packet.  The EKT field appears after the optional
authentication tag if one is present, otherwise the EKT field appears
after the ciphertext portion of the packet.
Paragraph (version A):
The data that is output from the EKT encryption operation,
described in cipher.  This field is included in SRTP packets when
EKT is in use.
Paragraph (version A):
The length of the SRTPMasterKey.  This depends on the cipher suite
negotiated for SRTP using RFC3264 SDP Offer/Answer for the SRTP.
Paragraph (version B):
The data that is output from the EKT encryption operation,
described in cipher.  This field is included in SRTP packets when
EKT is in use.  The length of EKTCiphertext can be larger than the
length of the EKTPlaintext that was encrypted.
Paragraph (version B):
The length of the SRTPMasterKey in bytes.  This depends on the
cipher suite negotiated for SRTP using RFC3264 SDP Offer/Answer
for the SRTP.
Paragraph (version A):
See timing which describes when to send an EKT packet with a
FullEKTField.  If a FullEKTField is not being sent, then a
ShortEKTField needs to be sent so the receiver can correctly
determine how to process the packet.
Paragraph (version A):
When an SRTP packet is to be 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):
See timing which describes when to send an EKT 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.
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.  The creation of the EKTField MUST precede the normal SRTP
packet processing.
Paragraph (version A):
Then the FullEKTField is formed using the EKTCiphertext and the
SPI associated with the EKTKey used above.  Also appended are the
Length and EKTMEsgTypeFull elements.
Paragraph (version A):
Note: the value of the EKT Ciphertext 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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
The resulting EKTPlaintext is parsed as described in EKT, to
recover the SRTP Master Key, SSRC, and ROC fields.  The 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.
Paragraph (version B):
The resulting EKTPlaintext is parsed as described in EKT, 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.
Paragraph (version A):
If a DTLS client includes "srtp_ekt_key_transport" in its
ClientHello, then a DTLS server that supports this extensions will
includes "srtp_ekt_key_transport" in its ServerHello message.  If a
DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but
does not receive "srtp_ekt_key_transport" in the ServerHello, the
DTLS client MUST NOT send DTLS EKTMessage messages.
Paragraph (version B):
If a DTLS client includes "srtp_ekt_key_transport" in its
ClientHello, then a DTLS server that supports this extensions will
includes "srtp_ekt_key_transport" in its ServerHello message.  If a
DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but
does not receive "srtp_ekt_key_transport" in the ServerHello, the
DTLS client MUST NOT send DTLS EKTMessage messages.  Also, the
"srtp_ekt_key_transport" in the ServerHello MUST select one and only
one EKTCipherType from the list provided by the client in the
"srtp_ekt_key_transport" in the ClientHello.