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

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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>