Re: [MMUSIC] Input wanted for draft-ietf-mmusic-sdp-uks

[Martin Thomson <[e-mail]>]

Thanks for the comments Dale, they helped clarify things a lot.

On Thu, Jun 21, 2018 at 1:07 PM Dale R. Worley <[e-mail]> wrote:
> (My previous comments were limited to the request for discussion, and
> the Abstract.  My comments were hastily written, but that's probably OK,
> since the Abstract should be clear even if read hastily and without the
> body of document ...)

Yep, that's perfectly OK :)

> My first look at the body of sdp-uks left me wondering exactly what the
> problem is that this is defending against.  From a telephony point of
> view, if the SDP peer sends me a fingerprint for establishing TLS, and I
> establish a TLS session that matches the fingerprint, then clearly I am
> communicating with the entity that the peer intended me to communicate
> with.  To the degree I trust that I know the identity of the SDP peer, I
> can trust the media session.
>
> This logic shows up most clearly in 3PCC, when (from the point of view
> of a non-executing UA) the SDP peer isn't the RTP peer; the 3PCC
> controller is, effectively, authenticating each of the RTP peers to each
> other by passing through their certificate fingerprints.

Ahh, the 3PCC bugaboo continues to make everything worse :/

So yeah, the attack this describes and 3PCC are strangely
indistinguishable.  You are right that the controller can connect
arbitrary nodes, and that's what we understand as a feature when we
talk about 3PCC.

The (missing) assumption here is that there is often an assumed
identity for signaling that is assumed to also transfer to the media.
The assumption that a=fingerprint provides this is very common,
especially for people who are not so familiar with the ins and outs of
the actual guarantees the protocols provide.  Sadly, I was one of
these people, and we built the WebRTC identity system to rely on this
bad assumption.  That 3PCC sits neatly in this gap is something I find
interesting.

The main difference between the described attack and 3PCC, if my
understanding of 3PCC is correct, is that under 3PCC, the endpoints
are aware of the use of 3PCC.  That is, the controller makes no effort
to deceive the ultimate endpoints of the media session.  As long as
that holds and endpoints can be involved, the proposed mechanism can
still help.  Endpoints can use the TLS extension to bind media to
signaling.  For someone who does not expect 3PCC, the proposed defense
is mostly effective; for someone who is, the defense doesn't make
things worse other than maybe presenting a modest deployment
challenge.  That is, there is no expectation that the defense prevent
3PCC, just to prevent any mismatch between signaling and media in the
simple case.

> My guess is that the problem arises when the entity can independently
> verify that the SDP peer has presented the fingerprint of a certificate
> for EXAMPLE.COM, and the entity then establishes a TLS session whose
> peer presents that certificate, and the entity then incorrectly
> concludes that the *SDP* peer must be EXAMPLE.COM, because hey they
> could arrange for a TLS session with an EXAMPLE.COM peer!

Yes, that is one attack.

More seriously, the holder of EXAMPLE.COM can use the WebRTC identity
system to bestow their identity on any other entity.  That could
definitely be clearer in the draft.

The analogous attack might be EXAMPLE.COM getting a certificate from a
CA for use in HTTPS.  That certificate could cover the public key of
OTHER.EXAMPLE.  HTTPS isn't vulnerable to this because it carries the
identity in the handshake through the certificate itself and
OTHER.EXAMPLE wouldn't offer the EXAMPLE.COM certificate.  The draft
describes the same basic defense here.

> So, I think you're going to need to revise sectons 1 and 2 to clarify
> what security assertion is getting violated in this situation -- it
> seems that some people consider security assertions to be included that
> I do not.

I see where you are coming from.  I think that's a reasonable request.
No guarantee that you will see a draft before the cutoff, but I've
opened issues to track these points.