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

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

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

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.

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

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

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?