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

From: Flemming Andreasen <[email-masked]>
Date: Fri, 3 May 2019 17:28:30 -0400

On 4/23/19 12:29 AM, Martin Thomson wrote:
> On Mon, Apr 22, 2019, at 08:07, Flemming Andreasen wrote:
>>> Right.  What is relevant here is the offers and answers, not the SIP requests.  RFC 3725 shows only inconsequential offers being generated by the controller.
>> This is where we differ. In the SIP case, the attack you describe is predicated on a mismatch between the Identity information provided in the SIP request and the (assumed) identity of the SDP in an offer, thus the SIP requests are indeed very relevant to the discussion.
> I see your point below.  I missed the bit in RFC 8224 where it has to be a request. I was concentrating on the properties of the assertions, not the protocol integration.  I agree that it's important.
>
> If 3PCC as described in RFC 3725 never produces a scenario where a request is bound to valid SDP, then 8224 + 3725 won't ever intersect.  Looking again with that constraint in mind (that it has to be a request), I see no scenario where 8224 and 3725 could be used together unless the controller is also the authorization service.  That arrangement would rule the controller out as an attacker we care about, because it has to be trusted by definition.   (More below.)
Agreed.
> This doesn't invalidate the other aspects of the attack, just that this attack isn't valid when both 8224 and 3725 are used.  SIP identity can be used on calls without 3PCC and the text here applies to those uses.
With the clarificiations discussed in mind, I'll take another look at 
the update for the chair comments you referred me to separately 
(https://martinthomson.github.io/sdp-uks/chair-review/draft-ietf-mmusic-sdp-uks.html)

>    Or 3PCC can be used without SIP identity (maybe the WebRTC identity is used) and the attack would be relevant.
Can WebRTC identity be used with regular SIP ? That's not the impression 
I got from 
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18 (where 
WebRTC identity is defined), nor do I think it should be since that would:
a) Be redundant with the SIP Identiy information defined in RFC 8224 and 
hence require further treatment in terms of how you deal with 
discrepancies between the two.
b) Conflate session signaling (SIP) with media signaling (SDP).

In any case, this is probably something that should be clarified in 
draft-ietf-rtcweb-security-arch-18 (might as well do that now, since you 
will ultimately get an SDP designated expert review from me on that one 
that will ask the same).

>
> It might be good to categorically say that 3PCC - as described in RFC 3725 - is incompatible with RFC 8224.  Would that help clarify this bit?
>
I believe so.
> On the specific flows:
>
> Flow I might work if the controller was the Authorization Service for A.  Or the controller was between A and its Authorization Service.
> Flow II only works if the controller is the Authorization Service for both A and B.
> Flows III and IV might work if the controller was the Authorization Service for B.  Or the controller was between B and its Authorization Service.
>
> I base this on the fact that any non-trivial offers only appear in 200 responses.  So the first place that the message appears in a request is at the controller.  This puts the controller on a "trusted" segment of the signaling path.
Agree, which again goes against the premise of the attack and hence 
supports your suggestion above about 3PCC and RFC 8224 being 
incompatible, and hence the attack scenario not being applicable to 3PCC.

Thanks

-- Flemming

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 May 2019 20:18:15 -0400

Perhaps slightly off topic for *this* draft, but ISTM it is a problem if 
some form of authenticated identity can't be used with 3PCC. Perhaps 
this needs to be treated as a separate problem to be solved.

I think, for a click to dial case it may be necessary that initially 
each participant gets the identity of the server. Then, a subsequent 
step might be for another round of signaling to convey identity end to end.

	Thanks,
	Paul

On 5/3/19 5:28 PM, Flemming Andreasen wrote:
>> ..

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 May 2019 00:53:30 -0400

(I apologize for errors in adjusting quoting, our MTAs seem incompatible somehow.)

