[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Media over DTLS
Eric,
I have a lot of comments and questions about your work, please see
below.
Hi,
AVT working group members may be interested in the following suite
of drafts, which define a method for securing multimedia (especially)
RTP traffic using DTLS:
http://www.ietf.org/internet-drafts/draft-fischl-sipping-media-
dtls-00.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-avt-rtp-
dtls-00.txt
http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-
dtls-00.txt
http://www.ietf.org/internet-drafts/draft-modadugu-dtls-short-00.txt
http://www.ietf.org/internet-drafts/draft-rescorla-tls-partial-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.txt
Why is this interesting? SIP does not have a scheme for key
negotiation
of media encryption that works with early media and forking.
That's not really true. SDP security descriptions with SDP security
preconditions solves these problems, but at the cost of an extra
round trip in the signaling plane. As it has become evident that the
preconditions approach isn't desirable, and number of other methods
have been proposed. See for example draft-mcgrew-srtp-ekt-00.txt
This set of
drafts addresses these issues. Instead of inventing a new key
negotiation protocol,
There's a lot of new text that you're referencing - wouldn't you
consider DTLS in "SRTP Compatibility Mode" the equivalent of a new
protocol?
it uses DTLS for key establishment and algorithm
negotiation while having the same on-the-wire packet format as SRTP.
But unfortunately the format compatibility doesn't give us any
interoperability with SRTP; please see comment number 12 below.
HTML versions can be found at:
http://scm.sipfoundry.org/rep/ietf-drafts/ekr/{draft}.html
The draft of most interest to this WG is probably
draft-tschofenig-avt-rtp-dtls-00 but you may find it helpful to read
draft-fischl-sipping-media-dtls-00 first for background.
-Ekr
I've itemized my points below for convenience in discussion.
Best regards,
David
--
1. SRTP works in group scenarios (both multi-unicast and multicast),
while RTP over DTLS only addresses point to point scenarios.
2. RTP over DTLS does not provide all of the security policy options
that SRTP allows. For example, an SRTCP sender can selectively
choose which SRTCP packets to encrypt, and SRTP can allow short
authentication tags on conversational voice media, but long
authentication tags on other data within the same session
(e.g. DTMF digits).
3. RTP-over-DTLS appears not to work with Symmetric RTP [6]. That
RTP method is commonly used in order to allow RTP sessions to
traverse NAT and firewall devices. This facility relies on the
fact that the media source behind the NAT sends data that triggers
a NAT translation that allows inbound media. If the initiator of
the DTLS handshake is outside of the NAT or firewall, then
RTP-over-DTLS will fail.
4. The partial encryption extension [2] does not properly handle RTP
header extensions. That extension negotiates some number of
initial bytes that will be unencrypted in each packet. However,
it is desirable to leave the RTP header extension unencrypted
whenever it is present (not encrypting the header is the first
goal named for "SRTP Compatibility Mode"), and this facility does
not allow that. It would require the RTP application to choose in
advance to use or not use an RTP header extension with some fixed
length established prior to the start of the session.
A security protocol for RTP should not constrain which RTP
applications can be supported, but items 1,2,3 and 4 put
significant constraints on the applications. SRTP is flexible
enough to have been adopted for use with many diverse RTP
applications, both inside and outside of the IETF; see
http://srtp.sourceforge.net/spec.html#Uses for example.
RTP-over-DTLS lacks the ability to work with many of these
applications.
5. In Appendix A.3 of [3]. An "SRTP MKI" field is included in the
DTLS packet. Is this intentional? If so, where is this
field defined?
6. RTP over DTLS appears to rely on the DTLS "content type" field
being distinct from the initial bits of the RTP header. Is this
right?
7. The RTP over DTLS spec [3] says that "DTLS uses a 10 byte MAC and
SRTP uses a 4 byte MAC". This is misleading; a ten-byte MAC is
defined in the SRTP standard, and is the default and recommended
value for the protocol, though a four-byte MAC has been defined
and used elsewhere for use in the VoIP context.
8. The RTP over DTLS "SRTP Compatibility Mode" requires a large
number of extensions to DTLS (which itself is a significant
extension to TLS):
The TLS partial encryption extension, with an InitialPlaintext
value equal to the length of the RTP header [2],
The DTLS implicit application data header [1],
The TLS MAC truncation extension [4],
The Counter Mode cipher [5]
It is not clear whether or not the other extensions defined in [1]
- sequence_number_length, no_version_field, no_length_field - are
also required, or perhaps are implicitly required by the other
extensions. The number and complexity of these options show that
the claim "because RTP/DTLS runs over DTLS, which is based on TLS,
which has seen extensive security analysis, we can have fairly
high confidence in the security of the system" (Section 7 of [3])
is misleading.
9. TLS does decryption before a MAC check. When combined with
partial decryption, this may be a potential security problem - at
the very least, some analysis would need to be published showing
that it is not. One point that needs to be considered is that a
receiver that performs multiple guesses, each followed by an
authentication check, is weakening the authentication in doing so.
In SRTP, we very consciously did not recommend this method.
[1] now says that "The "implicit_header" extension introduces some
ambiguity in record receipt processing. This ambiguity can,
however, be resolved by trial decryption." Shouldn't this state
that the message authentication check is used to resolve the
ambiguity, rather than an encryption? Or is there some
redundancy check on the decrypted material, and if so, what
is that check?
10. Does RTP/DTLS work with RTP Forward Error Correction [7], and if
so, how? Is it capable of working with FEC with either order
of processing?
11. The performance of RTP/DTLS will lag behind that of the SRTP
alternatives. It will require two TLS handshakes - one for RTP,
and one for RTCP - and at least one full handshake's worth of
certificate validation as well as a public key
encryption/decryption or a public key exchange. Another
performance demerit is the fact that, because decryption precedes
an authentication check, trial decryption must be done in
RTP-over-DTLS, unlike SRTP. Also, self-signed certificates
introduce costly additional and superfluous public key
operations.
12. The "SRTP Compatibility Mode" of [3] is not really compatible with
SRTP - it does not interoperate with SRTP in any way. Wouldn't it
be preferable if it was compatible in an interoperable way?
The advantage of RTP-over-DTLS is that it re-uses the TLS
handshake, thus providing a built-in key management method. The
way to achieve this advantage while retaining SRTP's advantages is
to define a way to use that handshake to provide keying material
to a media-protection method that is actually compatible with
SRTP. This way, the advantages of the DTLS handshake could be
used in scenarios in which it is useful, while other keying
methods could be used in other scenarios, with only a single
implementation of a media-security layer. This interface
is already defined for SRTP in Section 8.2. of RFC 3711.
This SRTP-interoperable method is better suited to constrained
environments where SRTP is much easier to support because of its
smaller code size. It also would enable significant code re-use,
especially for all of the devices that already implement SRTP.
There are many ways that a DTLS handshake could be used
to establish SRTP keys. One simple method that is obviously
secure is to pass SRTP keying material over a DTLS connection
that has been established for that purpose. The following
text expresses the SRTP key management interface in terms
of the TLS presentation layer:
enum { null_cipher, aes_128_icm, aes_128_f8 } srtp_cipher_type;
enum { null_auth, hmac_sha1_80 } srtp_auth_type;
enum { aes_cm } srtp_kdf_type;
struct {
uint32 ssrc;
srtp_cipher_type cipher_type;
srtp_auth_type auth_type;
srtp_kdf_type kdf_type;
uint8 cipher_key_size;
uint8 auth_key_size;
uint8 cipher_salt_size;
opaque cipher_key[32];
opaque cipher_salt[32];
opaque auth_key[32];
} srtp_parameters;
What disadvantage would an SRTP-interoperable method have
relative to RTP-over-DTLS?
References
[1] Modadugu, N. and E. Rescorla, "Extensions for DTLS in Low
Bandwidth Environments", draft-modadugu-dtls-short-00 (work in
progress), October 2005.
[2] Rescorla, E., "TLS Partial Encryption Mode",
draft-rescorla-tls-partial-00 (work in progress), January 2006.
[3] Tschofenig, H., Rescorla, E., "Real-Time Transport Protocol
(RTP) over Datagram Transport Layer Security (DTLS)", February
25, 2006
[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Wright, T., Transport Layer Security (TLS) Extensions, RFC
2246.
[5] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher Suites
for TLS and DTLS", draft-modadugu-tls-ctr-00 (work in
progress), October 2005.
[6] Wing, D., Common Local Transmit and Receive Ports (Symmetric
RTP) draft-wing-behave-symmetric-rtprtcp-01
[7] J. Rosenberg, H. Schulzrinne, An RTP Payload Format for Generic
Forward Error Correction, RFC 2733.
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt