idnits 2.17.1 draft-ietf-mmusic-4572-update-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 5, 2017) is 2667 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 4566 (ref. '8') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5246 (ref. '10') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '14') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4572 (ref. '21') (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. '23') (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Lennox 3 Internet-Draft Vidyo 4 Obsoletes: 4572 (if approved) C. Holmberg 5 Intended status: Standards Track Ericsson 6 Expires: July 9, 2017 January 5, 2017 8 Connection-Oriented Media Transport over TLS in SDP 9 draft-ietf-mmusic-4572-update-10 11 Abstract 13 This document specifies how to establish secure connection-oriented 14 media transport sessions over the Transport Layer Security (TLS) 15 protocol using the Session Description Protocol (SDP). It defines a 16 new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax 17 and semantics for an SDP 'fingerprint' attribute that identifies the 18 certificate that will be presented for the TLS session. This 19 mechanism allows media transport over TLS connections to be 20 established securely, so long as the integrity of session 21 descriptions is assured. 23 This document obsoletes RFC 4572, by clarifying the usage of multiple 24 fingerprints. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 9, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. SDP Operational Modes . . . . . . . . . . . . . . . . . . 4 64 3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. The Need for Self-Signed Certificates . . . . . . . . . . 5 66 3.4. Example SDP Description for TLS Connection . . . . . . . 6 67 4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . 6 68 5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Multiple Fingerprints . . . . . . . . . . . . . . . . . . 8 70 6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 9 71 6.1. Certificate Choice . . . . . . . . . . . . . . . . . . . 9 72 6.2. Certificate Presentation . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 9.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 The Session Description Protocol (SDP) [8] provides a general-purpose 84 format for describing multimedia sessions in announcements or 85 invitations. For many applications, it is desirable to establish, as 86 part of a multimedia session, a media stream that uses a connection- 87 oriented transport. RFC 4145, Connection-Oriented Media Transport in 88 the Session Description Protocol (SDP) [7], specifies a general 89 mechanism for describing and establishing such connection-oriented 90 streams; however, the only transport protocol it directly supports is 91 TCP. In many cases, session participants wish to provide 92 confidentiality, data integrity, and authentication for their media 93 sessions. This document therefore extends the Connection-Oriented 94 Media specification to allow session descriptions to describe media 95 sessions that use the Transport Layer Security (TLS) protocol [10]. 97 TLS protocol allows applications to communicate over a channel t 98 provides confidentiality and data integrity. The TLS specification, 99 however, does not specify how specific protocols establish and use 100 this secure channel; particularly, TLS leaves the question of how to 101 interpret and validate authentication certificates as an issue for 102 the protocols that run over TLS. This document specifies such usage 103 for the case of connection-oriented media transport. 105 Complicating this issue, endpoints exchanging media will often be 106 unable to obtain authentication certificates signed by a well-known 107 root certification authority (CA). Most certificate authorities 108 charge for signed certificates, particularly host-based certificates; 109 additionally, there is a substantial administrative overhead to 110 obtaining signed certificates, as certification authorities must be 111 able to confirm that they are issuing the signed certificates to the 112 correct party. Furthermore, in many cases endpoints' IP addresses 113 and host names are dynamic: they may be obtained from DHCP, for 114 example. It is impractical to obtain a CA-signed certificate valid 115 for the duration of a DHCP lease. For such hosts, self-signed 116 certificates are usually the only option. This specification defines 117 a mechanism that allows self-signed certificates can be used 118 securely, provided that the integrity of the SDP description is 119 assured. It provides for endpoints to include a secure hash of their 120 certificate, known as the "certificate fingerprint", within the 121 session description. Provided that the fingerprint of the offered 122 certificate matches the one in the session description, end hosts can 123 trust even self-signed certificates. 125 The rest of this document is laid out as follows. An overview of the 126 problem and threat model is given in Section 3. Section 4 gives the 127 basic mechanism for establishing TLS-based connected-oriented media 128 in SDP. Section 5 describes the SDP fingerprint attribute, which, 129 assuming that the integrity of SDP content is assured, allows the 130 secure use of self-signed certificates. Section 6 describes which 131 X.509 certificates are presented, and how they are used in TLS. 132 Section 7 discusses additional security considerations. 134 This document obsoletes [21] but remains backwards compatible with 135 older implementations. The changes from [21] are that it clarified 136 that multiple 'fingerprint' attributes can be used to carry 137 fingerprints, calculated using different hash functions, associated 138 with a given certificate, and to carry fingerprints associated with 139 multiple certificates. The fingerprint matching procedure, when 140 multiple fingerprints are provided, are also clarified. The document 141 also updates the preferred cipher suite with a stronger cipher suite, 142 and removes the requirement to use the same hash function for 143 calculating a certificate fingerprint and certificate signature. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [3]. 151 3. Overview 153 This section discusses the threat model that motivates TLS transport 154 for connection-oriented media streams. It also discusses in more 155 detail the need for end systems to use self-signed certificates. 157 3.1. SDP Operational Modes 159 There are two principal operational modes for multimedia sessions: 160 advertised and offer-answer. Advertised sessions are the simpler 161 mode. In this mode, a server publishes, in some manner, an SDP 162 session description of a multimedia session it is making available. 163 The classic example of this mode of operation is the Session 164 Announcement Protocol (SAP) [15], in which SDP session descriptions 165 are periodically transmitted to a well-known multicast group. 166 Traditionally, these descriptions involve multicast conferences, but 167 unicast sessions are also possible. (Connection-oriented media, 168 obviously, cannot use multicast.) Recipients of a session 169 description connect to the addresses published in the session 170 description. These recipients may not previously have been known to 171 the advertiser of the session description. 173 Alternatively, SDP conferences can operate in offer-answer mode [4]. 174 This mode allows two participants in a multimedia session to 175 negotiate the multimedia session between them. In this model, one 176 participant offers the other a description of the desired session 177 from its perspective, and the other participant answers with the 178 desired session from its own perspective. In this mode, each of the 179 participants in the session has knowledge of the other one. This is 180 the mode of operation used by the Session Initiation Protocol (SIP) 181 [17]. 183 3.2. Threat Model 185 Participants in multimedia conferences often wish to guarantee 186 confidentiality, data integrity, and authentication for their media 187 sessions. This section describes various types of attackers and the 188 ways they attempt to violate these guarantees. It then describes how 189 the TLS protocol can be used to thwart the attackers. 191 The simplest type of attacker is one who listens passively to the 192 traffic associated with a multimedia session. This attacker might, 193 for example, be on the same local-area or wireless network as one of 194 the participants in a conference. This sort of attacker does not 195 threaten a connection's data integrity or authentication, and almost 196 any operational mode of TLS can provide media stream confidentiality. 198 More sophisticated is an attacker who can send his own data traffic 199 over the network, but who cannot modify or redirect valid traffic. 200 In SDP's 'advertised' operational mode, this can barely be considered 201 an attack; media sessions are expected to be initiated from anywhere 202 on the network. In SDP's offer-answer mode, however, this type of 203 attack is more serious. An attacker could initiate a connection to 204 one or both of the endpoints of a session, thus impersonating an 205 endpoint, or acting as a man in the middle to listen in on their 206 communications. To thwart these attacks, TLS uses endpoint 207 certificates. So long as the certificates' private keys have not 208 been compromised, the endpoints have an external trusted mechanism 209 (most commonly, a mutually-trusted certification authority) to 210 validate certificates, and the endpoints know what certificate 211 identity to expect, endpoints can be certain that such an attack has 212 not taken place. 214 Finally, the most serious type of attacker is one who can modify or 215 redirect session descriptions: for example, a compromised or 216 malicious SIP proxy server. Neither TLS itself nor any mechanisms 217 that use it can protect an SDP session against such an attacker. 218 Instead, the SDP description itself must be secured through some 219 mechanism; SIP, for example, defines how S/MIME [23] can be used to 220 secure session descriptions. 222 3.3. The Need for Self-Signed Certificates 224 SDP session descriptions are created by any endpoint that needs to 225 participate in a multimedia session. In many cases, such as SIP 226 phones, such endpoints have dynamically-configured IP addresses and 227 host names and must be deployed with nearly zero configuration. For 228 such an endpoint, it is for practical purposes impossible to obtain a 229 certificate signed by a well-known certification authority. 231 If two endpoints have no prior relationship, self-signed certificates 232 cannot generally be trusted, as there is no guarantee that an 233 attacker is not launching a man-in-the-middle attack. Fortunately, 234 however, if the integrity of SDP session descriptions can be assured, 235 it is possible to consider those SDP descriptions themselves as a 236 prior relationship: certificates can be securely described in the 237 session description itself. This is done by providing a secure hash 238 of a certificate, or "certificate fingerprint", as an SDP attribute; 239 this mechanism is described in Section 5. 241 3.4. Example SDP Description for TLS Connection 243 Figure 1 illustrates an SDP offer that signals the availability of a 244 T.38 fax session over TLS. For the purpose of brevity, the main 245 portion of the session description is omitted in the example, showing 246 only the 'm' line and its attributes. (This example is the same as 247 the first one in RFC 4145 [7], except for the proto parameter and the 248 fingerprint attribute.) See the subsequent sections for explanations 249 of the example's TLS-specific attributes. 251 (Note: due to RFC formatting conventions, this document splits SDP 252 across lines whose content would exceed 72 characters. A backslash 253 character marks where this line folding has taken place. This 254 backslash and its trailing CRLF and whitespace would not appear in 255 actual SDP content.) 257 m=image 54111 TCP/TLS t38 258 c=IN IP4 192.0.2.2 259 a=setup:passive 260 a=connection:new 261 a=fingerprint:SHA-1 \ 262 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 264 Figure 1: Example SDP Description Offering a TLS Media Stream 266 4. Protocol Identifiers 268 The 'm' line in SDP specifies, among other items, the transport 269 protocol to be used for the media in the session. See the "Media 270 Descriptions" section of SDP [8] for a discussion on transport 271 protocol identifiers. 273 This specification defines a new protocol identifier, 'TCP/TLS', 274 which indicates that the media described will use the Transport Layer 275 Security protocol [10] over TCP. (Using TLS over other transport 276 protocols is not discussed in this document.) The 'TCP/TLS' protocol 277 identifier describes only the transport protocol, not the upper-layer 278 protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify 279 the protocol using a fmt identifier to indicate the application being 280 run over TLS. 282 Media sessions described with this identifier follow the procedures 283 defined in RFC 4145 [7]. They also use the SDP attributes defined in 284 that specification, 'setup' and 'connection'. 286 5. Fingerprint Attribute 288 Parties to a TLS session indicate their identities by presenting 289 authentication certificates as part of the TLS handshake procedure. 290 Authentication certificates are X.509 [2] certificates, as profiled 291 by RFC 3279 [5], RFC 5280 [11], and RFC 4055 [6]. 293 In order to associate media streams with connections and to prevent 294 unauthorized barge-in attacks on the media streams, endpoints MUST 295 provide a certificate fingerprint. If the X.509 certificate 296 presented for the TLS connection matches the fingerprint presented in 297 the SDP, the endpoint can be confident that the author of the SDP is 298 indeed the initiator of the connection. 300 A certificate fingerprint is a secure one-way hash of the DER 301 (distinguished encoding rules) form of the certificate. (Certificate 302 fingerprints are widely supported by tools that manipulate X.509 303 certificates; for instance, the command "openssl x509 -fingerprint" 304 causes the command-line tool of the openssl package to print a 305 certificate fingerprint, and the certificate managers for Mozilla and 306 Internet Explorer display them when viewing the details of a 307 certificate.) 309 A fingerprint is represented in SDP as an attribute (an 'a' line). 310 It consists of the name of the hash function used, followed by the 311 hash value itself. The hash value is represented as a sequence of 312 uppercase hexadecimal bytes, separated by colons. The number of 313 bytes is defined by the hash function. (This is the syntax used by 314 openssl and by the browsers' certificate managers. It is different 315 from the syntax used to represent hash values in, e.g., HTTP digest 316 authentication [25], which uses unseparated lowercase hexadecimal 317 bytes. It was felt that consistency with other applications of 318 fingerprints was more important.) 320 The formal syntax of the fingerprint attribute is given in Augmented 321 Backus-Naur Form [9] in Figure 2. This syntax extends the BNF syntax 322 of SDP [8]. 324 attribute =/ fingerprint-attribute 326 fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint 328 hash-func = "sha-1" / "sha-224" / "sha-256" / 329 "sha-384" / "sha-512" / 330 "md5" / "md2" / token 331 ; Additional hash functions can only come 332 ; from updates to RFC 3279 334 fingerprint = 2UHEX *(":" 2UHEX) 335 ; Each byte in upper-case hex, separated 336 ; by colons. 338 UHEX = DIGIT / %x41-46 ; A-F uppercase 340 Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute 342 Following RFC 3279 [5] as updated by RFC 4055 [6], therefore, the 343 defined hash functions are 'SHA-1' [1] [16], 'SHA-224' [1], 'SHA-256' 344 [1], 'SHA-384'[1], 'SHA-512' [1], 'MD5' [13] and 'MD2' [24], with 345 'SHA-256' preferred. A new IANA registry of Hash Function Textual 346 Names, specified in Section 8, allows for addition of future tokens, 347 but they may only be added if they are included in RFCs that update 348 or obsolete RFC 3279 [5]. 350 For backward compatibility with implementations compliant with RFC 351 4572 [21], the MD2 and MD5 cipher suites are still listed in the 352 syntax. However, implementations compliant to this specification 353 MUST NOT use them. 355 The fingerprint attribute may be either a session-level or a media- 356 level SDP attribute. If it is a session-level attribute, it applies 357 to all TLS sessions for which no media-level fingerprint attribute is 358 defined. 360 5.1. Multiple Fingerprints 362 Multiple SDP fingerprint attributes can be associated with an m- 363 line. This can occur if multiple fingerprints have been calculated 364 for a certificate using different hash functions. It can also occur 365 if one or more fingerprints associated with multiple certificates 366 have been calculated. This might be needed if multiple certificates 367 will be used for media associated with an m- line (e.g. if separate 368 certificates are used for RTP and RTCP), or where it is not known 369 which certificate will be used when the fingerprints are exchanged. 370 In such cases, one or more fingerprints MUST be calculated for each 371 possible certificate. 373 An endpoint MUST, as a minimum, calculate a fingerprint using both 374 the 'SHA-256' hash function algorithm and the hash function used to 375 generate the signature on the certificate for each possible 376 certificate. Including the hash from the signature algorithm ensures 377 interoperability with strict implementations of RFC 4572 [21]. 378 Either of these fingerprints MAY be omitted if the endpoint includes 379 a hash with a stronger hash algorithm that it knows that the peer 380 supports, if it is known that the peer does not support the hash 381 algorithm, or if local policy mandates use of stronger algorithms. 383 If fingerprints associated with multiple certificates are calculated, 384 the same set of hash functions MUST be used to calculate fingerprints 385 for each certificate associated with the m- line. 387 For each used certificate, an endpoint MUST be able to match at least 388 one fingerprint, calculated using the hash function that the endpoint 389 supports and considers most secure, with the used certificate. If 390 the checked fingerprint does not match the used certificate, the 391 endpoint MUST NOT establish the TLS connection. In addition, the 392 endpoint MAY also check fingerprints calculated using other hash 393 functions that it has received for a match. For each hash function 394 checked, one of the received fingerprints calculated using the hash 395 function MUST match the used certificate. 397 NOTE: The SDP fingerprint attribute does not contain a reference to a 398 specific certificate. Endpoints need to compare the fingerprint with 399 a certificate hash in order to look for a match. 401 6. Endpoint Identification 403 6.1. Certificate Choice 405 An X.509 certificate binds an identity and a public key. If SDP 406 describing a TLS session is transmitted over a mechanism that 407 provides integrity protection, a certificate asserting any 408 syntactically valid identity MAY be used. For example, an SDP 409 description sent over HTTP/TLS [14] or secured by S/MIME [23] MAY 410 assert any identity in the certificate securing the media connection. 412 Security protocols that provide only hop-by-hop integrity protection 413 (e.g., the sips protocol [17], SIP over TLS) are considered 414 sufficiently secure to allow the mode in which any valid identity is 415 accepted. However, see Section 7 for a discussion of some security 416 implications of this fact. 418 In situations where the SDP is not integrity-protected, however, the 419 certificate provided for a TLS connection MUST certify an appropriate 420 identity for the connection. In these scenarios, the certificate 421 presented by an endpoint MUST certify either the SDP connection 422 address, or the identity of the creator of the SDP message, as 423 follows: 425 o If the connection address for the media description is specified 426 as an IP address, the endpoint MAY use a certificate with an 427 iPAddress subjectAltName that exactly matches the IP in the 428 connection-address in the session description's 'c' line. 429 Similarly, if the connection address for the media description is 430 specified as a fully-qualified domain name, the endpoint MAY use a 431 certificate with a dNSName subjectAltName matching the specified 432 'c' line connection-address exactly. (Wildcard patterns MUST NOT 433 be used.) 435 o Alternately, if the SDP session description of the session was 436 transmitted over a protocol (such as SIP [17]) for which the 437 identities of session participants are defined by uniform resource 438 identifiers (URIs), the endpoint MAY use a certificate with a 439 uniformResourceIdentifier subjectAltName corresponding to the 440 identity of the endpoint that generated the SDP. The details of 441 what URIs are valid are dependent on the transmitting protocol. 442 (For more details on the validity of URIs, see Section 7.) 444 Identity matching is performed using the matching rules specified by 445 RFC 5280 [11]. If more than one identity of a given type is present 446 in the certificate (e.g., more than one dNSName name), a match in any 447 one of the set is considered acceptable. To support the use of 448 certificate caches, as described in Section 7, endpoints SHOULD 449 consistently provide the same certificate for each identity they 450 support. 452 6.2. Certificate Presentation 454 In all cases, an endpoint acting as the TLS server (i.e., one taking 455 the 'setup:passive' role, in the terminology of connection-oriented 456 media) MUST present a certificate during TLS initiation, following 457 the rules presented in Section 6.1. If the certificate does not 458 match the original fingerprint, the client endpoint MUST terminate 459 the media connection with a bad_certificate error. 461 If the SDP offer/answer model [4] is being used, the client (the 462 endpoint with the 'setup:active' role) MUST also present a 463 certificate following the rules of Section 6.1. The server MUST 464 request a certificate, and if the client does not provide one, or if 465 the certificate does not match the provided fingerprint, the server 466 endpoint MUST terminate the media connection with a bad_certificate 467 error. 469 Note that when the offer/answer model is being used, it is possible 470 for a media connection to outrace the answer back to the offerer. 471 Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' 472 role, it MUST (as specified in RFC 4145 [7]) begin listening for an 473 incoming connection as soon as it sends its offer. However, it MUST 474 NOT assume that the data transmitted over the TLS connection is valid 475 until it has received a matching fingerprint in an SDP answer. If 476 the fingerprint, once it arrives, does not match the client's 477 certificate, the server endpoint MUST terminate the media connection 478 with a bad_certificate error, as stated in the previous paragraph. 480 If offer/answer is not being used (e.g., if the SDP was sent over the 481 Session Announcement Protocol [15]), there is no secure channel 482 available for clients to communicate certificate fingerprints to 483 servers. In this case, servers MAY request client certificates, 484 which SHOULD be signed by a well-known certification authority, or 485 MAY allow clients to connect without a certificate. 487 7. Security Considerations 489 This entire document concerns itself with security. The problem to 490 be solved is addressed in Section 1, and a high-level overview is 491 presented in Section 3. See the SDP specification [8] for security 492 considerations applicable to SDP in general. 494 Offering a TCP/TLS connection in SDP (or agreeing to one in SDP 495 offer/answer mode) does not create an obligation for an endpoint to 496 accept any TLS connection with the given fingerprint. Instead, the 497 endpoint must engage in the standard TLS negotiation procedure to 498 ensure that the TLS stream cipher and MAC algorithm chosen meet the 499 security needs of the higher-level application. (For example, an 500 offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected 501 in almost every application scenario.) 503 Like all SDP messages, SDP messages describing TLS streams are 504 conveyed in an encapsulating application protocol (e.g., SIP, Media 505 Gateway Control Protocol (MGCP), etc.). It is the responsibility of 506 the encapsulating protocol to ensure the integrity of the SDP 507 security descriptions. Therefore, the application protocol SHOULD 508 either invoke its own security mechanisms (e.g., secure multiparts) 509 or, alternatively, utilize a lower-layer security service (e.g., TLS 510 or IPsec). This security service SHOULD provide strong message 511 authentication as well as effective replay protection. 513 However, such integrity protection is not always possible. For these 514 cases, end systems SHOULD maintain a cache of certificates that other 515 parties have previously presented using this mechanism. If possible, 516 users SHOULD be notified when an unsecured certificate associated 517 with a previously unknown end system is presented and SHOULD be 518 strongly warned if a different unsecured certificate is presented by 519 a party with which they have communicated in the past. In this way, 520 even in the absence of integrity protection for SDP, the security of 521 this document's mechanism is equivalent to that of the Secure Shell 522 (ssh) protocol [19], which is vulnerable to man-in-the-middle attacks 523 when two parties first communicate, but can detect ones that occur 524 subsequently. (Note that a precise definition of the "other party" 525 depends on the application protocol carrying the SDP message.) Users 526 SHOULD NOT, however, in any circumstances be notified about 527 certificates described in SDP descriptions sent over an integrity- 528 protected channel. 530 To aid interoperability and deployment, security protocols that 531 provide only hop-by-hop integrity protection (e.g., the sips protocol 532 [17], SIP over TLS) are considered sufficiently secure to allow the 533 mode in which any syntactically valid identity is accepted in a 534 certificate. This decision was made because sips is currently the 535 integrity mechanism most likely to be used in deployed networks in 536 the short to medium term. However, in this mode, SDP integrity is 537 vulnerable to attacks by compromised or malicious middleboxes, e.g., 538 SIP proxy servers. End systems MAY warn users about SDP sessions 539 that are secured in only a hop-by-hop manner, and definitions of 540 media formats running over TCP/TLS MAY specify that only end-to-end 541 integrity mechanisms be used. 543 Depending on how SDP messages are transmitted, it is not always 544 possible to determine whether or not a subjectAltName presented in a 545 remote certificate is expected for the remote party. In particular, 546 given call forwarding, third-party call control, or session 547 descriptions generated by endpoints controlled by the Gateway Control 548 Protocol [22], it is not always possible in SIP to determine what 549 entity ought to have generated a remote SDP response. In general, 550 when not using authenticity and integrity protection of SDP 551 descriptions, a certificate transmitted over SIP SHOULD assert the 552 endpoint's SIP Address of Record as a uniformResourceIndicator 553 subjectAltName. When an endpoint receives a certificate over SIP 554 asserting an identity (including an iPAddress or dNSName identity) 555 other than the one to which it placed or received the call, it SHOULD 556 alert the user and ask for confirmation. This applies whether 557 certificates are self-signed, or signed by certification authorities; 558 a certificate for "sip:bob@example.com" may be legitimately signed by 559 a certification authority, but may still not be acceptable for a call 560 to "sip:alice@example.com". (This issue is not one specific to this 561 specification; the same consideration applies for S/MIME-signed SDP 562 carried over SIP.) 563 This document does not define any mechanism for securely transporting 564 RTP and RTP Control Protocol (RTCP) packets over a connection- 565 oriented channel. There was no consensus in the working group as to 566 whether it would be better to send Secure RTP packets [18] over a 567 connection-oriented transport [20], or whether it would be better to 568 send standard unsecured RTP packets over TLS using the mechanisms 569 described in this document. The group consensus was to wait until a 570 use-case requiring secure connection-oriented RTP was presented. 572 TLS is not always the most appropriate choice for secure connection- 573 oriented media; in some cases, a higher- or lower-level security 574 protocol may be appropriate. 576 This document improves security from the RFC 4572 [21]. It updates 577 the preferred hash function cipher suite from SHA-1 to SHA-256, and 578 deprecates the usage of the MD2 and MD5 cipher suites. 579 By clarifying the usage and handling of multiple fingerprints, the 580 document also enables hash agility, and incremental deployment of 581 newer, and more secure, cipher suites. 583 8. IANA Considerations 585 Note to IANA. No IANA considerations are changed from RFC4572 [21] 586 so the only actions required are to update the registries to point at 587 this specification. 589 This document defines an SDP proto value: 'TCP/TLS'. Its format is 590 defined in Section 4. This proto value has been registered by IANA 591 under "Session Description Protocol (SDP) Parameters" under "proto". 593 This document defines an SDP session and media-level attribute: 594 'fingerprint'. Its format is defined in Section 5. This attribute 595 has been registered by IANA under "Session Description Protocol (SDP) 596 Parameters" under "att-field (both session and media level)". 598 The SDP specification [8] states that specifications defining new 599 proto values, like the 'TCP/TLS' proto value defined in this one, 600 must define the rules by which their media format (fmt) namespace is 601 managed. For the TCP/TLS protocol, new formats SHOULD have an 602 associated MIME registration. Use of an existing MIME subtype for 603 the format is encouraged. If no MIME subtype exists, it is 604 RECOMMENDED that a suitable one be registered through the IETF 605 process [12] by production of, or reference to, a standards-track RFC 606 that defines the transport protocol for the format. 608 This specification creates a new IANA registry named "Hash Function 609 Textual Names". It will not be part of the SDP Parameters. 611 The names of hash functions used for certificate fingerprints are 612 registered by the IANA. Hash functions MUST be defined by standards- 613 track RFCs that update or obsolete RFC 3279 [5]. 615 When registering a new hash function textual name, the following 616 information MUST be provided: 618 o The textual name of the hash function. 620 o The Object Identifier (OID) of the hash function as used in X.509 621 certificates. 623 o A reference to the standards-track RFC, updating or obsoleting RFC 624 3279 [5], defining the use of the hash function in X.509 625 certificates. 627 Table 1 contains the initial values of this registry. 629 +--------------------+------------------------+-----------+ 630 | Hash Function Name | OID | Reference | 631 +--------------------+------------------------+-----------+ 632 | "md2" | 1.2.840.113549.2.2 | RFC 3279 | 633 | "md5" | 1.2.840.113549.2.5 | RFC 3279 | 634 | "sha-1" | 1.3.14.3.2.26 | RFC 3279 | 635 | "sha-224" | 2.16.840.1.101.3.4.2.4 | RFC 4055 | 636 | "sha-256" | 2.16.840.1.101.3.4.2.1 | RFC 4055 | 637 | "sha-384" | 2.16.840.1.101.3.4.2.2 | RFC 4055 | 638 | "sha-512" | 2.16.840.1.101.3.4.2.3 | RFC 4055 | 639 +--------------------+------------------------+-----------+ 641 Table 1: IANA Hash Function Textual Name Registry 643 9. References 645 9.1. Normative References 647 [1] National Institute of Standards and Technology, "Secure 648 Hash Standard", FIPS PUB 180-2, August 2002, 649 . 652 [2] International Telecommunications Union, "Information 653 technology - Open Systems Interconnection - The Directory: 654 Public-key and attribute certificate frameworks", 655 ITU-T Recommendation X.509, ISO Standard 9594-8, March 656 2000. 658 [3] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, 660 DOI 10.17487/RFC2119, March 1997, 661 . 663 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 664 with Session Description Protocol (SDP)", RFC 3264, 665 DOI 10.17487/RFC3264, June 2002, 666 . 668 [5] Bassham, L., Polk, W., and R. Housley, "Algorithms and 669 Identifiers for the Internet X.509 Public Key 670 Infrastructure Certificate and Certificate Revocation List 671 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 672 2002, . 674 [6] Schaad, J., Kaliski, B., and R. Housley, "Additional 675 Algorithms and Identifiers for RSA Cryptography for use in 676 the Internet X.509 Public Key Infrastructure Certificate 677 and Certificate Revocation List (CRL) Profile", RFC 4055, 678 DOI 10.17487/RFC4055, June 2005, 679 . 681 [7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 682 the Session Description Protocol (SDP)", RFC 4145, 683 DOI 10.17487/RFC4145, September 2005, 684 . 686 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 687 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 688 July 2006, . 690 [9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 691 Specifications: ABNF", STD 68, RFC 5234, 692 DOI 10.17487/RFC5234, January 2008, 693 . 695 [10] Dierks, T. and E. Rescorla, "The Transport Layer Security 696 (TLS) Protocol Version 1.2", RFC 5246, 697 DOI 10.17487/RFC5246, August 2008, 698 . 700 [11] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 701 Housley, R., and W. Polk, "Internet X.509 Public Key 702 Infrastructure Certificate and Certificate Revocation List 703 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 704 . 706 [12] Freed, N., Klensin, J., and T. Hansen, "Media Type 707 Specifications and Registration Procedures", BCP 13, 708 RFC 6838, DOI 10.17487/RFC6838, January 2013, 709 . 711 9.2. Informative References 713 [13] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 714 DOI 10.17487/RFC1321, April 1992, 715 . 717 [14] Rescorla, E., "HTTP Over TLS", RFC 2818, 718 DOI 10.17487/RFC2818, May 2000, 719 . 721 [15] Handley, M., Perkins, C., and E. Whelan, "Session 722 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 723 October 2000, . 725 [16] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 726 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 727 . 729 [17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 730 A., Peterson, J., Sparks, R., Handley, M., and E. 731 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 732 DOI 10.17487/RFC3261, June 2002, 733 . 735 [18] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 736 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 737 RFC 3711, DOI 10.17487/RFC3711, March 2004, 738 . 740 [19] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 741 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 742 January 2006, . 744 [20] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 745 and RTP Control Protocol (RTCP) Packets over Connection- 746 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 747 2006, . 749 [21] Lennox, J., "Connection-Oriented Media Transport over the 750 Transport Layer Security (TLS) Protocol in the Session 751 Description Protocol (SDP)", RFC 4572, 752 DOI 10.17487/RFC4572, July 2006, 753 . 755 [22] Taylor, T., "Reclassification of RFC 3525 to Historic", 756 RFC 5125, DOI 10.17487/RFC5125, February 2008, 757 . 759 [23] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 760 Mail Extensions (S/MIME) Version 3.2 Message 761 Specification", RFC 5751, DOI 10.17487/RFC5751, January 762 2010, . 764 [24] Turner, S. and L. Chen, "MD2 to Historic Status", 765 RFC 6149, DOI 10.17487/RFC6149, March 2011, 766 . 768 [25] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 769 Digest Access Authentication", RFC 7616, 770 DOI 10.17487/RFC7616, September 2015, 771 . 773 Appendix A. Acknowledgments 775 This version of the document included significant contributions by 776 Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson. 778 Authors' Addresses 780 Jonathan Lennox 781 Vidyo 783 Email: jonathan@vidyo.com 785 Christer Holmberg 786 Ericsson 788 Email: christer.holmberg@ericsson.com