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