idnits 2.17.1 draft-fischl-sipping-media-dtls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1103. 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 : ---------------------------------------------------------------------------- == There are 12 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2007) is 6261 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) == Missing Reference: 'TODO' is mentioned on line 755, but not defined ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-04) exists of draft-fischl-mmusic-sdp-dtls-02 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-02 == Outdated reference: A later version (-06) exists of draft-mcgrew-srtp-ekt-02 == Outdated reference: A later version (-05) exists of draft-wing-media-security-requirements-00 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-05 == Outdated reference: A later version (-07) exists of draft-ietf-avt-rtp-and-rtcp-mux-03 -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Fischl 3 Internet-Draft CounterPath Solutions, Inc. 4 Intended status: Standards Track H. Tschofenig 5 Expires: September 7, 2007 6 E. Rescorla 7 Network Resonance 8 March 6, 2007 10 Datagram Transport Layer Security (DTLS) Protocol for Protection of 11 Media Traffic Established with the Session Initiation Protocol 12 draft-fischl-sipping-media-dtls-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 7, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document specifies how to use the Session Initiation Protocol 46 (SIP) to establish secure media sessions using or over the Datagram 47 Transport Layer Security (DTLS) protocol. It describes a mechanism 48 of transporting a fingerprint attribute in the Session Description 49 Protocol (SDP) that identifies the key that will be presented during 50 the DTLS handshake. It relies on the SIP identity mechanism to 51 ensure the integrity of the fingerprint attribute. This allows the 52 establishment of media security along the media path. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Verifying Certificate Integrity . . . . . . . . . . . . . . . 6 61 6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 7 62 6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 8 63 6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 9 66 6.5. Session Modification . . . . . . . . . . . . . . . . . . . 9 67 6.6. UDP Payload De-multiplex . . . . . . . . . . . . . . . . . 9 68 6.7. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.8. Conference Servers and Shared Encryptions Contexts . . . . 10 70 6.9. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 10 71 7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 10 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 8.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8.4. Single-sided Verification . . . . . . . . . . . . . . . . 17 77 8.5. Continuity of Authentication . . . . . . . . . . . . . . . 17 78 8.6. Short Authentication String . . . . . . . . . . . . . . . 18 79 8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 18 80 9. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 18 81 9.1. Forking and retargeting (R1, R2, R3) . . . . . . . . . . . 18 82 9.2. Clipping (R5) . . . . . . . . . . . . . . . . . . . . . . 19 83 9.3. Passive Attacks (R6) . . . . . . . . . . . . . . . . . . . 19 84 9.4. Perfect Forward Secrecy (R7) . . . . . . . . . . . . . . . 19 85 9.5. Algorithm Negotiation (R8, R9) . . . . . . . . . . . . . . 19 86 9.6. Endpoint Idenfification When Forking (R10) . . . . . . . . 19 87 9.7. 3rd Party Certificates (R11) . . . . . . . . . . . . . . . 19 88 9.8. FIPS 140-2 (R12) . . . . . . . . . . . . . . . . . . . . . 20 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 93 12.2. Informational References . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 95 Intellectual Property and Copyright Statements . . . . . . . . . . 25 97 1. Introduction 99 The Session Initiation Protocol (SIP) RFC 3261 [RFC3261] and the 100 Session Description Protocol (SDP) [I-D.ietf-mmusic-sdp-new] are used 101 to set up multimedia sessions or calls. SDP is also used to set up 102 TCP [I-D.ietf-mmusic-sdp-comedia] and additionally TCP/TLS 103 connections for usage with media sessions 104 [I-D.ietf-mmusic-comedia-tls]. The Real-Time Protocol (RTP) RFC 3550 105 [RFC3550] is used to transmit real time media on top of UDP, TCP 106 [I-D.ietf-avt-rtp-framing-contrans], and TLS 107 [I-D.ietf-mmusic-comedia-tls]. Datagram TLS RFC 4347 [RFC4347] was 108 introduced to allow TLS functionality to be applied to datagram 109 transport protocols, such as UDP and DCCP. This draft provides 110 guidelines on how to use and to support for (a) transmission of media 111 over DTLS and (b) to establish SRTP security using extensions to DTLS 112 (see [I-D.mcgrew-tls-srtp]). 114 The goal of this work is to provide a key negotiation technique that 115 allows encrypted communication between devices with no prior 116 relationships. It also does not require the devices to trust every 117 call signaling element that was involved in routing or session setup. 118 This approach does not require any extra effort by end users and does 119 not require deployment of certificates to all devices that are signed 120 by a well-known certificate authority. 122 The media is transported over a mutually authenticated DTLS session 123 where both sides have certificates. The certificate fingerprints are 124 sent in SDP over SIP as part of the offer/answer exchange. The SIP 125 Identity mechanism [I-D.ietf-sip-identity] is used to provide 126 integrity for the fingerprints. It is very important to note that 127 certificates are being used purely as a carrier for the public keys 128 of the peers. This is required because DTLS does not have a mode for 129 carrying bare keys, but it is purely an issue of formatting. The 130 certificates can be self-signed and completely self-generated. All 131 major TLS stacks have the capability to generate such certificates on 132 demand. However, third party certificates MAY also be used for extra 133 security. 135 This approach differs from previous attempts to secure media traffic 136 where the authentication and key exchange protocol (e.g., MIKEY RFC 137 3830 [RFC3830]) is piggybacked in the signaling message exchange. 138 With this approach, establishing the protection of the media traffic 139 between the endpoints is done by the media endpoints without 140 involving the SIP/SDP communication. It allows RTP and SIP to be 141 used in the usual manner when there is no encrypted media. 143 In SIP, typically the caller sends an offer and the callee may 144 subsequently send one-way media back to the caller before a SIP 145 answer is received by the caller. The approach in this 146 specification, where the media key negotiation is decoupled from the 147 SIP signaling, allows the early media to be set up before the SIP 148 answer is received while preserving the important security property 149 of allowing the media sender to choose some of the keying material 150 for the media. This also allows the media sessions to be changed, 151 re-keyed, and otherwise modified after the initial SIP signaling 152 without any additional SIP signaling. 154 Design decisions that influence the applicability of this 155 specification are discussed in Section 3. 157 2. Overview 159 Endpoints wishing to set up an RTP media session do so by exchanging 160 offers and answers in SDP messages over SIP. In a typical use case, 161 two endpoints would negotiate to transmit audio data over RTP using 162 the UDP protocol. 164 Figure 1 shows a typical message exchange in the SIP Trapezoid. 166 +-----------+ +-----------+ 167 |SIP | SIP/SDP |SIP | 168 +------>|Proxy |<---------->|Proxy |<------+ 169 | |Server X | (+finger- |Server Y | | 170 | +-----------+ print, +-----------+ | 171 | +auth.id.) | 172 | SIP/SDP SIP/SDP | 173 | (+fingerprint) (+fingerprint,| 174 | +auth.id.) | 175 | | 176 v v 177 +-----------+ Datagram TLS +-----------+ 178 |SIP | <---------------------------------> |SIP | 179 |User Agent | Media |User Agent | 180 |Alice@X | <=================================> |Bob@Y | 181 +-----------+ +-----------+ 183 Legend: 184 <--->: Signaling Traffic 185 <===>: Data Traffic 187 Figure 1: DTLS Usage in the SIP Trapezoid 189 Consider Alice wanting to set up an encrypted audio session with Bob. 190 Both Bob and Alice could use public-key based authentication in order 191 to establish a confidentiality protected channel using DTLS. 193 Since providing mutual authentication between two arbitrary end 194 points on the Internet using public key based cryptography tends to 195 be problematic, we consider more deployment friendly alternatives. 196 This document uses one approach and several others are discussed in 197 Section 8. 199 Alice sends an SDP offer to Bob over SIP. If Alice uses only self- 200 signed certificates for the communication with Bob, a fingerprint is 201 included in the SDP offer/answer exchange. This fingerprint is 202 integrity protected using the identity mechanism defined in 203 Enhancements for Authenticated Identity Management in SIP 204 [I-D.ietf-sip-identity]. When Bob receives the offer, Bob 205 establishes a mutually authenticated DTLS connection with Alice. At 206 this point Bob can begin sending media to Alice. Once Bob accepts 207 Alice's offer and sends an SDP answer to Alice, Alice can begin 208 sending confidential media to Bob. 210 3. Motivation 212 Although there is already prior work in this area (e.g., Secure 213 Descriptions for SDP [I-D.ietf-mmusic-sdescriptions], Key Management 214 Extensions [I-D.ietf-mmusic-kmgmt-ext] combined with MIKEY RFC 3830 215 [RFC3830] for authentication and key exchange), this specification is 216 motivated as follows: 218 o TLS will be used to offer security for connection-oriented media. 219 The design of TLS is well-known and implementations are widely 220 available. 221 o This approach deals with forking and early media without requiring 222 support for PRACK RFC 3262 [RFC3262] while preserving the 223 important security property of allowing the offerer to choose 224 keying material for encrypting the media. 225 o The establishment of security protection for the media path is 226 also provided along the media path and not over the signaling 227 path. In many deployment scenarios, the signaling and media 228 traffic travel along a different path through the network. 229 o This solution works even when the SIP proxies downstream of the 230 identity service are not trusted. There is no need to reveal keys 231 in the SIP signaling or in the SDP message exchange. In order for 232 SDES and MIKEY to provide this security property, they require 233 distribution of certificates to the endpoints that are signed by 234 well known certificate authorities. SDES further requires that 235 the endpoints employ S/MIME to encrypt the keying material. 236 o In this method, SSRC collisions do not result in any extra SIP 237 signaling. 239 o Many SIP endpoints already implement TLS. The changes to existing 240 SIP and RTP usage are minimal even when DTLS-SRTP 241 [I-D.mcgrew-tls-srtp] is used. 243 4. Terminology 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in RFC 2119 [RFC2119]. 249 DTLS/TLS uses the term "session" to refer to a long-lived set of 250 keying material that spans associations. In this document, 251 consistent with SIP/SDP usage, we use it to refer to a multimedia 252 session and use the term "TLS session" to refer to the TLS construct. 253 We use the term "association" to refer to a particular DTLS 254 ciphersuite and keying material set. For consistency with other SIP/ 255 SDP usage, we use the term "connection" when what's being referred to 256 is a multimedia stream that is not specifically DTLS/TLS. 258 In this document, the term "Mutual DTLS" indicates that both the DTLS 259 client and server present certificates even if one or both 260 certificates are self-signed. 262 5. Verifying Certificate Integrity 264 The offer/answer model, defined in RFC 3264 [RFC3264], is used by 265 protocols like the Session Initiation Protocol (SIP) RFC 3261 266 [RFC3261] to set up multimedia sessions. In addition to the usual 267 contents of an SDP [I-D.ietf-mmusic-sdp-new] message, each 'm' line 268 will also contain several attributes as specified in 269 [I-D.fischl-mmusic-sdp-dtls], RFC 4145 [RFC4145] and 270 [I-D.ietf-mmusic-comedia-tls]. 272 The endpoint MUST use the setup and connection attributes defined in 273 RFC 4145 [RFC4145]. A setup:active endpoint will act as a DTLS 274 client and a setup:passive endpoint will act as a DTLS server. The 275 connection attribute indicates whether or not to reuse an existing 276 DTLS association. 278 The endpoint MUST use the certificate fingerprint attribute as 279 specified in [I-D.ietf-mmusic-comedia-tls]. 281 The setup:active endpoint establishes a DTLS association with the 282 setup:passive endpoint RFC 4145 [RFC4145]. Typically, the receiver 283 of the SIP INVITE request containing an offer will take the setup: 284 active role. 286 The certificate presented during the DTLS handshake MUST match the 287 fingerprint exchanged via the signaling path in the SDP. The 288 security properties of this mechanism are described in Section 8. 290 If the fingerprint does not match the hashed certificate then the 291 endpoint MUST tear down the media session immediately. 293 When an endpoint wishes to set up a secure media session with another 294 endpoint it sends an offer in a SIP message to the other endpoint. 295 This offer includes, as part of the SDP payload, the fingerprint of 296 the certificate that the endpoint wants to use. The SIP message 297 containing the offer is sent to the offerer's sip proxy over an 298 integrity protected channel which will add an identity header 299 according to the procedures outlined in [I-D.ietf-sip-identity]. 300 When the far endpoint receives the SIP message it can verify the 301 identity of the sender using the identity header. Since the identity 302 header is a digital signature across several SIP headers, in addition 303 to the bodies of the SIP message, the receiver can also be certain 304 that the message has not been tampered with after the digital 305 signature was applied and added to the SIP message. 307 The far endpoint (answerer) may now establish a mutually 308 authenticated DTLS association to the offerer. After completing the 309 DTLS handshake, information about the authenticated identities, 310 including the certificates, are made available to the endpoint 311 application. The answerer is then able to verify that the offerer's 312 certificate used for authentication in the DTLS handshake can be 313 associated to the certificate fingerprint contained in the offer in 314 the SDP. At this point the answerer may indicate to the end user 315 that the media is secured. The offerer may only tentatively accept 316 the answerer's certificate since it may not yet have the answerer's 317 certificate fingerprint. 319 When the answerer accepts the offer, it provides an answer back to 320 the offerer containing the answerer's certificate fingerprint. At 321 this point the offerer can definitively accept or reject the peer's 322 certificate and the offerer can indicate to the end user that the 323 media is secured. 325 Note that the entire authentication and key exchange for securing the 326 media traffic is handled in the media path through DTLS. The 327 signaling path is only used to verify the peers' certificate 328 fingerprints. 330 6. Miscellaneous Considerations 331 6.1. Anonymous Calls 333 When making anonymous calls, a new self-signed certificate SHOULD be 334 used for each call so that the calls can not be correlated as to 335 being from the same caller. In situations where some degree of 336 correlation is acceptable, the same certificate SHOULD be used for a 337 number of calls in order to enable continuity of authentication 338 Section 8.5. 340 Additionally, it MUST be ensured that the Privacy header RFC 3325 341 [RFC3325] is used in conjunction with the SIP identity mechanism to 342 ensure that the identity of the user is not asserted when enabling 343 anonymous calls. Furthermore, the content of the subjectAltName 344 attribute inside the certificate MUST NOT contain information that 345 either allows correlation or identification of the user that wishes 346 to place an anonymous call. 348 6.2. Early Media 350 If an offer is received by an endpoint that wishes to provide early 351 media, it MUST take the setup:active role and can immediately 352 establish a DTLS association with the other endpoint and begin 353 sending media. The setup:passive endpoint may not yet have validated 354 the fingerprint of the active endpoint's certificate. The security 355 aspects of media handling in this situation are discussed in 356 Section 8. 358 6.3. Forking 360 In SIP, it is possible for a request to fork to multiple endpoints. 361 Each forked request can result in a different answer. Assuming that 362 the requester provided an offer, each of the answerers' will provide 363 a unique answer. Each answerer will create a DTLS association with 364 the offerer. The offerer can then correlate the SDP answer received 365 in the SIP message by comparing the fingerprint in the answer to the 366 hashed certificate for each DTLS association. 368 Note that in the situation where a request forks to multiple 369 endpoints that all share the same certificate, there is no way for 370 the caller to correlate the DTLS associations with the SIP dialogs. 371 Practically, this is not a problem, since the callees will terminate 372 the unused associations. No new security problem is introduced here 373 since endpoints which share the same certificate are assumed to 374 represent the same user. 376 6.4. Delayed Offer Calls 378 An endpoint may send a SIP INVITE request with no offer in it. When 379 this occurs, the receiver(s) of the INVITE will provide the offer in 380 the response and the originator will provide the answer in the 381 subsequent ACK request or in the PRACK request RFC 3262 [RFC3262] if 382 both endpoints support reliable provisional responses. In any event, 383 the active endpoint still establishes the DTLS association with the 384 passive endpoint as negotiated in the offer/answer exchange. 386 6.5. Session Modification 388 Once an answer is provided to the offerer, either endpoint MAY 389 request a session modification which MAY include an updated offer. 390 This session modification can be carried in either an INVITE or 391 UPDATE request. In this case, it is RECOMMENDED that the offerer 392 indicate a request to reuse the existing association (using the 393 connection attribute) as described in Connection-Oriented Media RFC 394 4145 [RFC4145]. Once the answer is received, the active endpoint 395 will either reuse the existing association or establish a new one, 396 tearing down the existing association as soon as the offer/answer 397 exchange is completed. The exact association/connection reuse 398 behavior is specified in RFC 4145 [RFC4145]. 400 6.6. UDP Payload De-multiplex 402 Interactive Connectivity Establishment (ICE), as specified in 403 [I-D.ietf-mmusic-ice], provides a methodology of allowing 404 participants in multi-media sessions to verify mutual connectivity. 405 In order to make ICE work with this specification the endpoints MUST 406 be able to demultiplex STUN packets from DTLS packets. STUN RFC 3489 407 [RFC3489] packets MUST NOT be sent over DTLS. 409 The first byte of a STUN message is 0 or 1 and it is reasonable to 410 expect it to remain 0 or 1 for the near future. The first byte of a 411 DTLS packet is "Type" which can currently have values of 20, 21, 22, 412 and 23 as defined in ContentType declaration in 413 [I-D.ietf-tls-rfc2246-bis]. It is reasonable to expect the first 414 byte to remain under 64 and greater than 1. For RTP the first byte 415 has a value that is 196 or above. A viable demultiplexing strategy 416 would be to look at the first byte of the UDP payload and if the 417 value is less than 2, assume STUN, if greater or equal to 196 assume 418 RTP, otherwise assume DTLS. 420 6.7. Rekeying 422 As with TLS, DTLS endpoints can rekey at any time by redoing the DTLS 423 handshake. While the rekey is under way, the endpoints continue to 424 use the previously established keying material for usage with DTLS. 425 Once the new session keys are established the session can switch to 426 using these and abandon the old keys. This ensures that latency is 427 not introduced during the rekeying process. 429 Further considerations regarding rekeying in case the SRTP security 430 context is established with DTLS can be found in Section 3.7 of 431 [I-D.mcgrew-tls-srtp]. 433 6.8. Conference Servers and Shared Encryptions Contexts 435 It has been proposed that conference servers might use the same 436 encryption context for all of the participants in a conference. The 437 advantage of this approach is that the conference server only needs 438 to encrypt the output for all speakers instead of once per 439 participant. 441 This shared encryption context approach is not possible under this 442 specification. However, it is argued that the effort to encrypt each 443 RTP packet is small compared to the other tasks performed by the 444 conference server such as the codec processing. 446 Future extensions such as [I-D.mcgrew-srtp-ekt] could be used to 447 provide this functionality in concert with the mechanisms described 448 in this specification. 450 6.9. Media over SRTP 452 Because DTLS's data transfer protocol is generic, it is less highly 453 optimized for use with RTP than is SRTP [RFC3711], which has been 454 specifically tuned for that purpose. DTLS-SRTP 455 [I-D.mcgrew-tls-srtp], has been defined to provide for the 456 negotiation of SRTP transport using a DTLS connection, thus allowing 457 the performance benefits of SRTP with the easy key management of 458 DTLS. The ability to reuse existing SRTP software and hardware 459 implementations may in some environments another important motivation 460 for using DTLS-SRTP instead of RTP over DTLS. Implementations of 461 this specification SHOULD support DTLS-SRTP [I-D.mcgrew-tls-srtp]. 463 7. Example Message Flow 465 Prior to establishing the session, both Alice and Bob generate self- 466 signed certificates which are used for a single session or, more 467 likely, reused for multiple sessions. In this example, Alice calls 468 Bob. In this example we assume that Alice and Bob share the same 469 proxy. 471 The example shows the SIP message flows where Alice acts as the 472 passive endpoint and Bob acts as the active endpoint meaning that as 473 soon as Bob receives the INVITE from Alice, with DTLS specified in 474 the 'm' line of the offer, Bob will begin to negotiate a DTLS 475 association with Alice for both RTP and RTCP streams. Early media 476 (RTP and RTCP) starts to flow from Bob to Alice as soon as Bob sends 477 the DTLS finished message to Alice. Bi-directional media (RTP and 478 RTCP) can flow after Bob sends the SIP 200 response and once Alice 479 has sent the DTLS finished message. 481 The SIP signaling from Alice to her proxy is transported over TLS to 482 ensure an integrity protected channel between Alice and her identity 483 service. Note that all other signaling is transported over TCP in 484 this example although it could be done over any supported transport. 486 Alice Proxies Bob 487 |(1) INVITE | | 488 |---------------->| | 489 | |(2) INVITE | 490 | |----------------->| 491 | | (3) hello | 492 |<-----------------------------------| 493 |(4) hello | | 494 |----------------------------------->| 495 | | (5) finished | 496 |<-----------------------------------| 497 | | (6) media | 498 |<-----------------------------------| 499 |(7) finished | | 500 |----------------------------------->| 501 | | (8) 200 OK | 502 |<-----------------------------------| 503 | | (9) media | 504 |----------------------------------->| 505 |(10) ACK | | 506 |----------------------------------->| 508 Message (1): INVITE Alice -> Proxy 510 This shows the initial INVITE from Alice to Bob carried over the 511 TLS transport protocol to ensure an integrity protected channel 512 between Alice and her proxy which acts as Alice's identity 513 service. Note that Alice has requested to be the passive endpoint 514 which means that it will act as the DTLS server and Bob will 515 initiate the session. Also note that there is a fingerprint 516 attribute on the 'c' line of the SDP. This is computed from Bob's 517 self-signed certificate. 519 [[ NOTE: This example is not completely correct because the exact 520 syntax of the SDP is not yet determined. The MMUSIC working group 521 is currently working on standardizing mechanisms for SDP 522 capability negotiation which will enable this sort of best-effort 523 encryption. When that work is finished, this draft will be 524 harmonized with it.]] 526 INVITE sip:bob@example.com SIP/2.0 527 Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj 528 Max-Forwards: 70 529 Contact: 530 To: 531 From: "Alice";tag=843c7b0b 532 Call-ID: 6076913b1c39c212@REVMTEpG 533 CSeq: 1 INVITE 534 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE 535 Content-Type: application/sdp 536 Content-Length: xxxx 538 v=0 539 o=- 1181923068 1181923196 IN IP4 192.168.1.103 540 s=example1 541 c=IN IP4 192.168.1.103 542 a=setup:passive 543 a=connection:new 544 a=fingerprint: \ 545 SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 546 t=0 0 547 m=audio 6056 UDP/TLS/RTP/AVP 0 548 a=sendrecv 550 Message (2): INVITE Proxy -> Bob 552 This shows the INVITE being relayed to Bob from Alice (and Bob's) 553 proxy. Note that Alice's proxy has inserted an Identity and 554 Identity-Info header. This example only shows one element for 555 both proxies for the purposes of simplification. Bob verifies the 556 identity provided with the INVITE. 558 INVITE sip:bob@example.com SIP/2.0 559 Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj 560 Via: SIP/2.0/TCP 192.168.1.100:5060;branch=z9hG4bK-0e53244234324234 561 Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 562 Max-Forwards: 70 563 Contact: 564 To: 565 From: "Alice";tag=843c7b0b 566 Call-ID: 6076913b1c39c212@REVMTEpG 567 CSeq: 1 INVITE 568 Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 569 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC 570 HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= 571 Identity-Info: https://example.com/cert 572 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE 573 Content-Type: application/sdp 574 Content-Length: xxxx 576 v=0 577 o=- 1181923068 1181923196 IN IP4 192.168.1.103 578 s=example1 579 c=IN IP4 192.168.1.103 580 a=setup:passive 581 a=connection:new 582 a=fingerprint: \ 583 SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 584 t=0 0 585 m=audio 6056 UDP/TLS/RTP/AVP 0 586 a=sendrecv 588 Message (3): ClientHello Bob -> Alice 590 Assuming that Alice's identity is valid, Message 3 shows Bob 591 sending a DTLS ClientHello directly to Alice for each 'm' line in 592 the SDP. In this case two DTLS ClientHello messages are sent to 593 Alice. Bob sends a DTLS ClientHello to 192.168.1.103:6056 for RTP 594 and another to port 6057 for RTCP. 596 Message (4): ServerHello+Certificate Alice -> Bob 598 Alice sends back a ServerHello, Certificate, ServerHelloDone for 599 both RTP and RTCP associations. Note that the same certificate is 600 used for both the RTP and RTCP associations. If RTP/RTCP 601 multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] were being used only 602 a single association would be required. 604 Message (5): Certificate Bob -> Alice 606 Bob sends a Certificate, ClientKeyExchange, CertificateVerify, 607 change_cipher_spec and Finished for both RTP and RTCP 608 associations. Again note that Bob uses the same server 609 certificate for both associations. 611 Message (6): Early Media Bob -> Alice 613 At this point, Bob can begin sending early media (RTP and RTCP) to 614 Alice. Note that Alice can't yet trust the media since the 615 fingerprint has not yet been received. This lack of trusted, 616 secure media is indicated to Alice. 618 Message (7): Finished Alice -> Bob 620 After Message 5 is received by Bob, Alice sends change_cipher_spec 621 and Finished. 623 Message (8): 200 OK Bob -> Alice 625 When Bob answers the call, Bob sends a 200 OK SIP message which 626 contains the fingerprint for Bob's certificate. When Alice 627 receives the message and validates the certificate presented in 628 Message 5. The endpoint now shows Alice that the call as secured. 630 SIP/2.0 200 OK 632 To: ;tag=6418913922105372816 633 From: "Alice" ;tag=843c7b0b 634 Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 635 Call-ID: 6076913b1c39c212@REVMTEpG 636 CSeq: 1 INVITE 637 Contact: 638 Content-Type: application/sdp 639 Content-Length: xxxx 641 v=0 642 o=- 6418913922105372816 2105372818 IN IP4 192.168.1.104 643 s=example2 644 c=IN IP4 192.168.1.104 645 a=setup:active 646 a=connection:new 647 a=fingerprint:\ 648 SHA-1 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 649 t=0 0 650 m=audio 12000 UDP/TLS/RTP/AVP 0 651 a=rtpmap:0 PCMU/8000/1 653 Message (9): RTP+RTCP Alice -> Bob 655 At this point, Alice can also start sending RTP and RTCP to Bob 657 Message 10: ACK Alice -> Bob 659 Finally, Alice sends the SIP ACK to Bob. 661 8. Security Considerations 663 DTLS or TLS media signalled with SIP requires a way to ensure that 664 the communicating peers' certificates are correct. 666 The standard TLS/DTLS strategy for authenticating the communicating 667 parties is to give the server (and optionally the client) a PKIX RFC 668 3280 [RFC3280] certificate. The client then verifies the certificate 669 and checks that the name in the certificate matches the server's 670 domain name. This works because there are a relatively small number 671 of servers with well-defined names; a situation which does not 672 usually occur in the VoIP context. 674 The design described in this document is intended to leverage the 675 authenticity of the signaling channel (while not requiring 676 confidentiality). As long as each side of the connection can verify 677 the integrity of the SDP INVITE then the DTLS handshake cannot be 678 hijacked via a man-in-the-middle attack. This integrity protection 679 is easily provided by the caller to the callee (see Alice to Bob in 680 Section 7) via the SIP Identity [I-D.ietf-sip-identity] mechanism. 681 However, it is less straightforward for the responder. 683 Ideally Alice would want to know that Bob's SDP had not been tampered 684 with and who it was from so that Alice's User Agent could indicate to 685 Alice that there was a secure phone call to Bob. This is known as the 686 SIP connected party problem and is still a topic of ongoing work in 687 the SIP community. In the meantime, there are several approaches 688 that can be used to mitigate this problem: Use UPDATE, Use SIPS, Use 689 S/MIME, Single Sided Verification, or use human-read Short 690 Authentication String (SAS) to validate the certificates. Each one 691 is discussed here followed by the security implications of that 692 approach. 694 8.1. UPDATE 696 [I-D.ietf-sip-connected-identity] defines an approach for a UA to 697 supply its identity to its peer UA and for this identity to be signed 698 by an authentication service. For example, using this approach, Bob 699 sends an answer, then immediately follows up with an UPDATE that 700 includes the fingerprint and uses the SIP Identity mechanism to 701 assert that the message is from Bob@example.com. The downside of 702 this approach is that it requires the extra round trip of the UPDATE. 703 However, it is simple and secure even when not all of the proxies are 704 trusted. In this example, Bob only needs to trust his proxy. 706 [[OPEN ISSUE: Note that there is a window of vulnerability during 707 the early media phase of this operation before Alice receives the 708 UPDATE (which immediately follows the SDP answer). During this 709 window, Alice cannot be sure of Bob's identity. This risk might be 710 mitigated by including a secret in the offer which must be used to 711 establish the DTLS association, for instance via TLS PSK [RFC4279]. 712 We are still studying this issue. Obviously, this is more attractive 713 is SIPS is used.]] 715 8.2. SIPS 717 In this approach, the signaling is protected by TLS from hop to hop. 718 As long as all proxies are trusted, this provides integrity for the 719 fingerprint. It does not provide a strong assertion of who Alice is 720 communicating with. However, as much as the target domain can be 721 trusted to correctly populate the From header field value, Alice can 722 use that. The security issue with this approach is that if one of 723 the Proxies wished to mount a man-in-the-middle attack, it could 724 convince Alice that she was talking to Bob when really the media was 725 flowing through a man in the middle media relay. However, this 726 attack could not convince Bob that he was taking to Alice. 728 8.3. S/MIME 730 RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that 731 could be used to sign that the fingerprint was from Bob. This would 732 be secure. However, so far there have been no deployments of S/MIME 733 for SIP. 735 8.4. Single-sided Verification 737 In this approach, no integrity is provided for the fingerprint from 738 Bob to Alice. In this approach, an attacker that was on the 739 signaling path could tamper with the fingerprint and insert 740 themselves as a man-in-the-middle on the media. Alice would know 741 that she had a secure call with someone but would not know if it was 742 with Bob or a man-in-the-middle. Bob would know that an attack was 743 happening. The fact that one side can detect this attack means that 744 in most cases where Alice and Bob both wish the communications to be 745 encrypted there is not a problem. Keep in mind that in any of the 746 possible approaches Bob could always reveal the media that was 747 received to anyone. We are making the assumption that Bob also wants 748 secure communications. In this do nothing case, Bob knows the media 749 has not been tampered with or intercepted by a third party and that 750 it is from Alice@example.com. Alice knows that she is talking to 751 someone and that whoever that is has probably checked that the media 752 is not being intercepted or tampered with. This approach is 753 certainly less than ideal but very usable for many situations. 755 [TODO] 757 8.5. Continuity of Authentication 759 One desirable property of a secure media system is to provide 760 continuity of authentication: being able to ensure cryptographically 761 that you are talking to the same person as before. With DTLS, 762 continuity of authentication is achieved by having each side use the 763 same public key/self-signed certificate for each connection (at least 764 with a given peer entity). It then becomes possible to cache the 765 credential (or its hash) and verify that it is unchanged. Thus, once 766 a single secure connection has been established, an implementation 767 can establish a future secure channel even in the face of future 768 insecure signalling. 770 In order to enable continuity of authentication, implementations 771 SHOULD attempt to keep a constant long-term key. Verifying 772 implementations SHOULD maintain a cache of the key used for each peer 773 identity and alert the user if that key changes. 775 8.6. Short Authentication String 777 An alternative available to Alice and Bob is to use human speech to 778 verify each others' identity and then to verify each others' 779 fingerprints also using human speech. Assuming that it is difficult 780 to impersonate another's speech and seamlessly modify the audio 781 contents of a call, this approach is relatively safe. It would not 782 be effective if other forms of communication were being used such as 783 video or instant messaging. DTLS supports this mode of operation. 784 The minimal secure fingerprint length is around 64 bits. 786 ZRTP [I-D.zimmermann-avt-zrtp] includes Short Authentication String 787 mode in which a unique per-connection bitstring is generated as part 788 of the cryptographic handshake. The SAS can be as short as 25 bits 789 and so is somewhat easier to read. DTLS does not natively support 790 this mode, however it would be straightforward to add one as a TLS 791 extension [RFC3546]. 793 8.7. Perfect Forward Secrecy 795 One concern about the use of a long-term key is that compromise of 796 that key may lead to compromise of past communications. In order to 797 prevent this attack, DTLS supports modes with Perfect Forward Secrecy 798 using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites. 799 When these modes are in use, the system is secure against such 800 attacks. Note that compromise of a long-term key may still lead to 801 future active attacks. If this is a concern, a backup authentication 802 channel such as manual fingerprint establishment or a short 803 authentication string should be used. 805 9. Requirements Analysis 807 [I-D.wing-media-security-requirements] describes security 808 requirements for media keying. This section evaluates this proposal 809 with respect to each requirement. 811 9.1. Forking and retargeting (R1, R2, R3) 813 In this draft, the SDP offer (in the INVITE) is simply an 814 advertisement of the capability to do security. This advertisement 815 does not depend on the identity of the communicating peer, so forking 816 and retargeting work work when all the endpoints will do SRTP (R1). 818 When a mix of SRTP and non-SRTP endpoints are present, we expect to 819 use the SDP capabilities mechanism currently being defined 820 [I-D.ietf-mmusic-sdp-capability-negotiation] to transparently 821 negotiate security where possible (R2). Because DTLS establishes a 822 new key for each session, only the entity with which the call is 823 finally established gets the media encryption keys (R3). 825 9.2. Clipping (R5) 827 Because the key establishment occurs in the media plane, media need 828 not be clipped before the receipt of the SDP answer (R5). 830 9.3. Passive Attacks (R6) 832 The public key algorithms used by DTLS (RSA, Diffie-Hellman, and 833 Elliptic Curve Diffie-Hellman) are secure against passive attacks 834 (R6). 836 9.4. Perfect Forward Secrecy (R7) 838 DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher 839 suites which provide PFS (R7). 841 9.5. Algorithm Negotiation (R8, R9) 843 DTLS negotiates cipher suites before performing significant 844 cryptographic computation and therefore supports algorithm 845 negotiation (R8) and multiple cipher suites (R9) without additional 846 computational expense. 848 9.6. Endpoint Idenfification When Forking (R10) 850 Once the SDP response is received, the implementation can match the 851 fingerprint against the offered client Certificate message (R10). 852 Note, however, that if the server is using ephemeral DH or ECDH, it 853 still must compute a fresh DH share and sign it in the 854 ServerKeyExchange. This could be optimized away by having a DTLS 855 ClientHello extension in which the client provide a copy of its 856 fingerprint in advance. 858 9.7. 3rd Party Certificates (R11) 860 Third party certificates are not required. However, if the parties 861 share an authentication infrastructure that is compatible with TLS 862 (3rd party certificates or shared keys) it can be used (R11). 864 9.8. FIPS 140-2 (R12) 866 TLS implementations already may be FIPS 140-2 approved and the 867 algorithms used here are consistent with the approval of DTLS and 868 DTLS-SRTP (R12). 870 10. IANA Considerations 872 This specification does not require any IANA actions. 874 11. Acknowledgments 876 Cullen Jennings contributed substantial text and comments to this 877 document. This document benefited from discussions with Francois 878 Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful 879 comments by Flemming Andreasen, Rohan Mahy, David McGrew, and David 880 Oran. 882 12. References 884 12.1. Normative References 886 [I-D.ietf-mmusic-comedia-tls] 887 Lennox, J., "Connection-Oriented Media Transport over the 888 Transport Layer Security (TLS) Protocol in the Session 889 Description Protocol (SDP)", 890 draft-ietf-mmusic-comedia-tls-06 (work in progress), 891 March 2006. 893 [I-D.ietf-mmusic-sdp-new] 894 Handley, M., "SDP: Session Description Protocol", 895 draft-ietf-mmusic-sdp-new-26 (work in progress), 896 January 2006. 898 [I-D.ietf-sip-identity] 899 Peterson, J. and C. Jennings, "Enhancements for 900 Authenticated Identity Management in the Session 901 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 902 (work in progress), October 2005. 904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", BCP 14, RFC 2119, March 1997. 907 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 908 A., Peterson, J., Sparks, R., Handley, M., and E. 910 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 911 June 2002. 913 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 914 with Session Description Protocol (SDP)", RFC 3264, 915 June 2002. 917 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 918 X.509 Public Key Infrastructure Certificate and 919 Certificate Revocation List (CRL) Profile", RFC 3280, 920 April 2002. 922 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 923 Extensions to the Session Initiation Protocol (SIP) for 924 Asserted Identity within Trusted Networks", RFC 3325, 925 November 2002. 927 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 928 "STUN - Simple Traversal of User Datagram Protocol (UDP) 929 Through Network Address Translators (NATs)", RFC 3489, 930 March 2003. 932 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 933 Jacobson, "RTP: A Transport Protocol for Real-Time 934 Applications", STD 64, RFC 3550, July 2003. 936 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 937 the Session Description Protocol (SDP)", RFC 4145, 938 September 2005. 940 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 941 Security", RFC 4347, April 2006. 943 [I-D.fischl-mmusic-sdp-dtls] 944 Fischl, J. and H. Tschofenig, "Session Description 945 Protocol (SDP) Indicators for Datagram Transport Layer 946 Security (DTLS)", draft-fischl-mmusic-sdp-dtls-02 (work in 947 progress), March 2007. 949 12.2. Informational References 951 [I-D.ietf-avt-rtp-framing-contrans] 952 Lazzaro, J., "Framing RTP and RTCP Packets over 953 Connection-Oriented Transport", 954 draft-ietf-avt-rtp-framing-contrans-06 (work in progress), 955 September 2005. 957 [I-D.ietf-mmusic-ice] 958 Rosenberg, J., "Interactive Connectivity Establishment 959 (ICE): A Methodology for Network Address Translator (NAT) 960 Traversal for Offer/Answer Protocols", 961 draft-ietf-mmusic-ice-13 (work in progress), January 2007. 963 [I-D.ietf-mmusic-kmgmt-ext] 964 Arkko, J., "Key Management Extensions for Session 965 Description Protocol (SDP) and Real Time Streaming 966 Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in 967 progress), June 2005. 969 [I-D.ietf-mmusic-sdescriptions] 970 Andreasen, F., "Session Description Protocol Security 971 Descriptions for Media Streams", 972 draft-ietf-mmusic-sdescriptions-12 (work in progress), 973 September 2005. 975 [I-D.ietf-mmusic-sdp-comedia] 976 Yon, D., "Connection-Oriented Media Transport in the 977 Session Description Protocol (SDP)", 978 draft-ietf-mmusic-sdp-comedia-10 (work in progress), 979 November 2004. 981 [I-D.ietf-tls-rfc2246-bis] 982 Dierks, T. and E. Rescorla, "The TLS Protocol Version 983 1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress), 984 June 2005. 986 [I-D.ietf-sip-connected-identity] 987 Elwell, J., "Connected Identity in the Session Initiation 988 Protocol (SIP)", draft-ietf-sip-connected-identity-05 989 (work in progress), February 2007. 991 [I-D.zimmermann-avt-zrtp] 992 Zimmermann, P., "ZRTP: Extensions to RTP for Diffie- 993 Hellman Key Agreement for SRTP", 994 draft-zimmermann-avt-zrtp-02 (work in progress), 995 October 2006. 997 [I-D.mcgrew-srtp-ekt] 998 McGrew, D., "Encrypted Key Transport for Secure RTP", 999 draft-mcgrew-srtp-ekt-02 (work in progress), March 2007. 1001 [I-D.mcgrew-tls-srtp] 1002 Rescorla, E. and D. McGrew, "Datagram Transport Layer 1003 Security (DTLS) Extension to Establish Keys for Secure 1004 Real-time Transport Protocol (SRTP)", 1005 draft-mcgrew-tls-srtp-02 (work in progress), March 2007. 1007 [I-D.wing-media-security-requirements] 1008 Wing, D., "Media Security Requirements", 1009 draft-wing-media-security-requirements-00 (work in 1010 progress), October 2006. 1012 [I-D.ietf-mmusic-sdp-capability-negotiation] 1013 Andreasen, F., "SDP Capability Negotiation", 1014 draft-ietf-mmusic-sdp-capability-negotiation-05 (work in 1015 progress), March 2007. 1017 [I-D.ietf-avt-rtp-and-rtcp-mux] 1018 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1019 Control Packets on a Single Port", 1020 draft-ietf-avt-rtp-and-rtcp-mux-03 (work in progress), 1021 December 2006. 1023 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1024 Provisional Responses in Session Initiation Protocol 1025 (SIP)", RFC 3262, June 2002. 1027 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1028 and T. Wright, "Transport Layer Security (TLS) 1029 Extensions", RFC 3546, June 2003. 1031 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1032 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1033 RFC 3711, March 2004. 1035 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1036 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1037 August 2004. 1039 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1040 for Transport Layer Security (TLS)", RFC 4279, 1041 December 2005. 1043 Authors' Addresses 1045 Jason Fischl 1046 CounterPath Solutions, Inc. 1047 8th Floor, 100 West Pender Street 1048 Vancouver, BC V6B 1R8 1049 Canada 1051 Phone: +1 604 320-3340 1052 Email: jason@counterpath.com 1053 Hannes Tschofenig 1055 Email: Hannes.Tschofenig@gmx.net 1057 Eric Rescorla 1058 Network Resonance 1059 2483 E. Bayshore #212 1060 Palo Alto, CA 94303 1061 USA 1063 Email: ekr@networkresonance.com 1065 Full Copyright Statement 1067 Copyright (C) The IETF Trust (2007). 1069 This document is subject to the rights, licenses and restrictions 1070 contained in BCP 78, and except as set forth therein, the authors 1071 retain all their rights. 1073 This document and the information contained herein are provided on an 1074 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1075 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1076 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1077 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1078 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1079 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1081 Intellectual Property 1083 The IETF takes no position regarding the validity or scope of any 1084 Intellectual Property Rights or other rights that might be claimed to 1085 pertain to the implementation or use of the technology described in 1086 this document or the extent to which any license under such rights 1087 might or might not be available; nor does it represent that it has 1088 made any independent effort to identify any such rights. Information 1089 on the procedures with respect to rights in RFC documents can be 1090 found in BCP 78 and BCP 79. 1092 Copies of IPR disclosures made to the IETF Secretariat and any 1093 assurances of licenses to be made available, or the result of an 1094 attempt made to obtain a general license or permission for the use of 1095 such proprietary rights by implementers or users of this 1096 specification can be obtained from the IETF on-line IPR repository at 1097 http://www.ietf.org/ipr. 1099 The IETF invites any interested party to bring to its attention any 1100 copyrights, patents or patent applications, or other proprietary 1101 rights that may cover technology that may be required to implement 1102 this standard. Please address the information to the IETF at 1103 ietf-ipr@ietf.org. 1105 Acknowledgment 1107 Funding for the RFC Editor function is provided by the IETF 1108 Administrative Support Activity (IASA).