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

From: Bo Burman <[email-masked]>
Date: Fri, 1 Mar 2019 14:29:22 +0000

Thanks, I believe that addresses almost all of my concerns (see also inline).

Just a final nit for section 4.1 (also listed in the below);
"...Once the second session completes, Mallory might cause DTLS packets
> sent by Norma to Patsy to be dropped.  It is likely that these DTLS packets will
> be discarded by Patsy as Patsy will already have a successful DTLS connection
> established."
[BoB] I think there can still be confusion what you mean with "Once the second session completes"; suggest changing to "Once the second session is established", if that was the intention.
Also, a couple of sentences before "Though Patsy...", there's one too many "is complete" in this sentence: "Once signaling is complete on a session, ostensibly between Mallory and Norma, is complete."

Cheers,
/Bo

> -----Original Message-----
> From: Martin Thomson <[email-masked]>
> Sent: den 1 mars 2019 07:04
> To: Bo Burman <[email-masked]>; mmusic <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
> 
> Thanks for reviewing Bo,
> 
> I've got the changes I've made up at
> https://github.com/martinthomson/sdp-uks/pull/7
> 
> The changes look like a lot, but that is mostly because of some reordering of
> text.  I've reworded a few things to improve clarity.  I appreciate having a
> new set of eyes on this.  I find I tend to miss places where the text assumes
> too much prior knowledge.
> 
> I'll put a second PR up for Flemming's review shortly.  That will stack on top of
> this one.
> 
> On Tue, Feb 26, 2019, at 00:23, Bo Burman wrote:
> > Hi Martin,
> >
> > I've now also reviewed this and have a set of comments and questions,
> > after taking Magnus' comments and your suggested edits in response to
> > that into account:
> >
> > Section 2.1:
> > * In bullet 2, "complete communications" is slightly unclear (more so
> > if "complete" is used in other contexts further down in the text). Do
> > you with "complete" mean "accept", or perhaps "accept setting up"?
> 
> Yes, I can see how this could be confusing. Reworded to:
> 
> "2. No entity will successfully establish a session with a peer unless they are
>    willing to participate in a session with that peer."
[BoB] OK, good.

