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

Bo Burman <> Mon, 01 April 2019 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 479B6120169; Mon, 1 Apr 2019 07:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] 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 Y6jcf6jDv2fC; Mon, 1 Apr 2019 07:30:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65F62120110; Mon, 1 Apr 2019 07:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t0PP7v341LcR8x1ZdunMPsG3PyUfxwHZHzoTnxXGC5M=; b=Xnek1qn2nh7l7E1tovnqS4iwcElAB0FKmAPo89HiGYlnsm1+7BlnExz2IGrI3OUs/uLnUCL6GOAyfMcxLA78Q39nZCnqgwDhIZTWDu5NSQ+WQ1HwufYCkQcqHYuDnpU6lL3dF/kmxWcNQTrOizlEhVx077N7DjdZ+rzGEmZB0N4=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.11; Mon, 1 Apr 2019 14:30:44 +0000
Received: from ([fe80::5ce7:e79c:91a5:5629]) by ([fe80::5ce7:e79c:91a5:5629%6]) with mapi id 15.20.1771.011; Mon, 1 Apr 2019 14:30:44 +0000
From: Bo Burman <>
To: Flemming Andreasen <>, Martin Thomson <>, mmusic <>
CC: "" <>
Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
Thread-Index: AQHUppKYzbL9IIoclE+lDKCXhZBCwqXxzxIAgATZAYCAB0f8gIAAVxuAgAK+34CAJtpEsA==
Date: Mon, 1 Apr 2019 14:30:44 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4a440061-5512-48a1-72d3-08d6b6aea021
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(4534185)(4627221)(201703031133081)(201702281549075)(5600139)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR07MB3164;
x-ms-traffictypediagnostic: HE1PR07MB3164:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0994F5E0C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(346002)(396003)(136003)(199004)(189003)(51444003)(26005)(105586002)(186003)(316002)(229853002)(6346003)(6506007)(256004)(14444005)(102836004)(606006)(7736002)(53546011)(106356001)(66066001)(97736004)(7696005)(25786009)(71200400001)(71190400001)(3846002)(5660300002)(86362001)(11346002)(74316002)(6116002)(790700001)(446003)(33656002)(476003)(76176011)(6436002)(8936002)(52536014)(110136005)(8676002)(4326008)(81166006)(486006)(81156014)(68736007)(99286004)(14454004)(478600001)(93886005)(236005)(9686003)(99936001)(6246003)(2906002)(53936002)(966005)(44832011)(55016002)(6306002)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3164;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ckU63elzCZPRO6UMg+R3BFREvM4HUNlAS49PWG/evtGtqP6GoMJqi6QlaQfg+/9MeScPUx1kwHrf0yNNFN4p9ECfCrayGQre9++IxhMoTEHDH5L104l9GWRtih288FycHgVj3bYYru4DmulKnibxR0rQAzcwn85e6bK24DOeJFLClclHeywA0P6rdBusCE2/Kho3/GbFxxW9sWJyHzLVoelYPM+l6erE8AmshFgve/5Bxi4fjwktfnNExVV5wiu99WPwn6YgnL6PXcl/0EjRpFaoQmxGMBQTcpFHzNVm3NZM+t3XxnmHdEN3913CBTGrHvOz2DDDJyKp40BYa1/dcLVqTdrWo1zCw6F9GeVf7j7owwL69WfnXaMM/CBrrfNNPoZVqUn+ggiTRlycMVG2R0fKVY3ck8Vr5rEejKoSFBY=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_009E_01D4E8A8.3C76B7B0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a440061-5512-48a1-72d3-08d6b6aea021
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 14:30:44.4773 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3164
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: Mon, 01 Apr 2019 14:30:51 -0000



Do you have any answers to Flemming’s questions below?


When those questions are answered, please submit a new version that addresses them and all other WGLC comments.


/Bo (as MMUSIC co-chair)


From: mmusic <> On Behalf Of Flemming Andreasen
Sent: den 7 mars 2019 22:06
To: Martin Thomson <>et>; mmusic <>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03



On 3/5/19 10:10 PM, Martin Thomson wrote:

Hi Flemming,

"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 
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. 

