Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-ekt-03.txt

[John Mattsson <[e-mail]>]

Here is a concrete proposal for a -04 version of Section 8 - Security
Considerations. Motivations are provided further down.

Cheers
John



New suggested text:

8.  Security Considerations

   EKT inherits the security properties of the SRTP keying mechanism it
   uses: SDP Security Descriptions, DTLS-SRTP, or MIKEY.

   With EKT, RTP senders and receivers MUST generate distinct SRTP
   master keys for each SRTP source (SSRC).  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, SRTP with EKT remains
   secure even in the absence of out-of-band coordination of SSRCs, and
   even when SSRC values collide.

   The EKT Cipher includes its own authentication/integrity check.  For
   an attacker to successfully forge a SRTP packet with a Full EKT
   Field, the attacker would need to defeat the authentication

   mechanisms of both the EKT Cipher and the SRTP authentication
   mechanism.

   The presence of the SSRC in the EKT Plaintext ensures that an
   attacker cannot substitute an EKT Ciphertext from one SRTP stream
   into another SRTP stream with a different SSRC.

   An attacker who strips a Full EKT Field from an SRTP packet may
   prevent the intended receiver of that packet from being able to
   decrypt it.  This is a minor denial of service vulnerability.
   Similarly, an attacker who modifies a SRTP packet in any way can
   disrupt service.

   An attacker could send packets containing either Short EKT Field or a
   falsified Full EKT Field, in an attempt to consume additional CPU
   resources of the receiving system.  In the case of the Short EKT
   Field, this field is stripped and normal SRTP or SRTCP processing is
   performed.  In the case of the Full EKT Field: If an invalid SPI is
   provided by the attacker, processing stops.  If a valid SPI is
   provided by the attacker, the receiving system will decrypt the EKT
   Ciphertext and with a probability of at least 2^-8 return an
   authentication failure (Step 3 of Section 2.2.2).  In the case the
   EKT Cipher does not return an authentication failure, the SSRC, ROC,
   and ISN checks of Section 2.2.2 will fail with a high probability
   causing EKT processing to stop.

   EKT can rekey an SRTP stream until the SRTP rollover counter (ROC) or
   SRTCP index needs to roll over.  Thus, new EKT Keys need to be
   established after 2^48 SRTP packets or 2^31 SRTCP packets are
   transmitted in a single SRTP stream.  Due to the relatively low
   packet rates of typical RTP sessions, this is not expected to be a
   burden.

   The EKT Key length MUST be at least as long as the SRTP master key
   length.

   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.







Old text:

8.  Security Considerations

   EKT inherits the security properties of the SRTP keying it uses:
   Security Descriptions, DTLS-SRTP, or MIKEY.

   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 in the absence of out-of-band
   coordination of SSRCs, and even when SSRC values collide.

   The EKT Cipher includes its own authentication/integrity check.  For
   an attacker to successfully forge a full EKT packet, it would need to
   defeat the authentication mechanisms of both the EKT Cipher and the
   SRTP authentication mechanism.

   The presence of the SSRC in the EKT_Plaintext ensures that an
   attacker cannot substitute an EKT_Ciphertext from one SRTP stream
   into another SRTP stream.

   An attacker who strips a Full_EKT_Field from an SRTP packet may
   prevent the intended receiver of that packet from being able to
   decrypt it.  This is a minor denial of service vulnerability.
   Similarly, an attacker who adds a Full_EKT_Field can disrupt service.

   An attacker could send packets containing either Short EKT Field or
   Full EKT Field, in an attempt to consume additional CPU resources of
   the receiving system.  In the case of the Short EKT Field, this field
   is stripped and normal SRTP or SRTCP processing is performed.  In the
   case of the Full EKT Field, the attacker would have to have guessed
   or otherwise determined the SPI being used by the receiving system.
   If an invalid SPI is provided by the attacker, processing stops.  If
   a valid SPI is provided by the attacker, the receiving system will
   decrypt the EKT ciphertext and return an authentication failure (Step
   3 of Section 2.2.2).

   EKT can rekey an SRTP stream until the SRTP rollover counter (ROC)
   needs to roll over.  EKT does not extend SRTP's rollover counter
   (ROC), and like SRTP itself EKT cannot properly handle a ROC
   rollover.  Thus even if using EKT, new (master or session) keys need
   to be established after 2^48 packets are transmitted in a single SRTP
   stream as described in Section 3.3.1 of [RFC3711].  Due to the
   relatively low packet rates of typical RTP sessions, this is not
   expected to be a burden.

   The confidentiality, integrity, and authentication of the EKT cipher
   MUST be at least as strong as the SRTP cipher.

   Part of the EKT_Plaintext 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.  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.





