< draft-wing-rtpsec-keying-eval-01.txt   draft-wing-rtpsec-keying-eval-02.txt >
Network Working Group F. Audet Network Working Group F. Audet
Internet-Draft Nortel Internet-Draft Nortel
Expires: December 24, 2006 D. Wing Intended status: Informational D. Wing
Cisco Systems Expires: August 3, 2007 Cisco Systems
June 22, 2006 January 30, 2007
Evaluation of SRTP Keying with SIP Evaluation of SRTP Keying with SIP
draft-wing-rtpsec-keying-eval-01 draft-wing-rtpsec-keying-eval-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 24, 2006. This Internet-Draft will expire on August 3, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Over a dozen incompatible mechanisms have been defined to key an Over a dozen incompatible mechanisms have been defined to key an
Secure RTP (SRTP) media stream. This document evaluates the keying Secure RTP (SRTP) media stream. This document evaluates the keying
mechanisms, concentrating on their interaction with SIP features and mechanisms, concentrating on their interaction with SIP features and
their security properties. their security properties.
This document is discussed on the rtpsec mailing list, This document is discussed on the rtpsec mailing list,
<http://www.imc.org/ietf-rtpsec>. <http://www.imc.org/ietf-rtpsec>.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
3.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 5 3.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 5
3.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 6
3.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 6 3.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 6
3.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 6 3.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 6
3.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 7 3.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 7
3.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 7 3.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 7
3.1.8. Security Descriptions with SIPS . . . . . . . . . . . 7 3.1.8. Security Descriptions with SIPS . . . . . . . . . . . 7
3.1.9. Security Descriptions with S/MIME . . . . . . . . . . 7 3.1.9. Security Descriptions with S/MIME . . . . . . . . . . 7
3.1.10. SDP-DH . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.10. SDP-DH . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.11. MIKEYv2 in SDP . . . . . . . . . . . . . . . . . . . . 8 3.1.11. MIKEYv2 in SDP . . . . . . . . . . . . . . . . . . . . 8
3.2. Media Path Keying Technique . . . . . . . . . . . . . . . 8 3.2. Media Path Keying Technique . . . . . . . . . . . . . . . 8
3.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Signaling and Media Path Keying Techniques . . . . . . . . 8 3.3. Signaling and Media Path Keying Techniques . . . . . . . . 9
3.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. RTP-DTLS . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 9 3.3.3. MIKEYv2 Inband . . . . . . . . . . . . . . . . . . . . 9
3.3.4. MIKEYv2 Inband . . . . . . . . . . . . . . . . . . . . 10
4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . . . 10 4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . . . 10
4.1. Secure Retargeting and Secure Forking . . . . . . . . . . 10 4.1. Secure Retargeting and Secure Forking . . . . . . . . . . 10
4.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 15 4.2. Clipping Media Before SDP Answer . . . . . . . . . . . . . 15
4.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 17 4.3. Centralized Keying . . . . . . . . . . . . . . . . . . . . 17
4.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 20 4.4. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . . . 20
5. Evaluation Criteria - Security . . . . . . . . . . . . . . . . 22 5. Evaluation Criteria - Security . . . . . . . . . . . . . . . . 22
5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 22 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 22
5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 24 5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 24
5.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 26 5.3. Best Effort Encryption . . . . . . . . . . . . . . . . . . 25
5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 28 5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informational References . . . . . . . . . . . . . . . . . 31 9.2. Informational References . . . . . . . . . . . . . . . . . 30
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 33
A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 34 A.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 A.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
SIP needs to operate across the world-wide public Internet and thus SIP needs to operate across the world-wide public Internet and thus
needs a single, mandatory-to-implement mechanism for strongly needs a single, mandatory-to-implement mechanism for strongly
authenticating an endpoint. It is likely that the mechanism will be authenticating an endpoint. It is likely that the mechanism will be
based on RSA, Diffie-Hellman, or Digital Signature Standard (DSS) but based on RSA, Diffie-Hellman, or Digital Signature Standard (DSS) but
cannot rely on an X.509 PKI or pre-shared keys. cannot rely on an X.509 PKI or pre-shared keys.
There are currently 13 mechanisms defined or under consideration by There are currently 13 mechanisms defined or under consideration by
skipping to change at page 3, line 24 skipping to change at page 3, line 24
the IETF to establish SRTP [RFC3711] keys between endpoints. the IETF to establish SRTP [RFC3711] keys between endpoints.
Although an endpoint can implement several mechanisms, these 13 Although an endpoint can implement several mechanisms, these 13
mechanisms are not interoperable with each other. The mechanisms can mechanisms are not interoperable with each other. The mechanisms can
be broken into three general categories for exchanging SRTP keying: be broken into three general categories for exchanging SRTP keying:
exchanging keys in signaling, media, or both. exchanging keys in signaling, media, or both.
The goals of an SRTP key exchange mechanism are, in rough order: The goals of an SRTP key exchange mechanism are, in rough order:
1. Ability to deploy the mechanism across administrative boundaries, 1. Ability to deploy the mechanism across administrative boundaries,
such as on the Internet, such as on the Internet,
2. Cryptographically authenticate the endpoints, 2. Cryptographically authenticate the endpoints,
3. Securely exchange SRTP keys, 3. Securely exchange SRTP keys,
4. Support SIP features such as retargeting and forking. 4. Support SIP features such as retargeting and forking.
Existing key exchange mechanisms fail to meet all of these Existing key exchange mechanisms fail to meet all of these
requirements. requirements.
Two mechanisms, MIKEY and Security Descriptions, have been Two mechanisms, MIKEY and Security Descriptions, have been
standardized for SRTP key exchange. Both of these mechanisms perform standardized for SRTP key exchange. Both of these mechanisms perform
key exchange in the signaling path (SIP or RTSP). key exchange in the signaling path (SIP or RTSP).
All MIKEY modes share a common syntax (a=key-mgmt, defined in Key All MIKEY modes share a common syntax (a=key-mgmt, defined in Key
Management Extensions for Session Description Protocol (SDP) and Real Management Extensions for Session Description Protocol (SDP) and Real
Time Streaming Protocol (RTSP) [I-D.ietf-mmusic-kmgmt-ext]). The Time Streaming Protocol (RTSP) [RFC4567]). The base MIKEY
base MIKEY specification [RFC3830] defines four MIKEY modes and specification [RFC3830] defines four MIKEY modes and additional modes
additional modes are defined in other specifications. MIKEY modes are defined in other specifications. MIKEY modes are not compatible
are not compatible with each other. with each other.
The other standard mechanism, Security Descriptions, uses a different The other standard mechanism, Security Descriptions, uses a different
syntax (a=crypto, defined in Security Descriptions [I-D.ietf-mmusic- syntax (a=crypto, defined in Security Descriptions [RFC4568]).
sdescriptions]).
Several extensions to MIKEY have been proposed and several techniques Several extensions to MIKEY have been proposed and several techniques
which perform some, or all, keying in the media path have been which perform some, or all, keying in the media path have been
proposed. These new techniques are also discussed in this document. proposed. These new techniques are also discussed in this document.
Out of scope of this document is how SIP, RTSP, and SDP messages Out of scope of this document is how SIP, RTSP, and SDP messages
themselves are encrypted. themselves are encrypted.
Call signaling (new call, end of call, call transfer, etc.) is done Call signaling (new call, end of call, call transfer, etc.) is done
in SIP, and media is sent in RTP. In the following diagram, Alice is in SIP, and media is sent in RTP. In the following diagram, Alice is
skipping to change at page 4, line 22 skipping to change at page 4, line 23
| Alice's +------------------>+ Bob's | | Alice's +------------------>+ Bob's |
| proxy | | proxy | | proxy | | proxy |
+----+----+ +---+---| +----+----+ +---+---|
^ | ^ |
SIP Invite | | SIP Invite SIP Invite | | SIP Invite
| V | V
+---+---+ +-----+ +---+---+ +-----+
| Alice |<===================>+ Bob | | Alice |<===================>+ Bob |
+-------+ SRTP +-----+ +-------+ SRTP +-----+
Figure 1: Simplified SIP Model Figure 1: Simplified SIP Model
2. Terminology 2. Terminology
AOR (Address-of-Record): A SIP or SIPS URI that points to a domain AOR (Address-of-Record): A SIP or SIPS URI that points to a domain
with a location service that can map the URI to another URI where with a location service that can map the URI to another URI where
the user might be available. Typically, the location service is the user might be available. Typically, the location service is
populated through registrations. An AOR is frequently thought of populated through registrations. An AOR is frequently thought of
as the "public address" of the user. as the "public address" of the user.
SSRC: The 32-bit value that defines the synchronization source, SSRC: The 32-bit value that defines the synchronization source,
used in RTP. These are generally unique, but collisions can used in RTP. These are generally unique, but collisions can
occur. occur.
two-time pad: The use of the same key and the same key index to
two-time pad: The use of the same key and the same key index to
encrypt different data. For SRTP, a two-time pad occurs if two encrypt different data. For SRTP, a two-time pad occurs if two
senders are using the same key and the same RTP SSRC value. senders are using the same key and the same RTP SSRC value.
PKI Public Key Infrastructure. Throughout this paper, the term PKI
PKI Public Key Infrastructure. Throughout this paper, the term PKI
refers to a global PKI. refers to a global PKI.
3. Overview of Keying Mechanisms 3. Overview of Keying Mechanisms
Based on how the SRTP keys are exchanged, each SRTP key exchange Based on how the SRTP keys are exchanged, each SRTP key exchange
mechanism belongs to one general category: mechanism belongs to one general category:
signaling path: signaling path: All the keying is carried in the call signaling
All the keying is carried in the call signaling (SIP or SDP) (SIP or SDP) path.
path.
media path: media path: All the keying is carried in the SRTP/SRTCP media
All the keying is carried in the SRTP/SRTCP media path, and no path, and no signaling whatsoever is carried in the call
signaling whatsoever is carried in the call signaling path. signaling path.
signaling and media path:
Parts of the keying are carried in the SRTP/SRTCP media path, signaling and media path: Parts of the keying are carried in the
and parts are carried in the call signaling (SIP or SDP) path. SRTP/SRTCP media path, and parts are carried in the call
signaling (SIP or SDP) path.
One of the significant benefits of SRTP over other end-to-end One of the significant benefits of SRTP over other end-to-end
encryption mechanisms, such as for example IPsec, is that SRTP is encryption mechanisms, such as for example IPsec, is that SRTP is
bandwidth efficient and SRTP retains the header of RTP packets. bandwidth efficient and SRTP retains the header of RTP packets.
Bandwidth efficiency is vital for VoIP in many scenarios where access Bandwidth efficiency is vital for VoIP in many scenarios where access
bandwidth is limited or expensive, and retaining the RTP header is bandwidth is limited or expensive, and retaining the RTP header is
important for troubleshooting packet loss, delay, and jitter. important for troubleshooting packet loss, delay, and jitter.
Related to SRTP's characteristics is a goal that any SRTP keying Related to SRTP's characteristics is a goal that any SRTP keying
mechanism to also be efficient and not cause additional call setup mechanism to also be efficient and not cause additional call setup
skipping to change at page 6, line 28 skipping to change at page 6, line 31
directions using the intended answerer's public key, which is directions using the intended answerer's public key, which is
obtained from a PKI. obtained from a PKI.
MIKEY-RSA requires one message from offerer to answerer (half a round MIKEY-RSA requires one message from offerer to answerer (half a round
trip), and does not add additional media path messages. MIKEY-RSA trip), and does not add additional media path messages. MIKEY-RSA
requires the offerer to obtain the intended answerer's certificate. requires the offerer to obtain the intended answerer's certificate.
3.1.4. MIKEY-RSA-R 3.1.4. MIKEY-RSA-R
MIKEY-RSA-R An additional mode of key distribution in MIKEY: MIKEY- MIKEY-RSA-R An additional mode of key distribution in MIKEY: MIKEY-
RSA-R [I-D.ietf-msec-mikey-rsa-r] is essentially the same as MIKEY- RSA-R [RFC4738] is essentially the same as MIKEY-RSA but reverses the
RSA-R but reverses the role of the offerer and the answerer with role of the offerer and the answerer with regards to providing the
regards to providing the keys. That is, the answerer encrypts the keys. That is, the answerer encrypts the keys for both directions
keys for both directions using the offerer's public key. Both the using the offerer's public key. Both the offerer and answerer
offerer and answerer validate each other's public keys using a PKI. validate each other's public keys using a PKI. MIKEY-RSA-R also
MIKEY-RSA-R also enables sending certificates in the MIKEY message. enables sending certificates in the MIKEY message.
MIKEY-RSA-R requires one message from offerer to answer, and one MIKEY-RSA-R requires one message from offerer to answer, and one
message from answerer to offerer (full round trip), and does not add message from answerer to offerer (full round trip), and does not add
additional media path messages. MIKEY-RSA-R requires the offerer additional media path messages. MIKEY-RSA-R requires the offerer
validate the answerer's certificate. validate the answerer's certificate.
3.1.5. MIKEY-DHSIGN 3.1.5. MIKEY-DHSIGN
In MIKEY-DHSIGN [RFC3830] the offerer and answerer derive the key In MIKEY-DHSIGN [RFC3830] the offerer and answerer derive the key
from a Diffie-Hellman exchange. In order to prevent an active man- from a Diffie-Hellman exchange. In order to prevent an active man-
skipping to change at page 7, line 7 skipping to change at page 7, line 10
private key and the associated public keys are validated using a PKI. private key and the associated public keys are validated using a PKI.
MIKEY-DHSIGN requires one message from offerer to answerer, and one MIKEY-DHSIGN requires one message from offerer to answerer, and one
message from answerer to offerer (full round trip), and does not add message from answerer to offerer (full round trip), and does not add
additional media path messages. MIKEY-DHSIGN requires the offerer additional media path messages. MIKEY-DHSIGN requires the offerer
and answerer to validate each other's certificates. MIKEY-DHSIGN and answerer to validate each other's certificates. MIKEY-DHSIGN
also enables sending the answerer's certificate in the MIKEY message. also enables sending the answerer's certificate in the MIKEY message.
3.1.6. MIKEY-DHHMAC 3.1.6. MIKEY-DHHMAC
MIKEY-DHHMAC [I-D.ietf-msec-mikey-dhhmac] uses a pre-shared secret to MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie-
HMAC the Diffie-Hellman exchange, essentially combining aspects of Hellman exchange, essentially combining aspects of MIKEY-PSK with
MIKEY-PSK with MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for a MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for a PKI to
PKI to authenticate the Diffie-Hellman exchange. authenticate the Diffie-Hellman exchange.
MIKEY-DHHMAC requires one message from offerer to answerer, and one MIKEY-DHHMAC requires one message from offerer to answerer, and one
message from answerer to offerer (full round trip), and does not add message from answerer to offerer (full round trip), and does not add
additional media path messages. additional media path messages.
3.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) 3.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC)
ECC Algorithms For MIKEY [I-D.ietf-msec-mikey-ecc] describes how ECC ECC Algorithms For MIKEY [I-D.ietf-msec-mikey-ecc] describes how ECC
can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY- can be used with MIKEY-RSA (using ECDSA signature) and with MIKEY-
DHSIGN (using a new DH-Group code), and also defines two new ECC- DHSIGN (using a new DH-Group code), and also defines two new ECC-
based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES)
and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) . and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) .
For the purposes of this paper, the ECDSA signature, MIKEY-ECIES, and For the purposes of this paper, the ECDSA signature, MIKEY-ECIES, and
MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group
code function exactly like MIKEY-DHSIGN. Therefore these ECC code function exactly like MIKEY-DHSIGN. Therefore these ECC
mechanisms aren't discussed separately in this paper. mechanisms aren't discussed separately in this paper.
3.1.8. Security Descriptions with SIPS 3.1.8. Security Descriptions with SIPS
Security Descriptions [I-D.ietf-mmusic-sdescriptions] has each side Security Descriptions [RFC4568] has each side indicate the key it
indicate the key it will use for transmitting SRTP media, and the will use for transmitting SRTP media, and the keys are sent in the
keys are sent in the clear in SDP. Security Descriptions relies on clear in SDP. Security Descriptions relies on hop-by-hop (TLS via
hop-by-hop (TLS via "SIPS:") encryption to protect the keys exchanged "SIPS:") encryption to protect the keys exchanged in signaling.
in signaling.
Security Descriptions requires one message from offerer to answerer, Security Descriptions requires one message from offerer to answerer,
and one message from answerer to offerer (full round trip), and does and one message from answerer to offerer (full round trip), and does
not add additional media path messages. not add additional media path messages.
3.1.9. Security Descriptions with S/MIME 3.1.9. Security Descriptions with S/MIME
This keying mechanism is identical to Section 3.1.8, except that This keying mechanism is identical to Section 3.1.8, except that
rather than protecting the signaling with TLS, the entire SDP is rather than protecting the signaling with TLS, the entire SDP is
encrypted with S/MIME. encrypted with S/MIME.
3.1.10. SDP-DH 3.1.10. SDP-DH
SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie- SDP Diffie-Hellman [I-D.baugher-mmusic-sdp-dh] exchanges Diffie-
Hellman messages in the signaling path to establish session keys. To Hellman messages in the signaling path to establish session keys. To
protect against active man-in-the-middle attacks, the Diffie-Hellman protect against active man-in-the-middle attacks, the Diffie-Hellman
exchange needs to be protected with S/MIME, SIPS, or SIP-Identity exchange needs to be protected with S/MIME, SIPS, or SIP-Identity
[RFC4474] and [I-D.ietf-sip-connected-identity].
[I-D.ietf-sip-identity] and [I-D.ietf-sip-connected-identity].
SDP-DH requires one message from offerer to answerer, and one message SDP-DH requires one message from offerer to answerer, and one message
from answerer to offerer (full round trip), and does not add from answerer to offerer (full round trip), and does not add
additional media path messages. additional media path messages.
3.1.11. MIKEYv2 in SDP 3.1.11. MIKEYv2 in SDP
MIKEYv2 [I-D.dondeti-msec-rtpsec-mikeyv2] adds mode negotiation to MIKEYv2 [I-D.dondeti-msec-rtpsec-mikeyv2] adds mode negotiation to
MIKEYv1 and removes the time synchronization requirement. It MIKEYv1 and removes the time synchronization requirement. It
therefore now takes 2 round-trips to complete. In the first round therefore now takes 2 round-trips to complete. In the first round
trip, the communicating parties learn each other's identities, agree trip, the communicating parties learn each other's identities, agree
on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces on a MIKEY mode, crypto algorithm, SRTP policy, and exchanges nonces
for replay protection. In the second round trip, they negotiate for replay protection. In the second round trip, they negotiate
unicast and/or group SRTP context for SRTP and/or SRTCP. unicast and/or group SRTP context for SRTP and/or SRTCP.
Furthemore, MIKEYv2 also defines an in-band negotiation mode as an Furthemore, MIKEYv2 also defines an in-band negotiation mode as an
alternative to SDP (see Section 3.3.4). alternative to SDP (see Section 3.3.3).
3.2. Media Path Keying Technique 3.2. Media Path Keying Technique
3.2.1. ZRTP 3.2.1. ZRTP
ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the ZRTP [I-D.zimmermann-avt-zrtp] does not exchange information in the
signaling path (although it's possible for endpoints to do so if they signaling path (although it's possible for endpoints to indicate
desire). In ZRTP the keys are exchanged entirely in the media path. support for ZRTP with "a=zrtp" in the initial Offer). In ZRTP the
The advantage to this mechanism is that the signaling channel is used keys are exchanged entirely in the media path using a Diffie-Hellman
only for call setup and the media channel is used to establish an exchange. The advantage to this mechanism is that the signaling
encrypted channel -- much like encryption devices on the PSTN. ZRTP channel is used only for call setup and the media channel is used to
uses voice authentication of the DH exchange by having each person establish an encrypted channel -- much like encryption devices on the
read digits to the other person. Subsequent sessions with the same PSTN. ZRTP uses voice authentication of its Diffie-Hellman exchange
peer can be authenticated using a hash of the previously negotiated by having each person read digits to the other person. Subsequent
key rather than voice authentication. sessions with the same ZRTP endpoint can be authenticated using the
stored hash of the previously negotiated key rather than voice
authentication.
ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2) ZRTP uses 4 media path messages (Hello, Commit, DHPart1, and DHPart2)
to establish the SRTP key, and 3 media path confirmation messages. to establish the SRTP key, and 3 media path confirmation messages.
The first 4 are sent as RTP packets (using RTP header extensions), The first 4 are sent as RTP packets (using RTP header extensions),
and the last 3 are sent in conjunction with SRTP media packets (again and the last 3 are sent in conjunction with SRTP media packets (again
as SRTP header extensions). Note that unencrypted RTP is being as SRTP header extensions). Note that unencrypted RTP is being
exchanged until the SRTP keys are established. exchanged until the SRTP keys are established.
3.3. Signaling and Media Path Keying Techniques 3.3. Signaling and Media Path Keying Techniques
skipping to change at page 9, line 17 skipping to change at page 9, line 25
participants in the session. participants in the session.
EKT requires the offerer to send some parameters (EKT_Cipher, KEK, EKT requires the offerer to send some parameters (EKT_Cipher, KEK,
and security parameter index (SPI)) via the bootstrapping protocol and security parameter index (SPI)) via the bootstrapping protocol
such as Security Descriptions or MIKEY. Each answerer sends an SRTCP such as Security Descriptions or MIKEY. Each answerer sends an SRTCP
message which contains the answerer's SRTP Master Key, rollover message which contains the answerer's SRTP Master Key, rollover
counter, and the SRTP sequence number. Rekeying is done by sending a counter, and the SRTP sequence number. Rekeying is done by sending a
new SRTCP message. For reliable transport, multiple RTCP messages new SRTCP message. For reliable transport, multiple RTCP messages
need to be sent. need to be sent.
3.3.2. RTP-DTLS 3.3.2. DTLS-SRTP
RTP-DTLS [I-D.fischl-mmusic-sdp-dtls] exchanges public key
fingerprints in SDP and then establishes a DTLS session over the
media channel [I-D.fischl-sipping-media-dtls]. The endpoints use the
DTLS handshake to agree on crypto suites and establish DTLS session
keys. Once established, the endpoints use a modified DTLS mode to
exchange encrypted media packets on the wire. These encrypted media
packets closely resemble SRTP's on-the-wire format, most importantly
by retaining the same RTP header as RTP packets so that header
compression and RTP analysis tools can be used. However, these
packets are not compatible with SRTP [RFC3711].
The authors of this mechanism have deprecated the mechanism in favor
of DTLS-SRTP (Section 3.3.3).
3.3.3. DTLS-SRTP
DTLS-SRTP [I-D.mcgrew-tls-srtp] exchanges public key fingerprints in DTLS-SRTP [I-D.mcgrew-tls-srtp] exchanges public key fingerprints in
SDP and then establishes a DTLS session over the media channel. The SDP [I-D.fischl-sipping-media-dtls] and then establishes a DTLS
endpoints use the DTLS handshake to agree on crypto suites and session over the media channel. The endpoints use the DTLS handshake
establish SRTP session keys. SRTP packets are then exchanged between to agree on crypto suites and establish SRTP session keys. SRTP
the endpoints. packets are then exchanged between the endpoints.
DTLS-SRTP requires one message from offerer to answerer (half round DTLS-SRTP requires one message from offerer to answerer (half round
trip), and, if the offerer wishes to correlate the SDP answer with trip), and, if the offerer wishes to correlate the SDP answer with
the endpoint, requires one message from answer to offerer (full round the endpoint, requires one message from answer to offerer (full round
trip). DTLS-SRTP uses 4 media path messages to establish the SRTP trip). DTLS-SRTP uses 4 media path messages to establish the SRTP
key. key.
This paper assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as its This paper assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as its
cipher suite, which is the mandatory-to-implement cipher suite in TLS cipher suite, which is the mandatory-to-implement cipher suite in TLS
[RFC4346]. [RFC4346].
3.3.4. MIKEYv2 Inband 3.3.3. MIKEYv2 Inband
As defined in Section 3.1.11, MIKEYv2 also defines an in-band As defined in Section 3.1.11, MIKEYv2 also defines an in-band
negotiation mode as an alternative to SDP (see Section 3.3.4). The negotiation mode as an alternative to SDP (see Section 3.3.3). The
details are not sorted out in the draft yet on what in-band actually details are not sorted out in the draft yet on what in-band actually
means (i.e., UDP, RTP, RTCP, etc.). means (i.e., UDP, RTP, RTCP, etc.).
4. Evaluation Criteria - SIP 4. Evaluation Criteria - SIP
This section considers how each keying mechanism interacts with SIP This section considers how each keying mechanism interacts with SIP
features. features.
4.1. Secure Retargeting and Secure Forking 4.1. Secure Retargeting and Secure Forking
skipping to change at page 10, line 45 skipping to change at page 10, line 38
| proxy | | proxy |
++-+-----++ ++-+-----++
| ^ | | ^ |
Invite (2) | | | Invite (4) Invite (2) | | | Invite (4)
& redirect (3) | | | & redirect (3) | | |
V | V V | V
++-++ ++----+ ++-++ ++----+
|Bob| |Carol| |Bob| |Carol|
+---+ +-----+ +---+ +-----+
Figure 2: Retargeting Figure 2: Retargeting
Successful use of SRTP requires strongly identifying both calling Successful use of SRTP requires strongly identifying both calling
party and the called party. The mechanism used by SIP for party and the called party. The mechanism used by SIP for
identifying the calling party is SIP Identity [I-D.ietf-sip- identifying the calling party is SIP Identity [RFC4474]. However,
identity]. However, due to SIP retargeting issues [I-D.peterson- due to SIP retargeting issues [I-D.peterson-sipping-retarget], SIP
sipping-retarget], SIP Identity can only identify the calling party Identity can only identify the calling party (that is, the party that
(that is, the party that initiated the SIP request). Some key initiated the SIP request). Some key exchange mechanisms predate SIP
exchange mechanisms predate SIP Identity and include their own Identity and include their own identity mechanism. However, those
identity mechanism. However, those built-in identity mechanism built-in identity mechanism suffer from the same SIP retargeting
suffer from the same SIP retargeting problem described in the above problem described in the above draft. Going forward, it is
draft. Going forward, it is anticipated that Connected Identity anticipated that Connected Identity [I-D.ietf-sip-connected-identity]
[I-D.ietf-sip-connected-identity] may allow identifying the called may allow identifying the called party. In the list below, this is
party. In the list below, this is described as the 'retargeting described as the 'retargeting identity' problem.
identity' problem.
In SIP, 'forking' is the delivery of a request to multiple locations. In SIP, 'forking' is the delivery of a request to multiple locations.
This happens when a single AOR is registered more than once. An This happens when a single AOR is registered more than once. An
example of forking is when a user has a desk phone, PC client, and example of forking is when a user has a desk phone, PC client, and
mobile handset all registered with the same AOR. mobile handset all registered with the same AOR.
+-----+ +-----+
|Alice| |Alice|
+--+--+ +--+--+
| |
skipping to change at page 11, line 34 skipping to change at page 11, line 26
+-----+-----+ +-----+-----+
| proxy | | proxy |
++---------++ ++---------++
| | | |
Invite | | Invite Invite | | Invite
V V V V
+--+--+ +--+--+ +--+--+ +--+--+
|Bob-1| |Bob-2| |Bob-1| |Bob-2|
+-----+ +-----+ +-----+ +-----+
Figure 3: Forking Figure 3: Forking
With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP
responses. Alice will see those intermediate (18x) and final (200) responses. Alice will see those intermediate (18x) and final (200)
responses. It is useful for Alice to be able to associate the SIP responses. It is useful for Alice to be able to associate the SIP
response with the incoming media stream. Although this association response with the incoming media stream. Although this association
can be done with ICE [I-D.ietf-mmusic-ice], and ICE is useful to make can be done with ICE [I-D.ietf-mmusic-ice], and ICE is useful to make
this association with RTP, it isn't desirable to require ICE to this association with RTP, it isn't desirable to require ICE to
accomplish this association. The table below analyzes if it is accomplish this association. The table below analyzes if it is
possible for an offerer to associate the media stream with each SDP possible for an offerer to associate the media stream with each SDP
answer, without using ICE. answer, without using ICE.
skipping to change at page 12, line 42 skipping to change at page 12, line 33
rejected and providing the far end-end's credentials, it is very rejected and providing the far end-end's credentials, it is very
possible that the rejection will never reach the sender. This possible that the rejection will never reach the sender. This
problem, called the Heterogeneous Error Response Forking Problem problem, called the Heterogeneous Error Response Forking Problem
(HERFP) [I-D.mahy-sipping-herfp-fix] is a complicated problem to (HERFP) [I-D.mahy-sipping-herfp-fix] is a complicated problem to
solve in SIP. solve in SIP.
The following list compares the behavior of secure forking, answering The following list compares the behavior of secure forking, answering
association, two-time pads, and secure retargeting for each keying association, two-time pads, and secure retargeting for each keying
mechanism. mechanism.
MIKEY-NULL MIKEY-NULL Secure Forking: No, all AORs see offerer's and
Secure Forking: No, all AORs see offerer's and answerer's answerer's keys. Answer is associated with media by the SSRC
keys. Answer is associated with media by the SSRC in MIKEY. in MIKEY. Additionally, a two-time pad occurs if two branches
Additionally, a two-time pad occurs if two branches choose the choose the same 32-bit SSRC and transmit SRTP packets.
same 32-bit SSRC and transmit SRTP packets.
Secure Retargeting: No, all targets see offerer's and Secure Retargeting: No, all targets see offerer's and
answerer's keys. Suffers from retargeting identity problem. answerer's keys. Suffers from retargeting identity problem.
MIKEY-PSK MIKEY-PSK
Secure Forking: No, all AORs see offerer's and answerer's Secure Forking: No, all AORs see offerer's and answerer's
keys. Answer is associated with media by the SSRC in MIKEY. keys. Answer is associated with media by the SSRC in MIKEY.
Note that all AORs must share the same pre-shared key in order Note that all AORs must share the same pre-shared key in order
for forking to work at all with MIKEY-PSK. Additionally, a for forking to work at all with MIKEY-PSK. Additionally, a
two-time pad occurs if two branches choose the same 32-bit SSRC two-time pad occurs if two branches choose the same 32-bit SSRC
skipping to change at page 14, line 46 skipping to change at page 14, line 38
EKT EKT
Secure Forking: Inherited from the bootstrapping mechanism Secure Forking: Inherited from the bootstrapping mechanism
(the specific MIKEY mode or Security Descriptions). Answer is (the specific MIKEY mode or Security Descriptions). Answer is
associated with media by the SPI in the EKT protocol. Answer associated with media by the SPI in the EKT protocol. Answer
is associated with media by the SPI in the EKT protocol. is associated with media by the SPI in the EKT protocol.
Secure Retargeting: Inherited from the bootstrapping mechanism Secure Retargeting: Inherited from the bootstrapping mechanism
(the specific MIKEY mode or Security Descriptions). (the specific MIKEY mode or Security Descriptions).
RTP-DTLS
Secure Forking: Yes. Each forked endpoint calculates a unique
SRTP key. Answer is associated with media by the certificate
fingerprint in signaling and certificate in the media path.
Secure Retargeting: Yes. The final target calculates a unique
SRTP key.
DTLS-SRTP DTLS-SRTP
Secure Forking: Yes. Each forked endpoint calculates a unique Secure Forking: Yes. Each forked endpoint calculates a unique
SRTP key. Answer is associated with media by the certificate SRTP key. Answer is associated with media by the certificate
fingerprint in signaling and certificate in the media path. fingerprint in signaling and certificate in the media path.
Secure Retargeting: Yes. The final target calculates a unique Secure Retargeting: Yes. The final target calculates a unique
SRTP key. SRTP key.
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
4.2. Clipping Media Before SDP Answer 4.2. Clipping Media Before SDP Answer
Per the SDP Offer/Answer Model [RFC3264], Per the SDP Offer/Answer Model [RFC3264],
Once the offerer has sent the offer, it MUST be prepared to Once the offerer has sent the offer, it MUST be prepared to
receive media for any recvonly streams described by that offer. receive media for any recvonly streams described by that offer.
It MUST be prepared to send and receive media for any sendrecv It MUST be prepared to send and receive media for any sendrecv
skipping to change at page 15, line 26 skipping to change at page 15, line 15
4.2. Clipping Media Before SDP Answer 4.2. Clipping Media Before SDP Answer
Per the SDP Offer/Answer Model [RFC3264], Per the SDP Offer/Answer Model [RFC3264],
Once the offerer has sent the offer, it MUST be prepared to Once the offerer has sent the offer, it MUST be prepared to
receive media for any recvonly streams described by that offer. receive media for any recvonly streams described by that offer.
It MUST be prepared to send and receive media for any sendrecv It MUST be prepared to send and receive media for any sendrecv
streams in the offer, and send media for any sendonly streams in streams in the offer, and send media for any sendonly streams in
the offer (of course, it cannot actually send until the peer the offer (of course, it cannot actually send until the peer
provides an answer with the needed address and port information). provides an answer with the needed address and port information).
To meet this requirement with SRTP, the offerer needs to know the To meet this requirement with SRTP, the offerer needs to know the
SRTP key for arriving media. If encrypted SRTP media arrives before SRTP key for arriving media. If encrypted SRTP media arrives before
the associated SRTP key, the offerer cannot play the media -- causing the associated SRTP key, the offerer cannot play the media -- causing
clipping and violating the above MUST requirement.s clipping and violating the above MUST requirement.s
For key exchange mechanisms which send the answerer's key in SDP, a For key exchange mechanisms which send the answerer's key in SDP, a
SIP provisional response [RFC3261] such as 183 (session progress) is SIP provisional response [RFC3261] such as 183 (session progress) is
useful. However the 183 messages aren't reliable unless both the useful. However the 183 messages aren't reliable unless both the
calling and called endpoint support PRACK [RFC3262], use TCP across calling and called endpoint support PRACK [RFC3262], use TCP across
all SIP proxies, implement Security Preconditions [I-D.ietf-mmusic- all SIP proxies, implement Security Preconditions
securityprecondition], or the both ends implement ICE [I-D.ietf- [I-D.ietf-mmusic-securityprecondition], or the both ends implement
mmusic-ice] and the answerer implements the reliable provisional ICE [I-D.ietf-mmusic-ice] and the answerer implements the reliable
response mechanism described in ICE. However, there is not wide provisional response mechanism described in ICE. However, there is
deployment of any of these techniques and there is industry not wide deployment of any of these techniques and there is industry
reluctance to requiring these techniques as solutions to avoid the reluctance to requiring these techniques as solutions to avoid the
problem described in this section. problem described in this section.
Furthermore, the problem gets compounded when forking is used. For Furthermore, the problem gets compounded when forking is used. For
example, if using a Diffie-Hellman keying technique with security example, if using a Diffie-Hellman keying technique with security
preconditions that forks to 20 endpoints, the call initiator would preconditions that forks to 20 endpoints, the call initiator would
get 20 provisional responses containing 20 signed Diffie-Hellman half get 20 provisional responses containing 20 signed Diffie-Hellman half
keys. Calculating 20 DH secrets and validating signatures can be a keys. Calculating 20 DH secrets and validating signatures can be a
difficult task depending on the device capabilities. difficult task depending on the device capabilities.
skipping to change at page 17, line 8 skipping to change at page 16, line 46
EKT EKT
Not clipped, as long as the first RTCP packet (containing the Not clipped, as long as the first RTCP packet (containing the
answerer's key) is not lost in transit. The answerer sends its answerer's key) is not lost in transit. The answerer sends its
encryption key in RTCP, which arrives at the same time (or encryption key in RTCP, which arrives at the same time (or
before) the first SRTP packet encrypted with that key. before) the first SRTP packet encrypted with that key.
Note: RTCP needs to work, in the answerer-to-offerer Note: RTCP needs to work, in the answerer-to-offerer
direction, before the offerer can decrypt SRTP media. direction, before the offerer can decrypt SRTP media.
RTP-DTLS
Not clipped. Media keys are exchanged in the media path
without relying on the signaling path.
DTLS-SRTP DTLS-SRTP
Not clipped. Keys are exchanged in the media path without Not clipped. Keys are exchanged in the media path without
relying on the signaling path. relying on the signaling path.
MIKEYv2 Inband MIKEYv2 Inband
Not clipped. Keys are exchanged in the media path without Not clipped. Keys are exchanged in the media path without
relying on the signaling path. relying on the signaling path.
4.3. Centralized Keying 4.3. Centralized Keying
For efficient scaling, large audio and video conference bridges For efficient scaling, large audio and video conference bridges
operate most efficiently by encrypting the current speaker once and operate most efficiently by encrypting the current speaker once and
distributing that stream to the conference attendees. Typically, distributing that stream to the conference attendees. Typically,
inactive participants receive the same streams -- they hear (or see) inactive participants receive the same streams -- they hear (or see)
skipping to change at page 17, line 44 skipping to change at page 17, line 34
A --- 1 --->| | A --- 1 --->| |
<-- 2 ----| M | <-- 2 ----| M |
| I | | I |
B --- 3 --->| X | B --- 3 --->| X |
<-- 4 ----| E | <-- 4 ----| E |
| R | | R |
C --- 5 --->| | C --- 5 --->| |
<-- 6 ----| | <-- 6 ----| |
+----+ +----+
Figure 4: Centralized Keying Figure 4: Centralized Keying
In the figure above, 1, 3, and 5 are RTP media contributions from In the figure above, 1, 3, and 5 are RTP media contributions from
Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those
devices carrying the 'mixed' media. devices carrying the 'mixed' media.
Several scenarios are possible: Several scenarios are possible:
a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP
sessions, sessions,
b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP
sessions, sessions,
c. Single inbound session: 1, 3, and 5 are just different sources c. Single inbound session: 1, 3, and 5 are just different sources
within the same RTP session, within the same RTP session,
d. Single outbound session: 2, 4, and 6 are different flows of the d. Single outbound session: 2, 4, and 6 are different flows of the
same (multi-unicast) RTP session same (multi-unicast) RTP session
If there are multiple inbound sessions and multiple outbound sessions If there are multiple inbound sessions and multiple outbound sessions
(scenarios a and b), then every keying mechanism behaves as if the (scenarios a and b), then every keying mechanism behaves as if the
mixer were an endpoint and can set up a point-to-point secure session mixer were an endpoint and can set up a point-to-point secure session
between the participant and the mixer. This is the simplest between the participant and the mixer. This is the simplest
situation, but is computationally wasteful, since SRTP processing has situation, but is computationally wasteful, since SRTP processing has
to be done independently for each participant. The use of multiple to be done independently for each participant. The use of multiple
inbound sessions (scenario a) doesn't waste computational resources, inbound sessions (scenario a) doesn't waste computational resources,
skipping to change at page 20, line 12 skipping to change at page 20, line 6
Rekeying: n/a Rekeying: n/a
ZRTP ZRTP
Keying: No; a group-key Diffie-Hellman protocol is not Keying: No; a group-key Diffie-Hellman protocol is not
supported. supported.
Rekeying: n/a Rekeying: n/a
EKT EKT
Keying: Yes. After bootstrapping a KEK using SDES or MIKEY, Keying: Yes. After bootstrapping a KEK using Security
each member originating an SRTP stream can send its SRTP master Descriptions or MIKEY, each member originating an SRTP stream
key, sequence number and ROC via RTCP. can send its SRTP master key, sequence number and ROC via RTCP.
Rekeying: Yes. EKT supports each sender to transmit its SRTP Rekeying: Yes. EKT supports each sender to transmit its SRTP
master key to the group via RTCP packets. Thus, EKT supports master key to the group via RTCP packets. Thus, EKT supports
each originator of an SRTP stream to rekey at any time. each originator of an SRTP stream to rekey at any time.
RTP-DTLS
Keying: Yes, because with the assumed cipher suite,
TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key.
Rekeying: via DTLS in the media path.
DTLS-SRTP DTLS-SRTP
Keying: Yes, because with the assumed cipher suite, Keying: Yes, because with the assumed cipher suite,
TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key. TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key.
Rekeying: via DTLS in the media path. Rekeying: via DTLS in the media path.
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
4.4. SSRC and ROC 4.4. SSRC and ROC
In SRTP, a cryptographic context is defined as the SSRC, destination In SRTP, a cryptographic context is defined as the SSRC, destination
network address, and destination transport port number. Whereas RTP, network address, and destination transport port number. Whereas RTP,
a flow is defined as the destination network address and destination a flow is defined as the destination network address and destination
transport port number. This results in a problem -- how to transport port number. This results in a problem -- how to
communicate the SSRC so that the SSRC can be used for the communicate the SSRC so that the SSRC can be used for the
skipping to change at page 21, line 17 skipping to change at page 21, line 6
Another related issue is that SRTP introduces a rollover counter Another related issue is that SRTP introduces a rollover counter
(ROC), which records how many times the SRTP sequence number has (ROC), which records how many times the SRTP sequence number has
rolled over. As the sequence number is used for SRTP's default rolled over. As the sequence number is used for SRTP's default
ciphers, it is important that all endpoints know the value of the ciphers, it is important that all endpoints know the value of the
ROC. The ROC starts at 0 at the beginning of a session. ROC. The ROC starts at 0 at the beginning of a session.
Some keying mechanisms cause a two-time pad to occur if two endpoints Some keying mechanisms cause a two-time pad to occur if two endpoints
of a forked call have an SSRC collision. of a forked call have an SSRC collision.
Note: A proposal has been made to send the ROC value on every Nth Note: A proposal has been made to send the ROC value on every Nth
SRTP packet[I-D.lehtovirta-srtp-rcc]. This proposal has not yet been SRTP packet[RFC4771]. This proposal has not yet been incorporated
incorporated into this document. into this document.
The following list examines handling of SSRC and ROC: The following list examines handling of SSRC and ROC:
MIKEY-NULL MIKEY-NULL
Each endpoint indicates a set of SSRCs and the ROC for SRTP Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits. packets it transmits.
MIKEY-PSK MIKEY-PSK
Each endpoint indicates a set of SSRCs and the ROC for SRTP Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits. packets it transmits.
skipping to change at page 22, line 26 skipping to change at page 22, line 14
ZRTP ZRTP
Neither SSRC nor ROC are signaled. SSRC 'late binding' is Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used. used.
EKT EKT
The SSRC of the SRTCP packet containing an EKT update The SSRC of the SRTCP packet containing an EKT update
corresponds to the SRTP master key and other parameters within corresponds to the SRTP master key and other parameters within
that packet. that packet.
RTP-DTLS
Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used.
DTLS-SRTP DTLS-SRTP
Neither SSRC nor ROC are signaled. SSRC 'late binding' is Neither SSRC nor ROC are signaled. SSRC 'late binding' is
used. used.
MIKEYv2 Inband MIKEYv2 Inband
Each endpoint indicates a set of SSRCs and the ROC for SRTP Each endpoint indicates a set of SSRCs and the ROC for SRTP
packets it transmits. packets it transmits.
5. Evaluation Criteria - Security 5. Evaluation Criteria - Security
This section evaluates each keying mechanism on the basis of their This section evaluates each keying mechanism on the basis of their
security properties. security properties.
5.1. Public Key Infrastructure 5.1. Public Key Infrastructure
skipping to change at page 23, line 10 skipping to change at page 22, line 42
communications it is desirable to avoid fetching certificates that communications it is desirable to avoid fetching certificates that
delay call setup; rather it is preferable to fetch or validate delay call setup; rather it is preferable to fetch or validate
certificates in such a way that call setup isn't delayed. For certificates in such a way that call setup isn't delayed. For
example, a certificate can be validated while the phone is ringing or example, a certificate can be validated while the phone is ringing or
can be validated while ring-back tones are being played or even while can be validated while ring-back tones are being played or even while
the called party is answering the phone and saying "hello". the called party is answering the phone and saying "hello".
SRTP key exchange mechanisms that require a global PKI to operate are SRTP key exchange mechanisms that require a global PKI to operate are
gated on the deployment of a common PKI available to both endpoints. gated on the deployment of a common PKI available to both endpoints.
This means that no media security is achievable until such a PKI This means that no media security is achievable until such a PKI
exists. For SIP, something like sipping-certs [I-D.ietf-sipping- exists. For SIP, something like sip-certs [I-D.ietf-sip-certs] might
certs] might be used to obtain the certificate of a peer. be used to obtain the certificate of a peer.
Note: Even if Sipping-certs was deployed, the retargeting problem Note: Even if Sip-certs was deployed, the retargeting problem
(Section 4.1) would still prevent successful deployment of keying (Section 4.1) would still prevent successful deployment of keying
techniques which require the offerer to obtain the actual target's techniques which require the offerer to obtain the actual target's
public key. public key.
The following list compares the PKI requirements of each keying The following list compares the PKI requirements of each keying
mechanism, both if a PKI is required for the key exchange itself, and mechanism, both if a PKI is required for the key exchange itself, and
if PKI is only used to authenticate the certificate supplied in if PKI is only used to authenticate the certificate supplied in
signaling. signaling.
MIKEY-NULL MIKEY-NULL
PKI not used. PKI not used.
MIKEY-PSK MIKEY-PSK
PKI not used; rather, all endpoints must have some way to PKI not used; rather, all endpoints must have some way to
exchange per-endpoint or per-system pre-shared keys. exchange per-endpoint or per-system pre-shared keys.
MIKEY-RSA MIKEY-RSA
The offerer obtains the intended answerer's public key before The offerer obtains the intended answerer's public key before
initiating the call. This public key is used to encrypt the initiating the call. This public key is used to encrypt the
SRTP keys. There is no defined mechanism for the offerer to SRTP keys. There is no defined mechanism for the offerer to
obtain the answerer's public key, although [I-D.ietf-sipping- obtain the answerer's public key, although [I-D.ietf-sip-certs]
certs] might be viable in the future. might be viable in the future.
MIKEY-RSA-R MIKEY-RSA-R
The offer contains the offerer's public key. The answerer uses The offer contains the offerer's public key. The answerer uses
that public key to encrypt the SRTP keys that will be used by that public key to encrypt the SRTP keys that will be used by
the offerer and the answerer. A PKI is necessary to validate the offerer and the answerer. A PKI is necessary to validate
the certificates. the certificates.
MIKEY-DHSIGN MIKEY-DHSIGN
PKI is used to authenticate the public key that is included in PKI is used to authenticate the public key that is included in
the MIKEY message, by walking the CA trust chain. the MIKEY message, by walking the CA trust chain.
skipping to change at page 24, line 31 skipping to change at page 24, line 15
SDP-DH SDP-DH
PKI not used. PKI not used.
ZRTP ZRTP
PKI not used. PKI not used.
EKT EKT
PKI not used by EKT itself, but might be used by the EKT PKI not used by EKT itself, but might be used by the EKT
bootstrapping keying mechanism (such as certain MIKEY modes). bootstrapping keying mechanism (such as certain MIKEY modes).
RTP-DTLS
Remote party's certificate is sent in media path, and a
fingerprint of the same certificate is sent in the signaling
path. PKI is used to authenticate the remote party's
certificate, by walking the CA trust chain.
DTLS-SRTP DTLS-SRTP
Remote party's certificate is sent in media path, and a Remote party's certificate is sent in media path, and a
fingerprint of the same certificate is sent in the signaling fingerprint of the same certificate is sent in the signaling
path. PKI is used to authenticate the remote party's path.
certificate, by walking the CA trust chain..
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
5.2. Perfect Forward Secrecy 5.2. Perfect Forward Secrecy
In the context of SRTP, Perfect Forward Secrecy is the property that In the context of SRTP, Perfect Forward Secrecy is the property that
SRTP session keys that protected a previous session are not SRTP session keys that protected a previous session are not
compromised if the static keys belonging to the endpoints are compromised if the static keys belonging to the endpoints are
compromised. That is, if someone were to record your encrypted compromised. That is, if someone were to record your encrypted
skipping to change at page 26, line 5 skipping to change at page 25, line 29
SDP-DH SDP-DH
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
ZRTP ZRTP
PFS is provided with the Diffie-Hellman exchange. PFS is provided with the Diffie-Hellman exchange.
EKT EKT
No PFS. No PFS.
RTP-DTLS
PFS is achieved if the negotiated cipher suite includes an
exponential or discrete-logarithmic key exchange (such as
Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]).
DTLS-SRTP DTLS-SRTP
PFS is achieved if the negotiated cipher suite includes an PFS is achieved if the negotiated cipher suite includes an
exponential or discrete-logarithmic key exchange (such as exponential or discrete-logarithmic key exchange (such as
Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]). Diffie-Hellman or Elliptic Curve Diffie-Hellman [RFC4492]).
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
5.3. Best Effort Encryption 5.3. Best Effort Encryption
Note: With the ongoing efforts in SDP Capability Negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation], the conclusions
reached in this section may no longer be accurate.
With best effort encryption, SRTP is used with endpoints that support With best effort encryption, SRTP is used with endpoints that support
SRTP, otherwise RTP is used. SRTP, otherwise RTP is used.
SIP needs a backwards-compatible best effort encryption in order for SIP needs a backwards-compatible best effort encryption in order for
SRTP to work successfully with SIP retargeting and forking when there SRTP to work successfully with SIP retargeting and forking when there
is a mix of forked or retargeted devices that support SRTP and don't is a mix of forked or retargeted devices that support SRTP and don't
support SRTP. support SRTP.
Consider the case of Bob, with a phone that only does RTP and a Consider the case of Bob, with a phone that only does RTP and a
voice mail system that supports SRTP and RTP. If Alice calls Bob voice mail system that supports SRTP and RTP. If Alice calls Bob
skipping to change at page 28, line 23 skipping to change at page 27, line 44
ZRTP ZRTP
Best effort encryption is done by probing (sending RTP messages Best effort encryption is done by probing (sending RTP messages
with header extensions) or by session attribute (see "a=zrtp", with header extensions) or by session attribute (see "a=zrtp",
defined in section 10 of [I-D.zimmermann-avt-zrtp]). Current defined in section 10 of [I-D.zimmermann-avt-zrtp]). Current
implementations of ZRTP use probing. implementations of ZRTP use probing.
EKT EKT
No best effort encryption. No best effort encryption.
RTP-DTLS
No best effort encryption.
DTLS-SRTP DTLS-SRTP
No best effort encryption. No best effort encryption.
MIKEY Inband MIKEY Inband
No best effort encryption. No best effort encryption.
5.4. Upgrading Algorithms 5.4. Upgrading Algorithms
It is necessary to allow upgrading SRTP encryption and hash It is necessary to allow upgrading SRTP encryption and hash
algorithms, as well as upgrading the cryptographic functions used for algorithms, as well as upgrading the cryptographic functions used for
the key exchange mechanism. With SIP's offer/answer model, this can the key exchange mechanism. With SIP's offer/answer model, this can
be computionally expensive because the offer needs to contain all be computionally expensive because the offer needs to contain all
combinations of the key exchange mechanisms (all MIKEY modes, combinations of the key exchange mechanisms (all MIKEY modes,
Security Descriptions, SRTP-DTLS) and all SRTP cryptographic suites Security Descriptions) and all SRTP cryptographic suites (AES-128,
(AES-128, AES-256) and all SRTP cryptographic hash functions (SHA-1, AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256)
SHA-256) that the offerer supports. In order to do this, the offerer that the offerer supports. In order to do this, the offerer has to
has to expend CPU resources to build an offer containing all of this expend CPU resources to build an offer containing all of this
information which becomes computationally prohibitive. information which becomes computationally prohibitive.
Thus, it is important to keep the offerer's CPU impact fixed so that Thus, it is important to keep the offerer's CPU impact fixed so that
offering multiple new SRTP encryption and hash functions incurs no offering multiple new SRTP encryption and hash functions incurs no
additional expense. additional expense.
The following list describes the CPU effort involved in using each The following list describes the CPU effort involved in using each
key exchange technique. key exchange technique.
MIKEY-NULL MIKEY-NULL
skipping to change at page 30, line 10 skipping to change at page 29, line 30
ZRTP ZRTP
The offerer has no additional computational expense at all, as The offerer has no additional computational expense at all, as
the offer contains no information about ZRTP or might contain the offer contains no information about ZRTP or might contain
"a=zrtp". "a=zrtp".
EKT EKT
The offerer's Computational expense depends entirely on the EKT The offerer's Computational expense depends entirely on the EKT
bootstrapping mechanism selected (one or more MIKEY modes or bootstrapping mechanism selected (one or more MIKEY modes or
Security Descriptions). Security Descriptions).
RTP-DTLS
The offerer has no additional computational expense at all, as
the offer contains only a fingerprint of the certificate that
will be presented in the DTLS exchange.
DTLS-SRTP DTLS-SRTP
The offerer has no additional computational expense at all, as The offerer has no additional computational expense at all, as
the offer contains only a fingerprint of the certificate that the offer contains only a fingerprint of the certificate that
will be presented in the DTLS exchange. will be presented in the DTLS exchange.
MIKEYv2 Inband MIKEYv2 Inband
The behavior will depend on which mode is picked. The behavior will depend on which mode is picked.
6. Security Considerations 6. Security Considerations
This entire document discusses security. This entire document discusses security.
7. Acknowledgements 7. Acknowledgements
Special thanks to Steffen Fries and Dragan Ignjatic for their Special thanks to Steffen Fries and Dragan Ignjatic for their
excellent MIKEY comparison document [I-D.ietf-msec-mikey- excellent MIKEY comparison document
applicability]. [I-D.ietf-msec-mikey-applicability].
Thanks also to Cullen Jennings, David Oran, David McGrew, Mark Thanks also to Cullen Jennings, David Oran, David McGrew, Mark
Baugher, Flemming Andreasen, Eric Raymond, Dave Ward, Leo Huang, Eric Baugher, Flemming Andreasen, Eric Raymond, Dave Ward, Leo Huang, Eric
Rescorla, Lakshminath Dondeti, Steffen Fries, Alan Johnston, Dragan Rescorla, Lakshminath Dondeti, Steffen Fries, Alan Johnston, Dragan
Ignjatic and John Elwell for their assistance with this document. Ignjatic and John Elwell for their assistance with this document.
8. IANA Considerations 8. IANA Considerations
This document does not add new IANA registrations. This document does not add new IANA registrations.
skipping to change at page 31, line 4 skipping to change at page 30, line 17
8. IANA Considerations 8. IANA Considerations
This document does not add new IANA registrations. This document does not add new IANA registrations.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[I-D.ietf-sip-identity] [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-sip-identity-06 Initiation Protocol (SIP)", RFC 4474, August 2006.
(work in progress), October 2005.
9.2. Informational References 9.2. Informational References
[I-D.ietf-mmusic-sdescriptions] [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Andreasen, F., "Session Description Protocol Security Carrara, "Key Management Extensions for Session
Descriptions for Media Streams", Description Protocol (SDP) and Real Time Streaming
draft-ietf-mmusic-sdescriptions-12 (work in progress), Protocol (RTSP)", RFC 4567, July 2006.
September 2005.
[I-D.ietf-mmusic-kmgmt-ext] [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Arkko, J., "Key Management Extensions for Session Description Protocol (SDP) Security Descriptions for Media
Description Protocol (SDP) and Real Time Streaming Streams", RFC 4568, July 2006.
Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in
progress), June 2005.
[I-D.ietf-mmusic-securityprecondition] [I-D.ietf-mmusic-securityprecondition]
Andreasen, F. and D. Wing, "Security Preconditions for Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol Media Streams", Session Description Protocol (SDP) Media Streams",
draft-ietf-mmusic-securityprecondition-01 (work in draft-ietf-mmusic-securityprecondition-03 (work in
progress), October 2005. progress), October 2006.
[I-D.ietf-msec-mikey-dhhmac] [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Euchner, M., "HMAC-authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650,
MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in September 2006.
progress), April 2005.
[I-D.ietf-msec-mikey-ecc] [I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms For MIKEY", Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-00 (work in progress), draft-ietf-msec-mikey-ecc-01 (work in progress),
February 2006. October 2006.
[I-D.ietf-msec-mikey-rsa-r] [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
Ignjatic, D., "An additional mode of key distribution in RSA-R: An Additional Mode of Key Distribution in
MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-06 (work Multimedia Internet KEYing (MIKEY)", RFC 4738,
in progress), June 2006. November 2006.
[I-D.ietf-sipping-certs] [I-D.ietf-sip-certs]
Jennings, C. and J. Peterson, "Certificate Management Jennings, C., "Certificate Management Service for The
Service for The Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-03 (work in progress), draft-ietf-sip-certs-02 (work in progress), October 2006.
March 2006.
[I-D.mahy-sipping-herfp-fix] [I-D.mahy-sipping-herfp-fix]
Mahy, R., "A Solution to the Heterogeneous Error Response Mahy, R., "A Solution to the Heterogeneous Error Response
Forking Problem (HERFP) in the Session Initiation Forking Problem (HERFP) in the Session Initiation
Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in Protocol (SIP)", draft-mahy-sipping-herfp-fix-01 (work in
progress), March 2006. progress), March 2006.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
skipping to change at page 32, line 41 skipping to change at page 31, line 48
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[I-D.fischl-sipping-media-dtls] [I-D.fischl-sipping-media-dtls]
Fischl, J., "Session Initiation Protocol (SIP) for Media Fischl, J., "Datagram Transport Layer Security (DTLS)
Over Datagram Transport Layer Security (DTLS)", Protocol for Protection of Media Traffic Established with
draft-fischl-sipping-media-dtls-00 (work in progress), the Session Initiation Protocol",
March 2006. draft-fischl-sipping-media-dtls-01 (work in progress),
June 2006.
[I-D.fischl-mmusic-sdp-dtls]
Fischl, J. and H. Tschofenig, "Session Description
Protocol (SDP) Indicators for Datagram Transport Layer
Security (DTLS)", draft-fischl-mmusic-sdp-dtls-00 (work in
progress), March 2006.
[I-D.ietf-msec-mikey-applicability] [I-D.ietf-msec-mikey-applicability]
Fries, S. and D. Ignjatic, "On the applicability of Fries, S. and D. Ignjatic, "On the applicability of
various MIKEY modes and extensions", various MIKEY modes and extensions",
draft-ietf-msec-mikey-applicability-01 (work in progress), draft-ietf-msec-mikey-applicability-03 (work in progress),
June 2006. December 2006.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., "ZRTP: Extensions to RTP for Diffie- Zimmermann, P., "ZRTP: Extensions to RTP for Diffie-
Hellman Key Agreement for SRTP", Hellman Key Agreement for SRTP",
draft-zimmermann-avt-zrtp-01 (work in progress), draft-zimmermann-avt-zrtp-02 (work in progress),
March 2006. October 2006.
[I-D.baugher-mmusic-sdp-dh] [I-D.baugher-mmusic-sdp-dh]
Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for
Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work
in progress), February 2006. in progress), February 2006.
[I-D.mcgrew-srtp-ekt] [I-D.mcgrew-srtp-ekt]
McGrew, D., "Encrypted Key Transport for Secure RTP", McGrew, D., "Encrypted Key Transport for Secure RTP",
draft-mcgrew-srtp-ekt-00 (work in progress), draft-mcgrew-srtp-ekt-01 (work in progress), June 2006.
February 2006.
[I-D.lehtovirta-srtp-rcc] [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
Lehtovirta, V., "Integrity Transform Carrying Roll-over Transform Carrying Roll-Over Counter for the Secure Real-
Counter", draft-lehtovirta-srtp-rcc-03 (work in progress), time Transport Protocol (SRTP)", RFC 4771, January 2007.
June 2006.
[I-D.peterson-sipping-retarget] [I-D.peterson-sipping-retarget]
Peterson, J., "Retargeting and Security in SIP: A Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", Framework and Requirements",
draft-peterson-sipping-retarget-00 (work in progress), draft-peterson-sipping-retarget-00 (work in progress),
February 2005. February 2005.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT) (ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-08 (work in progress), March 2006. draft-ietf-mmusic-ice-13 (work in progress), January 2007.
[I-D.ietf-sip-connected-identity] [I-D.ietf-sip-connected-identity]
Elwell, J., "Connected Identity in the Session Initiation Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", draft-ietf-sip-connected-identity-00 Protocol (SIP)", draft-ietf-sip-connected-identity-04
(work in progress), April 2006. (work in progress), January 2007.
[I-D.jennings-sipping-multipart] [I-D.jennings-sipping-multipart]
Wing, D. and C. Jennings, "Session Initiation Protocol Wing, D. and C. Jennings, "Session Initiation Protocol
(SIP) Offer/Answer with Multipart Alternative", (SIP) Offer/Answer with Multipart Alternative",
draft-jennings-sipping-multipart-02 (work in progress), draft-jennings-sipping-multipart-02 (work in progress),
March 2006. March 2006.
[I-D.mcgrew-tls-srtp] [I-D.mcgrew-tls-srtp]
Rescorla, E. and D. McGrew, "Datagram Transport Layer Rescorla, E. and D. McGrew, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", Real-time Transport Protocol (SRTP)",
draft-mcgrew-tls-srtp-00 (work in progress), June 2006. draft-mcgrew-tls-srtp-00 (work in progress), June 2006.
[I-D.dondeti-msec-rtpsec-mikeyv2] [I-D.dondeti-msec-rtpsec-mikeyv2]
Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY,
revisited", draft-dondeti-msec-rtpsec-mikeyv2-00 (work in revisited", draft-dondeti-msec-rtpsec-mikeyv2-00 (work in
progress), June 2006. progress), June 2006.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-01 (work in
progress), January 2007.
Appendix A. Changelog Appendix A. Changelog
Note to RFC Editor: this appendix should be removed prior to Note to RFC Editor: this appendix should be removed prior to
publication. publication.
A.1. Changes from -00 to -01 A.1. Changes from -01 to -02
o Removed DTLS-RTP
o Added note about SDP Capability Negotiation and its impact on
best-effort SRTP
A.2. Changes from -00 to -01
o Added MIKEYv2 as part of the main proposals. o Added MIKEYv2 as part of the main proposals.
o Removed retargeting as a problem for best-effort encryption's o Removed retargeting as a problem for best-effort encryption's
multipart/alternative multipart/alternative
o "Opportunistic encryption" to "best-effort encryption" o "Opportunistic encryption" to "best-effort encryption"
o Added 'Upgrading Algorithm' section o Added 'Upgrading Algorithm' section
o Separate analysis of 'Security Descriptions with SIPS' and o Separate analysis of 'Security Descriptions with SIPS' and
'Security Descriptions with S/MIME' 'Security Descriptions with S/MIME'
Authors' Addresses Authors' Addresses
Francois Audet Francois Audet
Nortel Nortel
4655 Great America Parkway 4655 Great America Parkway
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
skipping to change at page 36, line 5 skipping to change at page 35, line 5
Email: audet@nortel.com Email: audet@nortel.com
Dan Wing Dan Wing
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 36, line 29 skipping to change at page 35, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 88 change blocks. 
248 lines changed or deleted 207 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/