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

[Flemming Andreasen <[e-mail]>]

On 4/8/19 8:20 PM, Martin Thomson wrote:
> On Tue, Apr 9, 2019, at 06:48, Flemming Andreasen wrote:
>>   Offers and SIP Requests are not the same. In RFC 3725 Flow 2 and 3, it
>> is the controller that generates the SIP Requests and the endpoints
>> that generate the SIP Responses and to quote RFC 8224, Section 3:
>>
>>   Note that the scope of this document is limited to providing an
>>   identity assurance for SIP requests; solving this problem for SIP
>>   responses is outside the scope of this work (see [RFC4916]).
> 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.

> In the RFC 8224 context, this remains true, but it is hard to see why (more on that below).
>
>>   Thus, I still don't see how you get these endpoint Identity assertions
>> sent across with 3PCC. Maybe we need somebody else to chime in at this
>> point.
>>
>>   Jon/Cullen/Ekr: As authors of RFC 8224, can you help shed light on
>> this part of the thread ?
> [...]
>
>> Ok - I think you are saying a bit
>> more actually. Using the terminology of RFC 8224, I believe you are
>> assuming that the attacker controls the Authentication Service (which I
>> see as more than the signaling channel). If that is the case, then I
>> would suggest clarifying that in the text.
> I don't believe that is the case.  But I see now the angle you are concerned about.  Because RFC 8224 doesn't consider 3PCC, we might have a problem in the sense that 3PCC doesn't work at all with SIP Identity, but let's see if we can work out what it looks like.
>
> Note that "signing" as imagined in RFC 8224 depends on there being SDP to sign.  If there is SDP and it is not bogus, then there is potentially a binding between the a=fingerprint attributes and some identity.  Whether that is in the SIP Identity header field (RFC 8224) or the SDP itself (WebRTC), the result is the same.
Maybe so, but the flows and feasibility of the attacks are not, and that 
is an important distinction:
- 3PCC is defined for SIP, and SIP Identity is only defined for SIP Requests
- WebRTC Identity on the other hand is defined as an SDP attribute, and 
it is included in SDP offers (and optionally answers)

> For 3PCC with RFC 8224, either the controller is responsible for signing, the signing is performed by proxies near A and B (proxies that are not shown in the figure), or by A and B directly.  The point of the signature is to protect against attack between the point that the signature is added and where it is removed.  If the controller is both signing and consuming signatures, that would be pointless because they would be trusted by both A and B, so we'll ignore that case.   Therefore, we assume that signatures happen closer to A or B (or both) so that the signatures serve a purpose.
>
> So we have:  A---AuthSvcA---...---AuthSvcB---B with a controller somewhere on the signaling path between the two ends.  Generally, RFC 8224 assumes that the path from A to its Authentication Service is "trusted", so the attack is on the path between the two Authentication Services.  The controller can be anywhere, because we're not assuming anything about that.
Agreed so far.
> You might wonder whether the controller can generate bogus SDP that can be signed, but that is a constraint on deployment, not on security.
I disagree - it is a constraint on the overall feasibility of the 
attack. If we can't construct a deployment scenario that enables the 
attack, then the attack is not practically feasible, and then why are we 
concerned with it ?

To be more specific, the signature covering the SDP is generated by the 
authentication service above, and you stated (and I agree) that the 
attack cannot happen between A and AuthSvcA. Given that, how can the 
controller generate bogus SDP that gets signed (with a signature 
covering the "From: A", "To: B", Date and SDP fingerprint ) ?


>    Bogus SDP generated by a controller that sits on the "untrusted" portion of the signaling path won't be signed and therefore might be rejected, but that just limits the choices the controller has.
I agree it won't be signed, but at that point I don't believe we are in 
the attack scenario the document describes (?)

>   If the controller is on a "trusted" segment, then it might generate SDP for the endpoint nearest to it and have a valid signature over that content.
Sure, but above, you just said that wasn't the attack scenario we were 
contemplating (presumably because it invalidates the premise of SIP 
Identity to begin with)
>
> The attack that we're contemplating acts on the "untrusted" segment of the signaling path.  It operates without collaboration with any of the "trusted" entities.  It relies on being able to intercept and modify signaling on that path segment.  That's all.
I hear you, but you have yet to show me how that is possible. Please 
provide an example SIP flow that demonstrates how this attack is 
realized, 'cause I still don't see it.

>   In all cases other than the nonsensical one where the controller acts as Authentication Service for both parties, the attack we're  considering doesn't depend on the Authentication Service being compromised.
I agree that should be the premise, but I don't see how it is achieved.
> In the extreme case, say that  A and B sign their own SDP/signaling and assert their own identities.  If the controller is the attacker, they control when sessions are established and how.  They can copy-paste signatures between the different messages they receive.
Please provide an example flow that illustrates this in more detail.

Thanks

-- Flemming