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