Subject: Re: [AVT] Re: IESG comments on draft-ietf-avt-rtp-retransmission-11.txt: security concerns

From: Colin Perkins <[email-masked]>
Date: Mon, 2 May 2005 11:17:27 +0100

Russ,

Does this address your concerns?
Colin

On 27 Apr 2005, at 14:28, Jose Rey wrote:

> Hi Russ,
>
> Sorry for the delay.  Here is the proposed text, hopefully satisfying 
> your requests:
>
> --
> 12. Security considerations
>
> RTP packets using the payload format defined in this specification are 
> subject to the general security considerations discussed in RTP, 
> Section 9.
>
> In common streaming scenarios message authentication, data integrity, 
> replay protection and confidentiality are desired. The absence of 
> authentication may enable man-in-the-middle and replay attacks, which 
> can be very harmful for RTP retransmission. For example: tampered RTCP 
> packets may trigger inappropriate retransmissions that effectively 
> reduce the actual bitrate share allocated to the original data stream, 
> tampered RTP retransmission packets could cause the client's decoder 
> to crash, tampered retransmission requests may invalidate the SSRC 
> association mechanism described in Section 5 of this document. On the 
> other hand, replayed packets could lead to false re-ordering and RTT 
> measurements (required for the retransmission request strategy) and 
> may cause the receiver buffer to overflow. Further, in order to ensure 
> confidentiality of the data, the original payload data needs to be 
> encrypted. There is actually no need to encrypt the 2-byte 
> retransmission payload header since it does not provide any hints 
> about the data content.
>
> Furthermore, it is RECOMMENDED that the cryptography mechanisms used 
> for this payload format provide protection against known plaintext 
> attacks. RTP recommends that the initial RTP timestamp SHOULD be 
> random to secure the stream against known plaintext attacks. This 
> payload format does not follow this recommendation as the initial 
> timestamp will be the media timestamp of the first retransmitted 
> packet. However, since the initial timestamp of the original stream is 
> itself random, if the original stream is encrypted, the first 
> retransmitted packet timestamp would also be random to an attacker. 
> Therefore, confidentiality would not be compromised.
>
> If cryptography is used to provide security services on the original 
> stream, then the same services, with equivalent cryptographic 
> strength, MUST be provided on the retransmission stream.  The use of 
> the same key for the retransmitted stream and the original stream may 
> lead to security problems, e. g., two-time pads.  Refer to Section 9.1 
> of the Secure Real-Time Transport Protocol (SRTP)[12] for a discussion 
> the implications of two-time pads and how to avoid them.
>
> However, at the time of writing this document, the current SRTP 
> specification cannot afford all the security services mentioned. There 
> are, at least, two reasons for this: 1) the ocurrence of two-time pads 
> and 2) the fact that this payload format typically works under the 
> RTP/AVPF profile while SRTP only supports RTP/AVP.  An adapted variant 
> of SRTP shall solve these shortcomings in the future.
>
> Congestion control considerations with the use of retransmission are 
> dealt with in Section 7 of this document.
>
> --  
>
> Looking forward to your comments,
>
> José
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Russ Housley
>> Sent: Thursday, April 07, 2005 11:07 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: [AVT] Re: IESG comments on
>> draft-ietf-avt-rtp-retransmission-11.txt: security concerns
>>
>> Sorry for the delay in responding.  I have been out of the
>> office too much.
>>
>>> I'll start with the security comments.  Russ says:
>>>
>>>   The introduction says:
>>>
>>>   [snip] (no problems with these...)
>>>
>>>   The first paragraph of the security considerations says:
>>>>
>>>> If cryptography is used to provide security services on the
>>>> original stream, then the same services, with equivalent
>>>> cryptographic strength, MUST be provided on the retransmission
>>>> stream.  Old keys will likely need to be cached so that when the
>>>> keys change for the original stream, the old key is
>> used until it
>>>> is determined that the key has changed on the retransmission
>>>> packets as well.
>>>>
>>>> The use of the same key for the retransmitted stream and the
>>>> original stream may lead to security problems, e.g.
>> two-time pads.
>>>> This sharing has to be evaluated towards the chosen security
>>>> protocol and security algorithms.
>>>>
>>>   I like the first sentence of the first paragraph very
>> much.  However,
>>>   the second sentence implies that the same keying material might be
>>>   used to encrypt the retransmission, even though it is
>> being sent on a
>>>   separate stream.  The second paragraph points to the
>> possible security
>>>   flaw if this is done.  Since a SRTP-variant is the
>> security protocol
>>>   that would be used in this context and SRTP is almost
>> always used with
>>>   counter mode, the result could be a loss of
>> confidentiality.  If the
>>>   same keying material is used, then a mechanism is needed to ensure
>>>   that the counter value will be different.  SRTP seems to
>> be prepared
>>>   to support this situation, but not without some guidance.
>>  RFC 3711
>>>   says:
>>>>
>>>> In addition, there can be cases (see Sections 8 and 9.1) where
>>>> several SRTP streams within a given RTP session,
>> identified by their
>>>> synchronization source (SSRCs, which is part of the RTP header),
>>>> share most of the crypto context parameters (including possibly
>>>> master and session keys).  In such cases, just as in the normal
>>>> SRTP/SRTCP parameter sharing above, separate replay
>> lists and packet
>>>> counters for each stream (SSRC) MUST still be maintained.
>>>
>>>
>>> I am not sure what is the action that should result from
>> this comment.
>>> Let me explain myself: the two-time pads issue was discussed in the
>>> past with the SRTP authors.  The last sentence in the second
>> paragraph
>>> " This sharing..." is trying to say that if two-time pads
>> are not dealt
>>> with in the security protocol used, then there is a security
>> problem.
>>> As Russ (and the doc) says it is a variant of SRTP,  SAVPF,
>> that will
>>> be used to secure the original and rtx streams.
>>>
>>> Therefore it would be in this SRTP variant that shall define
>> what to do
>>> with potential two-time pads cases and not in the draft, hence what
>>> else could be said here?  Since SAVPF draft has expired, I
>> understand
>>> that the security issue is not solved. Is this what has to be
>>> documented or make these two last facts even more explicit?
>>
>> I think we need to start with a more basic discussion of
>> security services.  Which ones are desired? And, what are the
>> consequences if they are not provided.  At a minimum, data
>> integrity, authentication, replay protection, and
>> confidentiality should be discussed.
>>
>> Next, the section should point out that a SRTP variant is a
>> likely way to provide the needed services.  State that SRTP
>> as it stands is not acceptable because of the two-time pad
>> issue.  Give a reference to the two-time pad discussion in
>> the SRTP specification.
>>
>> This would be a good place to include the sentence that I
>> liked so much:
>>> If cryptography is used to provide security services on the
>>> original stream, then the same services, with equivalent
>>> cryptographic strength, MUST be provided on the retransmission
>>> stream.
>>
>> I would omit the discussion of "old keys."  Leave the
>> solution to the designers of the SRTP variant.
>>
>> I have no problem with the following two paragraphs from your
>> -11 document coming next; it seems like good context for the
>> SRTP variant designers:
>>> Furthermore, it is RECOMMENDED that the cryptography mechanisms
>>> used for this payload format provide protection against known
>>> plaintext attacks.  RTP recommends that the initial RTP timestamp
>>> SHOULD be random to secure the stream against known plaintext
>>> attacks.  This payload format does not follow this recommendation
>>> as the initial timestamp will be the media timestamp of the first
>>> retransmitted packet.  However, since the initial
>> timestamp of the
>>> original stream is itself random, if the original stream is
>>> encrypted, the first retransmitted packet timestamp would also be
>>> random to an attacker.  Therefore, confidentiality would not be
>>> compromised.
>>>
>>> Congestion control considerations with the use of retransmission
>>> are dealt with in Section 7 of this document.
>>
>> Does this raise any concerns?
>>
>> Russ
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/avt
>>
>>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Russ Housley <[email-masked]>
Date: Sun, 01 May 2005 09:02:04 -0400

