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

"Martin Thomson" <mt@lowentropy.net> Tue, 09 April 2019 00:20 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 8A17A1200DE; Mon, 8 Apr 2019 17:20:18 -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=LRgLfoYI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SVCNK8wX
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 0UOJwg0HglQ9; Mon, 8 Apr 2019 17:20:16 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9251A1200C7; Mon, 8 Apr 2019 17:20:16 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6DF75A12; Mon, 8 Apr 2019 20:20:15 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 08 Apr 2019 20:20:15 -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=fm1; bh=Ol+dO9q//kNGLoN0XVk2t530huwj 7+MisswxyiCbTYE=; b=LRgLfoYIr2MO7RfG3sK32l/Pvs67A2xZz2vmUjb0CD7g 0ZcDB7ts9yd8wxIC0kEC3qMEmm4IBdPABG2TOYbQmoT7OgJzwPZ+EELligpcDFTP yDLXnbCKiAF8Ol3i7MrzlZW4tVi0LkjpIaP4uMwz2/POWqkk1pU/uNPlW4Mlf0KT iQu/ZU0r2lOsldLhhkUZyhrCE4Y+1tGpEtDKGh8WLirHL+U2iEEcnjgY4/Z94ftb JdlqsQRrlheH86h8RZPVZK46I9+DnnXW7iPHWmws2bCprvdBwlKdhZGIwUU7cX1p ZRiM4+Q6Y08P2Ta5JPtn93KQDGP5U1SCjCmZxr/Q6w==
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=Ol+dO9 q//kNGLoN0XVk2t530huwj7+MisswxyiCbTYE=; b=SVCNK8wX9n7MZhEd+/av+g dG2vBFVf12VYnHGTSPqiQGkrtYtCLDp+mP6QLWlVn9uHrP5XytH3EQ+1upmPFNdn A3wRR03IIolwkQdkUsI7kDvhOKgTC2SzZb2DA7rhHN8GMixFN/521qQkqwlCttfL AWvQXAIALTE5qdLKPnd92m9eI17igEjXCLLsb40QBJNiHh6NXTt5QJMwV7u97FDT PwFRQOejw5b66u502w48WUjPO8O0YVkoqfNeKl5Eo7zpMmF2ov17pAJl+671fvCa 8yYPKIfXKITb0VHNaiy3bOFe1h/zxUrGEySUK2TLuW5DGayctPQknUqsBbr1JCVA ==
X-ME-Sender: <xms:PuWrXGq40wwgPO_CdLTFXo5Hmkq8lA4vplWhTVcXzH_GLik8kMc7GA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:PuWrXI62sTwGEsqUxSRaMimOtSmO1QrehmYFmpE8fgo5azB7Q9TrWA> <xmx:PuWrXGM7QbLFmKYg2bpn1rGGWjpzg5uMvXR9zjsd8NJhqUMIvoFvzA> <xmx:PuWrXKNEZCkbJ-p8jbm418AAAhh-DjW86FvuPos6XaBV4xN0LRDJCA> <xmx:P-WrXDyFoawZ1vRdkLdj7-0JZp8ZJLvfdEjEtu07Q9dyuh3xSkg5EA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2C83B7C1B9; Mon, 8 Apr 2019 20:20:14 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <0de3648b-e750-41a7-819d-59d1bbf5ad70@www.fastmail.com>
In-Reply-To: <4a6a7d47-bd49-ed20-561e-ed4223f2d190@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>
Date: Mon, 08 Apr 2019 20:20:14 -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/NB75-WjJ4-JKLiMfRE-Ac9SBv8Y>
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, 09 Apr 2019 00:20:18 -0000

On Tue, Apr 9, 2019, at 06:48, Flemming Andreasen wrote:
>  Offers and SIP Requests are not the same. In RFC 3725 Flow 2 and 3, it 
> is the controller that generates the SIP Requests and the endpoints 
> that generate the SIP Responses and to quote RFC 8224, Section 3:
>
>  Note that the scope of this document is limited to providing an
>  identity assurance for SIP requests; solving this problem for SIP
>  responses is outside the scope of this work (see [RFC4916]). 

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.  In the RFC 8224 context, this remains true, but it is hard to see why (more on that below).

>  Thus, I still don't see how you get these endpoint Identity assertions 
> sent across with 3PCC. Maybe we need somebody else to chime in at this 
> point. 
> 
>  Jon/Cullen/Ekr: As authors of RFC 8224, can you help shed light on 
> this part of the thread ?

[...]

> Ok - I think you are saying a bit 
> more actually. Using the terminology of RFC 8224, I believe you are 
> assuming that the attacker controls the Authentication Service (which I 
> see as more than the signaling channel). If that is the case, then I 
> would suggest clarifying that in the text. 

I don't believe that is the case.  But I see now the angle you are concerned about.  Because RFC 8224 doesn't consider 3PCC, we might have a problem in the sense that 3PCC doesn't work at all with SIP Identity, but let's see if we can work out what it looks like.

Note that "signing" as imagined in RFC 8224 depends on there being SDP to sign.  If there is SDP and it is not bogus, then there is potentially a binding between the a=fingerprint attributes and some identity.  Whether that is in the SIP Identity header field (RFC 8224) or the SDP itself (WebRTC), the result is the same. 

For 3PCC with RFC 8224, either the controller is responsible for signing, the signing is performed by proxies near A and B (proxies that are not shown in the figure), or by A and B directly.  The point of the signature is to protect against attack between the point that the signature is added and where it is removed.  If the controller is both signing and consuming signatures, that would be pointless because they would be trusted by both A and B, so we'll ignore that case.   Therefore, we assume that signatures happen closer to A or B (or both) so that the signatures serve a purpose.

So we have:  A---AuthSvcA---...---AuthSvcB---B with a controller somewhere on the signaling path between the two ends.  Generally, RFC 8224 assumes that the path from A to its Authentication Service is "trusted", so the attack is on the path between the two Authentication Services.  The controller can be anywhere, because we're not assuming anything about that.

You might wonder whether the controller can generate bogus SDP that can be signed, but that is a constraint on deployment, not on security.  Bogus SDP generated by a controller that sits on the "untrusted" portion of the signaling path won't be signed and therefore might be rejected, but that just limits the choices the controller has.  If the controller is on a "trusted" segment, then it might generate SDP for the endpoint nearest to it and have a valid signature over that content.

The attack that we're contemplating acts on the "untrusted" segment of the signaling path.  It operates without collaboration with any of the "trusted" entities.  It relies on being able to intercept and modify signaling on that path segment.  That's all.  In all cases other than the nonsensical one where the controller acts as Authentication Service for both parties, the attack we're  considering doesn't depend on the Authentication Service being compromised.  

In the extreme case, say that  A and B sign their own SDP/signaling and assert their own identities.  If the controller is the attacker, they control when sessions are established and how.  They can copy-paste signatures between the different messages they receive.