idnits 2.17.1 draft-ietf-mmusic-4572-update-02.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 : ---------------------------------------------------------------------------- No issues found here. 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 (May 18, 2016) is 2899 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: '7' on line 147 -- Looks like a reference, but probably isn't: '9' on line 141 -- Looks like a reference, but probably isn't: '11' on line 143 -- Looks like a reference, but probably isn't: '19' on line 142 -- Looks like a reference, but probably isn't: '12' on line 143 -- Looks like a reference, but probably isn't: '13' on line 144 == Unused Reference: 'RFC3264' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC5576' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-sdp-mux-attributes' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-sdp-bundle-negotiation' is defined on line 270, 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) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-12 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-29 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 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) May 18, 2016 5 Intended status: Standards Track 6 Expires: November 19, 2016 8 Updates to RFC 4572 9 draft-ietf-mmusic-4572-update-02.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, and 16 removes the requirement to use the same hash function for calculating 17 a certificate fingerprint that is used to calculate the certificate 18 signature. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 19, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Update to RFC 4572 . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Update to the sixth paragraph of section 5 . . . . . . . 3 58 3.2. New paragraphs to the end of section 5 . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 8.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 RFC 4572 [RFC4572] specifies how to establish Transport Layer 71 Security (TLS) connections using the Session Description Protocol 72 (SDP) [RFC4566]. 74 RFC 4572 defines the SDP 'fingerprint' attribute, which is used to 75 carry a secure hash value (fingerprint) associated with a 76 certificate. However, RFC 4572 is currently unclear on whether 77 multiple 'fingerprint' attributes can be associated with a single SDP 78 media description ("m= line") [RFC4566], and the associated 79 semantics. Multiple fingerprints are needed if an endpoints wants to 80 provide fingerprints associated with multiple certificates. For 81 example, with RTP-based media, an endpoint might use different 82 certificates for RTP and RTCP. 84 RFC 4572 also specifies a preferred cipher suite. However, the 85 currently preferred cipher suite is considered outdated, and the 86 preference needs to be updated. 88 RFC 4572 mandates that the hash function used to calculate the 89 fingerprint is the same hash function used to calculate the 90 certificate signature. That requirement might prevent usage of 91 newer, stronger and more collision-safe hash functions for 92 calculating certificate fingerprints. This change also requires that 93 multiple 'fingerprint' attributes can be associated with a single 94 "m=" line, so that implementations are able to provide fingerprints 95 calculated using updated hash functions alongside those that are 96 needed to interoperate with existing implementations. 98 This document updates RFC 4572 [RFC4572] by clarifying the usage of 99 multiple SDP 'fingerprint' attributes. It is clarified that multiple 100 'fingerprint' attributes can be used to carry fingerprints, 101 calculated using different hash functions, associated with a given 102 certificate, and to carry fingerprints associated with multiple 103 certificates. The fingerprint matching procedure, when multiple 104 fingerprints are provided, are also clarified. The document also 105 updates the preferred cipher suite to be used, and removes the 106 requirement to use the same hash function for calculating a 107 certificate fingerprint and certificate signature. 109 2. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Update to RFC 4572 117 This section updates section 5 of RFC 4572. 119 3.1. Update to the sixth paragraph of section 5 120 OLD TEXT: 122 A certificate fingerprint MUST be computed using the same one-way 123 hash function as is used in the certificate's signature algorithm. 124 (This ensures that the security properties required for the 125 certificate also apply for the fingerprint. It also guarantees that 126 the fingerprint will be usable by the other endpoint, so long as the 127 certificate itself is.) Following RFC 3279 [7] as updated by RFC 128 4055 [9], therefore, the defined hash functions are 'SHA-1' [11] 129 [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11] 130 , 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA 131 registry of Hash Function Textual Names, specified in Section 8, 132 allows for addition of future tokens, but they may only be added if 133 they are included in RFCs that update or obsolete RFC 3279 [7]. 134 Self-signed certificates (for which legacy certificates are not a 135 consideration) MUST use one of the FIPS 180 algorithms (SHA-1, 136 SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, 137 and thus also MUST use it to calculate certificate fingerprints. 139 NEW TEXT: 141 Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the 142 defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11], 143 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and 144 'MD2' [13], with 'SHA-256' preferred. A new IANA registry of Hash 145 Function Textual Names, specified in Section 8, allows for addition 146 of future tokens, but they may only be added if they are included 147 in RFCs that update or obsolete RFC 3279 [7]. 149 3.2. New paragraphs to the end of section 5 150 NEW TEXT: 152 Multiple SDP fingerprint attributes can be associated with an m- 153 line. This can occur if multiple fingerprints have been calculated 154 for a certificate, using different hash functions. It can also 155 occur if one or more fingerprints associated with multiple 156 certificates have been calculated, e.g. for cases where multiple 157 certificates will be used for media associated with an m- line 158 (e.g. separate certificates for RTP and RTCP), or where it is not 159 known which certificate will be used when the fingerprints are 160 exchanged. In such cases, one or more fingerprints MUST be 161 calculated for each possible certificate. 163 If fingerprints associated with multiple certificates are 164 calculated, the same set of fingerprints (using the same hash 165 functions) MUST be calculated for each certificate associated 166 with the m- line. 168 For each used certificate, an endpoint MUST be able to match at 169 least one fingerprint, calculated using the hash function that the 170 endpoint supports and considers most secure, with the used 171 certificate. If there is no match, the endpoint MUST NOT establish 172 the TLS connection. In addition, the endpoint MAY also check other 173 fingerprints (calculated using other hash functions) that it has 174 received for a match. For each hash function checked, one of the 175 received fingerprints MUST match the used certificate. 177 NOTE: The SDP fingerprint attribute does not contain a reference to 178 a specific certificate. Endpoints need to compare the fingerprint 179 with a certificate hash in order to look for a match. 181 4. Security Considerations 183 This document improves security. It updates the preferred hash 184 function cipher suite from SHA-1 to SHA-256. By clarifying the usage 185 and handling of multiple fingerprints, the document also enables hash 186 agility, and incremental deployment of newer, and more secure, cipher 187 suites. 189 5. IANA Considerations 191 This document makes no requests from IANA. 193 6. Acknowledgements 195 Martin Thomson, Paul Kyzivat, Jonathan Lennox and Roman Shpount 196 provided valuable comments and input on this document. 198 7. Change Log 200 [RFC EDITOR NOTE: Please remove this section when publishing] 202 Changes from draft-ietf-mmusic-4572-update-01 204 o Changes based on comments from Martin Thomson. 206 o - Editorial fixes 208 o Changes in handling of multiple fingerprints. 210 o - Sender must send same set of hash functions for each offered 211 certificate. 213 o - Receiver must check the hash function it considers most secure 214 for a match. It may check other hash functions. 216 Changes from draft-ietf-mmusic-4572-update-00 218 o Changes in handling of multiple fingerprints. 220 o - Number of fingerprints calculated for each certificate does not 221 have to match. 223 o - Clarified that receiver shall check check fingerprints using 224 hash algorithms it considers safe. 226 o - Additional text added to security considerations section. 228 Changes from draft-holmberg-mmusic-4572-update-01 230 o Adopted WG document (draft-ietf-mmusic-4572-update-00) submitted. 232 o IANA considerations section added. 234 8. References 236 8.1. Normative References 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, 240 DOI 10.17487/RFC2119, March 1997, 241 . 243 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 244 with Session Description Protocol (SDP)", RFC 3264, 245 DOI 10.17487/RFC3264, June 2002, 246 . 248 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 249 Transport Layer Security (TLS) Protocol in the Session 250 Description Protocol (SDP)", RFC 4572, 251 DOI 10.17487/RFC4572, July 2006, 252 . 254 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 255 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 256 July 2006, . 258 8.2. Informative References 260 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 261 Media Attributes in the Session Description Protocol 262 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 263 . 265 [I-D.ietf-mmusic-sdp-mux-attributes] 266 Nandakumar, S., "A Framework for SDP Attributes when 267 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 268 (work in progress), January 2016. 270 [I-D.ietf-mmusic-sdp-bundle-negotiation] 271 Holmberg, C., Alvestrand, H., and C. Jennings, 272 "Negotiating Media Multiplexing Using the Session 273 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 274 negotiation-29 (work in progress), April 2016. 276 Author's Address 278 Christer Holmberg 279 Ericsson 280 Hirsalantie 11 281 Jorvas 02420 282 Finland 284 Email: christer.holmberg@ericsson.com