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

["Martin Thomson" <[e-mail]>]

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

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

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

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

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

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

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

Yep, thanks.