The problem here is that RFC 3725 doesn't really contemplate the sorts of changes that earlier commenters observed happen in practice.  All the flows and recommendations there limit the changes made by the controller to fixups that ensure that offers and answers from the endpoints work effectively.  On that basis, simply following the guidance in RFC 3725 would - absent some mistake - result in a working session.  Presumably, if the controller supports tls-id, then it copies the value faithfully and things work.  That is how I would interpret the guidance in 3725.
But some people observed that 3PCC covers more than the fixups that 3725 recommends, so this text hedges a little.  Would it help if it were expanded thus:
"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}}.  For a connection to be successfully
established, a controller needs to forward all fields that contain identity
assertions, including any fields outside of SDP that are used, such as the SIP
Identity header field {{?SIP-ID}}.  A controller that follows the best practices
in RFC 3725 is expected to forward the necessary information contained in SDP,
such as the WebRTC `identity` attribute, thus ensuring the necessary information
is present.
"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.  A
controller that follows the best practices in RFC 3725 will produce SDP with
consistent `tls-id` values, but other forms of modification might not.
"It is understood that this technique will prevent the use of 3PCC if peers have
different views of the involved identities, or the value of SDP `tls-id`

The text is clearer, but I still don't follow. If I understand RFC 8224 correctly, authenticated identity is only defined for SIP requests, however all four 3PCC flows in RFC 3725 have the controller generate the SIP INVITE, so how do the endpoints exchange authenticated identity information ? 

 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. 

Yeah, I really want to avoid adding all the SIP stuff here.  There would be lots of irrelevant messages involved and it distracts from the message.
The key insight here is that SIP identity only certifies a small number of fields and that the rest of the session is open to be modified by the signaling server.  RFC 8225 only covers the identity (sip:norma@example or tel:+12345556789) and the a=fingerprint values, everything else is open to attack.  So if we allow Mallory the ability to modify signaling, there is a lot she can do.  In practice however, this doesn't require much of an attack on the session, other than (maybe) to substitute transport parameters.
>From the perspective of SIP and SIP identity, these are largely legitimate sessions.  The attack on signaling is necessary only to the extent that the attack also depends on 
I've added more text here, realizing that it was a little light.  This is the updated section in full:
"The attack requires that Mallory obtain an identity binding for her own identity
with the fingerprints presented by Patsy (P).  This false binding is then
presented to Norma (Signaling1 in the figure).

You mean Signaling2 in the figure (below), right ? 

     Norma                   Mallory                   Patsy
     (fp=N)                   -----                    (fp=P)
       |                        |                        |
       |                        |<---- Signaling1 ------>|
       |                        |   Norma=N Patsy=P      |
       |<---- Signaling2 ------>|                        |
       |   Norma=N Mallory=P    |                        |
       |                                                 |
       |<=================DTLS (fp=N,P)=================>|
       |                                                 |
     (peer = Mallory!)                         (peer = Norma)

               Figure 1: Example Attack on Identity Bindings

"Patsy could be similarly duped, but in this example, a correct binding between
Norma's identity and fingerprint (N) is faithfully presented by Mallory.  This
session (Signaling2 in the figure) can be entirely legitimate.

Signaling1 ? 

"A DTLS session is established directly between Norma and Patsy.  In order for
this to happen Mallory can substitute transport-level information in both
sessions to facilitate this, though this is not necessary if Mallory is on the
network path between Norma and Patsy.
"As a result, Patsy correctly believes that she is communicating with Norma.

I don't follow the above sentence (just like I don't follow the sentence I referenced originally, i.e. "In the first session, Patsy is presented with the option to communicate with Norma".

If we double-click on "Signaling1", then I believe we start with:

    INVITE(From: Mallory, To: Patsy, Fingerprint:Norma, Identity:{From:Mallory, Fingerprint:Norma})

Implicit in the sentence above is an assumption that *Mallory* is somehow able to generate an INVITE to Patsy with an Identity header that authenticates *Norma* as the originator, i.e.:

    INVITE(From: Norma, To: Patsy, Fingerprint:Norma, Identity:{From:Norma, Fingerprint:Norma})

How is that possible ? What am I missing here ? 

However, Norma incorrectly believes she is talking to Mallory."

This part I understand. 

There is one last thing that I realized while writing up those changes, and that is that the text was a little vague about the relationship between the attacks.  I'll send another email with a proposed clarification, because I think that's important enough not to hide.

Ok - thanks 

-- Flemming 

mmusic mailing list <>