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

[Justin Uberti <[e-mail]>]

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

Different m= lines can have different fingerprints, but do we expect to
support multiple fingerprints with the same digest algorithm on the same m=
line, where the receiver then checks that the received certificate matches
one of the possible fingerprints?


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