idnits 2.17.1 draft-ietf-mmusic-4572-update-09.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 2, 2017) is 2642 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 6, 2017 January 2, 2017 8 Connection-Oriented Media Transport over TLS in SDP 9 draft-ietf-mmusic-4572-update-09 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 6, 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 [24], 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" / 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], with 'SHA-256' 345 preferred. A new IANA registry of Hash Function Textual Names, 346 specified in Section 8, allows for addition of future tokens, but 347 they may only be added if they are included in RFCs that update or 348 obsolete RFC 3279 [5]. 350 The fingerprint attribute may be either a session-level or a media- 351 level SDP attribute. If it is a session-level attribute, it applies 352 to all TLS sessions for which no media-level fingerprint attribute is 353 defined. 355 5.1. Multiple Fingerprints 357 Multiple SDP fingerprint attributes can be associated with an m- 358 line. This can occur if multiple fingerprints have been calculated 359 for a certificate using different hash functions. It can also occur 360 if one or more fingerprints associated with multiple certificates 361 have been calculated. This might be needed if multiple certificates 362 will be used for media associated with an m- line (e.g. if separate 363 certificates are used for RTP and RTCP), or where it is not known 364 which certificate will be used when the fingerprints are exchanged. 365 In such cases, one or more fingerprints MUST be calculated for each 366 possible certificate. 368 An endpoint MUST, as a minimum, calculate a fingerprint using both 369 the 'SHA-256' hash function algorithm and the hash function used to 370 generate the signature on the certificate for each possible 371 certificate. Including the hash from the signature algorithm ensures 372 interoperability with strict implementations of RFC 4572 [21]. 373 Either of these fingerprints MAY be omitted if the endpoint includes 374 a hash with a stronger hash algorithm that it knows that the peer 375 supports, if it is known that the peer does not support the hash 376 algorithm, or if local policy mandates use of stronger algorithms. 378 If fingerprints associated with multiple certificates are calculated, 379 the same set of hash functions MUST be used to calculate fingerprints 380 for each certificate associated with the m- line. 382 For each used certificate, an endpoint MUST be able to match at least 383 one fingerprint, calculated using the hash function that the endpoint 384 supports and considers most secure, with the used certificate. If 385 the checked fingerprint does not match the used certificate, the 386 endpoint MUST NOT establish the TLS connection. In addition, the 387 endpoint MAY also check fingerprints calculated using other hash 388 functions that it has received for a match. For each hash function 389 checked, one of the received fingerprints calculated using the hash 390 function MUST match the used certificate. 392 NOTE: The SDP fingerprint attribute does not contain a reference to a 393 specific certificate. Endpoints need to compare the fingerprint with 394 a certificate hash in order to look for a match. 396 6. Endpoint Identification 398 6.1. Certificate Choice 400 An X.509 certificate binds an identity and a public key. If SDP 401 describing a TLS session is transmitted over a mechanism that 402 provides integrity protection, a certificate asserting any 403 syntactically valid identity MAY be used. For example, an SDP 404 description sent over HTTP/TLS [14] or secured by S/MIME [23] MAY 405 assert any identity in the certificate securing the media connection. 407 Security protocols that provide only hop-by-hop integrity protection 408 (e.g., the sips protocol [17], SIP over TLS) are considered 409 sufficiently secure to allow the mode in which any valid identity is 410 accepted. However, see Section 7 for a discussion of some security 411 implications of this fact. 413 In situations where the SDP is not integrity-protected, however, the 414 certificate provided for a TLS connection MUST certify an appropriate 415 identity for the connection. In these scenarios, the certificate 416 presented by an endpoint MUST certify either the SDP connection 417 address, or the identity of the creator of the SDP message, as 418 follows: 420 o If the connection address for the media description is specified 421 as an IP address, the endpoint MAY use a certificate with an 422 iPAddress subjectAltName that exactly matches the IP in the 423 connection-address in the session description's 'c' line. 424 Similarly, if the connection address for the media description is 425 specified as a fully-qualified domain name, the endpoint MAY use a 426 certificate with a dNSName subjectAltName matching the specified 427 'c' line connection-address exactly. (Wildcard patterns MUST NOT 428 be used.) 430 o Alternately, if the SDP session description of the session was 431 transmitted over a protocol (such as SIP [17]) for which the 432 identities of session participants are defined by uniform resource 433 identifiers (URIs), the endpoint MAY use a certificate with a 434 uniformResourceIdentifier subjectAltName corresponding to the 435 identity of the endpoint that generated the SDP. The details of 436 what URIs are valid are dependent on the transmitting protocol. 437 (For more details on the validity of URIs, see Section 7.) 439 Identity matching is performed using the matching rules specified by 440 RFC 5280 [11]. If more than one identity of a given type is present 441 in the certificate (e.g., more than one dNSName name), a match in any 442 one of the set is considered acceptable. To support the use of 443 certificate caches, as described in Section 7, endpoints SHOULD 444 consistently provide the same certificate for each identity they 445 support. 447 6.2. Certificate Presentation 449 In all cases, an endpoint acting as the TLS server (i.e., one taking 450 the 'setup:passive' role, in the terminology of connection-oriented 451 media) MUST present a certificate during TLS initiation, following 452 the rules presented in Section 6.1. If the certificate does not 453 match the original fingerprint, the client endpoint MUST terminate 454 the media connection with a bad_certificate error. 456 If the SDP offer/answer model [4] is being used, the client (the 457 endpoint with the 'setup:active' role) MUST also present a 458 certificate following the rules of Section 6.1. The server MUST 459 request a certificate, and if the client does not provide one, or if 460 the certificate does not match the provided fingerprint, the server 461 endpoint MUST terminate the media connection with a bad_certificate 462 error. 464 Note that when the offer/answer model is being used, it is possible 465 for a media connection to outrace the answer back to the offerer. 466 Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' 467 role, it MUST (as specified in RFC 4145 [7]) begin listening for an 468 incoming connection as soon as it sends its offer. However, it MUST 469 NOT assume that the data transmitted over the TLS connection is valid 470 until it has received a matching fingerprint in an SDP answer. If 471 the fingerprint, once it arrives, does not match the client's 472 certificate, the server endpoint MUST terminate the media connection 473 with a bad_certificate error, as stated in the previous paragraph. 475 If offer/answer is not being used (e.g., if the SDP was sent over the 476 Session Announcement Protocol [15]), there is no secure channel 477 available for clients to communicate certificate fingerprints to 478 servers. In this case, servers MAY request client certificates, 479 which SHOULD be signed by a well-known certification authority, or 480 MAY allow clients to connect without a certificate. 482 7. Security Considerations 484 This entire document concerns itself with security. The problem to 485 be solved is addressed in Section 1, and a high-level overview is 486 presented in Section 3. See the SDP specification [8] for security 487 considerations applicable to SDP in general. 489 Offering a TCP/TLS connection in SDP (or agreeing to one in SDP 490 offer/answer mode) does not create an obligation for an endpoint to 491 accept any TLS connection with the given fingerprint. Instead, the 492 endpoint must engage in the standard TLS negotiation procedure to 493 ensure that the TLS stream cipher and MAC algorithm chosen meet the 494 security needs of the higher-level application. (For example, an 495 offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected 496 in almost every application scenario.) 498 Like all SDP messages, SDP messages describing TLS streams are 499 conveyed in an encapsulating application protocol (e.g., SIP, Media 500 Gateway Control Protocol (MGCP), etc.). It is the responsibility of 501 the encapsulating protocol to ensure the integrity of the SDP 502 security descriptions. Therefore, the application protocol SHOULD 503 either invoke its own security mechanisms (e.g., secure multiparts) 504 or, alternatively, utilize a lower-layer security service (e.g., TLS 505 or IPsec). This security service SHOULD provide strong message 506 authentication as well as effective replay protection. 508 However, such integrity protection is not always possible. For these 509 cases, end systems SHOULD maintain a cache of certificates that other 510 parties have previously presented using this mechanism. If possible, 511 users SHOULD be notified when an unsecured certificate associated 512 with a previously unknown end system is presented and SHOULD be 513 strongly warned if a different unsecured certificate is presented by 514 a party with which they have communicated in the past. In this way, 515 even in the absence of integrity protection for SDP, the security of 516 this document's mechanism is equivalent to that of the Secure Shell 517 (ssh) protocol [19], which is vulnerable to man-in-the-middle attacks 518 when two parties first communicate, but can detect ones that occur 519 subsequently. (Note that a precise definition of the "other party" 520 depends on the application protocol carrying the SDP message.) Users 521 SHOULD NOT, however, in any circumstances be notified about 522 certificates described in SDP descriptions sent over an integrity- 523 protected channel. 525 To aid interoperability and deployment, security protocols that 526 provide only hop-by-hop integrity protection (e.g., the sips protocol 527 [17], SIP over TLS) are considered sufficiently secure to allow the 528 mode in which any syntactically valid identity is accepted in a 529 certificate. This decision was made because sips is currently the 530 integrity mechanism most likely to be used in deployed networks in 531 the short to medium term. However, in this mode, SDP integrity is 532 vulnerable to attacks by compromised or malicious middleboxes, e.g., 533 SIP proxy servers. End systems MAY warn users about SDP sessions 534 that are secured in only a hop-by-hop manner, and definitions of 535 media formats running over TCP/TLS MAY specify that only end-to-end 536 integrity mechanisms be used. 538 Depending on how SDP messages are transmitted, it is not always 539 possible to determine whether or not a subjectAltName presented in a 540 remote certificate is expected for the remote party. In particular, 541 given call forwarding, third-party call control, or session 542 descriptions generated by endpoints controlled by the Gateway Control 543 Protocol [22], it is not always possible in SIP to determine what 544 entity ought to have generated a remote SDP response. In general, 545 when not using authenticity and integrity protection of SDP 546 descriptions, a certificate transmitted over SIP SHOULD assert the 547 endpoint's SIP Address of Record as a uniformResourceIndicator 548 subjectAltName. When an endpoint receives a certificate over SIP 549 asserting an identity (including an iPAddress or dNSName identity) 550 other than the one to which it placed or received the call, it SHOULD 551 alert the user and ask for confirmation. This applies whether 552 certificates are self-signed, or signed by certification authorities; 553 a certificate for "sip:bob@example.com" may be legitimately signed by 554 a certification authority, but may still not be acceptable for a call 555 to "sip:alice@example.com". (This issue is not one specific to this 556 specification; the same consideration applies for S/MIME-signed SDP 557 carried over SIP.) 559 This document does not define any mechanism for securely transporting 560 RTP and RTP Control Protocol (RTCP) packets over a connection- 561 oriented channel. There was no consensus in the working group as to 562 whether it would be better to send Secure RTP packets [18] over a 563 connection-oriented transport [20], or whether it would be better to 564 send standard unsecured RTP packets over TLS using the mechanisms 565 described in this document. The group consensus was to wait until a 566 use-case requiring secure connection-oriented RTP was presented. 568 TLS is not always the most appropriate choice for secure connection- 569 oriented media; in some cases, a higher- or lower-level security 570 protocol may be appropriate. 572 This document improves security from the RFC 4572 [21]. It updates 573 the preferred hash function cipher suite from SHA-1 to SHA-256, and 574 removes the reference to the MD2 cipher suite. 575 By clarifying the usage and handling of multiple fingerprints, the 576 document also enables hash agility, and incremental deployment of 577 newer, and more secure, cipher suites. 579 8. IANA Considerations 581 Note to IANA. No IANA considerations are changed from RFC4572 [21] 582 so the only actions required are to update the registries to point at 583 this specification. 585 This document defines an SDP proto value: 'TCP/TLS'. Its format is 586 defined in Section 4. This proto value has been registered by IANA 587 under "Session Description Protocol (SDP) Parameters" under "proto". 589 This document defines an SDP session and media-level attribute: 590 'fingerprint'. Its format is defined in Section 5. This attribute 591 has been registered by IANA under "Session Description Protocol (SDP) 592 Parameters" under "att-field (both session and media level)". 594 The SDP specification [8] states that specifications defining new 595 proto values, like the 'TCP/TLS' proto value defined in this one, 596 must define the rules by which their media format (fmt) namespace is 597 managed. For the TCP/TLS protocol, new formats SHOULD have an 598 associated MIME registration. Use of an existing MIME subtype for 599 the format is encouraged. If no MIME subtype exists, it is 600 RECOMMENDED that a suitable one be registered through the IETF 601 process [12] by production of, or reference to, a standards-track RFC 602 that defines the transport protocol for the format. 604 This specification creates a new IANA registry named "Hash Function 605 Textual Names". It will not be part of the SDP Parameters. 607 The names of hash functions used for certificate fingerprints are 608 registered by the IANA. Hash functions MUST be defined by standards- 609 track RFCs that update or obsolete RFC 3279 [5]. 611 When registering a new hash function textual name, the following 612 information MUST be provided: 614 o The textual name of the hash function. 616 o The Object Identifier (OID) of the hash function as used in X.509 617 certificates. 619 o A reference to the standards-track RFC, updating or obsoleting RFC 620 3279 [5], defining the use of the hash function in X.509 621 certificates. 623 Table 1 contains the initial values of this registry. 625 +--------------------+------------------------+-----------+ 626 | Hash Function Name | OID | Reference | 627 +--------------------+------------------------+-----------+ 628 | "md5" | 1.2.840.113549.2.5 | RFC 3279 | 629 | "sha-1" | 1.3.14.3.2.26 | RFC 3279 | 630 | "sha-224" | 2.16.840.1.101.3.4.2.4 | RFC 4055 | 631 | "sha-256" | 2.16.840.1.101.3.4.2.1 | RFC 4055 | 632 | "sha-384" | 2.16.840.1.101.3.4.2.2 | RFC 4055 | 633 | "sha-512" | 2.16.840.1.101.3.4.2.3 | RFC 4055 | 634 +--------------------+------------------------+-----------+ 636 Table 1: IANA Hash Function Textual Name Registry 638 9. References 640 9.1. Normative References 642 [1] National Institute of Standards and Technology, "Secure 643 Hash Standard", FIPS PUB 180-2, August 2002, 644 . 647 [2] International Telecommunications Union, "Information 648 technology - Open Systems Interconnection - The Directory: 649 Public-key and attribute certificate frameworks", 650 ITU-T Recommendation X.509, ISO Standard 9594-8, March 651 2000. 653 [3] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 659 with Session Description Protocol (SDP)", RFC 3264, 660 DOI 10.17487/RFC3264, June 2002, 661 . 663 [5] Bassham, L., Polk, W., and R. Housley, "Algorithms and 664 Identifiers for the Internet X.509 Public Key 665 Infrastructure Certificate and Certificate Revocation List 666 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 667 2002, . 669 [6] Schaad, J., Kaliski, B., and R. Housley, "Additional 670 Algorithms and Identifiers for RSA Cryptography for use in 671 the Internet X.509 Public Key Infrastructure Certificate 672 and Certificate Revocation List (CRL) Profile", RFC 4055, 673 DOI 10.17487/RFC4055, June 2005, 674 . 676 [7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 677 the Session Description Protocol (SDP)", RFC 4145, 678 DOI 10.17487/RFC4145, September 2005, 679 . 681 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 682 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 683 July 2006, . 685 [9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 686 Specifications: ABNF", STD 68, RFC 5234, 687 DOI 10.17487/RFC5234, January 2008, 688 . 690 [10] Dierks, T. and E. Rescorla, "The Transport Layer Security 691 (TLS) Protocol Version 1.2", RFC 5246, 692 DOI 10.17487/RFC5246, August 2008, 693 . 695 [11] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 696 Housley, R., and W. Polk, "Internet X.509 Public Key 697 Infrastructure Certificate and Certificate Revocation List 698 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 699 . 701 [12] Freed, N., Klensin, J., and T. Hansen, "Media Type 702 Specifications and Registration Procedures", BCP 13, 703 RFC 6838, DOI 10.17487/RFC6838, January 2013, 704 . 706 9.2. Informative References 708 [13] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 709 DOI 10.17487/RFC1321, April 1992, 710 . 712 [14] Rescorla, E., "HTTP Over TLS", RFC 2818, 713 DOI 10.17487/RFC2818, May 2000, 714 . 716 [15] Handley, M., Perkins, C., and E. Whelan, "Session 717 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 718 October 2000, . 720 [16] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 721 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 722 . 724 [17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 725 A., Peterson, J., Sparks, R., Handley, M., and E. 726 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 727 DOI 10.17487/RFC3261, June 2002, 728 . 730 [18] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 731 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 732 RFC 3711, DOI 10.17487/RFC3711, March 2004, 733 . 735 [19] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 736 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 737 January 2006, . 739 [20] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 740 and RTP Control Protocol (RTCP) Packets over Connection- 741 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 742 2006, . 744 [21] Lennox, J., "Connection-Oriented Media Transport over the 745 Transport Layer Security (TLS) Protocol in the Session 746 Description Protocol (SDP)", RFC 4572, 747 DOI 10.17487/RFC4572, July 2006, 748 . 750 [22] Taylor, T., "Reclassification of RFC 3525 to Historic", 751 RFC 5125, DOI 10.17487/RFC5125, February 2008, 752 . 754 [23] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 755 Mail Extensions (S/MIME) Version 3.2 Message 756 Specification", RFC 5751, DOI 10.17487/RFC5751, January 757 2010, . 759 [24] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 760 Digest Access Authentication", RFC 7616, 761 DOI 10.17487/RFC7616, September 2015, 762 . 764 Appendix A. Acknowledgments 766 This version of the document included significant contributions by 767 Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson. 769 Authors' Addresses 771 Jonathan Lennox 772 Vidyo 774 Email: jonathan@vidyo.com 776 Christer Holmberg 777 Ericsson 779 Email: christer.holmberg@ericsson.com