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

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

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

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.

You might wonder whether the controller can generate bogus SDP that can be signed, but that is a constraint on deployment, not on security.  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.  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.

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

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.