AVT Working Group D. Wing
Internet-Draft Cisco Systems
Intended status: Standards Track November 11, 2007
Expires: May 14, 2008
Datagram TLS Secure RTP (DTLS-SRTP) Key Transport
draft-wing-avt-dtls-srtp-key-transport-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The existing DTLS-SRTP specification allows SRTP keys to be
established between a pair of SRTP endpoints. However, when there
are more than two participants in an RTP session, DTLS-SRTP is unable
to provide a single key for all of the participants.
This document describes an extension to DTLS-SRTP which transports
SRTP keying material from one DTLS-SRTP peer to another, so the same
SRTP keying material can be used by multiple DTLS-SRTP peers. This
Wing Expires May 14, 2008 [Page 1]
Internet-Draft DTLS-SRTP Key Transport November 2007
reduces or eliminates the need to key each SRTP session individually.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Point to Multipoint using the RFC 3550 mixer model . . . . 3
3.2. Point to Multipoint using video switching MCU . . . . . . 4
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6
4.1. key_transport extension . . . . . . . . . . . . . . . . . 6
4.2. SRTP Key Transport Protocol . . . . . . . . . . . . . . . 7
4.3. Key Transport SSRC and RTP SSRC Collisions . . . . . . . . 10
4.4. Fragmentation, Reassembly, and Retransmission . . . . . . 11
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informational References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Wing Expires May 14, 2008 [Page 2]
Internet-Draft DTLS-SRTP Key Transport November 2007
1. Introduction
Unique SRTP master keys can be established, in each direction, using
DTLS-SRTP [I-D.ietf-avt-dtls-srtp]. Using DTLS, each peer
contributes part of the keying material to generate the eventual SRTP
master key.
In some scenarios after the DTLS handshake has completed, it is
desirable for one peer to change its SRTP key and to transmit SRTP
packets using an SRTP key that was not derived from the DTLS key
exchange. These scenarios are described in Section 3.
The extensions described in this document allow transporting an SRTP
master key from one DTLS peer to the other. Thus, DTLS Key Transport
differs from from normal DTLS-SRTP in that the SRTP master key is not
derived from the TLS handshake.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Scenarios
DTLS Key Transport allows mixers and video switchers to avoid having
to encrypt each packet multiple times under multiple SRTP keys. DTLS
Key Transport causes sharing of SRTP keys. When sharing SRTP keys
with several listeners, it is imperative that the SRTP is changed
when a new listener is added or a listener is removed. This is
because a legitimate listener should only be able to decrypt the SRTP
stream while he is listening; he should not be able to decrypt the
SRTP stream prior to joining the conference or after leaving the
conference. The needs for audio mixing and video switching are
different, and are described below.
3.1. Point to Multipoint using the RFC 3550 mixer model
In [I-D.ietf-avt-topologies], this RTP topology is called 'Topo-
Mixer'. A common application of an RTP mixer is to receive one (or
more) streams from speakers, each individually keyed. The mixer will
then do something intelligent with those streams (e.g., select the
loudest one), and sends that stream to all of the listeners. Using
DTLS-SRTP, without key transport, it is computationally expensive for
the mixer to encrypt the payload uniquely for each SRTP listener.
The architecture of a typical mixer requires each listener's SRTP to
Wing Expires May 14, 2008 [Page 3]
Internet-Draft DTLS-SRTP Key Transport November 2007
be encrypted serially, incurring additional delay for each successive
listener. This is depicted below in Figure 1.
+-------+ +------------+
+---------+ | +--key=C->+ listener 1 |
| speaker +--key=A-->+ | +------------+
+---------+ | | +------------+
| mixer +--key=D->+ listener 2 |
+---------+ | | +------------+
| speaker +--key=B-->+ | +------------+
+---------+ | +--key=E->+ listener 3 |
+-------+ +------------+
Figure 1: Point to Multipoint Mixer, without DTLS Key Transport
With DTLS Key Transport, the mixer can maintain one outbound SRTP
cryptographic context, and encrypt the SRTP once for all listeners.
This is depicted below in Figure 2.
+-------+ +------------+
+---------+ | +--key=C->+ listener 1 |
| speaker +--key=A-->+ | +------------+
+---------+ | | +------------+
| mixer +--key=C->+ listener 2 |
+---------+ | | +------------+
| speaker +--key=B-->+ | +------------+
+---------+ | +--key=C->+ listener 3 |
+-------+ +------------+
Figure 2: Point to Multipoint Mixer, with DTLS Key Transport
The mixer is aware of listeners leaving or joining, and can rekey the
remaining active listeners by the mixer sending them a DTLS
"new_srtp_key" message Section 4.
3.2. Point to Multipoint using video switching MCU
In [I-D.ietf-avt-topologies], this RTP topology is called 'Topo-
Video-switch-MCU'. Video switching works differently than audio
mixing. In video switching a simple decision is made: which video
stream to send to the listeners. As with audio mixing shown above,
DTLS-SRTP without key transport is computationally expensive for the
video switcher to encrypt the payload uniquely for each SRTP
listener. The architecture of a typical video switcher requires each
listener's SRTP to be encrypted serially, incurring additional delay
for each successive listener. This is depicted below in Figure 3.
Wing Expires May 14, 2008 [Page 4]
Internet-Draft DTLS-SRTP Key Transport November 2007
+--------- + +------------+
+---------+ | +--key=C->+ listener 1 |
| speaker +--key=A-->+selected | +------------+
+---------+ | | +------------+
| switcher +--key=D->+ listener 2 |
+---------+ | | +------------+
| speaker +--key=B-->+dropped | +------------+
+---------+ | +--key=E->+ listener 3 |
+----------+ +------------+
Figure 3: Point to Multipoint Video Switching, without DTLS Key
Transport
With DTLS key transport, this becomes easier; in fact, the video
switcher doesn't need to decrypt the SRTP at all, but just make its
decision (select the stream or drop the stream) and transmit the SRTP
packets to the listeners. This is depicted below in Figure 4.
+----------+ +------------+
+---------+ | +==key=A=>+ listener 1 |
| speaker +==key=A==>+selected | +------------+
+---------+ | | +------------+
| switcher +==key=A=>+ listener 2 |
+---------+ | | +------------+
| speaker +==key=B==>+dropped | +------------+
+---------+ | +==key=A=>+ listener 3 |
+----------+ +------------+
Figure 4: Point to Multipoint Video Switching, with DTLS Key
Transport
The video switcher is aware of listeners leaving or joining. When
such a change occurs, the video switcher SHOULD request the
speaker(s) change their respective SRTP keys. This is done by the
video switcher sending a DTLS "new_srtp_key_request" message. The
speaker will respond with a DTLS "new_srtp_key" message, which will
be relayed, by the switcher, to each of the active listeners.
Failing to change the key when a listener joins (or leaves) allows a
listener to decrypt SRTP traffic prior to (or after) they are
authorized participants in the conference.
Discussion point: additionally, do we want to recommend the video
switcher also SRTP traffic until the key is changed? Some
security policies would reasonably require that, but other
security policies would not require that.
When there are multiple speakers, as shown in Figure 4 above, each
speaker transmits with his own SRTP key. That SRTP key is derived
Wing Expires May 14, 2008 [Page 5]
Internet-Draft DTLS-SRTP Key Transport November 2007
from the DTLS handshake with the switcher. Each speaker uses DTLS-
SRTP Key Transport to signal the SSRC that it will use.
4. Protocol Description
This section describes the extension to the DTLS protocol for DTLS-
SRTP key transport, which allows securely communicating the SRTP key
to the DTLS peer.
4.1. key_transport extension
This document adds a new negotiated extension called "key_transport",
which MUST only be requested in conjunction with the "use_srtp"
extension (Section 3.2 of [I-D.ietf-avt-dtls-srtp]). The DTLS server
indicates its support for key_transport by including key_transport in
its ServerHello message. If a DTLS client includes key_transport in
its ClientHello, but does not receive key_transport in the
ServerHello, the DTLS client MUST NOT send DTLS packets with the
srtp_key_transport content-type.
Support for the DTLS Key Transport extension is indicated in SDP with
the "srtp-kt" attribute. Advertising support for the extension is
necessary in SDP because in some cases it is required to establish an
SRTP call. For example, a mixer may be able to only support SRTP
listeners if those listeners implement DTLS Key Transport (because it
lacks the CPU cycles necessary to encrypt SRTP uniquely for each
listener).
Wing Expires May 14, 2008 [Page 6]
Internet-Draft DTLS-SRTP Key Transport November 2007
A message flow showing a DTLS client and DTLS server using the
key_transport extension
Client Server
ClientHello + use_srtp + key_transport
-------->
ServerHello + use_srtp + key_transport
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SRTP packets <-------> SRTP packets
Figure 5: Hangshake Message Flow
After successful negotiation of the key_transport extension, the DTLS
client and server MAY exchange SRTP packets, encrypted using the KDF
described in [I-D.ietf-avt-dtls-srtp]. This is normal and expected,
even if Key Transport was negotiated by both sides, as neither side
may (yet) have a need to alter the SRTP key. However, it is also
possible that one (or both) peers will immediately send a
new_srtp_key message before sending any SRTP.
4.2. SRTP Key Transport Protocol
A new protocol is defined, called the srtp_key_transport protocol
which uses srtp_key_transport content-type which consists of the
following message types:
new_srtp_key_request: request that the DTLS peer choose a new key.
Valid responses are new_srtp_key and new_srtp_key_error.
new_srtp_key: contains the new SRTP keying material. This message
is sent by a DTLS endpoint that wants to change its SRTP key.
This does not change any cryptographic parameters (a new DTLS
handshake is necessary for that), but only the DTLS key for the
associated SRTP session. This message includes the SSRC that will
be used for this key, which allows listeners to establish one SRTP
crypto-context per speaker (necessary for the video switching
scenario). The key chosen MUST be cryptographically random
Wing Expires May 14, 2008 [Page 7]
Internet-Draft DTLS-SRTP Key Transport November 2007
[RFC4086].
new_key_activate: indicates receiver is prepared to receive SRTP
packets encrypted with the new key.
new_srtp_key_failure: indicates a failure.
At any time, the DTLS client or DTLS server MAY send a key_transport
message, as shown in Figure 6. The sender of the new_srtp_key
message MAY immediately start transmitting SRTP packets with this new
key. However, to account for loss of the new_srtp_key message it is
RECOMMENDED that the sender wait before changing to the new SRTP key
until it receives the new_key_activate message or it times out
waiting for the new_key_activate_message. The duration of this
timeout may vary depending on the sensitivity of the content (e.g., 1
second or 10 seconds). In any case, the new_srtp_key message is
retransmitted until acknowledged by receipt of a new_key_activate
message.
Client / Server Server / Client
[new_srtp_key_request] -------->
<-------- new_srtp_key
new_srtp_key_activiate -------->
Figure 6: New Key Message Flow
The following figure shows the state machine for the protocol.
Wing Expires May 14, 2008 [Page 8]
Internet-Draft DTLS-SRTP Key Transport November 2007
receive new_srtp_key_request from peer
or decide to choose new SRTP key
|
|
send V
new_srtp_key +---------------+ timeout
+---------| Communicate |--------+
| | Key | |
+-------->| | |
+---------------+ |
| ^ |
receive | | +----------------+
new_key_activate| +---| send SRTP using|
| | new SRTP key |
+----------------+ +----------------+
| send SRTP using|
| new SRTP key |
+----------------+
|
V
done
Figure 7: Key Transport protocol state machine
Wing Expires May 14, 2008 [Page 9]
Internet-Draft DTLS-SRTP Key Transport November 2007
Using the syntax described in TLS [RFC4346], the following structures
are used:
enum {
new_srtp_key_request(0),
new_srtp_key(1),
new_srtp_key_activate(2),
new_srtp_key_failure(128),
(255)
} SRTPKeyTransportType;
struct {
SRTPKeyTransportType keytrans_type;
uint24 length;
uint16 message_seq;
uint24 fragment_offset;
uint24 fragment_length;
select (SRTPKeyTransportType) {
case new_srtp_key_request: NewSRTPKeyRequest;
case new_srtp_key: NewSRTPKey;
case new_srtp_key_activate: NewSRTPKeyActivate;
case new_srtp_key_failure: NewSRTPKeyFailure;
};
} KeyTransport;
struct {
uint random<64>; // additional entropy for peer
} NewSRTPKeyRequest;
struct {
uint32 ssrc; // SSRC used for this keys
uint key<16..32>; // The last change_cipher_spec
uint auth_tag<4..10> // decides the length of key
// and auth_tag
uint random<64>; // additional entropy for peer
} NewSRTPKey;
struct {
uint random<64>; // additional entropy for peer
} NewSRTPKeyActivate;
struct { } NewSRTPKeyFailure;
4.3. Key Transport SSRC and RTP SSRC Collisions
Per [RFC3550], if an RTP source notices an RTP SSRC collision, it is
required to change its SSRC. If it has negotiated support for DTLS-
SRTP Key Transport, it then MUST also send a new_srtp_key message
Wing Expires May 14, 2008 [Page 10]
Internet-Draft DTLS-SRTP Key Transport November 2007
indicating the new SSRC. As part of this procedure, it does not need
to also change its SRTP key.
The communication of the SSRC used for each key is necessary if there
are multiple speakers in the video switching scenario. However,
because a speaker is not able to determine if their audio or their
video is being switched, a speaker MUST always adhere indicate a
change in SSRC by following the procedure in this section for any
SRTP stream (audio, video, or other).
4.4. Fragmentation, Reassembly, and Retransmission
Much like the DTLS handshake itself, this extension also needs to
handle fragmentation and reassembly (to send a large key) and
retransmission (to account for packet loss). Using the same
technique as DTLS's handshake, the message_seq, fragment_offset,
fragment_length are used.
When transmitting the key transport message, the sender divides the
message into a series of N contiguous data ranges. These ranges MUST
NOT be larger than the maximum handshake fragment size and MUST
jointly contain the entire key transport message. The ranges SHOULD
NOT overlap. The sender then creates N key transport messages, all
with the same message_seq value as the original key transport
message. Each new message is labelled with the fragment_offset (the
number of bytes contained in previous fragments) and the
fragment_length (the length of this fragment). The length field in
all messages is the same as the length field of the original message.
An unfragmented message is a degenerate case with fragment_offset=0
and fragment_length=length.
When a DTLS implementation receives a key transport message fragment,
it MUST buffer it until it has the entire key transport message.
DTLS implementations MUST be able to handle overlapping fragment
ranges. This allows senders to retransmit key transport messages
with smaller fragment sizes during path MTU discovery.
5. Examples
In some scenarios, a device cannot successfully establish an SRTP
session without DTLS-SRTP Key Transport. The following two examples
show
Wing Expires May 14, 2008 [Page 11]
Internet-Draft DTLS-SRTP Key Transport November 2007
Using the SDP syntax described in
[I-D.ietf-mmusic-sdp-capability-negotiation], the following figure
shows an offerer that requires DTLS Key Transport in order to set up
this call as an SRTP call, otherwise it can set up this call as an
RTP call. This is indicated by the ",2" on the "a=pcfg" line. If
the answerer does not understand "a=dtls-srtp" but does understand
DTLS-SRTP and [I-D.ietf-mmusic-sdp-capability-negotiation], this can
cannot be established using DTLS-SRTP; however, it can be established
using RTP.
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP
a=acap:1 SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=acap:2 dtls-srtp
a=pcfg:1 t=1 a=1,2
Figure 9: Example SDP offer showing Key Transport is required
Using the SDP syntax described in
[I-D.ietf-mmusic-sdp-capability-negotiation], the following figure
shows an offerer that indicates support for DTLS Key Transport but
does not require DTLS Key Transport in order to set up this call as
an SRTP call. This is indicated by the ",[2]" on the "a=pcfg" line.
If the answerer does not understand "a=dtls-srtp" but does understand
DTLS-SRTP and [I-D.ietf-mmusic-sdp-capability-negotiation], this call
can still be established using DTLS-SRTP.
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP
a=acap:1 SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=acap:2 dtls-srtp
a=pcfg:1 t=1 a=1,[2]
Figure 10: Example SDP offer showing Key Transport is optional
Wing Expires May 14, 2008 [Page 12]
Internet-Draft DTLS-SRTP Key Transport November 2007
6. Security Considerations
In the point-to-multipoint scenario, Section 3.1, all of the
listeners know the key being used by the mixer. Any of those
listeners could create SRTP packets that are encrypted with this same
key, and send those SRTP packets to other listeners. In order to
reduce the vulnerability to this threat, it is RECOMMENDED that the
source transport address of received SRTP packets be discarded if
they do not match the source transport address of the associated
DTLS-SRTP session. Additionally, the network SHOULD prevent IP
address spoofing [RFC2827].
In the
7. Acknowledgements
Thanks to David McGrew for his improvements to this document and to
the underlying protocol.
8. IANA Considerations
Register new SDP attribute "dtls-kt", new TLS content-type
"key_transport" (26?).
9. References
9.1. Normative References
[I-D.ietf-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-00 (work in progress), July 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Wing Expires May 14, 2008 [Page 13]
Internet-Draft DTLS-SRTP Key Transport November 2007
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-07 (work in
progress), October 2007.
9.2. Informational References
[I-D.ietf-avt-topologies]
Westerlund, M. and S. Wenger, "RTP Topologies",
draft-ietf-avt-topologies-07 (work in progress),
October 2007.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
Author's Address
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Wing Expires May 14, 2008 [Page 14]
Internet-Draft DTLS-SRTP Key Transport November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wing Expires May 14, 2008 [Page 15]