Re: [rtcweb] Security Architecture: IdP for RTP and RTCP

[Dan Wing <[e-mail]>]

On Jul 8, 2014, at 11:56 AM, Bernard Aboba <[e-mail]> wrote:

> Martin said: 
> 
> "I think that the way that we manage identity in a multi-party
> situation probably needs something different to that.  I don't see any
> particular value in terminating RTCP when you aren't also terminating
> RTP, the two are far too tightly coupled.  They shouldn't really have
> been given different names in the first place."
> 
> [BA] You might want to take a look at the following drafts which will be discussed in AVTCORE: 
> http://tools.ietf.org/html/draft-mattsson-avtvore-cloud-conferencing-use-case
> http://tools.ietf.org/html/draft-cheng-srtp-cloud

Related, "Requirements for Secure RTP Media Switching", http://tools.ietf.org/html/draft-ismail-avtcore-media-req

-d


> 
> 
> 
> 
> On Tue, Jul 8, 2014 at 11:09 AM, Martin Thomson <[e-mail]> wrote:
> On 8 July 2014 10:54, Bernard Aboba <[e-mail]> wrote:
> > In the situation where RTP and RTCP are not multiplexed, distinct DTLS
> > transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.
> >
> > In looking for guidance within the security architecture document, some
> > questions came to mind:
> >
> > a. Are the certificates used for RTP and RTCP DTLS Transports necessarily
> > the same on both the local and remote side? If they are supposed to be the
> > same, what happens if they aren't?
> 
> The certificates can be different.  As you might recall, one of the
> issues that we discussed was the possibility of having different
> a=fingerprint attributes on different m-lines, as well as having
> alternative a=fingerprint lines on the same m-lines.
> 
> The current draft handles this by covering multiple fingerprints by
> the identity assertion.
> 
> > b. Can different identities be asserted for the RTP and RTCP DTLS
> > Transports? Does this make sense in some circumstances? If so, when?
> 
> a=identity is a session-level attribute and they should (MUST?) only
> be one.  So no.  And I can think of any case where this makes sense in
> much the same way that having unmultiplexed RTP/RTCP doesn't make
> sense any more (if it ever did).
> 
> > The WebRTC 1.0 API Section 8.3 seems to indicate that this should always be
> > the case:
> >
> > "It is possible that different values for the "a=identity" attribute is
> > provided at a media level in SDP. A browser may either choose to treat this
> > as an error or ignore the attribute. If multiple different assertions are
> > validated, then they must produce identical identity values."
> 
> This is out of date.  I've sent the editors a pull request to have that fixed.
> 
> > However, I am wondering whether there can be legitimate cases where a
> > browser communicating with a gateway or SFU might encounter distinct
> > identities or certificates for RTP and RTCP.  For example, could an SFU
> > potentially terminate RTCP but not RTP, in which case the certificates and
> > asserted identities might be different between RTP and RTCP?
> 
> I think that the way that we manage identity in a multi-party
> situation probably needs something different to that.  I don't see any
> particular value in terminating RTCP when you aren't also terminating
> RTP, the two are far too tightly coupled.  They shouldn't really have
> been given different names in the first place.
> 
> > The WebRTC 1.0 spec seems to indicate that this should be treated as a fatal
> > error, but I'm wondering whether the browser shouldn't be "strict in what it
> > sends but liberal in handling what it receives" by just using the identity
> > and certificates for RTP, and ignoring the RTCP identities.  Trying to
> > inform the user about different asserted identities for RTP and RTCP seems
> > way too complicated to even be worth considering.
> 
> BTW, I wish that "liberal in what you permit" meme would go away.  I
> haven't found it to be particularly useful, except as a fatalistic
> acknowledgement of the messy end state that is the Internet.
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb