IETF Logo Mail Archive

Re: [MMUSIC] Getting draft-ietf-mmusic-sdp-uks-04 ready for PubReq

Bo Burman <bo.burman@ericsson.com> Tue, 04 June 2019 12:07 UTC

Return-Path: <bo.burman@ericsson.com>
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 A6E09120033; Tue, 4 Jun 2019 05:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 M5b56WDTbCQz; Tue, 4 Jun 2019 05:07:47 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20063.outbound.protection.outlook.com [40.107.2.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5C612004A; Tue, 4 Jun 2019 05:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xuTspy2fv8mhSXcRim3QrVIWzGgdq/0Bw8TdhBLaOA4=; b=pTrM3T+u5nbAnd9gEc7H09fPLb0tvGDbfEFzAhwtIGKnO1HxPxH5zCx3R3aN0BUNfawQ3s4hxmMS2n0fttMNoPWylcR+h4Tg5+ZWT19hWLr4sALx6dBX3GozJsdxugZ/CUYQvhRJ2MY2JjmzQzZFaO0CIA5Gq5tcZwr9k+5TBd4=
Received: from HE1PR07MB3259.eurprd07.prod.outlook.com (10.170.246.26) by HE1PR07MB4411.eurprd07.prod.outlook.com (20.176.167.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.9; Tue, 4 Jun 2019 12:07:43 +0000
Received: from HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::1c47:b690:803a:f2f5]) by HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::1c47:b690:803a:f2f5%4]) with mapi id 15.20.1965.011; Tue, 4 Jun 2019 12:07:43 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Martin Thomson <mt@lowentropy.net>, "draft-ietf-mmusic-sdp-uks.authors@ietf.org, " <draft-ietf-mmusic-sdp-uks.authors@ietf.org>
CC: mmusic <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Getting draft-ietf-mmusic-sdp-uks-04 ready for PubReq
Thread-Index: AdUMw3zvW0vhfA0KRLycVMoG67t8YgFybcaAAG5xd4AAiksSgAEW7rrA
Date: Tue, 04 Jun 2019 12:07:43 +0000
Message-ID: <HE1PR07MB32599C3B63042968BBCBCDD98D150@HE1PR07MB3259.eurprd07.prod.outlook.com>
References: <HE1PR07MB3259C69803BEB1913483C7328D0B0@HE1PR07MB3259.eurprd07.prod.outlook.com> <CAD5OKxvfBSs7Yu5xyD7LXgfEW_5-2c_u39935mF8XOTxvLxixg@mail.gmail.com> <1cebc5fa-81ac-455c-9619-48d273177e5b@www.fastmail.com> <CAD5OKxtt8Attax=9-LnndF8RD2D0eFzZVSh-PqCC=9485eTJPw@mail.gmail.com>
In-Reply-To: <CAD5OKxtt8Attax=9-LnndF8RD2D0eFzZVSh-PqCC=9485eTJPw@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com;
x-originating-ip: [192.176.1.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: acc93758-90b5-4ecc-6e10-08d6e8e53fb5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4411;
x-ms-traffictypediagnostic: HE1PR07MB4411:
x-microsoft-antispam-prvs: <HE1PR07MB441198546DE621025E9D861C8D150@HE1PR07MB4411.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0058ABBBC7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(376002)(366004)(346002)(189003)(51444003)(199004)(53546011)(52536014)(81156014)(74316002)(81166006)(8936002)(4326008)(316002)(9686003)(5660300002)(53936002)(14454004)(76176011)(76116006)(86362001)(73956011)(8676002)(66946007)(7736002)(33656002)(508600001)(71200400001)(66556008)(66476007)(71190400001)(66616009)(64756008)(66446008)(25786009)(26005)(14444005)(68736007)(2906002)(606006)(229853002)(186003)(6436002)(6506007)(99286004)(7696005)(476003)(54896002)(6306002)(446003)(110136005)(102836004)(3846002)(6116002)(55016002)(66066001)(6246003)(486006)(256004)(11346002)(790700001)(44832011)(99936001)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4411; H:HE1PR07MB3259.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: CmIgGSixI5DF64MnVqBfEGSOXdYeoeMyDWTMbatvHNHNtQP4SQOn/ucuCRnbPfblMNumWIZuL3c7xX3ij1foUCySY6I06Yivs/hLVdqPmcP/U+k4BRL7Ax7E4HoM2jzks3/YaJCg3nuCx7TMgsxsGNMrTp2IifCxLX4C1aNc2orss+Qml/BOu31xgiHkpmF3JNX9Ol4Yq1Fwevai4Kp3zvskMuAtjrH04YaS1GV8XPLxs0co7MUHrjKtl+TCFP2Ykg1Lq08naTMJxmY0mq9maTjYEHlmBpCZMfWt6ftoUAHlBk6RVoxbFG65fRO8WrQXwQZn//ltewrR4znvtcgwMqww6y8FEkDmbpbqh1x9Mq7nmWcO/PKIpA7oV3unXEEX+AoSPD87+ah5ZO9blkr0TyzxrQmsEr0BYMZfL+aFPEM=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00DC_01D51ADE.E05B2830"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: acc93758-90b5-4ecc-6e10-08d6e8e53fb5
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2019 12:07:43.2274 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bo.burman@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4411
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/FBfzLfEoQbCcRMm1_GUhL2OLE1w>
Subject: Re: [MMUSIC] Getting draft-ietf-mmusic-sdp-uks-04 ready for PubReq
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, 04 Jun 2019 12:07:50 -0000

Thank you for your review Roman.

 

Authors, since there are no unaddressed comments beyond the editorial ones from Flemming (here <https://mailarchive.ietf.org/arch/msg/mmusic/ZewhLMuV3EJ6r6rVsCtSiF4TsaM> ), and there seems to be no objections to proceed, please submit an update addressing Flemming’s comments that I will then submit for publication.

 

Thanks,

/Bo

MMUSIC co-chair

 

 

From: mmusic <mmusic-bounces@ietf.org> On Behalf Of Roman Shpount
Sent: den 30 maj 2019 00:45
To: Martin Thomson <mt@lowentropy.net>
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Getting draft-ietf-mmusic-sdp-uks-04 ready for PubReq

 

I have reviewed the document and I have confirmed that the document is clear and my understanding is correct.

 

Thank you, Martin.

_____________

Roman Shpount

 

 

On Mon, May 27, 2019 at 12:45 AM Martin Thomson <mt@lowentropy.net <mailto:mt@lowentropy.net> > wrote:

On Sat, May 25, 2019, at 10:03, Roman Shpount wrote:
> Sorry for the late question, but is there a scenario where party is 
> communicating with attacker but believes that it communicates with 
> patsy?

I don't think so.  I think that would require failures in parts of the system that we are assuming to be OK (the IdP in one case, the signaling system in the other).  The attacker can swap another entity into a call, but not vice versa.

> In all the described attacks, all I see is that one of the attacked 
> parties is communicating with another but thinks it is communicating 
> with the attacker. What is the risk associated with this? How this is 
> different then just setting up a communication channel with attacker 
> who is re-encoding the data?

This is different because a recipient is able to authenticate the source of the media as being the victim.  It is very much like relaying media by instantiating a new session and forwarding media, but if context (or ambient authority) is used in interpreting that data, the attacker might gain something.

Imagine the following conversation: 

victim: I will buy 10.
response: Are you quite sure?
victim: Yes. Please charge to my account.

If the attacker is selling boxes of cookies and the target is selling refrigerators, the result might be surprising.

v2.23.0 | Report a Bug | By Email