> 
> > * Don't understand what is meant with "...second condition..."; is it
> > bullet #2, or is it referring to "...joining two separate sessions"?
> 
> Bullet 2, but see below.
> 
> > * Also don't really understand in what way that second condition is
> > "not necessary"; to limit the attacker capabilities (related to bullet
> > #2), for the attacker to join two sessions, or something else like
> > "for the attack to succeed"?
> >
> > * Just to confirm, does "removing this constraint" refer to removing
> > use of an identity binding?
> 
> Does this make more sense?
> 
> "Systems that rely on strong identity bindings, such as those defined in
> {{WEBRTC}} or {{!SIP-ID}}, have a different threat model, which admits the
> possibility of attack by an entity with access to the signaling channel.
> Attacks under these conditions are more feasible as an attacker is assumed
> to be able to both observe and modify signaling messages."
[BoB] Yes, that's much better.

> 
> > Section 3:
> > * Is the "victim" of the first paragraph the same or another victim
> > compared to the one mentioned in the next paragraph?
> >
> > * Is "another entity of the attacker's choice" also to be considered a victim?
> 
> Yes, there are really two victims here, so I've reworded to use first victim and
> second victim.
> 
> "An attacker causes an
> identity binding to be created that binds an identity they control to the
> fingerprint of a first victim.
> 
> "An attacker can thereby cause a second victim to believe that they are
> communicating with an attacker-controlled identity, when they are really
> talking to the first victim.  The attacker only needs to create an identity
> assertion that covers a certificate fingerprint of the first victim."
[BoB] OK

> 
> > * The last paragraph in section 3, just before section 3.1 "The same
> > technique..." seems a bit misplaced, after text talking about a
> > solution. Should it perhaps be moved just before the paragraph "The
> > problem..." in section 3? Or, is this "same technique" referring to
> > what is described in section 4?
> 
> Yes, this was a little light.  I've moved it up with the attack synopsis.
> 
> "A variation on the same technique can be used to cause both victims to both
> believe they are talking to the attacker when they are talking to each other.
> In this case, the attacker performs the identity misbinding once for each
> victim."
[BoB] OK

> 
> > Section 4:
> > * First sentence, "similar attack"; similar to what?
> 
> Yeah, that lost context.  How about:
> 
> "Even where the integrity of session signaling can be relied upon, an attacker
> might still be able to create a session where there is confusion about the
> communicating endpoints by substituting the fingerprint of a communicating
> endpoint."
[BoB] OK

> 
> > Section 4.1:
> > * Believe it would be helpful for the reader to better understand why
> > "Mallory has no real interest in seeing that session complete"
> 
> The next sentence is intended to explain this point: Mallory needs Patsy to
> maintain her end of the communications, lest Norma believe that the session
> is broken.
> 
> > * Same sentence, does "session complete" mean "session setup
> complete"?
> > I first interpreted "complete" as "conclude" in the meaning "terminate".
> >
> > * Same paragraph, should "call completion" be "call setup completion",
> > and "session completes" be "session setup completes"?
> >
> > * Same paragraph, "will likely be discarded by Patsy"; believe it
> > would be helpful to say why.
> 
> Here's what I ended up with:
> 
> "Though Patsy needs to believe that the second signaling session has been
> successfully established, Mallory has no real interest in seeing that session
> also be established.  Mallory only needs to ensure that Patsy maintains the
> active session and does not abandon the session prematurely.  For this
> reason, it might be necessary to permit the signaling from Patsy to reach
> Norma to allow Patsy to receive a call setup completion signal, such as a SIP
> ACK.  Once the second session completes, Mallory might cause DTLS packets
> sent by Norma to Patsy to be dropped.  It is likely that these DTLS packets will
> be discarded by Patsy as Patsy will already have a successful DTLS connection
> established."
[BoB] I think there can still be confusion what you mean with "Once the second session completes"; suggest changing to "Once the second session is established", if that was the intention.
Also, a couple of sentences before "Though Patsy...", there seems to be one too many "is complete" in this sentence: "Once signaling is complete on a session, ostensibly between Mallory and Norma, is complete."

> 
> > Section 4.2:
> > * I believe the first paragraph ("An attack on... ...vulnerable to
> > attack.") would also be helpful as first text of section 4. Move? Copy?
> 
> Good suggestion.  I moved it up.
[BoB] OK

> 
> > * "Validating that peers..." -> "Successful validation that peers..."?
> 
> Yep.  Expanded to
> 
> "Successful validation that the identifier matches the expected value means
> that the connection corresponds to the signaled session and is therefore
> established between the correct two endpoints."
[BoB] Good

> 
> > Section 4.3:
> > * "When used with SDP, the value includes..." -> "When used with SDP,
> > the value MUST consist of..."?
> 
> Thanks.
> 
> > Section 5:
> > * "Use of the "external_session_id"
> >    does not guarantee that the identity of the peer at the TLS layer is
> >    the same as the identity of the signaling peer"; sounds a bit
> > strange - isn't this what the draft is supposed to solve? Is "... when
> > used with session concatenation" meant?
> 
> This is a fundamental restriction of the design and with DTLS-SRTP in the
> absence of some sort of identity bindings.  As described here, an attacker can
> establish two sessions, call them A and B, with two different parties, call
> them Alice and Bob if you like.  It can send Bob's connection parameters (ICE,
> fingerprints,etc...) to Alice, and forward Alice's details to Bob in the same
> way.  This creates two signaling sessions (or 3pcc if you like), one between
> Alice and Attacker, and one between Attacker and Bob.  But there is only one
> media session between Alice and Bob.
> 
> I've done some rearranging here in an attempt to improve the flow of the
> section.  There are a few more words.  Let me know if it makes sense.
[BoB] Had a look at the pull request and I think the resulting text looks good.

> 
> > * "Similarly, data from one TLS connection..."; I assume "data" means
> > "security-related information", not "user data" (TLS payload)?
> 
> Yep, thanks.
[BoB] Changed text looks good.

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 03 Mar 2019 18:09:09 -0500

Thanks Bo,

I've updated the combined review PR:
https://github.com/martinthomson/sdp-uks/pull/9

With just the changes discussed:
https://github.com/martinthomson/sdp-uks/pull/9/commits/82645026faa84cd1124ba2dcfda07f341175d364

On Sat, Mar 2, 2019, at 01:29, Bo Burman wrote:
> [BoB] I think there can still be confusion what you mean with "Once the 
> second session completes"; suggest changing to "Once the second session 
> is established", if that was the intention.
> Also, a couple of sentences before "Though Patsy...", there's one too 
> many "is complete" in this sentence: "Once signaling is complete on a 
> session, ostensibly between Mallory and Norma, is complete."
> 
> Cheers,
> /Bo
> 
> > > I first interpreted "complete" as "conclude" in the meaning "terminate"

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 5 Mar 2019 16:58:45 -0500

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: https://github.com/martinthomson/sdp-uks/pull/8
>
> All the changes I have made are on https://github.com/martinthomson/sdp-uks/pull/9 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.

Thanks

-- Flemming

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Mar 2019 22:10:31 -0500

Hi Flemming,

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

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

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

"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.
However, Norma incorrectly believes she is talking to Mallory."

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.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 7 Mar 2019 16:06:11 -0500

> 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 ?

> 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

> session (Signaling2 in the figure) can be entirely legitimate.
Signaling1 ?

> "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 prop…
Ok - thanks

-- Flemming

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>