Subject: [MMUSIC] comedia and TLS

From: Jonathan Lennox <[email-masked]>
Date: Thu, 19 Feb 2004 16:20:32 -0500

I was reading the comedia draft, and it occured to me that the TLS section
is quite underspecified.

Specifically, what certificates should each party to the connection present?
And is bidirectional authentication required, or just server-only
authentication?

TLS without certificates is proof against a passive snooper, but does
nothing to protect against a man-in-the-middle attack -- all the same
problems that have been discussed with TCP arise with TLS as well, rather
defeating the purpose of using a security protocol.

I think that with certificates, though, comedia-over-TLS can solve most of
the problems that have bedeviled comedia-over-TCP.  However, a number of
tricky issues arise.

First of all, unlike for https or even sips, many comedia end systems will
be small devices.  Thus, they won't be able to afford to have host
certificates signed by a certificate authority.  (thawte.com provides
certificates with an RFC822 subject for free, but I don't know of anyone who
provides one with a hostname or IP address subject.)

Second, many end systems have dynamic IP addresses and hostnames, because
they're (e.g.) DHCP-configured.  Furthermore, since comedia is designed to
work through NATs, any hostname or IP address presented in a certificate
might bear no relationship to the hostname or IP address to which the active
party connected, or from which the passive party received its connection.

Third, the device which is participating in the comedia connection might not
be the same as the device which is performing the signalling which carries
the comedia SDP -- consider, for example, SIP third-party call control.

So, picking a relevant certificate for TLS comedia -- or worse, trying to
figure out if your counterparty's certificate is legitimate -- is far from
trivial.  Clearly, the comedia draft needs to specify this.

So, here're my suggestions.

First of all, consider the case where an attacker can see the SDP, but can't
modify it.  (Attackers who can modify SDP can perform all sorts of
interesting attacks, both on comedia and on RTP or UDP media types, of
course; a big part of session establishment security needs to be the
protection of SDP.)

I propose that the SDP messages carry the certificate fingerprints of the
certificates each side will present.  (Certificate fingerprints -- MD5 or
SHA-1 hashes of a public key -- are a well-known concept, presented by,
among other things, web browsers' certificate managers and the "openssl x509
-fingerprint" command.)  This will be a new media-level attribute,
a=cert-fingerprint.  TLS comedia connections will always request client
certificates as well as server certificates, so both sides mutually
authenticate, and they'll tear down the TLS connections if the fingerprints
don't match.

Assuming that the integrity of SDP is indeed secure, this is entirely
sufficient to prevent man-in-the-middle attacks on comedia, even if both
sides are using self-signed keys.  (It also provides connection association,
corrolating TLS streams to SDP descriptions, for free.)

Of course, you can't always be sure of the integrity of SDP -- even if
you're using, e.g., sips for every SIP hop, a proxy server might be
compromised.  Therefore, endpoints should also provide CA-signed keys "if
available", or else certificates which are verifiable through a mechanism
such as the one Cullen Jennings describes in draft-jennings-sipping-certs.
I'm still somewhat uncertain what the certificate subject should be
specified as being in these cases, though; it's probably protocol-dependent,
and what makes sense for SIP doesn't make sense for RTSP or SAP.

Do people have thoughts on all of this?  Does it seem sensible, or is there
anything I've overlooked or need to explain more closely?

I'm willing to write some text for the comedia draft specifying all of this,
if people are interested.

-- 
Jonathan Lennox
[email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "John Lazzaro" <[email-masked]>
Date: Fri, 20 Feb 2004 11:26:00 -0800

> David Yon <yon.ietf at rfdsoftware.com> writes:
>
> Given the length of time comedia has remained in limbo, and my limited  
> availability to maintain it, I would favor a split as well. There are  
> potentially a lot of issues raised by fleshing out TLS to include  
> certificate validation information within SDP that have nothing to do  
> with basic TCP.
>
> The only question I would have is whether I should pull all mention of  
> TLS from the original comedia.

I'm viewing the issue from the perspective of using
the RTP over TCP framing defined in the contrans I-D:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-framing- 
contrans-00.txt

to make RTP MIDI sessions that split a MIDI cable over a
UDP RTP stream (for real-time commands) and a TCP RTP
stream (for bulk-data commands).  Any application that
does this, and that needs security, needs it for both the
UDP and TCP RTP MIDI streams -- thus, the simplest
mechanism is to use SRTP for both the UDP and TCP
flows, not to use SRTP for the UDP flow and TLS for the
reliable flow.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

---

From: David Yon <[email-masked]>
Date: Thu, 26 Feb 2004 11:52:00 -0500

Sounds good.  Comedia-tls is all yours. :-)

At 07:10 PM 2/25/2004, you wrote:
>On Friday, February 20 2004, "David Yon" wrote to "[email-masked]" saying:
>
> > certificate validation information within SDP that have nothing to do with
> > basic TCP.
>
>I'm fine with a split as well.  I'm also willing to be an author or
>co-author of the comedia TLS draft.
>
> > The only question I would have is whether I should pull all mention of TLS
> > from the original comedia.
>
>I'd say pull any normative mentions, but informative mentions would be okay
>(E.g., some text like "this framework could also be used for other
>connection-oriented protocols, such as SCTP or TLS; however, this
>specification does not define protocol identifiers for these protocols.")
>
>--
>Jonathan Lennox
>lennox at cs dot columbia dot edu