Works for me, but I suggest an editorial change (for clarity).

OLD:

However, at the time of writing this document, the current SRTP 
specification cannot afford all the security services mentioned.

NEW:

At the time of writing this document, SRTP does not provide all the 
security services mentioned.

Russ

At 09:28 AM 4/27/2005, Jose Rey wrote:
>Hi Russ,
>
>Sorry for the delay.  Here is the proposed text, hopefully satisfying your 
>requests:
>
>--
>subject to the general security considerations discussed in RTP, Section 9.
>
>authentication may enable man-in-the-middle and replay attacks, which can 
>be very harmful for RTP retransmission. For example: tampered RTCP packets 
>may trigger inappropriate retransmissions that effectively reduce the 
>actual bitrate share allocated to the original data stream, tampered RTP 
>retransmission packets could cause the client's decoder to crash, tampered 
>retransmission requests may invalidate the SSRC association mechanism 
>described in Section 5 of this document. On the other hand, replayed 
>packets could lead to false re-ordering and RTT measurements (required for 
>the retransmission request strategy) and may cause the receiver buffer to 
>overflow. Further, in order to ensure confidentiality of the data, the 
>original payload data needs to be encrypted. There is actually no need to 
>encrypt the 2-byte retransmission payload header since it does not provide 
>any hints about the data content.
>
>Furthermore, it is RECOMMENDED that the cryptography mechanisms used for 
>this payload format provide protection against known plaintext attacks. 
>RTP recommends that the initial RTP timestamp SHOULD be random to secure 
>the stream against known plaintext attacks. This payload format does not 
>follow this recommendation as the initial timestamp will be the media 
>timestamp of the first retransmitted packet. However, since the initial 
>timestamp of the original stream is itself random, if the original stream 
>is encrypted, the first retransmitted packet timestamp would also be 
>random to an attacker. Therefore, confidentiality would not be compromised.
>
>stream, then the same services, with equivalent cryptographic strength, 
>MUST be provided on the retransmission stream.  The use of the same key 
>for the retransmitted stream and the original stream may lead to security 
>problems, e. g., two-time pads.  Refer to Section 9.1 of the Secure 
>Real-Time Transport Protocol (SRTP)[12] for a discussion the implications 
>of two-time pads and how to avoid them.
>
>are, at least, two reasons for this: 1) the ocurrence of two-time pads and 
>2) the fact that this payload format typically works under the RTP/AVPF 
>profile while SRTP only supports RTP/AVP.  An adapted variant of SRTP 
>shall solve these shortcomings in the future.
>
>Congestion control considerations with the use of retransmission are dealt 
>with in Section 7 of this document.
>
>--
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 2 May 2005 13:36:01 +0100

