idnits 2.17.1 draft-ietf-mmusic-comedia-tls-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 807. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2006) is 6591 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) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 3280 (ref. '8') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4234 (ref. '10') (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '12') ** Obsolete normative reference: RFC 1319 (ref. '13') (Obsoleted by RFC 6149) ** Obsolete normative reference: RFC 4288 (ref. '14') (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '17') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '18') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '20') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3525 (ref. '22') (Obsoleted by RFC 5125) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multiparty Multimedia Session J. Lennox 3 Control Columbia U. 4 Internet-Draft March 3, 2006 5 Expires: September 4, 2006 7 Connection-Oriented Media Transport over the Transport Layer Security 8 (TLS) Protocol in the Session Description Protocol (SDP) 9 draft-ietf-mmusic-comedia-tls-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 4, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies how to establish secure connection-oriented 43 media transport sessions over the Transport Layer Security (TLS) 44 protocol using the Session Description Protocol (SDP). It defines a 45 new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax 46 and semantics for an SDP 'fingerprint' attribute that identifies the 47 certificate which will be presented for the TLS session. This 48 mechanism allows media transport over TLS connections to be 49 established securely, so long as the integrity of session 50 descriptions is assured. 52 This revision of the document reflects comments made during IESG 53 review. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. SDP Operational Modes . . . . . . . . . . . . . . . . . . 4 61 3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5 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 6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 8 67 6.1. Certificate Choice . . . . . . . . . . . . . . . . . . . . 8 68 6.2. Certificate Presentation . . . . . . . . . . . . . . . . . 9 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 13 72 Appendix A.1. Changes From Draft -05 . . . . . . . . . . . . . . . 13 73 Appendix A.2. Changes From Draft -04 . . . . . . . . . . . . . . . 14 74 Appendix A.3. Changes From Draft -03 . . . . . . . . . . . . . . . 14 75 Appendix A.4. Changes From Draft -02 . . . . . . . . . . . . . . . 15 76 Appendix A.5. Changes From Draft -01 . . . . . . . . . . . . . . . 15 77 Appendix A.6. Changes From Draft -00 . . . . . . . . . . . . . . . 15 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Intellectual Property and Copyright Statements . . . . . . . . . . 19 84 1. Introduction 86 The Session Description Protocol (SDP) [1] provides a general purpose 87 format for describing multimedia sessions in announcements or 88 invitations. For many applications, it is desirable to establish, as 89 part of a multimedia session, a media stream which uses a connection- 90 oriented transport. RFC 4145, Connection-Oriented Media Transport in 91 the Session Description Protocol (SDP) [2], specifies a general 92 mechanism for describing and establishing such connection-oriented 93 streams; however, the only transport protocol it directly supports is 94 TCP. In many cases, session participants wish to provide 95 confidentiality, data integrity, and authentication for their media 96 sessions. This document therefore extends the Connection-Oriented 97 Media specification to allow session descriptions to describe media 98 sessions that use the Transport Layer Security (TLS) protocol [3]. 100 The TLS protocol allows applications to communicate over a channel 101 which provides confidentiality and data integrity. The TLS 102 specification, however, does not specify how specific protocols 103 establish and use this secure channel; particularly, TLS leaves the 104 question of how to interpret and validate authentication certificates 105 as an issue for the protocols which run over TLS. This document 106 specifies such usage for the case of connection-oriented media 107 transport. 109 Complicating this issue, endpoints exchanging media will often be 110 unable to obtain authentication certificates signed by a well-known 111 root certification authority (CA). Most certificate authorities 112 charge for signed certificates, particularly host-based certificates; 113 additionally, there is a substantial administrative overhead to 114 obtaining signed certificates, as certification authorities must be 115 able to confirm that they are issuing the signed certificates to the 116 correct party. Furthermore, in many cases endpoints' IP addresses 117 and host names are dynamic: they may be obtained from DHCP, for 118 example. It is impractical to obtain a CA-signed certificate valid 119 for the duration of a DHCP lease. For such hosts, self-signed 120 certificates are usually the only option. This specification defines 121 a mechanism which allows self-signed certificates can be used 122 securely, provided that the integrity of the SDP description is 123 assured. It provides for endpoints to include a secure hash of their 124 certificate, known as the "certificate fingerprint", within the 125 session description. Provided the fingerprint of the offered 126 certificate matches the one in the session description, end hosts can 127 trust even self-signed certificates. 129 The rest of this document is laid out as follows. An overview of the 130 problem and threat model is given in Section 3. Section 4 gives the 131 basic mechanism for establishing TLS-based connected-oriented media 132 in SDP. Section 5 describes the SDP fingerprint attribute, which, 133 assuming the integrity of SDP content is assured, allows the secure 134 use of self-signed certificates. Section 6 describes which X.509 135 certificates are presented, and how they are used in TLS. Section 7 136 discusses additional security considerations. 138 2. Terminology 140 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 141 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 142 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and 143 indicate requirement levels for compliant implementations. 145 3. Overview 147 This section discusses the threat model which motivates TLS transport 148 for connection-oriented media streams. It also discusses in more 149 detail the need for end systems to use self-signed certificates. 151 3.1. SDP Operational Modes 153 There are two principal operational modes for multimedia sessions: 154 advertised and offer-answer. Advertised sessions are the simpler 155 mode. In this mode, a server publishes, in some manner, an SDP 156 session description describing a multimedia session it is making 157 available. The classic example of this mode of operation is the 158 Session Announcement Protocol (SAP) [15], in which SDP session 159 descriptions are periodically transmitted to a well-known multicast 160 group. Traditionally, these descriptions involve multicast 161 conferences, but unicast sessions are also possible. (Connection- 162 oriented media, obviously, cannot use multicast.) Recipients of a 163 session description connect to the addresses published in the session 164 description. These recipients may not previously have been known to 165 the advertiser of the session description. 167 Alternatively, SDP conferences can operate in offer-answer mode [5]. 168 This mode allows two participants in a multimedia session to 169 negotiate the multimedia session between them. In this model, one 170 participant offers the other a description of the desired session 171 from its perspective, and the other participant answers with the 172 desired session from its own perspective. In this mode, each of the 173 participants in the session has knowledge of the other one. This is 174 the mode of operation used by the Session Initiation Protocol (SIP) 175 [16]. 177 3.2. Threat Model 179 Participants in multimedia conferences often wish to guarantee 180 confidentiality, data integrity, and authentication for their media 181 sessions. This section describes various types of attackers and the 182 ways they attempt to violate these guarantees. It then describes how 183 the TLS protocol can be used to thwart the attackers. 185 The simplest type of attacker is one who listens passively to the 186 traffic associated with a multimedia session. This attacker might, 187 for example, be on the same local-area or wireless network as one of 188 the participants in a conference. This sort of attacker does not 189 threaten a connection's data integrity or authentication, and almost 190 any operational mode of TLS can provide media stream confidentiality. 192 More sophisticated is an attacker who can send his own data traffic 193 over the network, but who cannot modify or redirect valid traffic. 194 In SDP's 'advertised' operational mode, this can barely be considered 195 an attack; media sessions are expected to be initiated from anywhere 196 on the network. In SDP's offer-answer mode, however, this type of 197 attack is more serious. An attacker could initiate a connection to 198 one or both of the endpoints of a session, thus impersonating an 199 endpoint, or acting as a man in the middle to listen in on their 200 communications. To thwart these attacks, TLS uses endpoint 201 certificates. So long as the certificates' private keys have not 202 been compromised, the endpoints have an external trusted mechanism 203 (most commonly, a mutually-trusted certification authority) to 204 validate certificates, and the endpoints know what certificate 205 identity to expect, endpoints can be certain that such an attack has 206 not taken place. 208 Finally, the most serious type of attacker is one who can modify or 209 redirect session descriptions: for example, a compromised or 210 malicious SIP proxy server. Neither TLS itself, nor any mechanisms 211 which use it, can protect an SDP session against such an attacker. 212 Instead, the SDP description itself must be secured through some 213 mechanism; SIP, for example, defines how S/MIME [17] can be used to 214 secure session descriptions. 216 3.3. The Need For Self-Signed Certificates 218 SDP session descriptions are created by any endpoint that needs to 219 participate in a multimedia session. In many cases, such as SIP 220 phones, such endpoints have dynamically-configured IP addresses and 221 host names, and must be deployed with nearly zero configuration. For 222 such an endpoint, it is for practical purposes impossible to obtain a 223 certificate signed by a well-known certification authority. 225 If two endpoints have no prior relationship, self-signed certificates 226 cannot generally be trusted, as there is no guarantee that an 227 attacker is not launching a man-in-the-middle attack. Fortunately, 228 however, if the integrity of SDP session descriptions can be assured, 229 it is possible to consider those SDP descriptions themselves as a 230 prior relationship: certificates can be securely described in the 231 session description itself. This is done by providing a secure hash 232 of a certificate, or "certificate fingerprint", as an SDP attribute; 233 this mechanism is described in Section 5. 235 3.4. Example SDP Description For TLS Connection 237 Figure 1 illustrates an SDP offer which signals the availability of a 238 T.38 fax session over TLS. For the purpose of brevity, the main 239 portion of the session description is omitted in the example, showing 240 only the 'm' line and its attributes. (This example is the same as 241 the first one in RFC 4145 [2], except for the proto parameter and the 242 fingerprint attribute.) See the subsequent sections for explanations 243 of the example's TLS-specific attributes. 245 (Note: due to RFC formatting conventions, this draft splits SDP 246 across lines whose content would exceed 72 characters. A backslash 247 character marks where this line folding has taken place. This 248 backslash and its trailing CRLF and whitespace would not appear in 249 actual SDP content.) 251 m=image 54111 TCP/TLS t38 252 c=IN IP4 192.0.2.2 253 a=setup:passive 254 a=connection:new 255 a=fingerprint:SHA-1 \ 256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 258 Figure 1: Example SDP Description Offering a TLS Media Stream 260 4. Protocol Identifiers 262 The 'm' line in SDP specifies, among other items, the transport 263 protocol to be used for the media in the session. See the "Media 264 Descriptions" section of SDP [1] for a discussion on transport 265 protocol identifiers. 267 This specification defines a new protocol identifier, 'TCP/TLS', 268 which indicates that the media described will use the Transport Layer 269 Security protocol [3] over TCP. (Using TLS over other transport 270 protocols is not discussed by this document.) The 'TCP/TLS' protocol 271 identifier describes only the transport protocol, not the upper-layer 272 protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify 273 the protocol using a fmt identifier, to indicate the application 274 being run over TLS. 276 Media sessions described with this identifier follow the procedures 277 defined in RFC 4145 [2]. They also use the SDP attributes defined in 278 that specification, 'setup' and 'connection'. 280 5. Fingerprint Attribute 282 Parties to a TLS session indicate their identities by presenting 283 authentication certificates as part of the TLS handshake procedure. 284 Authentication certificates are X.509 [6] certificates, as profiled 285 by RFC 3279 [7], RFC 3280 [8] and RFC 4055 [9]. 287 In order to associate media streams with connections, and to prevent 288 unauthorized barge-in attacks on the media streams, endpoints MUST 289 provide a certificate fingerprint. If the X.509 certificate 290 presented for the TLS connection matches the fingerprint presented in 291 the SDP, the endpoint can be confident that the author of the SDP is 292 indeed the initiator of the connection. 294 A certificate fingerprint is a secure one-way hash of the DER 295 (distinguished encoding rules) form of the certificate. (Certificate 296 fingerprints are widely supported by tools which manipulate X.509 297 certificates; for instance, the command "openssl x509 -fingerprint" 298 causes the command-line tool of the openssl package to print a 299 certificate fingerprint, and the certificate managers for Mozilla and 300 Internet Explorer display them when viewing the details of a 301 certificate.) 303 A fingerprint is represented in SDP as an attribute (an 'a' line). 304 It consists of the name of the hash function used, followed by the 305 hash value itself. The hash value is represented as a sequence of 306 upper-case hexadecimal bytes, separated by colons. The number of 307 bytes is defined by the hash function. (This is the syntax used by 308 openssl and by the browsers' certificate managers. It is different 309 from the syntax used to represent hash values in, e.g., HTTP digest 310 authentication [18], which uses unseparated lower-case hexadecimal 311 bytes. It was felt that consistency with other applications of 312 fingerprints was more important.) 314 The formal syntax of the fingerprint attribute is given in Augmented 315 Backus-Naur Form [10] in Figure 2. This syntax extends the BNF 316 syntax of SDP [1]. 318 attribute =/ fingerprint-attribute 320 fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint 322 hash-func = "sha-1" / "sha-224" / "sha-256" / 323 "sha-384" / "sha-512" / 324 "md5" / "md2" / token 325 ; Additional hash functions can only come 326 ; from updates to RFC 3279 328 fingerprint = 2UHEX *(":" 2UHEX) 329 ; Each byte in upper-case hex, separated 330 ; by colons. 332 UHEX = DIGIT / %x41-46 ; A-F uppercase 334 Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute 336 A certificate fingerprint MUST be computed using the same one-way 337 hash function as is used in the certificate's signature algorithm. 338 (This ensures that the security properties required for the 339 certificate are also apply for the fingerprint. It also guarantees 340 that the fingerprint will be usable by the other endpoint, so long as 341 the certificate itself is.) Following RFC 3279 [7] as updated by RFC 342 4055 [9], therefore, the defined hash functions are 'SHA-1' [11] 343 [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 344 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA 345 registry of Hash Function Textual Names, specified in Section 8, 346 allows for addition of future tokens, but they may only be added if 347 they are included in RFCs which update or obsolete RFC 3279 [7]. 348 Self-signed certificates (for which legacy certificates are not a 349 consideration) MUST use one of the FIPS 180 algorithms (SHA-1, SHA- 350 224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and 351 thus also MUST use it to calculate certificate fingerprints. 353 The fingerprint attribute may be either a session-level or a media- 354 level SDP attribute. If it is a session-level attribute, it applies 355 to all TLS sessions for which no media-level fingerprint attribute is 356 defined. 358 6. Endpoint Identification 360 6.1. Certificate Choice 362 An X.509 certificate binds an identity and a public key. If SDP 363 describing a TLS session is transmitted over a mechanism which 364 provides integrity protection, a certificate asserting any 365 syntactically valid identity MAY be used. For example, an SDP 366 description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY 367 assert any identity in the certificate securing the media connection. 369 Security protocols which provide only hop-by-hop integrity 370 protection, e.g., the sips protocol [16] (SIP over TLS), are 371 considered sufficiently secure to allow the mode in which any valid 372 identity is accepted. However, see Section 7 for a discussion of 373 some security implications of this fact. 375 In situations where the SDP is not integrity-protected, however, the 376 certificate provided for a TLS connection MUST certify an appropriate 377 identity for the connection. In these scenarios, the certificate 378 presented by an endpoint MUST certify either the SDP connection 379 address, or the identity of the creator of the SDP message, as 380 follows: 382 o If the connection address for the media description is specified 383 as an IP address, the endpoint MAY use a certificate with an 384 iPAddress subjectAltName which exactly matches the IP in the 385 connection-address in the session description's 'c' line. 386 Similarly, if the connection address for the media description is 387 specified as a pfully-qualified domain name, the endpoint MAY use 388 a certificate with a dNSName subjectAltName matching the specified 389 'c' line connection-address exactly. (Wildcard patterns MUST NOT 390 be used.) 391 o Alternately, if the SDP session description describing the session 392 was transmitted over a protocol (such as SIP [16]) for which the 393 identities of session participants are defined by uniform resource 394 identifiers (URIs), the endpoint MAY use a certificate with a 395 uniformResourceIdentifier subjectAltName corresponding to the 396 identity of the endpoint which generated the SDP. The details of 397 what URIs are valid are dependent on the transmitting protocol. 398 (For more details on the validity of URIs, see Section 7.) 400 Identity matching is performed using the matching rules specified by 401 RFC 3280 [8]. If more than one identity of a given type is present 402 in the certificate (e.g., more than one dNSName name), a match in any 403 one of the set is considered acceptable. To support the use of 404 certificate caches, as described in Section 7, endpoints SHOULD 405 consistently provide the same certificate for each identity they 406 support. 408 6.2. Certificate Presentation 410 In all cases, an endpoint acting as the TLS server, i.e., one taking 411 the 'setup:passive' role, in the terminology of connection-oriented 412 media, MUST present a certificate during TLS initiation, following 413 the rules presented in Section 6.1. If the certificate does not 414 match the original fingerprint, the client endpoint MUST terminate 415 the media connection with a bad_certificate error. 417 If the SDP offer/answer model [5] is being used, the client (the 418 endpoint with the 'setup:active' role) MUST also present a 419 certificate following the rules of Section 6.1. The server MUST 420 request a certificate, and if the client does not provide one, or if 421 the certificate does not match the provided fingerprint, the server 422 endpoint MUST terminate the media connection with a bad_certificate 423 error. 425 Note that when the offer/answer model is being used, it is possible 426 for a media connection to outrace the answer back to the offerer. 427 Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' 428 role, it MUST (as specified in RFC 4145 [2]) begin listening for an 429 incoming connection as soon as it sends its offer. However, it MUST 430 NOT assume the data transmitted over the TLS connection is valid 431 until it has received a matching fingerprint in an SDP answer. If 432 the fingerprint, once it arrives, does not match the client's 433 certificate, the server endpoint MUST terminate the media connection 434 with a bad_certificate error, as stated in the previous paragraph. 436 If offer/answer is not being used (e.g., if the SDP was sent over the 437 Session Announcement Protocol [15]), there is no secure channel 438 available for clients to communicate certificate fingerprints to 439 servers. In this case, servers MAY request client certificates, 440 which SHOULD be signed by a well-known certification authority, or 441 MAY allow clients to connect without a certificate. 443 7. Security Considerations 445 This entire document concerns itself with security. The problem to 446 be solved is addressed in Section 1, and a high-level overview is 447 presented in Section 3. See the SDP specification [1] for security 448 considerations applicable to SDP in general. 450 Offering an TCP/TLS connection in SDP (or agreeing to one in SDP 451 offer/answer mode) does not create an obligation for an endpoint to 452 accept any TLS connection with the given fingerprint. Instead, the 453 endpoint must engage in the standard TLS negotiation procedure to 454 ensure that the TLS stream cypher and MAC algorithm chosen meet the 455 security needs of the higher-level application. (For example, an 456 offered stream cypher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected 457 in almost every application scenario.) 459 Like all SDP messages, SDP messages describing TLS streams are 460 conveyed in an encapsulating application protocol (e.g., SIP, MGCP, 461 etc.). It is the responsibility of the encapsulating protocol to 462 ensure the integrity of the SDP security descriptions. Therefore, 463 the application protocol SHOULD either invoke its own security 464 mechanisms (e.g., secure multiparts) or alternatively utilize a 465 lower-layer security service (e.g., TLS or IPsec). This security 466 service SHOULD provide strong message authentication as well as 467 effective replay protection. 469 However, such integrity protection is not always possible. For these 470 cases, end systems SHOULD maintain a cache of certificates which 471 other parties have previously presented using this mechanism. If 472 possible, users SHOULD be notified when an unsecured certificate 473 associated with a previously unknown end system is presented, and 474 SHOULD be strongly warned if a different unsecured certificate is 475 presented by a party with which they have communicated in the past. 476 In this way, even in the absence of integrity protection for SDP, the 477 security of this document's mechanism is equivalent to that of the 478 Secure Shell (ssh) protocol [21], which is vulnerable to man-in-the- 479 middle attacks when two parties first communicate, but can detect 480 ones that occur subsequently. (Note that a precise definition of the 481 "other party" depends on the application protocol carrying the SDP 482 message.) Users SHOULD NOT, however, in any circumstances be 483 notified about certificates described in SDP descriptions sent over 484 an integrity-protected channel. 486 To aid interoperability and deployment, security protocols which 487 provide only hop-by-hop integrity protection, e.g., the sips protocol 488 [16] (SIP over TLS), are considered sufficiently secure to allow the 489 mode in which any syntactially valid identity is accepted in a 490 certificate. This decision was made because sips is currently the 491 integrity mechanism most likely to be used in deployed networks in 492 the short to medium-term. However, in this mode, SDP integrity is 493 vulnerable to attacks by compromised or malicious middleboxes, e.g. 494 SIP proxy servers. End systems MAY warn users about SDP sessions 495 that are secured in only a hop-by-hop manner, and definitions of 496 media formats running over TCP/TLS MAY specify that only end-to-end 497 integrity mechanisms are to be used. 499 Depending on how SDP messages are transmitted, it is not always 500 possible to determine whether a subjectAltName presented in a remote 501 certificate is expected or not for the remote party. In particular, 502 given call forwarding, third-party call control, or session 503 descriptions generated by endpoints controlled by the Gateway Control 504 Protocol [22], it is not always possible in SIP to determine what 505 entity ought to have generated a remote SDP response. In general, 506 when not using authenticity and integrity protection of SDP 507 descriptions, a certificate transmitted over SIP SHOULD assert the 508 endpoint's SIP Address of Record as a uniformResourceIndicator 509 subjectAltName. When an endpoint receives a certificate over SIP 510 asserting an identity (including an iPAddress or dNSName identity) 511 other than the one to which it placed or received the call, it SHOULD 512 alert the user and ask for confirmation. This applies whether 513 certificates are self-signed, or signed by certification authorities; 514 a certificate for sip:bob@example.com may be legitimately signed by a 515 certification authority, but may still not be acceptable for a call 516 to sip:alice@example.com. (This issue is not one specific to this 517 specification; the same consideration applies for S/MIME-signed SDP 518 carried over SIP.) 520 This document does not define any mechanism for securely transporting 521 RTP and RTCP packets over a connection-oriented channel. There was 522 no consensus in the working group as to whether it would be better to 523 send Secure RTP packets [23] over a connection-oriented transport 524 [24], or whether it would be better to send standard unsecured RTP 525 packets over TLS using the mechanisms described in this document. 526 The group consensus was to wait until a use-case requiring secure 527 connection-oriented RTP was presented. 529 TLS is not always the most appropriate choice for secure connection- 530 oriented media; in some cases, a higher- or lower-level security 531 protocol may be appropriate. 533 8. IANA Considerations 535 This document defines an SDP proto value: 'TCP/TLS'. Its format is 536 defined in Section 4. This proto value should be registered by IANA 537 on under "Session Description Protocol (SDP) Parameters" under 538 "proto". 540 This document defines an SDP session and media level attribute: 541 'fingerprint'. Its format is defined in Section 5. This attribute 542 should be registered by IANA under "Session Description Protocol 543 (SDP) Parameters" under "att-field (both session and media level)". 545 The SDP specification [1] states that specifications defining new 546 proto values, like the 'TCP/TLS' proto value defined in this one, 547 must define the rules by which their media format (fmt) namespace is 548 managed. For the TCP/TLS protocol, new formats SHOULD have an 549 associated MIME registration. Use of an existing MIME subtype for 550 the format is encouraged. If no MIME subtype exists, it is 551 RECOMMENDED that a suitable one be registered through the IETF 552 process [14] by production of, or reference to, a standards-track RFC 553 that defines the transport protocol for the format. 555 This specification creates a new IANA registry named "Hash Function 556 Textual Names". It will not be part of the SDP Parameters. 558 The names of hash functions used for certificate fingerprints are 559 registered by the IANA. Hash functions MUST be defined by standards- 560 track RFCs which update or obsolete RFC 3279 [7]. 562 When registering a new hash function textual name, the following 563 information MUST be provided. 564 o The textual name of the hash function. 565 o The Object Identifier (OID) of the hash function as used in X.509 566 certificates. 567 o A reference to the standards-track RFC, updating or obsoleting RFC 568 3279 [7], defining the use of the hash function in X.509 569 certificates. 571 Figure 3 contains the initial values of this registry. 573 Hash Function Name OID Reference 574 ------------------ --- --------- 575 "md2" 1.2.840.113549.2.2 RFC 3279 576 "md5" 1.2.840.113549.2.5 RFC 3279 577 "sha-1" 1.3.14.3.2.26 RFC 3279 578 "sha-224" 2.16.840.1.101.3.4.2.4 RFC 4055 579 "sha-256" 2.16.840.1.101.3.4.2.1 RFC 4055 580 "sha-384" 2.16.840.1.101.3.4.2.2 RFC 4055 581 "sha-512" 2.16.840.1.101.3.4.2.3 RFC 4055 583 Figure 3: IANA Hash Function Textual Name Registry 585 Appendix A. Changes From Earlier Versions 587 Note to the RFC-Editor: please remove this section prior to 588 publication as an RFC. 590 Appendix A.1. Changes From Draft -05 592 o Specified that hop-by-hop integrity protection counts as valid 593 integrity protection (though specific media formats can define 594 otherwise if they choose.) 595 o Allowed SDP descriptions which are integrity-protected to 596 advertise any subjectAltName in their certificates. 597 o Made session teardown a MUST following a bad certificate 598 fingerprint -- user notification is no longer an option in this 599 scenario. 601 o Established and populated a new IANA registry for Hash Function 602 Textual Names. 603 o Allowed announcement-mode (SAP-like) uses of TLS to request client 604 certificates, even though there is no way for clients to provide 605 certificate fingerprints in this case. 606 o Confidentiality is not required for secure transmission of SDP 607 descriptions, only integrity protection; removed this requirement. 608 o Established that user notification about bad certificate 609 identities only applies to certificates not sent over a protected 610 channel. 611 o Clarified the language on what identity must be asserted, for 612 certificates which must include specific identities. 613 o Clarified the scenarios in which users must be consulted on 614 whether certificates are acceptable. 615 o Clarified that TLS connections MUST NOT act upon data transmitted 616 over a TLS connection before they have verified the fingerprint. 617 o Clarified that the use of the same hash function for fingerprints 618 as for their corresponding certificates ensures that the 619 certificates' security properties are preserved for their 620 fingerprints. 621 o Standardized some terminology to properly reflect standard 622 security usage. Notably, "confidentiality" and "certification 623 authority" replaced "privacy" and "certificate authority" 624 respectively. 625 o Updated the references for Connection-Oriented Media in SDP (now 626 RFC 4145 [2]), ABNF (now RFC 4234 [10]), Media Type Registration 627 Procedures (now RFC 4288 [14]), and the SSH Protocol Architecture 628 (now RFC 4251 [21]). 630 Appendix A.2. Changes From Draft -04 632 o The section discussing the difficulty of knowing what URI 633 identities are appropriate for SDP was expanded, adding a 634 reference to the Gateway Control Protocol. 635 o An un-cited informative reference was removed. 637 Appendix A.3. Changes From Draft -03 639 o The number of options in the protocol were significantly reduced: 640 a number of SHOULD requirements were elevated to MUST. Notably, 641 the use of the 'fingerprint' attribute, strict certificate 642 identity choices, and the use of the same digest algorithm for 643 fingerprints as for certificates were all made mandatory. 644 o Support for the digest algorithms from FIPS 180-2 [11] / RFC 4055 645 [9] ('SHA-224', 'SHA-256', 'SHA-384', and 'SHA-512') was added. 646 o Discussion was added about the difficulty of automatically 647 determining the URI a remote endpoint's certificate should assert, 648 especially in SIP in the presence of call forwarding or third- 649 party call control. 650 o The document was aligned with version -10 of 651 draft-ietf-mmusic-comedia [2]. This consisted mostly of wording 652 and formatting changes. 654 Appendix A.4. Changes From Draft -02 656 None, other than IPR boilerplate and reference updates. Draft -03 657 was a resubmission to refresh the draft's presence in the Internet- 658 Drafts repository. 660 Appendix A.5. Changes From Draft -01 662 o Made the use of SHA-1 fingerprints mandatory in self-signed 663 certificates. 664 o Aligned with version -09 of draft-ietf-mmusic-comedia [2], also 665 drawing some wording changes from that document. 666 o Forbid the use of wildcards for the dNS subjectAltName. 667 o Eliminated requirements on identities provided with self-signed 668 certificates. 669 o Recommended the use of a certificate cache when SDP integrity 670 protection cannot be assured. 671 o Explained that there is no currently supported mechanism for 672 securely sending RTP over connection-oriented media. 673 o Described the procedure for establishing media formats for TCP/ 674 TLS. 676 Appendix A.6. Changes From Draft -00 678 o Significantly expanded introduction and motivation sections. 679 o Significant clarifications to other sections. 680 o Aligned with version -07 of draft-ietf-mmusic-comedia [2]. 681 Protocol identifier changed from TLS to TCP/TLS at that document's 682 recommendation. 684 9. References 686 9.1. Normative References 688 [1] Handley, M., "SDP: Session Description Protocol", 689 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 691 [2] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 692 Session Description Protocol (SDP)", RFC 4145, September 2005. 694 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 695 RFC 2246, January 1999. 697 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 698 Levels", BCP 14, RFC 2119, March 1997. 700 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 701 Session Description Protocol (SDP)", RFC 3264, June 2002. 703 [6] International Telecommunications Union, "Information technology 704 - Open Systems Interconnection - The Directory: Public-key and 705 attribute certificate frameworks", ITU-T Recommendation X.509, 706 ISO Standard 9594-8, March 2000. 708 [7] Bassham, L., Polk, W., and R. Housley, "Algorithms and 709 Identifiers for the Internet X.509 Public Key Infrastructure 710 Certificate and Certificate Revocation List (CRL) Profile", 711 RFC 3279, April 2002. 713 [8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 714 Public Key Infrastructure Certificate and Certificate 715 Revocation List (CRL) Profile", RFC 3280, April 2002. 717 [9] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 718 and Identifiers for RSA Cryptography for use in the Internet 719 X.509 Public Key Infrastructure Certificate and Certificate 720 Revocation List (CRL) Profile", RFC 4055, June 2005. 722 [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax 723 Specifications: ABNF", RFC 4234, October 2005. 725 [11] National Institute of Standards and Technology, "Secure Hash 726 Standard", FIPS PUB 180-2, August 2002, . 729 [12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 730 April 1992. 732 [13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, 733 April 1992. 735 [14] Freed, N. and J. Klensin, "Media Type Specifications and 736 Registration Procedures", BCP 13, RFC 4288, December 2005. 738 9.2. Informative References 740 [15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 741 Protocol", RFC 2974, October 2000. 743 [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 744 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 746 Session Initiation Protocol", RFC 3261, June 2002. 748 [17] Ramsdell, B., "S/MIME Version 3 Message Specification", 749 RFC 2633, June 1999. 751 [18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 752 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 753 Basic and Digest Access Authentication", RFC 2617, June 1999. 755 [19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 756 RFC 3174, September 2001. 758 [20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 760 [21] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol 761 Architecture", RFC 4251, January 2006. 763 [22] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway 764 Control Protocol Version 1", RFC 3525, June 2003. 766 [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 767 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 768 RFC 3711, March 2004. 770 [24] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- 771 Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06 772 (work in progress), September 2005. 774 Author's Address 776 Jonathan Lennox 777 Columbia University Department of Computer Science 778 450 Computer Science 779 1214 Amsterdam Ave., M.C. 0401 780 New York, NY 10027 781 US 783 Email: lennox@cs.columbia.edu 785 Intellectual Property Statement 787 The IETF takes no position regarding the validity or scope of any 788 Intellectual Property Rights or other rights that might be claimed to 789 pertain to the implementation or use of the technology described in 790 this document or the extent to which any license under such rights 791 might or might not be available; nor does it represent that it has 792 made any independent effort to identify any such rights. Information 793 on the procedures with respect to rights in RFC documents can be 794 found in BCP 78 and BCP 79. 796 Copies of IPR disclosures made to the IETF Secretariat and any 797 assurances of licenses to be made available, or the result of an 798 attempt made to obtain a general license or permission for the use of 799 such proprietary rights by implementers or users of this 800 specification can be obtained from the IETF on-line IPR repository at 801 http://www.ietf.org/ipr. 803 The IETF invites any interested party to bring to its attention any 804 copyrights, patents or patent applications, or other proprietary 805 rights that may cover technology that may be required to implement 806 this standard. Please address the information to the IETF at 807 ietf-ipr@ietf.org. 809 Disclaimer of Validity 811 This document and the information contained herein are provided on an 812 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 813 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 814 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 815 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 816 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 817 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 819 Copyright Statement 821 Copyright (C) The Internet Society (2006). This document is subject 822 to the rights, licenses and restrictions contained in BCP 78, and 823 except as set forth therein, the authors retain all their rights. 825 Acknowledgment 827 Funding for the RFC Editor function is currently provided by the 828 Internet Society.