Motivation:

- “each SRTP sender and receiver MUST generate distinct SRTP
master keys”

->

"RTP senders and receivers MUST generate distinct SRTP
master keys for each SRTP source (SSRC)."


A SRTP receiver should not generate a SRTP key, a RTP receiver
that sends SRTCP should. An RTP Receiver may be an SRTP sender.

- “Full EKT packet”
This term is not defined. Suggest change to “SRTP packet with Full EKT
Field”

- "cannot substitute an EKT_Ciphertext from one SRTP stream
   Into another SRTP stream”


Suggest adding “with a different SSRC”.

- Similarly, an attacker who adds a Full_EKT_Field can disrupt service.

Suggest adding “Similarly, an attacker who modifies a SRTP packet in any
way can
disrupt service.” to illustrate that this is the way all security
protocols behave
And not specific to EKT.

- I suggest removing “the attacker would have to have guessed
or otherwise determined the SPI being used by the receiving system.”

As SPI is sent in cleartext, it is obviously known to a non-stupid
attacker.

- “If a valid SPI is provided by the attacker, the receiving system will
decrypt the EKT ciphertext and return an authentication failure (Step
3 of Section 2.2.2).”

This will not happened all the time as the EKT Cipher uses a very short
Authentication tag. But I donut think this is not a problem as later steps
will fail.
Suggest replacing with:

“and with a probability of at least 2^-8 return an
authentication failure (Step 3 of Section 2.2.2). In the case the
EKT Cipher does not return an authentication failure, the SSRC, ROC,
and ISN checks of Section 2.2.2 will fail with a high probability
causing EKT processing to stop.”

- "new (master or session) keys need to be established after 2^48 packets”

This should not be SRTP keys, the key that need to be established is
a new EKT Key and this is needed also after 2^31 SRTCP packets.

Suggested new text:

"EKT can rekey an SRTP stream until the SRTP rollover counter (ROC) or
SRTCP index needs to roll over. Thus, new EKT Keys need to be
established after 2^48 SRTP packets or 2^31 SRTCP packets are
transmitted in a single SRTP stream. Due to the relatively low
packet rates of typical RTP sessions, this is not expected to be a
burden.”

- “The confidentiality, integrity, and authentication of the EKT cipher
MUST be at least as strong as the SRTP cipher.”

This is clearly not possible as the EKT cipher uses a 8-bit authentication
tag, and what is meant by the “SRTP cipher”


I suggest simplifying the requirement. Suggested new text:

“The EKT Key length MUST be at least as long as the SRTP master key
length."

- “Part of the EKT_Plaintext 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. 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.”

This part contains a lot of redundant text. The EKT Cipher
should resist known plaintext attacks even if the plaintext is not
easily guessable. The second paragraph contains more strict requirements.

Suggestion:

“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."










>On 22/10/14 21:14, "[e-mail]" <[e-mail]>
>wrote:
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Audio/Video Transport Core Maintenance
>>Working Group of the IETF.
>>
>>        Title           : Encrypted Key Transport for Secure RTP
>>        Authors         : John Mattsson
>>                          David A. McGrew
>>                          Dan Wing
>>	Filename        : draft-ietf-avtcore-srtp-ekt-03.txt
>>	Pages           : 45
>>	Date            : 2014-10-20
>>
>>Abstract:
>>   Encrypted Key Transport (EKT) is an extension to Secure Real-time
>>   Transport Protocol (SRTP) that provides for the secure transport of
>>   SRTP master keys, Rollover Counters, and other information.  This
>>   facility enables SRTP to work for decentralized conferences with
>>   minimal control.
>>
>>   This note defines EKT, and also describes how to use it with SDP
>>   Security Descriptions, DTLS-SRTP, and MIKEY.  With EKT, these other
>>   key management protocols provide an EKT key to everyone in a session,
>>   and EKT coordinates the SRTP keys within the session.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-ekt/
>>
>>There's also a htmlized version available at:
>>http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-03
>>
>>A diff from the previous version is available at:
>>http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-ekt-03
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>Audio/Video Transport Core Maintenance
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/avt
>