Re: [secdir] secdir review of draft-ietf-avtext-rtp-stream-pause-08

[David Mandelberg <[e-mail]>]

On 2015-09-02 11:28, Magnus Westerlund wrote:
> Den 2015-08-11 kl. 06:45, skrev David Mandelberg:
>> Hi,
>>
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the 
>> IESG.
>> These comments were written primarily for the benefit of the 
>> security
>> area directors.  Document editors and WG chairs should treat these
>> comments just like any other last call comments.
>>
>> I think this draft is Ready with issues, though the two issues are
>> relatively minor:
>>
>> 1. The Security Considerations section talks about protecting 
>> against
>> injection of PAUSE requests:
>>
>>     The way of protecting the RTP session from these injections is 
>> to
>>     perform source authentication combined with message integrity, 
>> to
>>     prevent other than intended session participants from sending 
>> these
>>     messages.
>>
>> I think this paragraph should also mention replay protection, which 
>> is
>> needed if the 16-bit PauseID wraps around and the attacker has 
>> access to
>> old PAUSE requests.
>
> Yes, we should mention replay attacks. I note that due to that the
> current PauseID starts at 0 and increments by one, it takes some time
> until we wrap. And also then you might have to hold onto a lot of
> messages to be able to attempt a replay. But, clearly we should
> recommend replay protection at the outer security layer.
>
> I propose that we add the following sentence in the second paragraph
> prior to the last sentence:
>
> The security solution should provide replay protection, otherwise an
> attacker could for sessions that are long lived enough to wrap the
> PauseID replay old messages at the appropriate time to influence the
> media sender state.

Looks good to me.


>> 2. The next paragraph in Security Considerations talks about 
>> protecting
>> the multi-party use case against a single malicious participant by
>> individually authenticating participants. In addition to 
>> per-participant
>> authentication, I think there also needs to be a requirement for
>> attempted delivery of PAUSE requests to all participants. Without 
>> that
>> requirement, an attacker could cause the session to cycle through 
>> the
>> Playing, Pausing, and Paused states. To do that, the attacker would 
>> send
>> PAUSE requests only to the stream sender, instead of to the whole 
>> group.
>> Since no other participants receive the PAUSE request, they do not 
>> know
>> to send disapproving RESUMEs until after the stream sender has 
>> already
>> paused the stream. (I should note that I'm not particularly familiar
>> with multicast network operations. If it's infeasible for one
>> participant to send a message to another participant without the 
>> rest of
>> the group also receiving the message, then I apologize for bringing 
>> up a
>> non-issue.)
>
> Yes, you are correct that getting a malicious PAUSE message sent to
> multiple participants provides a mitigation in that the other
> participants can counter it. That I would expect to happen in
> multicast cases where anyone can send RTCP messages. It will fully
> depend on the multicast topology if an on-path attacker has any 
> chance
> of getting its messages delivered to the media stream endpoint and 
> not
> getting forwarded to other endpoints over the multicast tree.
>
> In the cases of the RTP middleboxes providing the multi-party
> functionality it will depend on the mode of operation of that
> middlebox. But, assuming the middlebox isn't compromised it will act
> on behalf of the whole session. It either works as multicast emulator
> and should forward it to everyone, or it will receive the request, 
> and
> only forward it if fits the rest of the session state.
>
> Proposed text for the end of Paragraph three:
>
>  An attacker that can send a PAUSE request without it reaching any
> other participant than the media sender can have its request being
> unopposed. This is mitigated in multi-party topologies that ensure
> that requests are seen by all or most of the RTP session 
> participants,
> enabling these participants to send RESUME. In topologies with
> middleboxes that consume and process PAUSE requests, the middlebox 
> can
> also mitigate such behavior as it will commonly not generate or
> forward a PAUSE message if it knows of another participant having use
> for the media stream.
>
> Comments on this?

This also looks good to me.

Thanks for addressing my concerns!

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/