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

Commentary: Here is fast round of review PR prior to IESG submission . 
 Have a look at my comments but other than that , LGTM
Paragraph (version A):
Encrypted Key Transport (EKT) is an extension to DTLS and Secure
Real-time Transport Protocol (SRTP) that provides for the secure
transport of SRTP master keys, rollover counters, and other
information within SRTP.  This facility enables SRTP for
decentralized conferences by distributing a common key to all of the
conference endpoints.
Paragraph (version B):
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.
Paragraph (version A):
This document defines Encrypted Key Transport (EKT) for SRTP and
reduces the amount of external signaling control that is needed in a
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 (see
Section 2.2) within a session without coordinating with other
entities via external signaling or other external means.
Paragraph (version A):
EKT provides a way for an SRTP session participant, either a sender
or receiver, to securely transport 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 A):
EKT can be used in conferences where the central media distributor or
conference bridge can not decrypt the media, such as the type defined
for I-D.ietf-perc-private-media-framework.  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 then send the same encrypted media to a large
number of participants.  This reduces the amount of CPU time needed
for encryption and can be used for some optimization to media sending
that use source specific multicast.
Paragraph (version B):
This document defines Encrypted Key Transport (EKT) for SRTP and
reduces the amount of external signaling control that is needed in a
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.
Paragraph (version B):
EKT provides a way for an SRTP session participant, to securely
transport 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 can be used in conferences where the central media distributor or
conference bridge cannot decrypt the media, such as the type defined
for I-D.ietf-perc-private-media-framework.  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 the amount of CPU time
needed for encryption and can be used for some optimization to media
sending that use source specific multicast.
Paragraph (version A):
This specification defines a way for the server in a DTLS-SRTP
negotiation to provide an ekt_key to the client during the DTLS
handshake.  This ekt_key can be used to encrypt the SRTP master key
used to encrypt the media the endpoint sends.  This specification
also defines a way to send the encrypted SRTP master key along with
the SRTP packet.  Endpoints that receive this and know the ekt_key
can use the ekt_key to decrypt the SRTP master key then use the SRTP
master key to decrypt the SRTP packet.
Paragraph (version A):
One way to use this is used is described in the architecture defined
by I-D.ietf-perc-private-media-framework.  Each participants in the
conference call forms a DTLS-SRTP connection to a common key
distributor that gives all the endpoints the same ekt_key.  Then each
endpoint picks there own SRTP master key for the media they send.
When sending media, the endpoint also includes the SRTP master key
encrypted with the ekt_key.  This allows all the endpoints to decrypt
the media.
Paragraph (version B):
This specification defines a way for the server in a DTLS-SRTP
negotiation, see dtls-srtp-kt, 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 srtp_ekt.  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.
Paragraph (version B):
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
encrypted with the EKTKey in the SRTP packet.  This allows all the
endpoints to decrypt the media.
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.  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 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
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.
Paragraph (version A):
The EKT Field uses the format defined below for the FullEKTField and
ShortEKTField.
Paragraph (version B):
The EKTField uses the format defined below for the FullEKTField and
ShortEKTField.
Paragraph (version A):
EKTPlaintext: The data that is input to the EKT encryption operation.
This data never appears on the wire, and is used only in computations
internal to EKT.  This is the concatenation of the SRTP Master Key,
the SSRC, and the ROC.
Paragraph (version B):
EKTPlaintext: The data that is input to the EKT encryption operation.
This data never appears on the wire, and is used only in computations
internal to EKT.  This is the concatenation of the SRTP Master Key
and its length, the SSRC, and the ROC.
Paragraph (version A):
SSRC: On the sender side, this field is the SSRC for this SRTP
source.  The length of this field is 32 bits.
Paragraph (version A):
Rollover Counter (ROC): On the sender side, this field is set to the
current value of the SRTP rollover counter in the SRTP context
associated with the SSRC in the SRTP or SRTCP packet.  The length of
this field is 32 bits.
Paragraph (version B):
SSRC: On the sender side, this is the SSRC for this SRTP source.  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/SRTCP context
associated with the SSRC in the SRTP or SRTCP packet.  The length of
this field is 32 bits.
Paragraph (version A):
EKTMsgLength: All EKT message other that ShortEKTField have a length
as second from the last element.  This is the length in octets of
either the FullEKTField/ExtensionEKTField including this length field
and the following message type.
Paragraph (version A):
Message Type: The last byte is used to indicate the type of the
EKTField.  This MUST be 2 in the FullEKTField format and 0 in
ShortEKTField format.  Values less than 64 are mandatory to
understand while other values are optional to understand.  A receiver
SHOULD discard the whole EKTField if it contains any message type
value that is less than 64 and that is not understood.  Message type
values that are 64 or greater but not implemented or understood can
simply be ignored.
Paragraph (version B):
EKTMsgLength: All EKT messages types other than the ShortEKTField
have a length as second from the last element.  This is the length in
octets of either the FullEKTField/ExtensionEKTField including this
length field and the following EKT Message Type.
Paragraph (version B):
Message Type: The last byte is used to indicate the type of the
EKTField.  This MUST be 2 for the FullEKTField format and 0 in
ShortEKTField format.  Values less than 64 are mandatory to
understand while other values are optional to understand.  A receiver
SHOULD discard the whole EKTField if it contains any message type
value that is less than 64 and that is not understood.  Message type
values that are 64 or greater but not implemented or understood can
simply be ignored.
Paragraph (version A):
Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets.  The decision on which to send is specified in
timing.
Paragraph (version B):
Either the FullEKTField or ShortEKTField is appended at the tail end
of all SRTP packets.  The decision on which to send when is specified
in timing.
Paragraph (version A):
When a packet is sent with the Short EKT Field, the ShortEKFField is
simply appended to the packet.
Paragraph (version A):
When receiving a packet on a RTP stream, the following steps are
applied for each received packet.
Paragraph (version B):
The computed value of the FullEKTField is written into the SRTP
packet.
Paragraph (version B):
When a packet is sent with the ShortEKTField, the ShortEKFField is
simply appended to the packet.
Paragraph (version B):
When receiving a packet on a RTP stream, the following steps are
applied for each SRTP received packet.
Paragraph (version A):
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 above steps.
Paragraph (version A):
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 keys
has been used to encrypt data to ensure it does not exceed the T
value for that cipher.  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 renegotiation
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.
Paragraph (version B):
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
{#pkt_proc}.
Paragraph (version B):
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 {#cipher}).  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.
Paragraph (version B):
The default EKT Cipher is the Advanced Encryption Standard (AES) Key
Wrap with Padding RFC5649 algorithm.  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.
Paragraph (version A):
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
transmitted media, because SRTP rekeying can occur without concern
for RTCP transmission limits, and to avoid SRTCP compound packets
with RTP translators and mixers.
Paragraph (version A):
A system using EKT learns the SRTP master keys distributed with
FullEKTFields sent with the SRTP, rather than with call signaling.  A
receiver can immediately decrypt an SRTP packet, provided the SRTP
packet contains a Full EKT Field.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
This document defines an extension to DTLS-SRTP called SRTP EKT Key
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):
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 A):
In the context of a multi-party SRTP session in which each endpoint
performs a DTLS handshake as a client with a central DTLS server, the
extensions defined in this session allow the DTLS server to set a
common EKT key among all participants.  Each endpoint can then use
EKT tags encrypted with that common key to inform other endpoint of
the keys it is using to protect SRTP packet.  This avoids the need
for many individual DTLS handshakes among the endpoints, at the cost
of preventing endpoints from directly authenticating one another.
Paragraph (version A):
To indicate its support for EKT, a DTLS-SRTP client includes in its
ClientHello an extension of type supported_ekt_ciphers listing the
EKT ciphers the client supports in preference order, with the most
preferred version first.  If the server agrees to use EKT, then it
includes a supported_ekt_ciphers extension in its ServerHello
containing a cipher selected from among those advertised by the
client.
Paragraph (version B):
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
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.
Paragraph (version B):
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 supports in preference order, with
the most preferred version first.  If the server agrees to use EKT,
then it includes a supported_ekt_ciphers extension in its ServerHello
containing a cipher selected from among those advertised by the
client.
Paragraph (version A):
If the server did not provide a supported_ekt_ciphers extension in
its ServerHello, then EKTKey messages MUST NOT be sent by either the
client or the server.
Paragraph (version B):
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.
Paragraph (version A):
An attacker who tampers with the bits in FullEKTField can prevent the
intended receiver of that packet from being able to decrypt it.  This
is a minor denial of service vulnerability.  Similarly the attacker
could take an old FullEKTField from the same session and attach it to
the packet.  The FullEKTField would correctly decode and pass
integrity but 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.
Paragraph (version A):
An attacker could send packets containing a Full EKT Field, in an
attempt to consume additional CPU resources of the receiving system
by causing the receiving system will decrypt the EKT ciphertext and
detect an authentication failure.  In some cases, caching the
previous values of the Ciphertext as described in inbound-impl-notes
helps mitigate this issue.
Paragraph (version B):
An attacker who tampers with the bits in FullEKTField can prevent the
intended receiver of that packet from being able to decrypt it.  This
is a minor denial of service vulnerability.  Similarly the attacker
could take an old FullEKTField from the same session and attach it to
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.
Paragraph (version B):
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
detect an authentication failure.  In some cases, caching the
previous values of the Ciphertext as described in inbound-impl-notes
helps mitigate this issue.
Paragraph (version A):
Each EKT cipher specifies a value T that is the maximum number of
times a given key can be used.  An endpoint MUST NOT encrypt more
than T different Full EKT Field using the same EKTKey.  In addition,
the EKTKey MUST NOT be used beyond the lifetime provided by the TTL
described in dtls-srtp-extensions.
Paragraph (version B):
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 dtls-srtp-extensions.
Paragraph (version A):
IANA is requested to add supported_ekt_ciphers as a new extension
name to the "ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this
specification and allocate a value of TBD to for this.
Paragraph (version B):
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.