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

Flemming Andreasen <fandreas@cisco.com> Mon, 08 April 2019 20:48 UTC

Return-Path: <fandreas@cisco.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 C8C3A12066A; Mon, 8 Apr 2019 13:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 eKU3TjvAp1sM; Mon, 8 Apr 2019 13:48:18 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB14120668; Mon, 8 Apr 2019 13:48:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17750; q=dns/txt; s=iport; t=1554756498; x=1555966098; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=3XrdHLk/AqV356RW0TPS5zK6yPyU6O/bIFZw32A4Qk0=; b=gjq/vScCoCArYcJqB3AWLFuaNm64jTuk+HaLKXDax7c+Dgl9YSYP30yt uX9I/xxSUDeUJfScwOuK9BkBJHpXJ8P+3fwV/v693RSHJRAoetl/29nze 1gznzm0o7DmsH4bhXiWzMj8ku+VA4+K1q8i33HBF8QoCI/2aXlsWBu+9x 0=;
X-IronPort-AV: E=Sophos;i="5.60,326,1549929600"; d="scan'208,217";a="459716419"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2019 20:48:17 +0000
Received: from [10.155.64.213] ([10.155.64.213]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id x38KmGf7007784; Mon, 8 Apr 2019 20:48:16 GMT
To: Martin Thomson <mt@lowentropy.net>, 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>
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>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <4a6a7d47-bd49-ed20-561e-ed4223f2d190@cisco.com>
Date: Mon, 8 Apr 2019 16:48:14 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <ea80d50b-9463-4bb4-ac89-862987a94585@www.fastmail.com>
Content-Type: multipart/alternative; boundary="------------0F0AF69C93F72CF2BFE27F0F"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.155.64.213, [10.155.64.213]
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/JutWDgBn-M0ZYvisdlu3_6hKapw>
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: Mon, 08 Apr 2019 20:48:21 -0000


On 4/7/19 10:18 PM, Martin Thomson wrote:
>> 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 ?
> Flows 2 and 3 show the Controller creating an offer, but in all cases it is an offer with no media.  The endpoints are still responsible for creating the offer that contains media.  Therefore I assume that they can create offers with identity assertions.
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]).

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 ?

>>>>   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 identitywith the fingerprints presented by Patsy (P).  This false binding is thenpresented 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
> I swapped the two flows in the figure so that it more closely matches the text.
Ok.
>>>    "Patsy could be similarly duped, but in this example, a correct binding betweenNorma's identity and fingerprint (N) is faithfully presented by Mallory.  Thissession (Signaling2 in the figure) can be entirely legitimate.
>> Signaling1 ?
>>
>>
>>
>>>   "A DTLS session is established directly between Norma and Patsy.  In
>> order forthis to happen Mallory can substitute transport-level
>> information in bothsessions to facilitate this, though this is not
>> necessary if Mallory is on thenetwork 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 ?
> The section starts with "it is assumed that the attacker also controls the signaling channel."  We allow this possibility because the use of an identity assertion assumes a more capable attacker.  More likely, this assumes that we are defending against the signaling service itself.
>
> Once you get into that state, it's trivial for Mallory to construct the above messages.  Note that Norma will provide Mallory with an identity assertion that binds the identity "Norma" to Norma's fingerprints as part of the Norma<->Patsy session.  So all that Mallory needs to do is fit that into a plausible INVITE.
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.

Thanks

-- Flemming


>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic