idnits 2.17.00 (12 Aug 2021) /tmp/idnits11349/draft-ietf-sip-dtls-srtp-framework-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1394 has weird spacing: '...ication along...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 07, 2009) is 4816 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 == Outdated reference: draft-zimmermann-avt-zrtp has been published as RFC 6189 == Outdated reference: A later version (-06) exists of draft-mcgrew-srtp-ekt-03 == Outdated reference: draft-ietf-avt-dtls-srtp has been published as RFC 5764 == Outdated reference: draft-ietf-sip-media-security-requirements has been published as RFC 5479 == Outdated reference: draft-ietf-mmusic-sdp-capability-negotiation has been published as RFC 5939 == Outdated reference: draft-ietf-avt-rtp-and-rtcp-mux has been published as RFC 5761 -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) == Outdated reference: A later version (-03) exists of draft-wing-avt-dtls-srtp-key-transport-02 == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-01 == Outdated reference: draft-ietf-sip-ua-privacy has been published as RFC 5767 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Fischl 3 Internet-Draft CounterPath Corporation 4 Intended status: Standards Track H. Tschofenig 5 Expires: September 8, 2009 Nokia Siemens Networks 6 E. Rescorla 7 RTFM, Inc. 8 March 07, 2009 10 Framework for Establishing an SRTP Security Context using DTLS 11 draft-ietf-sip-dtls-srtp-framework-07.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 8, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document specifies how to use the Session Initiation Protocol 60 (SIP) to establish an Secure Real-time Transport Protocol (SRTP) 61 security context using the Datagram Transport Layer Security (DTLS) 62 protocol. It describes a mechanism of transporting a fingerprint 63 attribute in the Session Description Protocol (SDP) that identifies 64 the key that will be presented during the DTLS handshake. The key 65 exchange travels along the media path as opposed to the signaling 66 path. The SIP Identity mechanism can be used to protect the 67 integrity of the fingerprint attribute from modification by 68 intermediate proxies. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. Establishing a Secure Channel . . . . . . . . . . . . . . . . 9 77 6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 11 78 6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 11 79 6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 12 82 6.5. Multiple Associations . . . . . . . . . . . . . . . . . . 12 83 6.6. Session Modification . . . . . . . . . . . . . . . . . . . 12 84 6.7. Middlebox Interaction . . . . . . . . . . . . . . . . . . 13 85 6.7.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 13 86 6.7.2. Latching Control Without ICE . . . . . . . . . . . . . 13 87 6.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 6.9. Conference Servers and Shared Encryptions Contexts . . . . 14 89 6.10. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 14 90 6.11. Best Effort Encryption . . . . . . . . . . . . . . . . . . 15 91 7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 15 92 7.1. Basic Message Flow with Early Media and Identity . . . . . 15 93 7.2. Basic Message Flow with Connected Identity (RFC 4916) . . 20 94 7.3. Basic Message Flow with STUN check for NAT Case . . . . . 24 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 96 8.1. Responder Identity . . . . . . . . . . . . . . . . . . . . 26 97 8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 8.4. Continuity of Authentication . . . . . . . . . . . . . . . 27 100 8.5. Short Authentication String . . . . . . . . . . . . . . . 28 101 8.6. Limits of Identity Assertions . . . . . . . . . . . . . . 28 102 8.7. Third Party Certificates . . . . . . . . . . . . . . . . . 30 103 8.8. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 30 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 105 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 108 11.2. Informational References . . . . . . . . . . . . . . . . . 32 109 Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 34 110 A.1. Forking and retargeting (R-FORK-RETARGET, 111 R-BEST-SECURE, R-DISTINCT) . . . . . . . . . . . . . . . . 34 112 A.2. Distinct Cryptographic Contexts (R-DISTINCT) . . . . . . . 34 113 A.3. Reusage of a Security Context (R-REUSE) . . . . . . . . . 34 114 A.4. Clipping (R-AVOID-CLIPPING) . . . . . . . . . . . . . . . 34 115 A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) . . . . . 35 116 A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) . . . . 35 117 A.7. (R-SIG-MEDIA, R-ACT-ACT) . . . . . . . . . . . . . . . . . 35 118 A.8. Binding to Identifiers (R-ID-BINDING) . . . . . . . . . . 35 119 A.9. Perfect Forward Secrecy (R-PFS) . . . . . . . . . . . . . 35 120 A.10. Algorithm Negotiation (R-COMPUTE) . . . . . . . . . . . . 36 121 A.11. RTP Validity Check (R-RTP-VALID) . . . . . . . . . . . . . 36 122 A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) . . . . . . . 36 123 A.13. FIPS 140-2 (R-FIPS) . . . . . . . . . . . . . . . . . . . 36 124 A.14. Linkage between Keying Exchange and SIP Signaling 125 (R-ASSOC) . . . . . . . . . . . . . . . . . . . . . . . . 36 126 A.15. Denial of Service Vulnerability (R-DOS) . . . . . . . . . 36 127 A.16. Crypto-Agility (R-AGILITY) . . . . . . . . . . . . . . . . 36 128 A.17. Downgrading Protection (R-DOWNGRADE) . . . . . . . . . . . 37 129 A.18. Media Security Negotation (R-NEGOTIATE) . . . . . . . . . 37 130 A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) . . . 37 131 A.20. Media Recording (R-RECORDING) . . . . . . . . . . . . . . 37 132 A.21. Interworking with Intermediaries (R-TRANSCODER) . . . . . 37 133 A.22. PSTN Gateway Termination (R-PSTN) . . . . . . . . . . . . 37 134 A.23. R-ALLOW-RTP . . . . . . . . . . . . . . . . . . . . . . . 37 135 A.24. R-HERFP . . . . . . . . . . . . . . . . . . . . . . . . . 38 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 138 1. Introduction 140 The Session Initiation Protocol (SIP) [RFC3261] and the Session 141 Description Protocol (SDP) [RFC4566] are used to set up multimedia 142 sessions or calls. SDP is also used to set up TCP [RFC4145] and 143 additionally TCP/TLS connections for usage with media sessions 144 [RFC4572]. The Real-time Transport Protocol (RTP) [RFC3550] is used 145 to transmit real time media on top of UDP and TCP [RFC4571]. 146 Datagram TLS [RFC4347] was introduced to allow TLS functionality to 147 be applied to datagram transport protocols, such as UDP and DCCP. 148 This draft provide guidelines on how to establish SRTP [RFC3711] 149 security over UDP using an extension to DTLS (see 150 [I-D.ietf-avt-dtls-srtp]). 152 The goal of this work is to provide a key negotiation technique that 153 allows encrypted communication between devices with no prior 154 relationships. It also does not require the devices to trust every 155 call signaling element that was involved in routing or session setup. 156 This approach does not require any extra effort by end users and does 157 not require deployment of certificates that are signed by a well- 158 known certificate authority to all devices. 160 The media is transported over a mutually authenticated DTLS session 161 where both sides have certificates. It is very important to note 162 that certificates are being used purely as a carrier for the public 163 keys of the peers. This is required because DTLS does not have a 164 mode for carrying bare keys, but it is purely an issue of formatting. 165 The certificates can be self-signed and completely self-generated. 166 All major TLS stacks have the capability to generate such 167 certificates on demand. However, third party certificates MAY also 168 be used if the peers have them (thus reducing the need to trust 169 intermediaries). The certificate fingerprints are sent in SDP over 170 SIP as part of the offer/answer exchange. 172 The fingerprint mechanism allows one side of the connection to verify 173 that the certificate presented in the DTLS handshake matches the 174 certificate used by the party in the signalling. However, this 175 requires some form of integrity protection on the signalling. S/MIME 176 signatures, as described in RFC 3261, or SIP Identity, as described 177 in [RFC4474] provides the highest level of security because they are 178 not susceptible to modification by malicious intermediaries. 179 However, even hop-by-hop security such as provided by SIPS provides 180 some protection against modification by attackers who are not in 181 control of on-path sigaling elements. Because DTLS-SRTP only 182 requires message integrity and not confidentiality for the signaling, 183 the number of elements which must have credentials and be trusted is 184 significantly reduced. In particular, if RFC 4474 is used, only the 185 Authentication Service need have a certificate and be trusted. 187 Intermediate elements cannot undetectably modify the message and 188 therefore cannot mount a MITM attack. By comparison, because 189 SDESCRIPTIONS [RFC4568] requires confidentiality for the signaling, 190 all intermediate elements must be trusted. 192 This approach differs from previous attempts to secure media traffic 193 where the authentication and key exchange protocol (e.g., MIKEY 194 [RFC3830]) is piggybacked in the signaling message exchange. With 195 DTLS-SRTP, establishing the protection of the media traffic between 196 the endpoints is done by the media endpoints with only a 197 cryptographic binding of the media keying to the SIP/SDP 198 communication. It allows RTP and SIP to be used in the usual manner 199 when there is no encrypted media. 201 In SIP, typically the caller sends an offer and the callee may 202 subsequently send one-way media back to the caller before a SIP 203 answer is received by the caller. The approach in this 204 specification, where the media key negotiation is decoupled from the 205 SIP signaling, allows the early media to be set up before the SIP 206 answer is received while preserving the important security property 207 of allowing the media sender to choose some of the keying material 208 for the media. This also allows the media sessions to be changed, 209 re-keyed, and otherwise modified after the initial SIP signaling 210 without any additional SIP signaling. 212 Design decisions that influence the applicability of this 213 specification are discussed in Section 3. 215 2. Overview 217 Endpoints wishing to set up an RTP media session do so by exchanging 218 offers and answers in SDP messages over SIP. In a typical use case, 219 two endpoints would negotiate to transmit audio data over RTP using 220 the UDP protocol. 222 Figure 1 shows a typical message exchange in the SIP Trapezoid. 224 +-----------+ +-----------+ 225 |SIP | SIP/SDP |SIP | 226 +------>|Proxy |----------->|Proxy |-------+ 227 | |Server X | (+finger- |Server Y | | 228 | +-----------+ print, +-----------+ | 229 | +auth.id.) | 230 | SIP/SDP SIP/SDP | 231 | (+fingerprint) (+fingerprint,| 232 | +auth.id.) | 233 | | 234 | v 235 +-----------+ Datagram TLS +-----------+ 236 |SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP | 237 |User Agent | Media |User Agent | 238 |Alice@X | <=================================> |Bob@Y | 239 +-----------+ +-----------+ 241 Legend: 242 ------>: Signaling Traffic 243 <-+-+->: Key Management Traffic 244 <=====>: Data Traffic 246 Figure 1: DTLS Usage in the SIP Trapezoid 248 Consider Alice wanting to set up an encrypted audio session with Bob. 249 Both Bob and Alice could use public-key based authentication in order 250 to establish a confidentiality protected channel using DTLS. 252 Since providing mutual authentication between two arbitrary end 253 points on the Internet using public key based cryptography tends to 254 be problematic, we consider more deployment-friendly alternatives. 255 This document uses one approach and several others are discussed in 256 Section 8. 258 Alice sends an SDP offer to Bob over SIP. If Alice uses only self- 259 signed certificates for the communication with Bob, a fingerprint is 260 included in the SDP offer/answer exchange. This fingerprint binds 261 the DTLS key exchange in the media plane to the signaling plane. 263 The fingerprint alone protects against active attacks on the media 264 but not active attacks on the signalling. In order to prevent active 265 attacks on the signalling, Enhancements for Authenticated Identity 266 Management in SIP [RFC4474] may be is used. When Bob receives the 267 offer, the peers establish some number of DTLS connections (depending 268 on the number of media sessions) with mutual DTLS authentication 269 (i.e., both sides provide certificates) At this point, Bob can verify 270 that Alice's credentials offered in TLS match the fingerprint in the 271 SDP offer, and Bob can begin sending media to Alice. Once Bob 272 accepts Alice's offer and sends an SDP answer to Alice, Alice can 273 begin sending confidential media to Bob over the appropriate streams. 274 Alice and Bob will verify that the fingerprints from the certificates 275 received over the DTLS handshakes match with the fingerprints 276 received in the SDP of the SIP signaling. This provides the security 277 property that Alice knows that the media traffic is going to Bob and 278 vice-versa without necessarily requiring global PKI certificates for 279 Alice and Bob. (see Section 8 for detailed security analysis.) 281 3. Motivation 283 Although there is already prior work in this area (e.g., Security 284 Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] 285 combined with MIKEY [RFC3830] for authentication and key exchange), 286 this specification is motivated as follows: 288 o TLS will be used to offer security for connection-oriented media. 289 The design of TLS is well-known and implementations are widely 290 available. 291 o This approach deals with forking and early media without requiring 292 support for PRACK [RFC3262] while preserving the important 293 security property of allowing the offerer to choose keying 294 material for encrypting the media. 295 o The establishment of security protection for the media path is 296 also provided along the media path and not over the signaling 297 path. In many deployment scenarios, the signaling and media 298 traffic travel along a different path through the network. 299 o When RFC 4474 Identity is used, this solution works even when the 300 SIP proxies downstream of the authentication service are not 301 trusted. There is no need to reveal keys in the SIP signaling or 302 in the SDP message exchange, as is done in SDESCRIPTIONS 303 [RFC4568]. Retargeting of a dialog-forming request (changing the 304 value of the Request-URI), the UA that receives it (the User Agent 305 Server, UAS) can have a different identity from that in the To 306 header field. When RFC 4916 is used then it is possible to supply 307 its identity to the peer UA by means of a request in the reverse 308 direction, and for that identity to be signed by an Authentication 309 Service. 310 o In this method, SSRC collisions do not result in any extra SIP 311 signaling. 312 o Many SIP endpoints already implement TLS. The changes to existing 313 SIP and RTP usage are minimal even when DTLS-SRTP 314 [I-D.ietf-avt-dtls-srtp] is used. 316 4. Terminology 318 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 319 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 320 document are to be interpreted as described in [RFC2119]. 322 DTLS/TLS uses the term "session" to refer to a long-lived set of 323 keying material that spans associations. In this document, 324 consistent with SIP/SDP usage, we use it to refer to a multimedia 325 session and use the term "TLS session" to refer to the TLS construct. 326 We use the term "association" to refer to a particular DTLS 327 ciphersuite and keying material set which is associated with a single 328 host/port quartet. The same DTLS/TLS session can be used to 329 establish the keying material for multiple associations. For 330 consistency with other SIP/SDP usage, we use the term "connection" 331 when what's being referred to is a multimedia stream that is not 332 specifically DTLS/TLS. 334 In this document, the term "Mutual DTLS" indicates that both the DTLS 335 client and server present certificates even if one or both 336 certificates are self-signed. 338 5. Establishing a Secure Channel 340 The two endpoints in the exchange present their identities as part of 341 the DTLS handshake procedure using certificates. This document uses 342 certificates in the same style as described in Comedia over TLS in 343 SDP [RFC4572]. 345 If self-signed certificates are used, the content of the 346 subjectAltName attribute inside the certificate MAY use the uniform 347 resource identifier (URI) of the user. This is useful for debugging 348 purposes only and is not required to bind the certificate to one of 349 the communication endpoints. The integrity of the certificate is 350 ensured through the fingerprint attribute in the SDP. The 351 subjectAltName is not an important component of the certificate 352 verification. 354 The generation of public/private key pairs is relatively expensive. 355 Endpoints are not required to generate certificates for each session. 357 The offer/answer model, defined in [RFC3264], is used by protocols 358 like the Session Initiation Protocol (SIP) [RFC3261] to set up 359 multimedia sessions. In addition to the usual contents of an SDP 360 [RFC4566] message, each media description ('m' line and associated 361 parameters) will also contain several attributes as specified in 362 [I-D.ietf-avt-dtls-srtp], [RFC4145] and [RFC4572]. 364 When an endpoint wishes to set up a secure media session with another 365 endpoint it sends an offer in a SIP message to the other endpoint. 366 This offer includes, as part of the SDP payload, the fingerprint of 367 the certificate that the endpoint wants to use. The endpoint SHOULD 368 send the SIP message containing the offer to the offerer's sip proxy 369 over an integrity protected channel. The proxy SHOULD add an 370 Identity header field according to the procedures outlined in 371 [RFC4474]. The SIP message containing the offer SHOULD be sent to 372 the offerer's sip proxy over an integrity protected channel. When 373 the far endpoint receives the SIP message it can verify the identity 374 of the sender using the Identity header field. Since the Identity 375 header field is a digital signature across several SIP header fields, 376 in addition to the body of the SIP message, the receiver can also be 377 certain that the message has not been tampered with after the digital 378 signature was applied and added to the SIP message. 380 The far endpoint (answerer) may now establish a DTLS association with 381 DTLS to the offerer. Alternately, it can indicate in its answer that 382 the offerer is to initiate the TLS association. In either case, 383 mutual DTLS certificate-based authentication will be used. After 384 completing the DTLS handshake, information about the authenticated 385 identities, including the certificates, are made available to the 386 endpoint application. The answerer is then able to verify that the 387 offerer's certificate used for authentication in the DTLS handshake 388 can be associated to the certificate fingerprint contained in the 389 offer in the SDP. At this point the answerer may indicate to the end 390 user that the media is secured. The offerer may only tentatively 391 accept the answerer's certificate since it may not yet have the 392 answerer's certificate fingerprint. 394 When the answerer accepts the offer, it provides an answer back to 395 the offerer containing the answerer's certificate fingerprint. At 396 this point the offerer can accept or reject the peer's certificate 397 and the offerer can indicate to the end user that the media is 398 secured. 400 Note that the entire authentication and key exchange for securing the 401 media traffic is handled in the media path through DTLS. The 402 signaling path is only used to verify the peers' certificate 403 fingerprints. 405 The offer and answer MUST be conform to the following requirements. 406 o The endpoint MUST use the setup attribute defined in [RFC4145]. 407 The endpoint which is the offerer MUST use the setup attribute 408 value of setup:actpass and be prepared to receive a client_hello 409 before it receives the answer. The answerer MUST use either a 410 setup attribute value of setup:active or setup:passive. Note that 411 if the answerer uses setup:passive, then the DTLS handshake will 412 not begin until the answerer is received, which adds additional 413 latency. setup:active allows the answer and the DTLS handshake to 414 occur in parallel. Thus, setup:active is RECOMMENDED. Whichever 415 party is active MUST initiate a DTLS handshake by sending a 416 ClientHello over each flow (host/port quartet). 417 o The endpoint MUST NOT use the connection attribute defined in 418 [RFC4145]. 419 o The endpoint MUST use the certificate fingerprint attribute as 420 specified in [RFC4572]. 421 o The certificate presented during the DTLS handshake MUST match the 422 fingerprint exchanged via the signaling path in the SDP. The 423 security properties of this mechanism are described in Section 8. 424 o If the fingerprint does not match the hashed certificate then the 425 endpoint MUST tear down the media session immediately. Note that 426 it is permissible to wait until the other side's fingerprint has 427 been received before establishing the connection, however this may 428 have undesirable latency effects. 430 6. Miscellaneous Considerations 432 6.1. Anonymous Calls 434 The use of DTLS-SRTP does not provide anonymous calling, however it 435 also does not prevent it. However, if care is not taken when 436 anonymous calling features such as those described in [RFC3325] or 437 [I-D.ietf-sip-ua-privacy] are used DTLS-SRTP may allow deanonymizing 438 an otherwise anonymous call. When anonymous calls are being made, 439 the following procedures SHOULD be used to prevent deanonymization. 441 When making anonymous calls, a new self-signed certificate SHOULD be 442 used for each call so that the calls can not be correlated as to 443 being from the same caller. In situations where some degree of 444 correlation is acceptable, the same certificate SHOULD be used for a 445 number of calls in order to enable continuity of authentication, see 446 Section 8.4. 448 Additionally note that in networks that deploy [RFC3325], RFC 3325 449 requires that the Privacy header field value defined in [RFC3323] 450 needs to be set to 'id'. This is used in conjunction with the SIP 451 identity mechanism to ensure that the identity of the user is not 452 asserted when enabling anonymous calls. Furthermore, the content of 453 the subjectAltName attribute inside the certificate MUST NOT contain 454 information that either allows correlation or identification of the 455 user that wishes to place an anonymous call. Note that following 456 this recommendation is not sufficient to provide anonymization. 458 6.2. Early Media 460 If an offer is received by an endpoint that wishes to provide early 461 media, it MUST take the setup:active role and can immediately 462 establish a DTLS association with the other endpoint and begin 463 sending media. The setup:passive endpoint may not yet have validated 464 the fingerprint of the active endpoint's certificate. The security 465 aspects of media handling in this situation are discussed in 466 Section 8. 468 6.3. Forking 470 In SIP, it is possible for a request to fork to multiple endpoints. 471 Each forked request can result in a different answer. Assuming that 472 the requester provided an offer, each of the answerers' will provide 473 a unique answer. Each answerer will form a DTLS association with the 474 offerer. The offerer can then securely correlate the SDP answer 475 received in the SIP message by comparing the fingerprint in the 476 answer to the hashed certificate for each DTLS association. 478 6.4. Delayed Offer Calls 480 An endpoint may send a SIP INVITE request with no offer in it. When 481 this occurs, the receiver(s) of the INVITE will provide the offer in 482 the response and the originator will provide the answer in the 483 subsequent ACK request or in the PRACK request [RFC3262] if both 484 endpoints support reliable provisional responses. In any event, the 485 active endpoint still establishes the DTLS association with the 486 passive endpoint as negotiated in the offer/answer exchange. 488 6.5. Multiple Associations 490 When there are multiple flows (e.g., multiple media streams, non- 491 multiplexed RTP and RTCP, etc.) the active side MAY perform the DTLS 492 handshakes in any order. Appendix B of [I-D.ietf-avt-dtls-srtp] 493 provides some guidance on the performance of parallel DTLS 494 handshakes. Note that if the answerer ends up being active, it may 495 only initiate handshakes on some subset of the potential streams 496 (e.g., if audio and video are offered but it only wishes to do 497 audio.) If the offerer ands up being active, the complete answer 498 will be received before the offerer begins initiating handshakes. 500 6.6. Session Modification 502 Once an answer is provided to the offerer, either endpoint MAY 503 request a session modification which MAY include an updated offer. 504 This session modification can be carried in either an INVITE or 505 UPDATE request. The peers can reuse the the existing associations if 506 they are compatible (i.e., they have the same key fingerprints and 507 transport parameters), or establish a new one following the same 508 rules are for initial exchanges, tearing down the existing 509 association as soon as the offer/answer exchange is completed. Note 510 that if the active/passive status of the endpoints changes, a new 511 connection MUST be established. 513 6.7. Middlebox Interaction 515 There are a number of potentially bad interactions between DTLS-SRTP 516 and middleboxes, as documented in 517 [I-D.ietf-mmusic-media-path-middleboxes], which also provides 518 recommendations for avoiding such problems. 520 6.7.1. ICE Interaction 522 Interactive Connectivity Establishment (ICE), as specified in 523 [I-D.ietf-mmusic-ice], provides a methodology of allowing 524 participants in multi-media sessions to verify mutual connectivity. 525 When ICE is being used the ICE connectivity checks are performed 526 before the DTLS handshake begins. Note that if aggressive nomination 527 mode is used, multiple candidate pairs may be marked valid before ICE 528 finally converges on a single candidate pair. Implementations MUST 529 treat all ICE candidate pairs associated with a single component as 530 part of the same DTLS association. Thus, there will be only one DTLS 531 handshake even if there are multiple valid candidate pairs. Note 532 that this may mean adjusting the endpoint IP addresses if the 533 selected candidate pair shifts, just as if the DTLS packets were an 534 ordinary media stream. 536 Note that STUN packets are sent directly over UDP, not over DTLS. 537 [I-D.ietf-avt-dtls-srtp] describes how to demultiplex STUN packets 538 from DTLS packets and SRTP packets. 540 6.7.2. Latching Control Without ICE 542 If ICE is not being used, then there is potential for a bad 543 interaction with SBCs via "latching", as described in 544 [I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this 545 issue, if ICE is not being used and the DTLS handshake has not 546 completed, upon receiving the other side's SDP then the passive side 547 MUST do a single unauthenticated STUN [RFC5389] connectivity check in 548 order to open up the appropriate pinhole. All implementations MUST 549 be prepared to answer this request during the handshake period even 550 if they do not otherwise do ICE. However, the active side MUST 551 proceed with the DTLS handshake as appopriate even if no such STUN 552 check is received and the passive MUST NOT wait for a STUN answer 553 before sending its ServerHello. 555 6.8. Rekeying 557 As with TLS, DTLS endpoints can rekey at any time by redoing the DTLS 558 handshake. While the rekey is under way, the endpoints continue to 559 use the previously established keying material for usage with DTLS. 560 Once the new session keys are established the session can switch to 561 using these and abandon the old keys. This ensures that latency is 562 not introduced during the rekeying process. 564 Further considerations regarding rekeying in case the SRTP security 565 context is established with DTLS can be found in Section 3.7 of 566 [I-D.ietf-avt-dtls-srtp]. 568 6.9. Conference Servers and Shared Encryptions Contexts 570 It has been proposed that conference servers might use the same 571 encryption context for all of the participants in a conference. The 572 advantage of this approach is that the conference server only needs 573 to encrypt the output for all speakers instead of once per 574 participant. 576 This shared encryption context approach is not possible under this 577 specification because each DTLS handshake establishes fresh keys 578 which are not completely under the control of either side. However, 579 it is argued that the effort to encrypt each RTP packet is small 580 compared to the other tasks performed by the conference server such 581 as the codec processing. 583 Future extensions such as [I-D.mcgrew-srtp-ekt] or 584 [I-D.wing-avt-dtls-srtp-key-transport] could be used to provide this 585 functionality in concert with the mechanisms described in this 586 specification. 588 6.10. Media over SRTP 590 Because DTLS's data transfer protocol is generic, it is less highly 591 optimized for use with RTP than is SRTP [RFC3711], which has been 592 specifically tuned for that purpose. DTLS-SRTP 593 [I-D.ietf-avt-dtls-srtp], has been defined to provide for the 594 negotiation of SRTP transport using a DTLS connection, thus allowing 595 the performance benefits of SRTP with the easy key management of 596 DTLS. The ability to reuse existing SRTP software and hardware 597 implementations may in some environments provide another important 598 motivation for using DTLS-SRTP instead of RTP over DTLS. 599 Implementations of this specification MUST support DTLS-SRTP 600 [I-D.ietf-avt-dtls-srtp]. 602 6.11. Best Effort Encryption 604 [I-D.ietf-sip-media-security-requirements] describes a requirement 605 for best effort encryption where SRTP is used where both endpoints 606 support it and key negotiation succeeds, otherwise RTP is used. 608 [I-D.ietf-mmusic-sdp-capability-negotiation] describes a mechanism 609 which can signal both RTP and SRTP as an alternative. This allows an 610 offerer to express a preference for SRTP, but RTP is the default and 611 will be understood by endpoints that do not understand SRTP or this 612 key exchange mechanism. Implementations of this document MUST 613 support [I-D.ietf-mmusic-sdp-capability-negotiation]. 615 7. Example Message Flow 617 Prior to establishing the session, both Alice and Bob generate self- 618 signed certificates which are used for a single session or, more 619 likely, reused for multiple sessions. In this example, Alice calls 620 Bob. In this example we assume that Alice and Bob share the same 621 proxy. 623 7.1. Basic Message Flow with Early Media and Identity 625 This example shows the SIP message flows where Alice acts as the 626 passive endpoint and Bob acts as the active endpoint meaning that as 627 soon as Bob receives the INVITE from Alice, with DTLS specified in 628 the 'm' line of the offer, Bob will begin to negotiate a DTLS 629 association with Alice for both RTP and RTCP streams. Early media 630 (RTP and RTCP) starts to flow from Bob to Alice as soon as Bob sends 631 the DTLS finished message to Alice. Bi-directional media (RTP and 632 RTCP) can flow after Alice receives the SIP 200 response and once 633 Alice has sent the DTLS finished message. 635 The SIP signaling from Alice to her proxy is transported over TLS to 636 ensure an integrity protected channel between Alice and her identity 637 service. Transport between proxies should also be protected somehow, 638 especially if Identity is not in use. 640 Alice Proxies Bob 641 |(1) INVITE | | 642 |---------------->| | 643 | |(2) INVITE | 644 | |----------------->| 645 | |(3) hello | 646 |<-----------------------------------| 647 |(4) hello | | 648 |----------------------------------->| 649 | |(5) finished | 650 |<-----------------------------------| 651 | |(6) media | 652 |<-----------------------------------| 653 |(7) finished | | 654 |----------------------------------->| 655 | |(8) 200 OK | 656 | <------------------| 657 |(9) 200 OK | | 658 |<----------------| | 659 | |(10) media | 660 |<---------------------------------->| 661 |(11) ACK | | 662 |----------------------------------->| 664 Message (1): INVITE Alice -> Proxy 666 This shows the initial INVITE from Alice to Bob carried over the 667 TLS transport protocol to ensure an integrity protected channel 668 between Alice and her proxy which acts as Alice's identity 669 service. Alice has requested to be either the active or passive 670 endpoint by specifying a=setup:actpass in the SDP. Bob chooses to 671 act as the DTLS client and will initiate the session. Also note 672 that there is a fingerprint attribute in the SDP. This is 673 computed from Alice's self-signed certificate. This offer 674 includes a default m-line offering RTP in case the answerer does 675 not support SRTP. However, the potential configuration utilizing 676 a transport of SRTP is preferred. See 677 [I-D.ietf-mmusic-sdp-capability-negotiation] for more details on 678 the details of SDP capability negotiation. 680 INVITE sip:bob@example.com SIP/2.0 681 To: 682 From: "Alice";tag=843c7b0b 683 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 684 Contact: 685 Call-ID: 6076913b1c39c212@REVMTEpG 686 CSeq: 1 INVITE 687 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 688 Max-Forwards: 70 689 Content-Type: application/sdp 690 Content-Length: xxxx 691 Supported: from-change 693 v=0 694 o=- 1181923068 1181923196 IN IP4 ua1.example.com 695 s=example1 696 c=IN IP4 ua1.example.com 697 a=setup:actpass 698 a=fingerprint: SHA-1 \ 699 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 700 t=0 0 701 m=audio 6056 RTP/AVP 0 702 a=sendrecv 703 a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP 704 a=pcfg:1 t=1 706 Message (2): INVITE Proxy -> Bob 708 This shows the INVITE being relayed to Bob from Alice (and Bob's) 709 proxy. Note that Alice's proxy has inserted an Identity and 710 Identity-Info header. This example only shows one element for 711 both proxies for the purposes of simplification. Bob verifies the 712 identity provided with the INVITE. 714 INVITE sip:bob@ua2.example.com SIP/2.0 715 To: 716 From: "Alice";tag=843c7b0b 717 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk 718 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 719 Record-Route: 720 Contact: 721 Call-ID: 6076913b1c39c212@REVMTEpG 722 CSeq: 1 INVITE 723 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 724 Max-Forwards: 69 725 Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 726 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC 727 HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= 728 Identity-Info: https://example.com/cert 729 Content-Type: application/sdp 730 Content-Length: xxxx 731 Supported: from-change 733 v=0 734 o=- 1181923068 1181923196 IN IP4 ua1.example.com 735 s=example1 736 c=IN IP4 ua1.example.com 737 a=setup:actpass 738 a=fingerprint: SHA-1 \ 739 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 740 t=0 0 741 m=audio 6056 RTP/AVP 0 742 a=sendrecv 743 a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP 744 a=pcfg:1 t=1 746 Message (3): ClientHello Bob -> Alice 748 Assuming that Alice's identity is valid, Line 3 shows Bob sending 749 a DTLS ClientHello(s) directly to Alice. In this case two DTLS 750 ClientHello messages would be sent to Alice: one to 751 ua1.example.com:6056 for RTP and another to port 6057 for RTCP, 752 but only one arrow is drawn for compactness of the figure. 754 Message (4): ServerHello+Certificate Alice -> Bob 756 Alice sends back a ServerHello, Certificate, ServerHelloDone for 757 both RTP and RTCP associations. Note that the same certificate is 758 used for both the RTP and RTCP associations. If RTP/RTCP 759 multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] were being used only 760 a single association would be required. 762 Message (5): Certificate Bob -> Alice 764 Bob sends a Certificate, ClientKeyExchange, CertificateVerify, 765 change_cipher_spec and Finished for both RTP and RTCP 766 associations. Again note that Bob uses the same server 767 certificate for both associations. 769 Message (6): Early Media Bob -> Alice 771 At this point, Bob can begin sending early media (RTP and RTCP) to 772 Alice. Note that Alice can't yet trust the media since the 773 fingerprint has not yet been received. This lack of trusted, 774 secure media is indicated to Alice via the UA user interface. 776 Message (7): Finished Alice -> Bob 778 After Message 7 is received by Bob, Alice sends change_cipher_spec 779 and Finished. 781 Message (8): 200 OK Bob -> Alice 783 When Bob answers the call, Bob sends a 200 OK SIP message which 784 contains the fingerprint for Bob's certificate. Bob signals the 785 actual transport protocol configuration of SRTP over DTLS in the 786 acfg parameter. 788 SIP/2.0 200 OK 789 To: ;tag=6418913922105372816 790 From: "Alice" ;tag=843c7b0b 791 Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk 792 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj 793 Record-Route: 794 Call-ID: 6076913b1c39c212@REVMTEpG 795 CSeq: 1 INVITE 796 Contact: 797 Content-Type: application/sdp 798 Content-Length: xxxx 799 Supported: from-change 801 v=0 802 o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com 803 s=example2 804 c=IN IP4 ua2.example.com 805 a=setup:active 806 a=fingerprint: SHA-1 \ 807 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 808 t=0 0 809 m=audio 12000 UDP/TLS/RTP/SAVP 0 810 a=acfg:1 t=1 812 Message (9): 200 OK Proxy -> Alice 814 Alice receives the message from her proxy and validates the 815 certificate presented in Message 7. The endpoint now shows Alice 816 that the call as secured. 818 Message (10): RTP+RTCP Alice -> Bob 820 At this point, Alice can also start sending RTP and RTCP to Bob. 822 Message (11): ACK Alice -> Bob 824 Finally, Alice sends the SIP ACK to Bob. 826 7.2. Basic Message Flow with Connected Identity (RFC 4916) 828 The previous example did not show the use of RFC 4916 for connected 829 identity. The following example does: 831 Alice Proxies Bob 832 |(1) INVITE | | 833 |---------------->| | 834 | |(2) INVITE | 835 | |----------------->| 836 | |(3) hello | 837 |<-----------------------------------| 838 |(4) hello | | 839 |----------------------------------->| 840 | |(5) finished | 841 |<-----------------------------------| 842 | |(6) media | 843 |<-----------------------------------| 844 |(7) finished | | 845 |----------------------------------->| 846 | |(8) 200 OK | 847 |<-----------------------------------| 848 |(9) ACK | | 849 |----------------------------------->| 850 | |(10) UPDATE | 851 | |<-----------------| 852 |(11) UPDATE | | 853 |<----------------| | 854 |(12) 200 OK | | 855 |---------------->| | 856 | |(13) 200 OK | 857 | |----------------->| 858 | |(14) media | 859 |<---------------------------------->| 861 The first 9 messages of this example are the same as before. 862 However, messages 10-13, performing the RFC 4916 UPDATE, are new. 864 Message (10): UPDATE Bob -> Proxy 866 Bob sends an RFC 4916 UPDATE towards Alice. This update contains 867 his fingerprint. Bob's UPDATE contains the same session 868 information that he provided in his 200 OK (message (8)). Note 869 that in principle an UPDATE here can be used to modify session 870 parameters. However, in this case it's being used solely to 871 confirm the fingerprint. 873 UPDATE sip:alice@ua1.example.com SIP/2.0 874 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj 875 To: "Alice" ;tag=843c7b0b 876 From ;tag=6418913922105372816 877 Route: 878 Call-ID: 6076913b1c39c212@REVMTEpG 879 CSeq: 2 UPDATE 880 Contact: 881 Content-Type: application/sdp 882 Content-Length: xxxx 883 Supported: from-change 884 Max-Forwards: 70 886 v=0 887 o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com 888 s=example2 889 c=IN IP4 ua2.example.com 890 a=setup:active 891 a=fingerprint: SHA-1 \ 892 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 893 t=0 0 894 m=audio 12000 UDP/TLS/RTP/SAVP 0 895 a=acfg:1 t=1 897 Message (11): UPDATE Proxy -> Alice 899 This shows the UPDATE being relayed to Alice from Bob (and Alice's 900 proxy). Note that Bob's proxy has inserted an Identity and 901 Identity-Info header. As above, we only show one element for both 902 proxies for purposes of simplification. Alice verifies the 903 identity provided [Note: the actual identity signatures here are 904 incorrect and provided merely as examples.] 906 UPDATE sip:alice@ua1.example.com SIP/2.0 907 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj 908 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj 909 To: "Alice" ;tag=843c7b0b 910 From ;tag=6418913922105372816 911 Call-ID: 6076913b1c39c212@REVMTEpG 912 CSeq: 2 UPDATE 913 Contact: 914 Content-Type: application/sdp 915 Content-Length: xxxx 916 Supported: from-change 917 Max-Forwards: 69 918 Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 919 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC 920 HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= 921 Identity-Info: https://example.com/cert 923 v=0 924 o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com 925 s=example2 926 c=IN IP4 ua2.example.com 927 a=setup:active 928 a=fingerprint: SHA-1 \ 929 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 930 t=0 0 931 m=audio 12000 UDP/TLS/RTP/SAVP 0 932 a=acfg:1 t=1 934 Message (12): 200 OK Alice -> Bob 936 This shows Alice's 200 OK response to Bob's UPDATE. Because Bob 937 has merely sent the same session parameters he sent in his 200 OK, 938 Alice can simply replay her view of the session parameters as 939 well. 941 SIP/2.0 200 OK 942 To: "Alice" ;tag=843c7b0b 943 From ;tag=6418913922105372816 944 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj 945 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj 946 Call-ID: 6076913b1c39c212@REVMTEpG 947 CSeq: 2 UPDATE 948 Contact: 949 Content-Type: application/sdp 950 Content-Length: xxxx 951 Supported: from-change 953 v=0 954 o=- 1181923068 1181923196 IN IP4 ua2.example.com 955 s=example1 956 c=IN IP4 ua2.example.com 957 a=setup:actpass 958 a=fingerprint: SHA-1 \ 959 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 960 t=0 0 961 m=audio 6056 RTP/AVP 0 962 a=sendrecv 963 a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP 964 a=pcfg:1 t=1 966 7.3. Basic Message Flow with STUN check for NAT Case 968 In the previous examples, the DTLS handshake has already completed by 969 the time Alice receives Bob's 200 OK (8). Therefore, no STUN check 970 is sent. However, if Alice had a NAT, then Bob's ClientHello might 971 get blocked by that NAT, in which case Alice would send the the STUN 972 check described in Section 6.7.1 upon receiving the 200 OK, as shown 973 below: 975 Alice Proxies Bob 976 |(1) INVITE | | 977 |---------------->| | 978 | |(2) INVITE | 979 | |----------------->| 980 | |(3) hello | 981 | X<-----------------| 982 | |(4) 200 OK | 983 |<-----------------------------------| 984 | (5) conn-check | | 985 |----------------------------------->| 986 | |(6) conn-response | 987 |<-----------------------------------| 988 | |(7) hello (rtx) | 989 |<-----------------------------------| 990 |(8) hello | | 991 |----------------------------------->| 992 | |(9) finished | 993 |<-----------------------------------| 994 | |(10) media | 995 |<-----------------------------------| 996 |(11) finished | | 997 |----------------------------------->| 998 | |(11) media | 999 |----------------------------------->| 1000 |(12) ACK | | 1001 |----------------------------------->| 1003 The messages here are the same as in the first example (for 1004 simplicity this example omits an UPDATE), with the following three 1005 new messages: 1007 Message (5): STUN connectivity-check Alice -> Bob 1009 Section 6.7.1 describes an approach to avoid an SBC interaction 1010 issue where the endpoints do not support ICE. Alice (the passive 1011 endpoint) sends a STUN connectivity check to Bob. This opens a 1012 pinhole in Alice's NAT/firewall. 1014 Message (6): STUN connectivity-check response Bob -> Alice 1016 Bob (the active endpoint) sends a response to the STUN 1017 connectivity check (Message 3) to Alice. This tells Alice that 1018 her connectivity check has succeeded and she can stop the 1019 retransmit state machine. 1021 Message (7): Hello (retransmit) Bob -> Alice 1023 Bob retransmits his DTLS ClientHello which now passes through the 1024 pinhole created in Alice's firewall. At this point, the DTLS 1025 handshake proceeds as before. 1027 8. Security Considerations 1029 DTLS or TLS media signalled with SIP requires a way to ensure that 1030 the communicating peers' certificates are correct. 1032 The standard TLS/DTLS strategy for authenticating the communicating 1033 parties is to give the server (and optionally the client) a PKIX 1034 [RFC5280] certificate. The client then verifies the certificate and 1035 checks that the name in the certificate matches the server's domain 1036 name. This works because there are a relatively small number of 1037 servers with well-defined names; a situation which does not usually 1038 occur in the VoIP context. 1040 The design described in this document is intended to leverage the 1041 authenticity of the signaling channel (while not requiring 1042 confidentiality). As long each side of the connection can verify the 1043 integrity of the SDP received from the other side, then the DTLS 1044 handshake cannot be hijacked via a man-in-the-middle attack. This 1045 integrity protection is easily provided by the caller to the callee 1046 (see Alice to Bob in Section 7) via the SIP Identity [RFC4474] 1047 mechanism. Other mechanisms, such as the S/MIME mechanism described 1048 in RFC 3261, or perhaps future mechanisms yet to be defined could 1049 also serve this purpose. 1051 While this mechanism can still be used without such integrity 1052 mechanisms, the security provided is limited to defense against 1053 passive attack by intermediaries. An active attack on the signaling 1054 plus an active attack on the media plane can allow an attacker to 1055 attack the connection (R-SIG-MEDIA in the notation of 1056 [I-D.ietf-sip-media-security-requirements]). 1058 8.1. Responder Identity 1060 SIP Identity does not support signatures in responses. Ideally Alice 1061 would want to know that Bob's SDP had not been tampered with and who 1062 it was from so that Alice's User Agent could indicate to Alice that 1063 there was a secure phone call to Bob. [RFC4916] defines an approach 1064 for a UA to supply its identity to its peer UA and for this identity 1065 to be signed by an authentication service. For example, using this 1066 approach, Bob sends an answer, then immediately follows up with an 1067 UPDATE that includes the fingerprint and uses the SIP Identity 1068 mechanism to assert that the message is from Bob@example.com. The 1069 downside of this approach is that it requires the extra round trip of 1070 the UPDATE. However, it is simple and secure even when not all of 1071 the proxies are trusted. In this example, Bob only needs to trust 1072 his proxy. Offerers SHOULD support this mechanism and Answerers 1073 SHOULD use it. 1075 In some cases, answerers will not send an UPDATE and in many calls, 1076 some media will be sent before the UPDATE is received. In these 1077 cases, no integrity is provided for the fingerprint from Bob to 1078 Alice. In this approach, an attacker that was on the signaling path 1079 could tamper with the fingerprint and insert themselves as a man-in- 1080 the-middle on the media. Alice would know that she had a secure call 1081 with someone but would not know if it was with Bob or a man-in-the- 1082 middle. Bob would know that an attack was happening. The fact that 1083 one side can detect this attack means that in most cases where Alice 1084 and Bob both wish the communications to be encrypted there is not a 1085 problem. Keep in mind that in any of the possible approaches Bob 1086 could always reveal the media that was received to anyone. We are 1087 making the assumption that Bob also wants secure communications. In 1088 this do nothing case, Bob knows the media has not been tampered with 1089 or intercepted by a third party and that it is from 1090 Alice@example.com. Alice knows that she is talking to someone and 1091 that whoever that is has probably checked that the media is not being 1092 intercepted or tampered with. This approach is certainly less than 1093 ideal but very usable for many situations. 1095 8.2. SIPS 1097 If SIP Identity is not used, but the signaling is protected by SIPS, 1098 the security guarantees are weaker. Some security is still provided 1099 as long as all proxies are trusted. This provides integrity for the 1100 fingerprint in a chain-of-trust security model. Note, however, that 1101 if the proxies are not trusted, then the level of security provided 1102 is limited. 1104 8.3. S/MIME 1106 RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that 1107 could be used to sign that the fingerprint was from Bob. This would 1108 be secure. 1110 8.4. Continuity of Authentication 1112 One desirable property of a secure media system is to provide 1113 continuity of authentication: being able to ensure cryptographically 1114 that you are talking to the same person as before. With DTLS, 1115 continuity of authentication is achieved by having each side use the 1116 same public key/self-signed certificate for each connection (at least 1117 with a given peer entity). It then becomes possible to cache the 1118 credential (or its hash) and verify that it is unchanged. Thus, once 1119 a single secure connection has been established, an implementation 1120 can establish a future secure channel even in the face of future 1121 insecure signalling. 1123 In order to enable continuity of authentication, implementations 1124 SHOULD attempt to keep a constant long-term key. Verifying 1125 implementations SHOULD maintain a cache of the key used for each peer 1126 identity and alert the user if that key changes. 1128 8.5. Short Authentication String 1130 An alternative available to Alice and Bob is to use human speech to 1131 verify each others' identity and then to verify each others' 1132 fingerprints also using human speech. Assuming that it is difficult 1133 to impersonate another's speech and seamlessly modify the audio 1134 contents of a call, this approach is relatively safe. It would not 1135 be effective if other forms of communication were being used such as 1136 video or instant messaging. DTLS supports this mode of operation. 1137 The minimal secure fingerprint length is around 64 bits. 1139 ZRTP [I-D.zimmermann-avt-zrtp] includes Short Authentication String 1140 mode in which a unique per-connection bitstring is generated as part 1141 of the cryptographic handshake. The SAS can be as short as 25 bits 1142 and so is somewhat easier to read. DTLS does not natively support 1143 this mode. Based on the level of deployment interest a TLS extension 1144 [RFC4366] could provide support for it. Note that SAS schemes only 1145 work well when the endpoints recognize each other's voices, which is 1146 not true in many settings (e.g., call centers). 1148 8.6. Limits of Identity Assertions 1150 When RFC 4474 is used to bind the media keying material to the SIP 1151 signalling, the assurances about the provenance and security of the 1152 media are only as good as those for the signalling. There are two 1153 important cases to note here: 1155 o RFC 4474 assumes that the proxy with the certificate "example.com" 1156 controls the namespace "example.com". Therefore the RFC 4474 1157 authentication service which is authoritative for a given 1158 namespace can control which user is assigned each name. Thus, the 1159 authentication service can take an address formerly assigned to 1160 Alice and transfer it to Bob. This is an intentional design 1161 feature of RFC 4474 and a direct consequence of the SIP namespace 1162 architecture. 1163 o When phone number URIs (e.g., 1164 'sip:+17005551008@chicago.example.com' or 1165 'sip:+17005551008@chicago.example.com;user=phone') are used, there 1166 is no structural reason to trust that the domain name is 1167 authoritative for a given phone number, although individual 1168 proxies and UAs may have private arrangements that allow them to 1169 trust other domains. This is a structural issue in that PSTN 1170 elements are trusted to assert their phone number correctly and 1171 that there is no real concept of a given entity being 1172 authoritative for some number space. 1174 In both of these cases, the assurances that DTLS-SRTP provides in 1175 terms of data origin integrity and confidentiality are necessarily no 1176 better than SIP provides for signalling integrity when RFC 4474 is 1177 used. Implementors should therefore take care not to indicate 1178 misleading peer identity information in the user interface. e.g. If 1179 the peer's identity is sip:+17005551008@chicago.example.com, it is 1180 not sufficient to display that the identity of the peer as 1181 +17005551008, unless there is some policy that states that the domain 1182 "chicago.example.com" is trusted to assert the E.164 numbers it is 1183 asserting. In cases where the UA can determine that the peer 1184 identity is clearly an E.164 number, it may be less confusing to 1185 simply identify the call as encrypted but to an unknown peer. 1187 In addition, some middleboxes (B2BUAs and Session Border Controllers) 1188 are known to modify portions of the SIP message which are included in 1189 the RFC 4474 signature computation, thus breaking the signature. 1190 This sort of man-in-the-middle operation is precisely the sort of 1191 message modification that 4474 is intended to detect. In cases where 1192 the middlebox is itself permitted to generate valid RFC 4474 1193 signatures (e.g., it is within the same administrative domain as the 1194 RFC 4474 authentication service), then it may generate a new 1195 signature on the modified message. Alternately, the middlebox may be 1196 able to sign with some other identity that it is permitted to assert. 1197 Otherwise, the recipient cannot rely on the RFC 4474 Identity 1198 assertion and the UA MUST NOT indicate to the user that a secure call 1199 has been established to the claimed identity. Implementations which 1200 are configured to only establish secure calls SHOULD terminate the 1201 call in this case. 1203 If SIP Identity or an equivalent mechanism is not used, then only 1204 protection against attackers who cannot actively change the signaling 1205 is provided. While this is still superior to previous mechanisms, 1206 the security provided is inferior to that provided if integrity is 1207 provided for the signaling. 1209 8.7. Third Party Certificates 1211 This specification does not depend on the certificates being held by 1212 endpoints being independently verifiable (e.g., being issued by a 1213 trusted third party.) However, there is no limitation on such 1214 certificates being used. Aside from the difficulty of obtaining such 1215 certificates, it is not clear what identities those certificates 1216 would contain---RFC 3261 specifies a convention for S/MIME 1217 certificates which could also be used here, but that has seen only 1218 minimal deployment. However, in closed or semi-closed contexts where 1219 such a convention can be established, third party certificates can 1220 reduce the reliance on trusting even proxies in the endpoint's 1221 domains. 1223 8.8. Perfect Forward Secrecy 1225 One concern about the use of a long-term key is that compromise of 1226 that key may lead to compromise of past communications. In order to 1227 prevent this attack, DTLS supports modes with Perfect Forward Secrecy 1228 using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites. 1229 When these modes are in use, the system is secure against such 1230 attacks. Note that compromise of a long-term key may still lead to 1231 future active attacks. If this is a concern, a backup authentication 1232 channel such as manual fingerprint establishment or a short 1233 authentication string should be used. 1235 9. IANA Considerations 1237 This specification does not require any IANA actions. 1239 10. Acknowledgments 1241 Cullen Jennings contributed substantial text and comments to this 1242 document. This document benefited from discussions with Francois 1243 Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful 1244 comments by Flemming Andreasen, Jonathan Rosenberg, Rohan Mahy, David 1245 McGrew, Miguel Garcia, Steffen Fries, Brian Stucker, Robert Gilman, 1246 David Oran, and Peter Schneider. 1248 We would like to thank Thomas Belling, Guenther Horn, Steffen Fries, 1249 Brian Stucker, Francois Audet, Dan Wing, Jari Arkko, and Vesa 1250 Lehtovirta for their input regarding traversal of SBCs. 1252 11. References 1253 11.1. Normative References 1255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1256 Requirement Levels", BCP 14, RFC 2119, March 1997. 1258 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1259 A., Peterson, J., Sparks, R., Handley, M., and E. 1260 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1261 June 2002. 1263 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1264 with Session Description Protocol (SDP)", RFC 3264, 1265 June 2002. 1267 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1268 Housley, R., and W. Polk, "Internet X.509 Public Key 1269 Infrastructure Certificate and Certificate Revocation List 1270 (CRL) Profile", RFC 5280, May 2008. 1272 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1273 Initiation Protocol (SIP)", RFC 3323, November 2002. 1275 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1276 Jacobson, "RTP: A Transport Protocol for Real-Time 1277 Applications", STD 64, RFC 3550, July 2003. 1279 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1280 the Session Description Protocol (SDP)", RFC 4145, 1281 September 2005. 1283 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1284 Security", RFC 4347, April 2006. 1286 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1287 Authenticated Identity Management in the Session 1288 Initiation Protocol (SIP)", RFC 4474, August 2006. 1290 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1291 Description Protocol", RFC 4566, July 2006. 1293 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1294 Transport Layer Security (TLS) Protocol in the Session 1295 Description Protocol (SDP)", RFC 4572, July 2006. 1297 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1298 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1299 October 2008. 1301 11.2. Informational References 1303 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1304 and RTP Control Protocol (RTCP) Packets over Connection- 1305 Oriented Transport", RFC 4571, July 2006. 1307 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1308 Extensions to the Session Initiation Protocol (SIP) for 1309 Asserted Identity within Trusted Networks", RFC 3325, 1310 November 2002. 1312 [I-D.ietf-mmusic-ice] 1313 Rosenberg, J., "Interactive Connectivity Establishment 1314 (ICE): A Protocol for Network Address Translator (NAT) 1315 Traversal for Offer/Answer Protocols", 1316 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1318 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1319 Carrara, "Key Management Extensions for Session 1320 Description Protocol (SDP) and Real Time Streaming 1321 Protocol (RTSP)", RFC 4567, July 2006. 1323 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1324 Description Protocol (SDP) Security Descriptions for Media 1325 Streams", RFC 4568, July 2006. 1327 [I-D.zimmermann-avt-zrtp] 1328 Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 1329 Path Key Agreement for Secure RTP", 1330 draft-zimmermann-avt-zrtp-15 (work in progress), 1331 March 2009. 1333 [I-D.mcgrew-srtp-ekt] 1334 McGrew, D., "Encrypted Key Transport for Secure RTP", 1335 draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. 1337 [I-D.ietf-avt-dtls-srtp] 1338 McGrew, D. and E. Rescorla, "Datagram Transport Layer 1339 Security (DTLS) Extension to Establish Keys for Secure 1340 Real-time Transport Protocol (SRTP)", 1341 draft-ietf-avt-dtls-srtp-07 (work in progress), 1342 February 2009. 1344 [I-D.ietf-sip-media-security-requirements] 1345 Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1346 "Requirements and Analysis of Media Security Management 1347 Protocols", draft-ietf-sip-media-security-requirements-09 1348 (work in progress), January 2009. 1350 [I-D.ietf-mmusic-sdp-capability-negotiation] 1351 Andreasen, F., "SDP Capability Negotiation", 1352 draft-ietf-mmusic-sdp-capability-negotiation-09 (work in 1353 progress), July 2008. 1355 [I-D.ietf-avt-rtp-and-rtcp-mux] 1356 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1357 Control Packets on a Single Port", 1358 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 1359 August 2007. 1361 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1362 Provisional Responses in Session Initiation Protocol 1363 (SIP)", RFC 3262, June 2002. 1365 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1366 and T. Wright, "Transport Layer Security (TLS) 1367 Extensions", RFC 4366, April 2006. 1369 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1370 Protocol (SIP)", RFC 4916, June 2007. 1372 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1373 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1374 RFC 3711, March 2004. 1376 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1377 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1378 August 2004. 1380 [I-D.wing-sipping-srtp-key] 1381 Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. 1382 Johnston, "Secure Media Recording and Transcoding with the 1383 Session Initiation Protocol", 1384 draft-wing-sipping-srtp-key-04 (work in progress), 1385 October 2008. 1387 [I-D.wing-avt-dtls-srtp-key-transport] 1388 Wing, D., "DTLS-SRTP Key Transport", 1389 draft-wing-avt-dtls-srtp-key-transport-02 (work in 1390 progress), July 2008. 1392 [I-D.ietf-mmusic-media-path-middleboxes] 1393 Stucker, B. and H. Tschofenig, "Analysis of Middlebox 1394 Interactions for Signaling Protocol Communication along 1395 the Media Path", 1396 draft-ietf-mmusic-media-path-middleboxes-01 (work in 1397 progress), July 2008. 1399 [I-D.ietf-sip-ua-privacy] 1400 Munakata, M., Schubert, S., and T. Ohba, "UA-Driven 1401 Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-06 1402 (work in progress), March 2009. 1404 Appendix A. Requirements Analysis 1406 [I-D.ietf-sip-media-security-requirements] describes security 1407 requirements for media keying. This section evaluates this proposal 1408 with respect to each requirement. 1410 A.1. Forking and retargeting (R-FORK-RETARGET, R-BEST-SECURE, 1411 R-DISTINCT) 1413 In this draft, the SDP offer (in the INVITE) is simply an 1414 advertisement of the capability to do security. This advertisement 1415 does not depend on the identity of the communicating peer, so forking 1416 and retargeting work work when all the endpoints will do SRTP. When 1417 a mix of SRTP and non-SRTP endpoints are present, we use the SDP 1418 capabilities mechanism currently being defined 1419 [I-D.ietf-mmusic-sdp-capability-negotiation] to transparently 1420 negotiate security where possible. Because DTLS establishes a new 1421 key for each session, only the entity with which the call is finally 1422 established gets the media encryption keys (R3). 1424 A.2. Distinct Cryptographic Contexts (R-DISTINCT) 1426 DTLS performs a new DTLS handshake with each endpoint, which 1427 establishes distinct keys and cryptographic contexts for each 1428 endpoint. 1430 A.3. Reusage of a Security Context (R-REUSE) 1432 DTLS allows sessions to be resumed with the 'TLS session resumption' 1433 functionality. This feature can be used to lower the amount of 1434 cryptographic computation that needs to be done when two peers re- 1435 initiates the communication. See [I-D.ietf-avt-dtls-srtp] for more 1436 on session resumption in this context. 1438 A.4. Clipping (R-AVOID-CLIPPING) 1440 Because the key establishment occurs in the media plane, media need 1441 not be clipped before the receipt of the SDP answer. Note, however, 1442 that only confidentiality is provided until the offerer receives the 1443 answer: the answerer knows that they are not sending data to an 1444 attacker but the offerer cannot know that they are receiving data 1445 from the answerer. 1447 A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) 1449 The public key algorithms used by DTLS ciphersuites, such as RSA, 1450 Diffie-Hellman, and Elliptic Curve Diffie-Hellman, are secure against 1451 passive attacks. 1453 A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) 1455 DTLS provides protection against passive attacks by adversaries on 1456 the signaling path since only a fingerprint is exchanged using SIP 1457 signaling. 1459 A.7. (R-SIG-MEDIA, R-ACT-ACT) 1461 An attacker who controls the media channel but not the signalling 1462 channel can perform a MITM attack on the DTLS handshake but this will 1463 change the certificates which will cause the fingerprint check to 1464 fail. Thus, any successful attack requires that the attacker modify 1465 the signalling messages to replace the fingerprints. 1467 If RFC 4474 Identity or an equivalent mechanism is used, a attacker 1468 who controls the signalling channel at any point between the proxies 1469 performing the Identity signatures cannot modify the fingerprints 1470 without invalidating the signature. Thus, even an attacker who 1471 controls both signalling and media paths cannot successfully attack 1472 the media traffic. Note that the channel between the UA and the 1473 authentication service MUST be secured and the authentication service 1474 MUST verify the UA's identity in order for this mechanism to be 1475 secure. 1477 Note that an attacker who controls the authentication service can 1478 impersonate the UA using that authentication service. This is an 1479 intended feature of SIP Identity--the authentication service owns the 1480 namespace and therefore defines which user has which identity. 1482 A.8. Binding to Identifiers (R-ID-BINDING) 1484 When an end-to-end mechanism such as SIP-Identity [RFC4474] and SIP- 1485 Connected-Identity [RFC4916] or S/MIME are used, they bind the 1486 endpoint's certificate fingerprints to the From: address in the 1487 signalling. The fingerprint is covered by the Identity signature. 1488 When other mechanisms (e.g., SIPS) are used, then the binding is 1489 correspondingly weaker. 1491 A.9. Perfect Forward Secrecy (R-PFS) 1493 DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher 1494 suites which provide PFS. 1496 A.10. Algorithm Negotiation (R-COMPUTE) 1498 DTLS negotiates cipher suites before performing significant 1499 cryptographic computation and therefore supports algorithm 1500 negotiation and multiple cipher suites without additional 1501 computational expense. 1503 A.11. RTP Validity Check (R-RTP-VALID) 1505 DTLS packets do not pass the RTP validity check. The first byte of a 1506 DTLS packet is the content type and All current DTLS content types 1507 have the first two bits set to zero, resulting in a version of 0, 1508 thus failing the first validity check. DTLS packets can also be 1509 distinguished from STUN packets. See [I-D.ietf-avt-dtls-srtp] for 1510 details on demultiplexing. 1512 A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) 1514 Third party certificates are not required because signalling (e.g., 1515 [RFC4474]) is used to authenticate the certificates used by DTLS. 1516 However, if the parties share an authentication infrastructure that 1517 is compatible with TLS (3rd party certificates or shared keys) it can 1518 be used. 1520 A.13. FIPS 140-2 (R-FIPS) 1522 TLS implementations already may be FIPS 140-2 approved and the 1523 algorithms used here are consistent with the approval of DTLS and 1524 DTLS-SRTP. 1526 A.14. Linkage between Keying Exchange and SIP Signaling (R-ASSOC) 1528 The signaling exchange is linked to the key management exchange using 1529 the fingerprints carried in SIP and the certificates are exchanged in 1530 DTLS. 1532 A.15. Denial of Service Vulnerability (R-DOS) 1534 DTLS offers some degree of DoS protection as a built-in feature (see 1535 Section 4.2.1 or RFC 4347). 1537 A.16. Crypto-Agility (R-AGILITY) 1539 DTLS allows ciphersuites to be negotiated and hence new algorithms 1540 can be incrementally deployed. Work on replacing the fixed MD5/SHA-1 1541 key derivation function is ongoing. 1543 A.17. Downgrading Protection (R-DOWNGRADE) 1545 DTLS provides protection against downgrading attacks since the 1546 selection of the offered ciphersuites is confirmed in a later stage 1547 of the handshake. This protection is efficient unless an adversary 1548 is able to break a ciphersuite in real-time. RFC 4474 is able to 1549 prevent an active attacker on the signalling path from downgrading 1550 the call from SRTP to RTP. 1552 A.18. Media Security Negotation (R-NEGOTIATE) 1554 DTLS allows a User Agent to negotiate media security parameters for 1555 each individual session. 1557 A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) 1559 The DTLS-SRTP framework does not rely on SIP; every protocol that is 1560 capable of exchanging a fingerprint and the media description can be 1561 secured. 1563 A.20. Media Recording (R-RECORDING) 1565 An extension, see [I-D.wing-sipping-srtp-key], has been specified to 1566 support media recording that does not require intermediaries to act 1567 as a MITM. 1569 When media recording is done by intermediaries then they need to act 1570 as a MITM. 1572 A.21. Interworking with Intermediaries (R-TRANSCODER) 1574 In order to interface with any intermediary that transcodes the 1575 media, the transcoder must have access to the keying material and be 1576 treated as an endpoint for the purposes of this document. 1578 A.22. PSTN Gateway Termination (R-PSTN) 1580 The DTLS-SRTP framework allows the media security to terminate at a 1581 PSTN gateway. This does not provide end-to-end security, but is 1582 consistent with the security goals of this framework because the 1583 gateway is authorized to speak for the PSTN namespace. 1585 A.23. R-ALLOW-RTP 1587 DTLS-SRTP allows RTP media to be received by the calling party until 1588 SRTP has been negotiated with the answerer, after which SRTP is 1589 preferred over RTP. 1591 A.24. R-HERFP 1593 The Heterogeneous Error Response Forking Problem (HERFP) is not 1594 applicable to DTLS-SRTP since the key exchange protocol will be 1595 executed along the media path and hence error messages are 1596 communicated along this path and proxies do not need to progress 1597 them. 1599 Authors' Addresses 1601 Jason Fischl 1602 CounterPath Corporation 1603 Suite 300, One Bentall Centre, 505 Burrard Street 1604 Vancouver, BC V7X 1M3 1605 Canada 1607 Phone: +1 604 320-3340 1608 Email: jason@counterpath.com 1610 Hannes Tschofenig 1611 Nokia Siemens Networks 1612 Otto-Hahn-Ring 6 1613 Munich, Bavaria 81739 1614 Germany 1616 Email: Hannes.Tschofenig@nsn.com 1617 URI: http://www.tschofenig.com 1619 Eric Rescorla 1620 RTFM, Inc. 1621 2064 Edgewood Drive 1622 Palo Alto, CA 94303 1623 USA 1625 Email: ekr@rtfm.com