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

From: Bo Burman <[email-masked]>
Date: Mon, 25 Feb 2019 13:23:04 +0000

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

* Don't understand what is meant with "...second condition..."; is it bullet #2, or is it referring to "...joining two separate sessions"?

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

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?

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

Section 4:
* First sentence, "similar attack"; similar to what?

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"

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

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?

* "Validating that peers..." -> "Successful validation that peers..."?

Section 4.3:
* "When used with SDP, the value includes..." -> "When used with SDP, the value MUST consist of..."?

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? 

* "Similarly, data from one TLS connection..."; I assume "data" means "security-related information", not "user data" (TLS payload)?

Nits:

Section 2.2:
* geniune -> genuine

Section 4:
* "believe that is calling" -> "believe that it is calling"

Section 4.1:
* "also needs to the ability" -> "also needs the ability"
* "ostensibly between Mallory and Norma, is complete.  Mallory begins forwarding DTLS" -> "ostensibly between Mallory and Norma, Mallory begins forwarding DTLS"
* "These packets denoted" -> "These packets are denoted"

Section 5:
* concatention -> concatenation

Cheers,
Bo (as individual)

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Martin Thomson
Sent: den 22 januari 2019 00:00
To: Magnus Westerlund <[email-masked]>; Flemming Andreasen <[email-masked]>; mmusic <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03

On Thu, Jan 17, 2019, at 19:50, Magnus Westerlund wrote:
> Hi Martin,
> 
> Thanks for the pull request. I have detailed inline comments, but I 
> think the pull request do address my issues.

Thanks again Magnus.

I made a few tweaks regarding canonicalization (or lack thereof) and merged the PR.  I'll await the end of the WGLC and the chairs' instruction before publishing again, but there's a preview here:

https://martinthomson.github.io/sdp-uks/draft-ietf-mmusic-sdp-uks.html

> Although I didn't read all the sections in 7, I do agree that security 
> arch appear to need some clarification so that what you write is clear.

FWIW, https://github.com/rtcweb-wg/security-arch/pull/84 attempts to fix that.

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Feb 2019 23:45:34 -0500

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.

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.

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

Editorial
======
Section 2.2, first paragraph: A reference after "key continuity" might 
be helpful.

Section 3.1, first paragraph after Figure 1:
- Old: The attack requires that Mallory obtain an identity binding for 
their own identity
- New: The attack requires that Mallory obtains an identity binding for 
her own identity

Section 3.1, 3rd paragraph after figure 1:
- Old: Patsy correctly believes that they are communicating with Norma. 
However Norma incorrectly believes they are talking to Mallory
- New: Patsy correctly believes that she is communicating with Norma. 
However Norma incorrectly believes she is talking to Mallory

Section 3.2, 4th last paragraph
- Old: in which the extension
- New: in which case the extension

Section 4.1, last paragraph
s/succeed/succeeds

Section 4.3
- Old: a ExternalSessionId
- New: an ExternalSessionId

On 1/7/19 9:08 AM, Flemming Andreasen wrote:
> Greetings MMUSIC
>
> This is to announce a 2 week WGLC on the draft:
>
> https://www.ietf.org/id/draft-ietf-mmusic-sdp-uks-03.txt
>
> as Proposed Standard. Please review and provide any comments you may 
> have on the document by Monday, January 21, 2019. Comments should be 
> sent to the document authors and the MMUSIC WG list. If you review the 
> document but do not have any comments, please send a note to that 
> effect as well.
>
> Thanks
>
> -- Flemming (MMUSIC co-chair)
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 01 Mar 2019 01:03:43 -0500

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

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

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

> Section 3:
> * Is the "victim" of the first paragraph the same or another victim 
> compared to the one mentioned in the next paragraph?
> 

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

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

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

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

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

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

> the value MUST consist of..."?

Thanks.

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

> * "Similarly, data from one TLS connection..."; I assume "data" means 
> "security-related information", not "user data" (TLS payload)?

Yep, thanks.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 01 Mar 2019 01:47:17 -0500

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.

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

> implicitly refers to the previous paragraph, which doesn't seem to make 

Bo made the same comment.  I moved it up and expanded it a little.

>  Section 3.1, second paragraph: "In the first session, Patsy is 
> presented with the option to communicate with Norma"

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.