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

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Jul 2014 10:54:41 -0700

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?

b. Can different identities be asserted for the RTP and RTCP DTLS
Transports? Does this make sense in some circumstances? If so, when?

Within a browser, it seems logical that the certificates used for RTP and
RTCP DTLS Transports and the asserted identities should be the same
(assuming that RTP and RTCP aren't multiplexed).

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

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?

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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Jul 2014 11:09:33 -0700

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

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

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Jul 2014 11:56:14 -0700

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 <[email-masked]>
wrote:

> fatal

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 Jul 2014 21:12:05 +0200

> been given different names in the first place.

I agree. The fact that RTP and RTCP seem two different protocols and,
even more, the fact that they can be carried over different
transports, does not mean that we should imagine exotic scenarios in
which a media endpoint generates just RTP or just RTCP.

OK, a media endpoint could be internally divided into different
components, one of then handling RTP and the other RTCP, but form the
point of view of media transmission it should behave as a single
endpoint.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Jul 2014 14:33:59 -0700

Inaki said: "OK, a media endpoint could be internally divided into different
components, one of then handling RTP and the other RTCP, but form the
point of view of media transmission it should behave as a single
endpoint."

[BA] It seems logical for the browser to utilize the same identity for both
RTP and RTCP, regardless of whether they are multiplexed or not.

However, if both the RTP and RTCP peer assertions are validated, shouldn't
it be up to the application decide whether to care?

A given application could compare the RTP and RTCP identities and consider
it a fatal error if the identities are not the same, OR it could decide to
ignore the RTCP identity.

BTW, the "compare" operation is potentially non-trivial in the case of
internationalized identities.  None of the specifications currently
describe how the identities are to be normalized in preparation for the
comparison, so I can imagine that some "fun" could be had there.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Jul 2014 14:47:01 -0700

On 8 July 2014 14:33, Bernard Aboba <[email-masked]> wrote:
> internationalized identities.  None of the specifications currently describe
> how the identities are to be normalized in preparation for the comparison,
> so I can imagine that some "fun" could be had there.

FWIW, the right hand side of identity is well defined:
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#section-5.6.5.4.1

The LHS is completely open to confusable glyphs and all sorts of
horrors.  I really want to avoid stringprep or whatever it's current
incarnation looks like, that's probably unavoidable long term.  For
now though, can we not pretend that the IdP knows what they are doing?

---

From: Dan Wing <[email-masked]>
Date: Tue, 8 Jul 2014 16:31:13 -0700

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

> [BA] You might want to take a look at the following drafts which will be discussed in AVTCORE: 

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 <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Emil Ivov <[email-masked]>
Date: Wed, 9 Jul 2014 13:02:29 +0200

> been given different names in the first place.

Adding to what others have said: this is only true today because of
the current state of things. In the SFU we are working on, we would
*love* not to terminate RTP encryption (it would mean slashing CPU
requirements by an order of magnitude at least) but we'd still need to
terminate RTCP. Not possible today but that's fixable as long as we
make sure we don't dig ourselves deeper into that hole.

Emil
-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 09:03:27 -0700

> The current draft handles this by covering multiple fingerprints by

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?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 10:56:44 -0700

> one of the possible fingerprints?

That's what the spec says to do.  That's how Firefox currently
operates.  It's not particularly hard to do.

To be precise, it assembles all relevant a=fingerprint attributes for
the m= section and allows the session to proceed if all sections have
one match, using the provided hash function.  I think that we provide
SHA-256, but support the full intersection of the textual names
registry and what is implemented and enabled (i.e., sha1 is OK).

I don't think that we require that the hash function match the
function used in the certificate signature; that's a nonsensical
requirement.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 11:46:43 -0700

That seems fine, as you say, it's not hard to implement. I just wasn't
aware the spec had provisions for that.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 11 Jul 2014 12:03:58 -0700

> registry and what is implemented and enabled (i.e., sha1 is OK).

So break one hash from the set and win. Why not require all to match?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 12:39:31 -0700

> So break one hash from the set and win. Why not require all to match?

That would prevent someone from ever adding a new hash function to the protocol.

http://tools.ietf.org/html/draft-thomson-mmusic-fingerprint explains a
little more, though I note that (with fresh eyes) Section 3 is pretty
damned cryptic and needs to be rewritten.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 11 Jul 2014 20:17:28 -0700

> damned cryptic and needs to be rewritten.
Ah, the spec does say all must match if present. Relevant sentence
from 2 " An endpoint that validates
a session using  fingerprint attributes MUST report failure if any
hash that it checks
doesn't match."

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 20:43:18 -0700

> a session using  fingerprint attributes MUST report failure if any

That's only a proposed update to the spec we're talking about: rfc
4572 (section 5)