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

Martin Thomson <martin.thomson@gmail.com> Tue, 08 July 2014 18:09 UTC

MIME-Version: 1.0
In-Reply-To: <CAOW+2dsVZj56aVL5+79d6RSTZFLwjfWdm=rs7FPnvdWQZHAdfA@mail.gmail.com>
References: <CAOW+2dsVZj56aVL5+79d6RSTZFLwjfWdm=rs7FPnvdWQZHAdfA@mail.gmail.com>
Date: Tue, 08 Jul 2014 11:09:33 -0700
Message-ID: <CABkgnnUEXCuOcG_p5BpZf8Wz2Y-Pq92XGpmEb5304-uTz9JNuA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Dsjb7JYP5w1tq1amuIjqUQlEIHE
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
Precedence: list

On 8 July 2014 10:54, Bernard Aboba <bernard.aboba@gmail.com> 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] Security Architecture: IdP for RTP and R… Bernard Aboba
Re: [rtcweb] Security Architecture: IdP for RTP a… Martin Thomson
Re: [rtcweb] Security Architecture: IdP for RTP a… Bernard Aboba
Re: [rtcweb] Security Architecture: IdP for RTP a… Iñaki Baz Castillo
Re: [rtcweb] Security Architecture: IdP for RTP a… Bernard Aboba
Re: [rtcweb] Security Architecture: IdP for RTP a… Martin Thomson
Re: [rtcweb] Security Architecture: IdP for RTP a… Dan Wing
Re: [rtcweb] Security Architecture: IdP for RTP a… Emil Ivov
Re: [rtcweb] Security Architecture: IdP for RTP a… Justin Uberti
Re: [rtcweb] Security Architecture: IdP for RTP a… Martin Thomson
Re: [rtcweb] Security Architecture: IdP for RTP a… Justin Uberti
Re: [rtcweb] Security Architecture: IdP for RTP a… Watson Ladd
Re: [rtcweb] Security Architecture: IdP for RTP a… Martin Thomson
Re: [rtcweb] Security Architecture: IdP for RTP a… Watson Ladd
Re: [rtcweb] Security Architecture: IdP for RTP a… Martin Thomson