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

David Mandelberg <david@mandelberg.org> Tue, 08 September 2015 22:01 UTC

Return-Path: <david@mandelberg.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B791B3313 for <secdir@ietfa.amsl.com>; Tue, 8 Sep 2015 15:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-IHhI6QxUXz for <secdir@ietfa.amsl.com>; Tue, 8 Sep 2015 15:01:06 -0700 (PDT)
Received: from nm9-vm2.access.bullet.mail.gq1.yahoo.com (nm9-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.37]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4971B3327 for <secdir@ietf.org>; Tue, 8 Sep 2015 15:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441749664; bh=GV96YdB47kC3I2jgW3BRIL27nNTRbFv1HBBGxD9A56g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=GaXuGzoujC7pc/pEa3e4OClHtPCm2nFA9HvWCaaMnngD9VgeukhOn5vA6x9InTojBEI1UCnlo5YiPpKct9691P7whYnjmOCXGM+hVwreD+dT9F8Tj/YYBYML3OCq1qk4XOPQQux/KVj/0BiPYUJy5D54N+77Cx2HIrAolta/rSmqhrG512XdlkSxRSYGc7g0WUCEAKa50ltLAKwgvm/eAJxzJCwpEc69vSnvewwoiXa5SefmN5IkMI69H/5KzWhxncQQ2MRIeMcnrhAdAo+pUS5EMy3EBAD97haUJjqYIrdLtkIHYWsSouyYLNKOAbiVjawP/s1A9jLDYNsg4Brlig==
Received: from [216.39.60.175] by nm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000
Received: from [98.138.226.244] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000
Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000
X-Yahoo-Newman-Id: 358563.59748.bm@smtp115.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: KRlcfQ0VM1mADaPypu2T5xkOqmaNdFnh7FohrAz7SMgdTld saYkQE..rdd.25aMOYfS6L8bl0wuNz677tc81mSHA6pnEtpBqtgC.aH2OQSt fiWGhVXaS3elOG8abWNoWUqNzOg3jAfsa39As6ZS9Ioa6IolPcv4HGKL5bPO jASi8dk9rOzz_yiZKaVk9Pd.4NsP3Iy408VUBoMK3HL_3180a8G7jlUdCDxI ZqVO5zC.lbcsIFg3KQhKOkylfJoyfrC_xdy5Ila8TF6m2GNyeFo_vFEGK2og 8_JxrBHUbd3OWXJj3yi7LVwsu.24Drh7Vqgg671AbttEvoB9U5K8dJI4terM O5wSOYob9Zq0opLlDkorkWHOqByutQFY4iWPhEn_gTtAAIqvd830yVJ9fym0 Kk8crgliMDnhC.NoltNuAaiADfIoUXJU1LkcJ58GeqfqTHZ3Lr5QDZ7Jsz.O jmeJMFQCW0n.P.z0YfJGnAC2JG6dwAimZt4giHg.rA1gLri0ISX_b9LdoZ5k 6Soy1IhwCRUyOufJLB88ik9w2kCzub.G5nZ2.kA--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id E19FB1C6095; Tue, 8 Sep 2015 18:01:01 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 08 Sep 2015 18:01:01 -0400
From: David Mandelberg <david@mandelberg.org>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
In-Reply-To: <55E7158D.5060304@ericsson.com>
References: <063cc84fb1eb8fbef30eda11ea7d8199@mail.mandelberg.org> <55E7158D.5060304@ericsson.com>
Message-ID: <5500272170d19009fe7d7e58ffaebd50@mail.mandelberg.org>
X-Sender: david@mandelberg.org
User-Agent: Roundcube Webmail/0.7.2
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/9JodrONYPYJA5OpQkyYDaucG9H4>
Cc: draft-ietf-avtext-rtp-stream-pause.all@tools.ietf.org, avtext@ietf.org, IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-avtext-rtp-stream-pause-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2015 22:01:08 -0000

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/