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