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

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