idnits 2.17.1 draft-holmberg-mmusic-4572-update-00.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 seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4572, updated by this document, for RFC5378 checks: 2004-04-28) -- 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 (February 29, 2016) is 2979 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) -- Looks like a reference, but probably isn't: '6' on line 177 -- Looks like a reference, but probably isn't: '7' on line 240 -- Looks like a reference, but probably isn't: '8' on line 178 -- Looks like a reference, but probably isn't: '9' on line 235 -- Looks like a reference, but probably isn't: '18' on line 203 -- Looks like a reference, but probably isn't: '10' on line 208 -- Looks like a reference, but probably isn't: '1' on line 209 -- Looks like a reference, but probably isn't: '11' on line 236 -- Looks like a reference, but probably isn't: '19' on line 236 -- Looks like a reference, but probably isn't: '12' on line 237 -- Looks like a reference, but probably isn't: '13' on line 237 == Unused Reference: 'RFC3264' is defined on line 274, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 4572 (if approved) February 29, 2016 5 Intended status: Standards Track 6 Expires: September 1, 2016 8 Updates to RFC 4572 9 draft-holmberg-mmusic-4572-update-00.txt 11 Abstract 13 This document updates RFC 4572 by clarifying the usage of multiple 14 SDP 'fingerprint' attributes with a single TLS connection. The 15 document also updates the preferred cipher suite to be used. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 1, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Update to RFC 4572 . . . . . . . . . . . . . . . . . . . . . 2 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 60 1. Introduction 62 RFC 4572 [RFC4572] specifies how to establish Transport Layer 63 Security (TLS) connections using the Session Description Protocol 64 (SDP) [RFC4566]. 66 RFC 4572 defines the SDP 'fingerprint' attribute, which is used to 67 carry a secure hash value associated with a certificate. However, 68 RFC 4572 is currently unclear on whether multiple 'fingerprint' can 69 be associated with a single SDP media description ("m= line") 70 [RFC4566], and the associated semantics. 72 RFC 4572 also specifies a preferred cipher suite. However, the 73 currently preferred cipher suite is considered outdated, and the 74 preference needs to be updated. 76 This document updates RFC 4572 [RFC4572] by clarifying the usage of 77 multiple SDP 'fingerprint' attributes with a single TLS connection. 78 The document also updates the preferred cipher suite to be used. 80 2. Conventions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. Update to RFC 4572 88 This section updates section 5 of RFC 4572. The change clarifies the 89 usage and semantics of multiple SDP "fingerprint" attributes, and 90 updates the preferred cipher suite. 92 Update to section 8.3.2 93 ----------------------- 95 OLD TEXT: 97 Parties to a TLS session indicate their identities by presenting 98 authentication certificates as part of the TLS handshake procedure. 99 Authentication certificates are X.509 [6] certificates, as profiled 100 by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9]. 102 In order to associate media streams with connections and to prevent 103 unauthorized barge-in attacks on the media streams, endpoints MUST 104 provide a certificate fingerprint. If the X.509 certificate 105 presented for the TLS connection matches the fingerprint presented in 106 the SDP, the endpoint can be confident that the author of the SDP is 107 indeed the initiator of the connection. 109 A certificate fingerprint is a secure one-way hash of the DER 110 (distinguished encoding rules) form of the certificate. (Certificate 111 fingerprints are widely supported by tools that manipulate X.509 112 certificates; for instance, the command "openssl x509 -fingerprint" 113 causes the command-line tool of the openssl package to print a 114 certificate fingerprint, and the certificate managers for Mozilla and 115 Internet Explorer display them when viewing the details of a 116 certificate.) 118 A fingerprint is represented in SDP as an attribute (an 'a' line). 119 It consists of the name of the hash function used, followed by the 120 hash value itself. The hash value is represented as a sequence of 121 uppercase hexadecimal bytes, separated by colons. The number of 122 bytes is defined by the hash function. (This is the syntax used by 123 openssl and by the browsers' certificate managers. It is different 124 from the syntax used to represent hash values in, e.g., HTTP digest 125 authentication [18], which uses unseparated lowercase hexadecimal 126 bytes. It was felt that consistency with other applications of 127 fingerprints was more important.) 129 The formal syntax of the fingerprint attribute is given in Augmented 130 Backus-Naur Form [10] in Figure 2. This syntax extends the BNF 131 syntax of SDP [1]. 133 attribute =/ fingerprint-attribute 135 fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint 137 hash-func = "sha-1" / "sha-224" / "sha-256" / 138 "sha-384" / "sha-512" / 139 "md5" / "md2" / token 140 ; Additional hash functions can only come 141 ; from updates to RFC 3279 143 fingerprint = 2UHEX *(":" 2UHEX) 144 ; Each byte in upper-case hex, separated 145 ; by colons. 147 UHEX = DIGIT / %x41-46 ; A-F uppercase 149 Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute 151 A certificate fingerprint MUST be computed using the same one-way 152 hash function as is used in the certificate's signature algorithm. 153 (This ensures that the security properties required for the 154 certificate also apply for the fingerprint. It also guarantees that 155 the fingerprint will be usable by the other endpoint, so long as the 156 certificate itself is.) Following RFC 3279 [7] as updated by RFC 157 4055 [9], therefore, the defined hash functions are 'SHA-1' [11] 158 [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 159 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA 160 registry of Hash Function Textual Names, specified in Section 8, 161 allows for addition of future tokens, but they may only be added if 162 they are included in RFCs that update or obsolete RFC 3279 [7]. 163 Self-signed certificates (for which legacy certificates are not a 164 consideration) MUST use one of the FIPS 180 algorithms (SHA-1, 165 SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, 166 and thus also MUST use it to calculate certificate fingerprints. 168 The fingerprint attribute may be either a session-level or a media- 169 level SDP attribute. If it is a session-level attribute, it applies 170 to all TLS sessions for which no media-level fingerprint attribute is 171 defined. 173 NEW TEXT: 175 Parties to a TLS session indicate their identities by presenting 176 authentication certificates as part of the TLS handshake procedure. 177 Authentication certificates are X.509 [6] certificates, as profiled 178 by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9]. 180 In order to associate media streams with connections and to prevent 181 unauthorized barge-in attacks on the media streams, endpoints MUST 182 provide a certificate fingerprint. If the X.509 certificate 183 presented for the TLS connection matches the fingerprint presented in 184 the SDP, the endpoint can be confident that the author of the SDP is 185 indeed the initiator of the connection. 187 A certificate fingerprint is a secure one-way hash of the DER 188 (distinguished encoding rules) form of the certificate. (Certificate 189 fingerprints are widely supported by tools that manipulate X.509 190 certificates; for instance, the command "openssl x509 -fingerprint" 191 causes the command-line tool of the openssl package to print a 192 certificate fingerprint, and the certificate managers for Mozilla and 193 Internet Explorer display them when viewing the details of a 194 certificate.) 196 A fingerprint is represented in SDP as an attribute (an 'a' line). 197 It consists of the name of the hash function used, followed by the 198 hash value itself. The hash value is represented as a sequence of 199 uppercase hexadecimal bytes, separated by colons. The number of 200 bytes is defined by the hash function. (This is the syntax used by 201 openssl and by the browsers' certificate managers. It is different 202 from the syntax used to represent hash values in, e.g., HTTP digest 203 authentication [18], which uses unseparated lowercase hexadecimal 204 bytes. It was felt that consistency with other applications of 205 fingerprints was more important.) 207 The formal syntax of the fingerprint attribute is given in Augmented 208 Backus-Naur Form [10] in Figure 2. This syntax extends the BNF 209 syntax of SDP [1]. 211 attribute =/ fingerprint-attribute 213 fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint 215 hash-func = "sha-1" / "sha-224" / "sha-256" / 216 "sha-384" / "sha-512" / 217 "md5" / "md2" / token 218 ; Additional hash functions can only come 219 ; from updates to RFC 3279 221 fingerprint = 2UHEX *(":" 2UHEX) 222 ; Each byte in upper-case hex, separated 223 ; by colons. 225 UHEX = DIGIT / %x41-46 ; A-F uppercase 227 Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute 229 A certificate fingerprint MUST be computed using the same one-way 230 hash function as is used in the certificate's signature algorithm. 231 (This ensures that the security properties required for the 232 certificate also apply for the fingerprint. It also guarantees that 233 the fingerprint will be usable by the other endpoint, so long as the 234 certificate itself is.) Following RFC 3279 [7] as updated by RFC 235 4055 [9], therefore, the defined hash functions are 'SHA-1' [11] 236 [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 237 'MD5' [12], and 'MD2' [13], with 'SHA-256' preferred. A new IANA 238 registry of Hash Function Textual Names, specified in Section 8, 239 allows for addition of future tokens, but they may only be added if 240 they are included in RFCs that update or obsolete RFC 3279 [7]. 241 Self-signed certificates (for which legacy certificates are not a 242 consideration) MUST use one of the FIPS 180 algorithms (SHA-1, 243 SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, 244 and thus also MUST use it to calculate certificate fingerprints. 246 The fingerprint attribute may be either a session-level or a media- 247 level SDP attribute. If it is a session-level attribute, it applies 248 to all TLS sessions for which no media-level fingerprint attribute is 249 defined. 251 4. Security Considerations 253 This document improves security. 255 5. Acknowledgements 257 TBD 259 6. Change Log 261 [RFC EDITOR NOTE: Please remove this section when publishing] 263 Changes from draft-holmberg-mmusic-4572-update-xx 265 o Add text 267 7. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 275 with Session Description Protocol (SDP)", RFC 3264, 276 DOI 10.17487/RFC3264, June 2002, 277 . 279 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 280 Transport Layer Security (TLS) Protocol in the Session 281 Description Protocol (SDP)", RFC 4572, 282 DOI 10.17487/RFC4572, July 2006, 283 . 285 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 286 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 287 July 2006, . 289 Author's Address 291 Christer Holmberg 292 Ericsson 293 Hirsalantie 11 294 Jorvas 02420 295 Finland 297 Email: christer.holmberg@ericsson.com