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

[Bernard Aboba <[e-mail]>]

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




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