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

Flemming Andreasen <> Tue, 05 March 2019 21:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AAEF1310ED; Tue, 5 Mar 2019 13:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bpGRlwnaQ9R5; Tue, 5 Mar 2019 13:58:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74C831310CD; Tue, 5 Mar 2019 13:58:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11136; q=dns/txt; s=iport; t=1551823127; x=1553032727; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=aP+Axj0bgFf6V7DRuvIaRlMpHnSnYCc4JrPst3yex/g=; b=lPsGy2tQZRkp7SYKUOnRGQY27vsUpTJBbPTeLNc9RGxuvI5nYQ8gBKdl ZN9ZKuiSkD6rPS5FequZvVv4xV2kb7PgILnxd9IIR2cz40Nqj5I6iEhJJ /A4bZfnIJemRVXkkOHHRvLoBxHe2MPzvleiZg+1HnOYdGl/v0qkwqDlo7 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADW735c/5BdJa1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVIDAQEBAQELAYENgQJogQOEL5VxiTyIcoVzgXsNI4R?= =?us-ascii?q?JAoQsIjUIDQEBAwEBAwEDAm0cDIVKAQEBAQIBI1YQCQIOCioCAlcGAQwIAQG?= =?us-ascii?q?DHgGBaAUID482m2aBLx+FJYRmBYEvAYsnF4FAP4ERJ4Jrgx4CgTcKAQGDKIJ?= =?us-ascii?q?XApFtkhoJh0ODeIczBhmBdIVkgyKFDYMgimWFXIxxgUkDM4FWTSMVgyiFd4p?= =?us-ascii?q?SHyEDjweCPgEB?=
X-IronPort-AV: E=Sophos;i="5.58,445,1544486400"; d="scan'208,217";a="529675160"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 21:58:46 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id x25LwjBR028641; Tue, 5 Mar 2019 21:58:45 GMT
To: Martin Thomson <>, mmusic <>
References: <> <> <>
From: Flemming Andreasen <>
Message-ID: <>
Date: Tue, 5 Mar 2019 16:58:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------70EDCCF04780CD42B63580C3"
Content-Language: en-US
Archived-At: <>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Mar 2019 21:58:50 -0000

Thanks for the updates Martin. Please see below.

On 3/1/19 1:47 AM, Martin Thomson wrote:
> Thanks for the review Flemming,
> I've made changes as suggested below, which you can review here:
> All the changes I have made are on if you want to see the entire batch of changes.
> On Tue, Feb 26, 2019, at 15:45, Flemming Andreasen wrote:
>> Hi Martin
>>   I also took a closer look at the document and have a few additional
>> comments (as individual):
>>   Non-Editorial
>>   =========
>>   Section 2.3, second paragraph: The description on how 3PCC can work
>> with the proposed mechanism is a bit vague. It would be helpful to
>> expand it and provide an example.
> Can do.
> "For 3PCC to work with the proposed mechanisms, TLS peers need to be aware of the
> signaling so that they can correctly generate (and check) the extension.  Peers
> need access to any identity assertions present in signaling in order to perform
> the checks in {{external_id_hash}}.  To perform the checks in
> {{external_session_id}}, a 3PCC system needs to ensure that guarantee that peers
> use the same SDP `tls-id` attribute value."
I'm still not clear on how this works. RFC 3725 defines four different 
flows - does the mechanism work with all four of them ? To some extent, 
this may be a question on SIP Authenticated Identity (RFC 8224) as it is 
not clear to me how that works with 3PCC. An actual (high-level) call 
flow illustratings this would be helpful.

>>   Section 3, last paragraph: The text seems out of place here. The text
>> implicitly refers to the previous paragraph, which doesn't seem to make
>> sense.
> Bo made the same comment.  I moved it up and expanded it a little.
Thanks - looks good.
>>   Section 3.1, second paragraph: "In the first session, Patsy is
>> presented with the option to communicate with Norma"
>>   How is that possible when the signaling originates from Mallory (I
>> thought we had signaling integrity and authenticated identity) ?
> The previous paragraph says "it is assumed that the attacker also controls the signaling channel."  As I mentioned in my other mail, when there is an identity binding, we assume that the signaling service is an attacker.  I've made some edits to the corresponding introductory text in response to Bo's review.  Let me know if you think that clears things up, or could be improved.
> .

The text reads well, but I'm still left with the same question:

Section 3.1, second paragraph says there are two separate sessions (I 
take that to mean SIP sessions). It then goes on to say

      "In the first session, Patsy is presented with the option to 
communicate with Norma "

If I understand correctly, this means there is a SIP INVITE sent by 
Mallory to Patsy, however Mallory somehow asserts Norma's identity to 
Patsy. How is Mallory able to do that if we are using SIP Authenticated 
Identity ? I'm not sure if the above would be cleare if the flow was 
expanded to show INVITE and 200-OK.


-- Flemming