SIP J. Fischl Internet-Draft CounterPath
Solutions, Inc. Intended status: Standards Track H. TschofenigCorporation Expires: May 15,August 26, 2008 H. Tschofenig Nokia Siemens Networks E. Rescorla Network Resonance November 12, 2007February 23, 2008 Framework for Establishing an SRTP Security Context using DTLS draft-ietf-sip-dtls-srtp-framework-00.txtdraft-ietf-sip-dtls-srtp-framework-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15,August 26, 2008. Copyright Notice Copyright (C) The IETF Trust (2007).(2008). Abstract This document specifies how to use the Session Initiation Protocol (SIP) to establish an Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. It relies on the SIP identity mechanism to ensure the integrity of the fingerprint attribute. The key managementexchange travels along the media path as opposed to the signaling path. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Verifying Certificate IntegrityExchanging Certificates . . . . . . . . . . . . . . . . . . . 7 6. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 89 6.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 89 6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 910 6.4. Delayed Offer Calls . . . . . . . . . . . . . . . . . . . 910 6.5. Session Modification . . . . . . . . . . . . . . . . . . . 10 6.6. UDP Payload De-multiplexICE Interaction . . . . . . . . . . . . . . . . . . . . . 10 6.7. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 1011 6.8. Conference Servers and Shared Encryptions Contexts . . . . 11 6.9. Media over SRTP . . . . . . . . . . . . . . . . . . . . . 1112 6.10. Best Effort Encryption . . . . . . . . . . . . . . . . . . 1112 7. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 1112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 1617 8.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 1718 8.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 1819 8.4. Single-sided Verification . . . . . . . . . . . . . . . . 1819 8.5. Continuity of Authentication . . . . . . . . . . . . . . . 1819 8.6. Short Authentication String . . . . . . . . . . . . . . . 19 8.7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 1920 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1920 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 2021 11.1. Normative References . . . . . . . . . . . . . . . . . . . 2021 11.2. Informational References . . . . . . . . . . . . . . . . . 2122 Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 2324 A.1. Forking and retargeting (R1, R2, R3)(R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT) . . . . . . . . . . . . . 23 A.2. Reusage of a Security Context (R4), (R11). . . 24 A.2. Distinct Cryptographic Contexts (R-DISTINCT) . . . . . . . 2324 A.3. Clipping (R5)Reusage of a Security Context (R-REUSE) . . . . . . . . . 24 A.4. Clipping (R-AVOID-CLIPPING) . . . . . . . . . . . . . 23 A.4.. . 24 A.5. Passive Attacks on the Media Path (R6) . . . . .(R-PASS-MEDIA) . . . . . 24 A.5.A.6. Passive Attacks on the Signaling Path (R7)(R-PASS-SIG) . . . . 24 A.7. (R-SIG-MEDIA, R-ACT-ACT) . . . . 24 A.6. Perfect Forward Secrecy (R8). . . . . . . . . . . . . 25 A.8. Binding to Identifiers (R-ID-BINDING) . . 24 A.7. Algorithm Negotiation (R9). . . . . . . . 25 A.9. Perfect Forward Secrecy (R-PFS) . . . . . . . . 24 A.8. RTP Validity Check (R10). . . . . 25 A.10. Algorithm Negotiation (R-COMPUTE) . . . . . . . . . . . . 24 A.9. 3rd Party Certificates (R12, R18)25 A.11. RTP Validity Check (R-RTP-VALID) . . . . . . . . . . . . 24 A.10. FIPS 140-2 (R13). 25 A.12. 3rd Party Certificates (R-CERTS, R-EXISTING) . . . . . . . 26 A.13. FIPS 140-2 (R-FIPS) . . . . . . . . . . . . . . . 24 A.11.. . . . 26 A.14. Linkage between Keying Exchange and SIP Signaling (R14)(R-ASSOC) . 24 A.12. Start with RTP and Upgrade to SRTP (R15). . . . . . . . . 25 A.13. Denial of Service Vulnerability (R16). . . . . . . . . . 25 A.14. Adversary Model (R17). . . . 26 A.15. Denial of Service Vulnerability (R-DOS) . . . . . . . . . 26 A.16. Adversary Model (R-SIG-MEDIA) . . . . . 25 A.15. Crypto-Agility (R19). . . . . . . . . 26 A.17. Crypto-Agility (R-AGILITY) . . . . . . . . . . . 25 A.16. Downgrading Protection (R20). . . . . 26 A.18. Downgrading Protection (R-DOWNGRADE) . . . . . . . . . . 25 A.17.. 26 A.19. Media Security Negotation (R21) .(R-NEGOTIATE) . . . . . . . . . . . . 25 A.18.26 A.20. Signaling Protocol Independence (R22) . . . . .(R-OTHER-SIGNALING) . . . . . 25 A.19.27 A.21. Media Recording (R23) . . . . . . . . . . .(R-RECORDING) . . . . . . . 25 A.20. Lawful Interception (R24) . . . . . .. . . . . . . . . . 26 A.21.27 A.22. Interworking with Intermediaries (R25) . .(R-TRANSCODER) . . . . . . . . 26 A.22.27 A.23. PSTN Gateway Termination (R26) .(R-PSTN) . . . . . . . . . . . . . 2627 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 2628 Intellectual Property and Copyright Statements . . . . . . . . . . 2829 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] and the Session Description Protocol (SDP) [RFC4566] are used to set up multimedia sessions or calls. SDP is also used to set up TCP [RFC4145] and additionally TCP/TLS connections for usage with media sessions [RFC4572]. The Real-TimeReal-time Transport Protocol (RTP) [RFC3550] is used to transmit real time media on top of UDP, TCP [RFC4571],UDP and TLS [RFC4572].TCP [RFC4571]. Datagram TLS [RFC4347] was introduced to allow TLS functionality to be applied to datagram transport protocols, such as UDP and DCCP. This draft provides guidelines on how to use and to support for (a) transmission of media over DTLS and (b) toestablish SRTP security using extensions to DTLS (see [I-D.ietf-avt-dtls-srtp]). The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. It also does not require the devices to trust every call signaling element that was involved in routing or session setup. This approach does not require any extra effort by end users and does not require deployment of certificates to all devicesthat are signed by a well-knownwell- known certificate authority.authority to all devices. The media is transported over a mutually authenticated DTLS session where both sides have certificates. The certificate fingerprints are sent in SDP over SIP as part of the offer/answer exchange. The SIP Identity mechanism [RFC4474] is used to provide integrity for the fingerprints.It is very important to note that certificates are being used purely as a carrier for the public keys of the peers. This is required because DTLS does not have a mode for carrying bare keys, but it is purely an issue of formatting. The certificates can be self-signed and completely self-generated. All major TLS stacks have the capability to generate such certificates on demand. However, third party certificates MAY also be used for extra security. The certificate fingerprints are sent in SDP over SIP as part of the offer/answer exchange. The SIP Identity mechanism [RFC4474] is used to provide integrity for the fingerprints. This DTLS-SRTP approach differs from previous attempts to secure media traffic where the authentication and key exchange protocol (e.g., MIKEY [RFC3830]) is piggybacked in the signaling message exchange. With this approach,DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpoints without involving the SIP/SDP communication. It allows RTP and SIP to be used in the usual manner when there is no encrypted media. In SIP, typically the caller sends an offer and the callee may subsequently send one-way media back to the caller before a SIP answer is received by the caller. The approach in this specification, where the media key negotiation is decoupled from the SIP signaling, allows the early media to be set up before the SIP answer is received while preserving the important security property of allowing the media sender to choose some of the keying material for the media. This also allows the media sessions to be changed, re-keyed, and otherwise modified after the initial SIP signaling without any additional SIP signaling. Design decisions that influence the applicability of this specification are discussed in Section 3. 2. Overview Endpoints wishing to set up an RTP media session do so by exchanging offers and answers in SDP messages over SIP. In a typical use case, two endpoints would negotiate to transmit audio data over RTP using the UDP protocol. Figure 1 shows a typical message exchange in the SIP Trapezoid. +-----------+ +-----------+ |SIP | SIP/SDP |SIP | +------>|Proxy |<---------->|Proxy |<------+|----------->|Proxy |-------+ | |Server X | (+finger- |Server Y | | | +-----------+ print, +-----------+ | | +auth.id.) | | SIP/SDP SIP/SDP | | (+fingerprint) (+fingerprint,| | +auth.id.) | | | v| v +-----------+ Datagram TLS +-----------+ |SIP | <---------------------------------><-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP | |User Agent | Media |User Agent | |Alice@X | <=================================> |Bob@Y | +-----------+ +-----------+ Legend: <--->:------>: Signaling Traffic <===>:<-+-+->: Key Management Traffic <=====>: Data Traffic Figure 1: DTLS Usage in the SIP Trapezoid Consider Alice wanting to set up an encrypted audio session with Bob. Both Bob and Alice could use public-key based authentication in order to establish a confidentiality protected channel using DTLS. Since providing mutual authentication between two arbitrary end points on the Internet using public key based cryptography tends to be problematic, we consider more deployment friendlydeployment-friendly alternatives. This document uses one approach and several others are discussed in Section 8. Alice sends an SDP offer to Bob over SIP. If Alice uses only self- signed certificates for the communication with Bob, a fingerprint is included in the SDP offer/answer exchange. This fingerprint is integrity protected using the identity mechanism defined in Enhancements for Authenticated Identity Management in SIP [RFC4474]. When Bob receives the offer, Bob establishes a mutually authenticated DTLS connection with Alice. At this point Bob can begin sending media to Alice. Once Bob accepts Alice's offer and sends an SDP answer to Alice, Alice can begin sending confidential media to Bob. Alice and Bob will verify the fingerprints from the certificates received over the DTLS handshakes match with the fingerprints received in the SDP of the SIP signaling. This provides the security property that Alice knows that the media traffic is going to Bob and vice-versa without necessarily requiring global PKI certificates for Alice and Bob. 3. Motivation Although there is already prior work in this area (e.g., Secure Descriptions for SDP [RFC4568], Key Management Extensions [RFC4567] combined with MIKEY [RFC3830] for authentication and key exchange), this specification is motivated as follows: o TLS will be used to offer security for connection-oriented media. The design of TLS is well-known and implementations are widely available. o This approach deals with forking and early media without requiring support for PRACK [RFC3262] while preserving the important security property of allowing the offerer to choose keying material for encrypting the media. o The establishment of security protection for the media path is also provided along the media path and not over the signaling path. In many deployment scenarios, the signaling and media traffic travel along a different path through the network. o This solution works even when the SIP proxies downstream of the identity service are not trusted. There is no need to reveal keys in the SIP signaling or in the SDP message exchange. In order for SDES and MIKEY to provide this security property, they require distribution of certificates to the endpoints that are signed by well known certificate authorities. SDES further requires that the endpoints employ S/MIME to encrypt the keying material. o In this method, SSRC collisions do not result in any extra SIP signaling. o Many SIP endpoints already implement TLS. The changes to existing SIP and RTP usage are minimal even when DTLS-SRTP [I-D.ietf-avt-dtls-srtp][I-D.ietf-avt- dtls-srtp] is used. 4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. DTLS/TLS uses the term "session" to refer to a long-lived set of keying material that spans associations. In this document, consistent with SIP/SDP usage, we use it to refer to a multimedia session and use the term "TLS session" to refer to the TLS construct. We use the term "association" to refer to a particular DTLS ciphersuite and keying material set.set which is associated with a single host/port quartet. The same DTLS/TLS session can be used to establish the keying material for multiple associations. For consistency with other SIP/ SDPSIP/SDP usage, we use the term "connection" when what's being referred to is a multimedia stream that is not specifically DTLS/TLS. In this document, the term "Mutual DTLS" indicates that both the DTLS client and server present certificates even if one or both certificates are self-signed. 5. Verifying Certificate IntegrityExchanging Certificates The offer/answer model, definedtwo endpoints in [RFC3264], is used by protocols like the Session Initiation Protocol (SIP) [RFC3261] to set up multimedia sessions. In addition tothe usual contentsexchange present their identities as part of an SDP [RFC4566] message, each 'm' line will also contain several attributesthe DTLS handshake procedure using certificates. This document uses certificates in the same style as specifieddescribed in [I-D.fischl-mmusic-sdp-dtls], [RFC4145] andComedia over TLS in SDP [RFC4572]. The endpoint MUSTIf self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the setupuniform resource identifier (URI) of the user. This is useful for debugging purposes only and connectionis not required to bind the certificate to one of the communication endpoints. The integrity of the certificate is ensured through the fingerprint attribute in the SDP. The subjectAltName is not an important component of the certificate verification. The generation of public/private key pairs is relatively expensive. Endpoints are not required to generate certificates for each session. The offer/answer model, defined in [RFC3264], is used by protocols like the Session Initiation Protocol (SIP) [RFC3261] to set up multimedia sessions. In addition to the usual contents of an SDP [RFC4566] message, each media description ('m' line and associated parameters) will also contain several attributes as specified in [I-D.ietf-avt-dtls-srtp], [RFC4145] and [RFC4572]. The endpoint MUST use the setup attribute defined in [RFC4145]. A setup:activeThe endpoint will act as a DTLS clientwhich is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a setup:passive endpointclient_hello before it receives the answer. The answerer SHOULD use the setup attribute value of setup:active and will act as a DTLS server.send the client_hello in the media path. The endpoint MUST NOT use the connection attribute indicates whether or not to reuse an existing DTLS association.defined in [RFC4145]. The endpoint MUST use the certificate fingerprint attribute as specified in [RFC4572]. The setup:active endpoint establishes a DTLS association with the setup:passive endpoint [RFC4145]. Typically, the receiver of the SIP INVITE request containing an offer will take the setup:active role. Thecertificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. The security properties of this mechanism are described in Section 8. If the fingerprint does not match the hashed certificate then the endpoint MUST tear down the media session immediately. When an endpoint wishes to set up a secure media session with another endpoint it sends an offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, the fingerprint of the certificate that the endpoint wants to use. The SIP message containing the offer is sent to the offerer's sip proxy over an integrity protected channel which will add an identity header according to the procedures outlined in [RFC4474]. When the far endpoint receives the SIP message it can verify the identity of the sender using the identity header. Since the identity header is a digital signature across several SIP headers, in addition to the bodies of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was applied and added to the SIP message. The far endpoint (answerer) may now establish a mutually authenticated DTLS association to the offerer. After completing the DTLS handshake, information about the authenticated identities, including the certificates, are made available to the endpoint application. The answerer is then able to verify that the offerer's certificate used for authentication in the DTLS handshake can be associated to the certificate fingerprint contained in the offer in the SDP. At this point the answerer may indicate to the end user that the media is secured. The offerer may only tentatively accept the answerer's certificate since it may not yet have the answerer's certificate fingerprint. When the answerer accepts the offer, it provides an answer back to the offerer containing the answerer's certificate fingerprint. At this point the offerer can definitivelyaccept or reject the peer's certificate and the offerer can indicate to the end user that the media is secured. Note that the entire authentication and key exchange for securing the media traffic is handled in the media path through DTLS. The signaling path is only used to verify the peers' certificate fingerprints. 6. Miscellaneous Considerations 6.1. Anonymous Calls DTLS-SRTP does not provide anonymous calling. However, if care is not taken, DTLS-SRTP may allow deanonymizing an otherwise anonymous call. The following procedures should be used to prevent deanonymization. When making anonymous calls, a new self-signed certificate SHOULD be used for each call so that the calls can not be correlated as to being from the same caller. In situations where some degree of correlation is acceptable, the same certificate SHOULD be used for a number of calls in order to enable continuity of authentication, see Section 8.5. Additionally, it MUST be ensured that the Privacy header [RFC3325] is used in conjunction with the SIP identity mechanism to ensure that the identity of the user is not asserted when enabling anonymous calls. Furthermore, the content of the subjectAltName attribute inside the certificate MUST NOT contain information that either allows correlation or identification of the user that wishes to place an anonymous call. Note that following this recommendation is not sufficient to provide anonymization. 6.2. Early Media If an offer is received by an endpoint that wishes to provide early media, it MUST take the setup:active role and can immediately establish a DTLS association with the other endpoint and begin sending media. The setup:passive endpoint may not yet have validated the fingerprint of the active endpoint's certificate. The security aspects of media handling in this situation are discussed in Section 8. 6.3. Forking In SIP, it is possible for a request to fork to multiple endpoints. Each forked request can result in a different answer. Assuming that the requester provided an offer, each of the answerers' will provide a unique answer. Each answerer will create a DTLS association with the offerer. The offerer can then securely correlate the SDP answer received in the SIP message by comparing the fingerprint in the answer to the hashed certificate for each DTLS association. Note that in the situation where6.4. Delayed Offer Calls An endpoint may send a request forks to multiple endpoints that all share the same certificate, there is no way for the caller to correlate the DTLS associations with the SIP dialogs. Practically, this is not a problem, since the callees will terminate the unused associations. No new security problem is introduced here since endpoints which share the same certificate are assumed to represent the same user. 6.4. Delayed Offer Calls An endpoint may send a SIP INVITESIP INVITE request with no offer in it. When this occurs, the receiver(s) of the INVITE will provide the offer in the response and the originator will provide the answer in the subsequent ACK request or in the PRACK request [RFC3262] if both endpoints support reliable provisional responses. In any event, the active endpoint still establishes the DTLS association with the passive endpoint as negotiated in the offer/answer exchange. 6.5. Session Modification Once an answer is provided to the offerer, either endpoint MAY request a session modification which MAY include an updated offer. This session modification can be carried in either an INVITE or UPDATE request. In this case, it is RECOMMENDED that the offerer indicate a request to reuse the existing association (using the connection attribute) as described in Connection-Oriented Media [RFC4145].Once the answer is received, the active endpoint will either reuse the existing association or establish a new one, tearing down the existing association as soon as the offer/answer exchange is completed. The exact association/connection reuse behavior is specified in RFC 4145 [RFC4145].6.6. UDP Payload De-multiplexICE Interaction Interactive Connectivity Establishment (ICE), as specified in [I-D.ietf-mmusic-ice], provides a methodology of allowing participants in multi-media sessions to verify mutual connectivity. In order to makeWhen ICE work with this specificationis being used the endpointsICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be able to demultiplex STUN packets fromonly one DTLS packets.handshake even if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just as if the DTLS packets were an ordinary media stream. Note that STUN [RFC3489]packets MUST NOT beare sent directly over UDP, not over DTLS. The first byte of a[I-D.ietf-avt-dtls-srtp] describes how to demultiplex STUN message is 0 or 1packets from DTLS packets and itSRTP packets. If ICE is reasonable to expect it to remain 0 or 1not being used, then there is potential for the near future. The first byte ofa DTLS packet is "Type" which can currently have values of 20, 21, 22, and 23bad interaction with SBCs via "latching", as defined in ContentType declarationdescribed in [RFC4346]. It is reasonable[I-D.ietf- mmusic-media-path-middleboxes]. In order to expectavoid this issue, if ICE is not being used, then the first bytepassive side MUST do a single unauthenticad STUN [I-D.ietf-behave-rfc3489bis] connectivity check in order to remain under 64 and greater than 1. For RTPopen up the first byte has a value that is 196 or above. A viable demultiplexing strategy wouldappropriate pinhole. All implementations MUST be prepared to look at the first byte of the UDP payload and ifanswer this request during the value is less than 2, assume STUN,handshake period even if greater or equal to 196 assume RTP,they do not otherwise assume DTLS.do ICE. 6.7. Rekeying As with TLS, DTLS endpoints can rekey at any time by redoing the DTLS handshake. While the rekey is under way, the endpoints continue to use the previously established keying material for usage with DTLS. Once the new session keys are established the session can switch to using these and abandon the old keys. This ensures that latency is not introduced during the rekeying process. Further considerations regarding rekeying in case the SRTP security context is established with DTLS can be found in Section 3.7 of [I-D.ietf-avt-dtls-srtp]. 6.8. Conference Servers and Shared Encryptions Contexts It has been proposed that conference servers might use the same encryption context for all of the participants in a conference. The advantage of this approach is that the conference server only needs to encrypt the output for all speakers instead of once per participant. This shared encryption context approach is not possible under this specification.specification because each DTLS handshake establishes fresh keys which are not completely under the control of either side. However, it is argued that the effort to encrypt each RTP packet is small compared to the other tasks performed by the conference server such as the codec processing. Future extensions such as [I-D.mcgrew-srtp-ekt] or [I-D.wing-avt- dtls-srtp-key-transport] could be used to provide this functionality in concert with the mechanisms described in this specification. 6.9. Media over SRTP Because DTLS's data transfer protocol is generic, it is less highly optimized for use with RTP than is SRTP [RFC3711], which has been specifically tuned for that purpose. DTLS-SRTP [I-D.ietf-avt-dtls-srtp],[I-D.ietf-avt-dtls- srtp], has been defined to provide for the negotiation of SRTP transport using a DTLS connection, thus allowing the performance benefits of SRTP with the easy key management of DTLS. The ability to reuse existing SRTP software and hardware implementations may in some environments provide another important motivation for using DTLS-SRTP instead of RTP over DTLS. Implementations of this specification SHOULD support DTLS-SRTP [I-D.ietf-avt-dtls-srtp]. 6.10. Best Effort Encryption [I-D.ietf-sip-media-security-requirements] describes a requirement for best effort encryption where SRTP is used where both endpoints support it and key negotiation succeeds otherwise RTP is used. [I-D.ietf-mmusic-sdp-capability-negotiation] describes a mechanism which can signal both RTP and SRTP as an alternative. RTP is the default and will be understood by endpoints that do not understand SRTP or this key exchange mechanism but SRTP is preferred. 7. Example Message Flow Prior to establishing the session, both Alice and Bob generate self- signed certificates which are used for a single session or, more likely, reused for multiple sessions. In this example, Alice calls Bob. In this example we assume that Alice and Bob share the same proxy. The example shows the SIP message flows where Alice acts as the passive endpoint and Bob acts as the active endpoint meaning that as soon as Bob receives the INVITE from Alice, with DTLS specified in the 'm' line of the offer, Bob will begin to negotiate a DTLS association with Alice for both RTP and RTCP streams. Early media (RTP and RTCP) starts to flow from Bob to Alice as soon as Bob sends the DTLS finished message to Alice. Bi-directional media (RTP and RTCP) can flow after Bob sendsAlice receives the SIP 200 response and once Alice has sent the DTLS finished message. The SIP signaling from Alice to her proxy is transported over TLS to ensure an integrity protected channel between Alice and her identity service. Note that all other signaling is transported over TCP in this example although it could be done over any supported transport. Alice Proxies Bob |(1) INVITE | | |---------------->| | | |(2) INVITE | | |----------------->| | | (3) hello|(3) conn-check | |<-----------------------------------| | |(4) hello | |<-----------------------------------| | |(5) conn-response | |----------------------------------->| |(6) hello | | |----------------------------------->| | (5)|(7) finished | |<-----------------------------------| | | (6)|(8) media | |<-----------------------------------| |(7)|(9) finished | | |----------------------------------->| | | (8)|(10) 200 OK | |<-----------------------------------| | | (9)|(11) media | |----------------------------------->| |(10)|(12) ACK | | |----------------------------------->| Message (1): INVITE Alice -> Proxy This shows the initial INVITE from Alice to Bob carried over the TLS transport protocol to ensure an integrity protected channel between Alice and her proxy which acts as Alice's identity service. Note that Alice has requested to be either the active or passive endpoint which means that it willby specifying a=setup:actpass. Bob chooses to act as the DTLS server and Bobwill initiate the session. Also note that there is a fingerprint attribute on the 'c' line of the SDP. This is computed from Bob's self-signed certificate. [[ NOTE: This example is not completely correct because the exact syntax of the SDP is not yet determined. The MMUSIC working group is currently working on standardizing mechanisms for SDP capability negotiation which will enable this sort of best-effort encryption. When that work is finished, this draft will be harmonized with it.]]INVITE sip:email@example.com SIP/2.0 Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj Max-Forwards: 70 Contact: <sip:firstname.lastname@example.org:6937;transport=TLS> To: <sip:email@example.com> From: "Alice"<sip:firstname.lastname@example.org>;tag=843c7b0b Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: xxxx v=0 o=- 1181923068 1181923196 IN IP4 192.168.1.103 s=example1 c=IN IP4 192.168.1.103 a=setup:passive a=connection:newa=setup:actpass a=fingerprint: \ SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 6056 RTP/AVP 0 a=sendrecv a=tcap:1 UDP/TLS/RTP/AVP RTP/AVP a=pcfg:1 t=1 Message (2): INVITE Proxy -> Bob This shows the INVITE being relayed to Bob from Alice (and Bob's) proxy. Note that Alice's proxy has inserted an Identity and Identity-Info header. This example only shows one element for both proxies for the purposes of simplification. Bob verifies the identity provided with the INVITE. Note that this offer includes a default m-line offering RTP in case the answerer does not support SRTP. However, the potential configuration utilizing a transport of SRTP is preferred. See [I-D.ietf-mmusic-sdp-capability-negotiation][I-D.ietf-mmusic-sdp- capability-negotiation] for more details on the details of SDP capability negotiation. INVITE sip:email@example.com SIP/2.0 Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TCP 192.168.1.100:5060;branch=z9hG4bK-0e53244234324234 Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 Max-Forwards: 70 Contact: <sip:firstname.lastname@example.org:6937;transport=TLS> To: <sip:email@example.com> From: "Alice"<sip:firstname.lastname@example.org>;tag=843c7b0b Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= Identity-Info: https://example.com/cert Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: xxxx v=0 o=- 1181923068 1181923196 IN IP4 192.168.1.103 s=example1 c=IN IP4 192.168.1.103 a=setup:passive a=connection:newa=setup:actpass a=fingerprint: \ SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 6056 RTP/AVP 0 a=sendrecv a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=pcfg:1 t=1 Message (3):(3): ICE connectivity-check Bob -> Alice Section 6.6 describes an approach to avoid an SBC interaction issue where the endpoints do not support ICE. Bob (the active endpoint) sends a STUN connectivity check to Alice and may begin the DTLS negotiation immediately after sending the STUN check. Message (4): ClientHello Bob -> Alice Assuming that Alice's identity is valid, Message 3 shows Bob sending a DTLS ClientHello directly to Alice for each 'm' line in the SDP. In this case two DTLS ClientHello messages are sent to Alice. Bob sends a DTLS ClientHello to 192.168.1.103:6056 for RTP and another to port 6057 for RTCP. Message (4):(5): ICE connectivity-check response Alice -> Bob Alice (the passive endpoint) sends a response to the STUN connectivity check (Message 3) to Bob. Message (6): ServerHello+Certificate Alice -> Bob Alice sends back a ServerHello, Certificate, ServerHelloDone for both RTP and RTCP associations. Note that the same certificate is used for both the RTP and RTCP associations. If RTP/RTCP multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] were being used only a single association would be required. Message (5):(7): Certificate Bob -> Alice Bob sends a Certificate, ClientKeyExchange, CertificateVerify, change_cipher_spec and Finished for both RTP and RTCP associations. Again note that Bob uses the same server certificate for both associations. Message (6):(8): Early Media Bob -> Alice At this point, Bob can begin sending early media (RTP and RTCP) to Alice. Note that Alice can't yet trust the media since the fingerprint has not yet been received. This lack of trusted, secure media is indicated to Alice. Message (7):(9): Finished Alice -> Bob After Message 57 is received by Bob, Alice sends change_cipher_spec and Finished. Message (8):(10): 200 OK Bob -> Alice When Bob answers the call, Bob sends a 200 OK SIP message which contains the fingerprint for Bob's certificate. When Alice receives the message and validates the certificate presented in Message 5.7. The endpoint now shows Alice that the call as secured. SIP/2.0 200 OK To: <sip:email@example.com>;tag=6418913922105372816 From: "Alice" <sip:firstname.lastname@example.org>;tag=843c7b0b Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Contact: <sip:192.168.1.104:5060;transport=TCP> Content-Type: application/sdp Content-Length: xxxx v=0 o=- 6418913922105372816 2105372818 IN IP4 192.168.1.104 s=example2 c=IN IP4 192.168.1.104 a=setup:active a=connection:newa=fingerprint:\ SHA-1 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 12000 UDP/TLS/RTP/SAVP 0 a=rtpmap:0 PCMU/8000/1a=acfg:1 t=1 Message (9):(11): RTP+RTCP Alice -> Bob At this point, Alice can also start sending RTP and RTCP to Bob. Note that in this case, Bob signals the actual transport protocol configuration of SRTP over DTLS in the acfg parameter. Message 10:(12): ACK Alice -> Bob Finally, Alice sends the SIP ACK to Bob. 8. Security Considerations DTLS or TLS media signalled with SIP requires a way to ensure that the communicating peers' certificates are correct. The standard TLS/DTLS strategy for authenticating the communicating parties is to give the server (and optionally the client) a PKIX [RFC3280] certificate. The client then verifies the certificate and checks that the name in the certificate matches the server's domain name. This works because there are a relatively small number of servers with well-defined names; a situation which does not usually occur in the VoIP context. The design described in this document is intended to leverage the authenticity of the signaling channel (while not requiring confidentiality). As long as each side of the connection can verify the integrity of the SDP INVITE then the DTLS handshake cannot be hijacked via a man-in-the-middle attack. This integrity protection is easily provided by the caller to the callee (see Alice to Bob in Section 7) via the SIP Identity [RFC4474] mechanism. However, it is less straightforward for the responder. Ideally Alice would want to know that Bob's SDP had not been tampered with and who it was from so that Alice's User Agent could indicate to Alice that there was a secure phone call to Bob. This is known as the SIP connected party problem and is still a topic of ongoing work in the SIP community. In the meantime, there are several approaches that can be used to mitigate this problem: Use UPDATE, Use SIPS, Use S/MIME, Single Sided Verification, or use human-read Short Authentication String (SAS) to validate the certificates. Each one is discussed here followed by the security implications of that approach. 8.1. UPDATE [RFC4916] defines an approach for a UA to supply its identity to its peer UA and for this identity to be signed by an authentication service. For example, using this approach, Bob sends an answer, then immediately follows up with an UPDATE that includes the fingerprint and uses the SIP Identity mechanism to assert that the message is from Bob@example.com. The downside of this approach is that it requires the extra round trip of the UPDATE. However, it is simple and secure even when not all of the proxies are trusted. In this example, Bob only needs to trust his proxy. [[OPEN ISSUE: Note that there is a window of vulnerability during the early media phase ofAnswerers SHOULD send use this operation before Alice receives theUPDATE (which immediately follows the SDP answer). During this window, Alice cannot be sure of Bob's identity. This risk might be mitigated by including a secret in the offer which must be used to establish the DTLS association, for instance via TLS PSK [RFC4279]. We are still studying this issue. Obviously, this is more attractive if SIPS is used.]]mechanisms. 8.2. SIPS In this approach, the signaling is protected by TLS from hop to hop. As long as all proxies are trusted, this provides integrity for the fingerprint. It does not provide a strong assertion of who Alice is communicating with. However, as much as the target domain can be trusted to correctly populate the From header field value, Alice can use that. The security issue with this approach is that if one of the Proxies wished to mount a man-in-the-middle attack, it could convince Alice that she was talking to Bob when really the media was flowing through a man in the middle media relay. However, this attack could not convince Bob that he was taking to Alice. 8.3. S/MIME RFC 3261 [RFC3261] defines a S/MIME security mechanism for SIP that could be used to sign that the fingerprint was from Bob. This would be secure. However, so far there have been no deployments of S/MIME for SIP. 8.4. Single-sided Verification In this approach, no integrity is provided for the fingerprint from Bob to Alice. In this approach, an attacker that was on the signaling path could tamper with the fingerprint and insert themselves as a man-in-the-middle on the media. Alice would know that she had a secure call with someone but would not know if it was with Bob or a man-in-the-middle. Bob would know that an attack was happening. The fact that one side can detect this attack means that in most cases where Alice and Bob both wish the communications to be encrypted there is not a problem. Keep in mind that in any of the possible approaches Bob could always reveal the media that was received to anyone. We are making the assumption that Bob also wants secure communications. In this do nothing case, Bob knows the media has not been tampered with or intercepted by a third party and that it is from Alice@example.com. Alice knows that she is talking to someone and that whoever that is has probably checked that the media is not being intercepted or tampered with. This approach is certainly less than ideal but very usable for many situations. 8.5. Continuity of Authentication One desirable property of a secure media system is to provide continuity of authentication: being able to ensure cryptographically that you are talking to the same person as before. With DTLS, continuity of authentication is achieved by having each side use the same public key/self-signed certificate for each connection (at least with a given peer entity). It then becomes possible to cache the credential (or its hash) and verify that it is unchanged. Thus, once a single secure connection has been established, an implementation can establish a future secure channel even in the face of future insecure signalling. In order to enable continuity of authentication, implementations SHOULD attempt to keep a constant long-term key. Verifying implementations SHOULD maintain a cache of the key used for each peer identity and alert the user if that key changes. 8.6. Short Authentication String An alternative available to Alice and Bob is to use human speech to verify each others' identity and then to verify each others' fingerprints also using human speech. Assuming that it is difficult to impersonate another's speech and seamlessly modify the audio contents of a call, this approach is relatively safe. It would not be effective if other forms of communication were being used such as video or instant messaging. DTLS supports this mode of operation. The minimal secure fingerprint length is around 64 bits. ZRTP [I-D.zimmermann-avt-zrtp] includes Short Authentication String mode in which a unique per-connection bitstring is generated as part of the cryptographic handshake. The SAS can be as short as 25 bits and so is somewhat easier to read. DTLS does not natively support this mode, however it would be straightforward to add one as a TLS extension [RFC3546]. 8.7. Perfect Forward Secrecy One concern about the use of a long-term key is that compromise of that key may lead to compromise of past communications. In order to prevent this attack, DTLS supports modes with Perfect Forward Secrecy using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites. When these modes are in use, the system is secure against such attacks. Note that compromise of a long-term key may still lead to future active attacks. If this is a concern, a backup authentication channel such as manual fingerprint establishment or a short authentication string should be used. 9. IANA Considerations This specification does not require any IANA actions. 10. Acknowledgments Cullen Jennings contributed substantial text and comments to this document. This document benefited from discussions with Francois Audet, Nagendra Modadugu, and Dan Wing. Thanks also for useful comments by Flemming Andreasen, Jonathan Rosenberg, Rohan Mahy, David McGrew, Miguel Garcia, Steffen Fries, Brian Stucker, Robert Gilman and David Oran. We would like to thank Thomas Belling, Guenther Horn, Steffen Fries, Brian Stucker, Francois Audet, Dan Wing, Jari Arkko, and Vesa Lehtovirta for their input regarding traversal of SBCs. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [I-D.fischl-mmusic-sdp-dtls] Fischl, J.[I-D.ietf-behave-rfc3489bis] Rosenberg, J., Mahy, R., Matthews, P., and H. Tschofenig,D. Wing, "Session Description Protocol (SDP) IndicatorsTraversal Utilities for Datagram Transport Layer Security (DTLS)", draft-fischl-mmusic-sdp-dtls-03(NAT) (STUN)", draft-ietf-behave-rfc3489bis-15 (work in progress), July 2007.February 2008. 11.2. Informational References [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, July 2006. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.[I-D.zimmermann-avt-zrtp] Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure RTP", draft-zimmermann-avt-zrtp-04 (work in progress), July 2007. [I-D.mcgrew-srtp-ekt] McGrew, D., "Encrypted Key Transport for Secure RTP", draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. [I-D.ietf-avt-dtls-srtp] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-00draft-ietf-avt-dtls-srtp-01 (work in progress), JulyNovember 2007. [I-D.ietf-sip-media-security-requirements] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security KeyManagement Protocols", draft-ietf-sip-media-security-requirements-00draft-ietf-sip-media-security-requirements-03 (work in progress), September 2007.February 2008. [I-D.ietf-mmusic-sdp-capability-negotiation] Andreasen, F., "SDP Capability Negotiation", draft-ietf-mmusic-sdp-capability-negotiation-07draft-ietf-mmusic-sdp-capability-negotiation-08 (work in progress), OctoberDecember 2007. [I-D.ietf-avt-rtp-and-rtcp-mux] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), August 2007. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.[I-D.wing-sipping-srtp-key] Wing, D., "DisclosingAudet, F., Fries, S., Tschofenig, H., and A. Johnston, "Secure Media Recording and Transcoding with the Session Initiation Protocol", draft-wing-sipping-srtp-key-03 (work in progress), February 2008. [I-D.wing-avt-dtls-srtp-key-transport] Wing, D., "Datagram TLS Secure RTP (SRTP) Session Keys with a SIP Event Package", draft-wing-sipping-srtp-key-01(DTLS-SRTP) Key Transport", draft-wing-avt-dtls-srtp-key-transport-01 (work in progress), July 2007.February 2008. [I-D.ietf-mmusic-media-path-middleboxes] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", draft-ietf-mmusic-media-path-middleboxes-00 (work in progress), January 2008. Appendix A. Requirements Analysis [I-D.ietf-sip-media-security-requirements] describes security requirements for media keying. This section evaluates this proposal with respect to each requirement. A.1. Forking and retargeting (R1, R2, R3)(R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT) In this draft, the SDP offer (in the INVITE) is simply an advertisement of the capability to do security. This advertisement does not depend on the identity of the communicating peer, so forking and retargeting work work when all the endpoints will do SRTP. When a mix of SRTP and non-SRTP endpoints are present, we expect touse the SDP capabilities mechanism currently being defined [I-D.ietf-mmusic-sdp-capability-negotiation][I-D.ietf-mmusic-sdp- capability-negotiation] to transparently negotiate security where possible. Because DTLS establishes a new key for each session, only the entity with which the call is finally established gets the media encryption keys (R3). A.2. Distinct Cryptographic Contexts (R-DISTINCT) DTLS performs a new DTLS handshake with each endpoint, which establishes distinct keys and cryptographic contexts for each endpoint. A.3. Reusage of a Security Context (R4), (R11)(R-REUSE) DTLS allows sessions to be resumed with the 'TLS session resumption' functionality. This feature can be used to lower the amount of cryptographic computation that needs to be done when two peers re- initiates the communication. A.3.A.4. Clipping (R5)(R-AVOID-CLIPPING) Because the key establishment occurs in the media plane, media need not be clipped before the receipt of the SDP answer. A.4.A.5. Passive Attacks on the Media Path (R6)(R-PASS-MEDIA) The public key algorithms used by DTLS ciphersuites, such as RSA, Diffie-Hellman, and Elliptic Curve Diffie-Hellman, are secure against passive attacks. A.5.A.6. Passive Attacks on the Signaling Path (R7)(R-PASS-SIG) DTLS provides protection against passive attacks by adversaries on the signaling path since only a fingerprint is exchanged using SIP signaling. A.6.A.7. (R-SIG-MEDIA, R-ACT-ACT) An attacker who controls the media channel but not the signalling channel can perform a MITM attack on the DTLS handshake but this will change the certificates which will cause the fingerprint check to fail. Thus, any successful attack requires that the attacker modify the signalling messages to replace the fingerprints. An attacker who controls the signalling channel at any point between the proxies performing the Identity signatures cannot modify the fingerprints without invalidating the Identity signature. Thus, even an attacker who controls both signalling and media paths cannot successfully attack the media traffic. Note that an attacker who controls the authentication service can impersonate the UA using that authentication service. This is an intended feature of SIP Identity--the authentication service owns the namespace and therefore defines which user has which identity. A.8. Binding to Identifiers (R-ID-BINDING) This mechanism uses SIP-Identity [RFC4474] and SIP-Connected-Identity [RFC4916] to bind the endpoint's certificate fingerprints to the From: address in the signalling. The fingerprint is covered by the Identity signature. A.9. Perfect Forward Secrecy (R8)(R-PFS) DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher suites which provide PFS. A.7.A.10. Algorithm Negotiation (R9)(R-COMPUTE) DTLS negotiates cipher suites before performing significant cryptographic computation and therefore supports algorithm negotiation and multiple cipher suites without additional computational expense. A.8.A.11. RTP Validity Check (R10) TBD A.9.(R-RTP-VALID) DTLS packets do not pass the RTP validity check. The first byte of a DTLS packet is the content type and All current DTLS content types have the first two bits set to zero, resulting in a version of 0, thus failing the first validity check. A.12. 3rd Party Certificates (R12, R18)(R-CERTS, R-EXISTING) Third party certificates are not required. However, if the parties share an authentication infrastructure that is compatible with TLS (3rd party certificates or shared keys) it can be used. A.10.A.13. FIPS 140-2 (R13)(R-FIPS) TLS implementations already may be FIPS 140-2 approved and the algorithms used here are consistent with the approval of DTLS and DTLS-SRTP. A.11.A.14. Linkage between Keying Exchange and SIP Signaling (R14)(R-ASSOC) The signaling exchange is linked to the key management exchange using the fingerprints carried in SIP and the certificates are exchanged in DTLS. A.12. Start with RTP and Upgrade to SRTP (R15) DTLS-SRTP as described in this framework does not require an SRTP security context to be established as part of the initial communication setup. Instead, the DTLS handshake can be initiated later during on ongoing session. A.13.A.15. Denial of Service Vulnerability (R16)(R-DOS) DTLS offers some degree of DoS protection particuarly as a built-in feature. A.14.A.16. Adversary Model (R17)(R-SIG-MEDIA) DTLS-SRTP requires that an adversary is at least able to intercept the fingerprint exchange along the SIP signaling path (i.e., active attack) and to intercept the DTLS handshake by acting as a man-in- the-middle adversary (i.e., active attack). A.15.A.17. Crypto-Agility (R19)(R-AGILITY) DTLS allows ciphersuites to be negotiated and hence new algorithms can be incrementally deployed. Work on replacing the fixed MD5/SHA-1 key derivation function is ongoing. A.16.A.18. Downgrading Protection (R20)(R-DOWNGRADE) DTLS provides protection against downgrading attacks since the selection of the offered ciphersuites is confirmed in a later stage of the handshake. This protection is efficient unless an adversary is able to break a ciphersuite in real-time. A.17.A.19. Media Security Negotation (R21)(R-NEGOTIATE) DTLS allows a User Agent to negotiate media security parameters for each individual session. A.18.A.20. Signaling Protocol Independence (R22)(R-OTHER-SIGNALING) The DTLS-SRTP framework does not rely on SIP; every protocol that is capable of exchanging a fingerprint and the media description can be secured. A.19.A.21. Media Recording (R23)(R-RECORDING) An extension, see [I-D.wing-sipping-srtp-key], has been specified to support media recording that does not require intermediaries to act as a MITM. When media recording is done by intermediaries then they need to act as a MITM. A.20. Lawful Interception (R24) Lawful interception requires an active MITM who is located along the signaling and the data path. A.21.as a MITM. A.22. Interworking with Intermediaries (R25)(R-TRANSCODER) A description of the interworking with Session Border Controllers is described in this document. A.22.A.23. PSTN Gateway Termination (R26)(R-PSTN) The DTLS-SRTP framework allows the media security to terminate at a PSTN gateway. [Editor's Note: A detailed description will be provided in a future versionThis does not provide end-to-end security, but is consistent with the security goals of this document.]framework because the gateway is authorized to speak for the PSTN namespace. Authors' Addresses Jason Fischl CounterPath Solutions, Inc.Corporation Suite 300, One Bentall Centre, 505 Burrard Street Vancouver, BC V7X 1M3 Canada Phone: +1 604 320-3340 Email: email@example.com Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Eric Rescorla Network Resonance 2483 E. Bayshore #212 Palo Alto, CA 94303 USA Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the IETF Administrative Support Activity (IASA).Internet Society.