On Sat, May 4, 2019, at 07:28, Flemming Andreasen wrote:
> >   Or 3PCC can be used without SIP identity (maybe the WebRTC identity 
> > is used) and the attack would be relevant. 
> 
> Can WebRTC identity be used with regular SIP ?
> 
> That's not the impression I got from 
>  a) Be redundant with the SIP Identiy information defined in RFC 8224 
> and hence require further treatment in terms of how you deal with 

These are reasons for not using WebRTC Identity in regular SIP, but I don't believe the two to be *fundamentally* incompatible.  The latter is perhaps a good argument against the use of WebRTC Identity at all, but the split between media and session signaling and the relationship of each with the security properties of the system is probably a topic of discussion for another draft.  We're just trying to work out how to proceed with this little piece.

> draft-ietf-rtcweb-security-arch-18 (might as well do that now, since 
> you will ultimately get an SDP designated expert review from me on that 
> one that will ask the same). 

I'm sure that there's something worth saying there.  Not sure what other think, but I wouldn't expressly prohibit the use of the two in combination.  I would reduce this to pointing out that there is a potential for disagreement between the two that would be bad.

> > It might be good to categorically say that 3PCC - as described in RFC 3725 - is incompatible with RFC 8224.  Would that help clarify this bit?

I've updated the PR with the following text (being the entire section on 3PCC):

---8<---
Third-party call control (3PCC) {{?RFC3725}} is a technique where a signaling
peer establishes a call that is terminated by a different entity.  This attack
is very similar to the 3PCC technique, except where the TLS peers are aware of
the use of 3PCC.

3PCC as described in RFC 3725 is incompatible with SIP identity {{?SIP-ID}} as
SIP Identity relies on creating a binding between SIP requests and SDP.  The
controller is the only entity that generates SIP requests in RFC 3725.
Therefore, in a 3PCC context, only the use of the `fingerprint` attribute
without additional bindings or WebRTC identity {{?WEBRTC-SEC}} is possible.

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 TLS extensions.  For
a connection to be successfully established, a 3PCC controller needs to either
forward SDP without modification, or to avoid modifications to `fingerprint`,
`tls-id`, and `identity` attributes.  A controller that follows the best
practices in RFC 3725 is expected to forward SDP without modification, thus
ensuring the integrity of these attributes.

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

How does that work for you?

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 7 May 2019 17:29:58 -0400

> How does that work for you?
That looks good to me - thx Martin

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 7 May 2019 22:07:52 -0400

I took another look at the "chair review update" version at 
https://martinthomson.github.io/sdp-uks/chair-review/draft-ietf-mmusic-sdp-uks.html 
(I see you just posted an -04 as well - not sure if there are any 
differences between those two).

The "chair-review" version generally looks good to me, except in Section 
3.2, I think we need to say something about how to handle the situation 
where you send and/or receive both SIP Identity and SDP identity (we can 
have one take precedence or try both).

Also, two suggested editorial updates:

Section 3.1, first sentence after Figure 1
OLD: "The attack requires that Mallory obtain an identity binding for 
her own identity with the fingerprints presented by Patsy (P)."
NEW: "The attack requires that Mallory obtain an identity binding for 
her own identity with the fingerprints presented by Patsy (P), which 
Mallory may have obtained previously.".

Section 3.2, First paragraph after "Note" section:
s/Identity/"SIP Identity"

Other than that it looks good.

Thanks for the patience in all the discussion on this.

-- Flemming

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 07 May 2019 22:14:19 -0400

Thanks Flemming, I've applied the two editorial updates to my tree.  They are minor enough that I'll wait for the next opportunity to include them in revised draft.  I'm sure that I'll get a chance.

On Wed, May 8, 2019, at 12:07, Flemming Andreasen wrote:
> https://martinthomson.github.io/sdp-uks/chair-review/draft-ietf-mmusic-sdp-uks.html (I see you just posted an -04 as well - not sure if there are any differences between those two). 

They were identical, aside for dates.

>  Thanks for the patience in all the discussion on this. 

And you.   I'm sure that this is much better for the effort.