Sorry - didn't see your answer since the list was down.
Colin

On 2 May 2005, at 11:17, Colin Perkins wrote:
>> RTP packets using the payload format defined in this specification 
>> are subject to the general security considerations discussed in RTP, 
>> Section 9.
>>
>> can be very harmful for RTP retransmission. For example: tampered 
>> RTCP packets may trigger inappropriate retransmissions that 
>> effectively reduce the actual bitrate share allocated to the original 
>> data stream, tampered RTP retransmission packets could cause the 
>> client's decoder to crash, tampered retransmission requests may 
>> invalidate the SSRC association mechanism described in Section 5 of 
>> this document. On the other hand, replayed packets could lead to 
>> false re-ordering and RTT measurements (required for the 
>> retransmission request strategy) and may cause the receiver buffer to 
>> overflow. Further, in order to ensure confidentiality of the data, 
>> the original payload data needs to be encrypted. There is actually no 
>> need to encrypt the 2-byte retransmission payload header since it 
>> does not provide any hints about the data content.
>>
>> packet. However, since the initial timestamp of the original stream 
>> is itself random, if the original stream is encrypted, the first 
>> lead to security problems, e. g., two-time pads.  Refer to Section 
>> 9.1 of the Secure Real-Time Transport Protocol (SRTP)[12] for a 
>> discussion the implications of two-time pads and how to avoid them.
>>
>> There are, at least, two reasons for this: 1) the ocurrence of 
>> two-time pads and 2) the fact that this payload format typically 
>> works under the RTP/AVPF profile while SRTP only supports RTP/AVP.  
>> An adapted variant of SRTP shall solve these shortcomings in the 
>> future.
>>