Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03

"Martin Thomson" <mt@lowentropy.net> Tue, 23 April 2019 04:29 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8531120021; Mon, 22 Apr 2019 21:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=oRK8H0kC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BWM4B//G
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 W4QMiwBLYHzc; Mon, 22 Apr 2019 21:29:01 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E154D1200D7; Mon, 22 Apr 2019 21:29:00 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0546622162; Tue, 23 Apr 2019 00:29:00 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 23 Apr 2019 00:29:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=NwDnUqLdOt9a6Ddn7pYPdfPscaMF ryd0dI20eEV3Ii4=; b=oRK8H0kCcgcWz5JFVL8pX90pB6O8NVu5vFBLMYUXr9tk FvudXTsjIFAJmCMC5Uv9ZxoJkYll/9c4ocgBfWgFsOTjx0k90T724jf4W0g7/9X6 nlo3y45i6kAzWb4iBlePnaPZMbn9FFg1tk6ZM/H2SVPJ3L4hnJEunmr8LgNZfII4 lqrXkTcSFj20GETZZdZzHWmT5wQfj+UGGvVEIfdaFJrXrwX3hfxAFX2nmJaXIm3F /wO6qihTAA38T7aeNBh8m+Val2EaKItMM2bKia5iCaygkV0LktYitKoAMMmidJ6W LGj5Mxb0no14x1eFkc1C9YWvuE00inWU8JcaMewfcQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=NwDnUq LdOt9a6Ddn7pYPdfPscaMFryd0dI20eEV3Ii4=; b=BWM4B//G0wqhvT1uRZrCk1 UMMZdgeB9GOxYy6FQhvesun97M8emoNYA8BLFebAFnOSXP3VpmfrFWW+xLr81boY UqSSIJRFzDN4priphWStJ3TBl97q3eyzkvS4NPEoqyM0kNPoCJXfaY+l855PQj9e 8zt5wsDARCrm1dPu3YEA6k2XOxENKAhoiW4JwpyCcIqd/yDckbp+3AGv1tqlL4rf /1VteS+b28UZDs70n3dQ+se/MO9jOOKpUc0cFjZ+3yHAw0lNOgqTd0ewPJYoai2Z MAWLXDSAPM0rEO4v8dLWWkvAsIJE7jZYKzEr78xHrj95fwPOSAxhQjf9LiDTuInA ==
X-ME-Sender: <xms:i5S-XD-UBLMZ04Th4OnidDLlucdZOC02kG-f_5XqWaySONO5U_49pg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:i5S-XBXAALj_zBktACoqEvd9s7J1RajJ0p8d5ULHwFPN1LOJ6OJUUA> <xmx:i5S-XFGMArVT2MLYt7QiUowT0hAvdP8Pb6IAsv9h3btOXonong3HGg> <xmx:i5S-XF4r5LpHahUJhmvw9M6ZhueCTgTVoDFHc28vxMKXe8Akkf6yvw> <xmx:i5S-XDNjN0hT-C5oyzZKX4mlX6opho2AuCtabTtbogwhIfzX5s2nXw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 22D167C199; Tue, 23 Apr 2019 00:28:59 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-444-g755619f-fmstable-20190423v1
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <0cdf21b5-40ce-473c-86be-4d024ecb18a8@www.fastmail.com>
In-Reply-To: <d94aa49b-048f-59f4-3351-80d4d0af7eb2@cisco.com>
References: <ec74675d-c576-f728-0481-c9488fb13beb@cisco.com> <ea61540a-20c7-0c3d-1f7d-4d702d9a5332@cisco.com> <e17042ae-af33-4b86-8a99-086290a1e8c0@www.fastmail.com> <f28a5698-d7bd-b39a-b307-fc8ced708ad3@cisco.com> <69e1ed84-7bae-4258-897b-a6d36716c261@www.fastmail.com> <718ce899-166c-b793-c7d4-84bb5fcceea5@cisco.com> <HE1PR07MB32592AA35C2183A0F1EB34BC8D550@HE1PR07MB3259.eurprd07.prod.outlook.com> <ea80d50b-9463-4bb4-ac89-862987a94585@www.fastmail.com> <4a6a7d47-bd49-ed20-561e-ed4223f2d190@cisco.com> <0de3648b-e750-41a7-819d-59d1bbf5ad70@www.fastmail.com> <d94aa49b-048f-59f4-3351-80d4d0af7eb2@cisco.com>
Date: Tue, 23 Apr 2019 00:29:01 -0400
From: Martin Thomson <mt@lowentropy.net>
To: Flemming Andreasen <fandreas@cisco.com>, Bo Burman <bo.burman@ericsson.com>, mmusic <mmusic@ietf.org>, Jon Peterson <jon.peterson@neustar.biz>, Cullen Jennings <fluffy@cisco.com>, 'Eric Rescorla' <ekr@rtfm.com>
Cc: "draft-ietf-mmusic-sdp-uks@ietf.org" <draft-ietf-mmusic-sdp-uks@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/kNwbgFCrKcfm6FMJa57vHaF_BPU>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Apr 2019 04:29:03 -0000

On Mon, Apr 22, 2019, at 08:07, Flemming Andreasen wrote:
> > Right.  What is relevant here is the offers and answers, not the SIP requests.  RFC 3725 shows only inconsequential offers being generated by the controller. 
> This is where we differ. In the SIP case, the attack you describe is predicated on a mismatch between the Identity information provided in the SIP request and the (assumed) identity of the SDP in an offer, thus the SIP requests are indeed very relevant to the discussion. 

I see your point below.  I missed the bit in RFC 8224 where it has to be a request. I was concentrating on the properties of the assertions, not the protocol integration.  I agree that it's important.

If 3PCC as described in RFC 3725 never produces a scenario where a request is bound to valid SDP, then 8224 + 3725 won't ever intersect.  Looking again with that constraint in mind (that it has to be a request), I see no scenario where 8224 and 3725 could be used together unless the controller is also the authorization service.  That arrangement would rule the controller out as an attacker we care about, because it has to be trusted by definition.   (More below.)

This doesn't invalidate the other aspects of the attack, just that this attack isn't valid when both 8224 and 3725 are used.  SIP identity can be used on calls without 3PCC and the text here applies to those uses.  Or 3PCC can be used without SIP identity (maybe the WebRTC identity is used) and the attack would be relevant.

It might be good to categorically say that 3PCC - as described in RFC 3725 - is incompatible with RFC 8224.  Would that help clarify this bit?


On the specific flows:

Flow I might work if the controller was the Authorization Service for A.  Or the controller was between A and its Authorization Service.
Flow II only works if the controller is the Authorization Service for both A and B.
Flows III and IV might work if the controller was the Authorization Service for B.  Or the controller was between B and its Authorization Service.

I base this on the fact that any non-trivial offers only appear in 200 responses.  So the first place that the message appears in a request is at the controller.  This puts the controller on a "trusted" segment of the signaling path.