idnits 2.17.1 draft-thomson-mmusic-fingerprint-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 : ---------------------------------------------------------------------------- No issues found here. 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). (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 (October 22, 2013) is 3810 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. 'FIPS2' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-07 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC M. Thomson 3 Internet-Draft Microsoft 4 Updates: 4572 (if approved) October 22, 2013 5 Intended status: Standards Track 6 Expires: April 25, 2014 8 Use of Fingerprints for Identifying Certificates in the Session 9 Description Protocol (SDP) 10 draft-thomson-mmusic-fingerprint-00 12 Abstract 14 The Session Description Protocol (SDP) fingerprint attribute binds a 15 session description to an X.509 certificate. This document describes 16 how hash agility is achieved without backwards compatibility issues. 17 This document also describes how the fingerprint attribute can be 18 used to identify a set of valid certificates. 20 This document updates RFC4572. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 58 2. Hash Agility . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Multiple Certificates . . . . . . . . . . . . . . . . . . . . 3 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 7.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 RFC 4572 [RFC4572] describes how the fingerprint Session Description 71 Protocol (SDP) [RFC4566] attribute binds a session description to an 72 X.509 certificate [X509]. Unfortunately, the only statement it makes 73 regarding multiple fingerprints is the following: 75 A certificate fingerprint MUST be computed using the same one-way 76 hash function as is used in the certificate's signature algorithm. 78 This has the unfortunate consequence of unnecessarily coupling the 79 security properties of the certificate to the hash function used in 80 signing the certificate. To maximize the chances of a certificate 81 being accepted, the hash algorithm used in certificates tends to lag 82 current best practice, potentially exposing sessions to attacks based 83 on hash collision. 85 The ability to use stronger cryptographic hash algorithms (hash 86 agility) improves the integrity of the binding between the session 87 description and the entity in possession of the private key. Systems 88 that rely on other bindings to the session (or the private keys used 89 to establish it) do not benefit from these changes. 91 This document also describes an optional mechanism that might be used 92 to identify multiple certificates, in cases where the offered 93 certificate might be selected from a small set. This might have 94 operational advantages where the endpoint answering a call is not 95 known ahead of a session description being created. 97 1.1. Conventions and Terminology 99 At times, this document falls back on shorthands for establishing 100 interoperability requirements on implementations: the capitalized 101 words "MUST", "SHOULD" and "MAY". These terms are defined in 102 [RFC2119]. 104 2. Hash Agility 106 The SDP fingerprint attribute is used to indicate the hash of the 107 certificate - a certificate fingerprint - that is offered in the TLS 108 [RFC5246] or DTLS [RFC5764] handshake. The certificate fingerprint 109 so included is used to bind the (D)TLS session to the session 110 description. 112 Multiple fingerprint attributes can be used to identify a certificate 113 using alternative cryptographic hash algorithms. This allows 114 sessions descriptions to use alternative, potentially stronger, hash 115 algorithms without risking interoperability failure. A stronger hash 116 algorithm is more resistant to collision attacks, which can be used 117 to impersonate endpoints. 119 To avoid cases where certificate fingerprints cannot be validated, 120 implementations MUST support SHA-256 [FIPS2]. That is, a fingerprint 121 attribute using SHA-256 MUST be included in any place that includes 122 fingerprint attributes and implementations MUST be able to validate 123 SHA-256 fingerprints. 125 Implementations or specific applications can specify that validation 126 using a different hash algorithm be mandatory in order to achieve a 127 desired level of collision resistance. Implementations MUST NOT 128 consider a session binding to be valid unless a certificate 129 fingerprint using sufficiently strong hash algorithm matches one in 130 the session description. For example, an application might specify 131 that certificates are validated using SHA-384 [FIPS2] in addition to, 132 or instead of, SHA-256. 134 Additional fingerprint attributes MAY be included using alternative 135 hash algorithms. An endpoint that validates a session using 136 fingerprint attributes MUST report failure if any hash that it checks 137 doesn't match. 139 Endpoints can ignore fingerprint attributes that use hash algorithms 140 it doesn't support or wish to validate. 142 3. Multiple Certificates 143 It might be that an application desires the ability to create session 144 descriptions where the security context can be terminated using one 145 of a small set of certificates. 147 An endpoint that validates a session description with multiple values 148 for the same hash algorithm MUST fail the validation unless a 149 fingerprint matches for each hash algorithm validated. Therefore, a 150 session description that includes multiple a=fingerprint values for 151 the same hash algorithm MUST include the same number of a=fingerprint 152 values for every hash algorithm that is included. 154 4. Security Considerations 156 Over time, advances in cryptanalysis and computational power render 157 hash algorithms increasingly prone to collision attacks. A hash 158 collision on a certificate fingerprint would allow for impersonation. 159 This document describes how to use different hash algorithms, 160 independent of those selected for use in certificates. 162 Hash agility does not reduce the need for session description 163 integrity protection or any of the suggested supporting mechanisms 164 described in [RFC4572]. 166 Adding support for hash agility does not affect the properties gained 167 through the use of other mechanisms like the use of other bindings 168 between session and identity. This document only improves the 169 binding between a session and its description in SDP. For example, 170 mechanisms such as the one described in 171 [I-D.ietf-rtcweb-security-arch] require the implementation of 172 equivalent processing rules to benefit from hash agility. Systems 173 relying on the X.509 certificate chain to a specific trust anchor are 174 similarly unaffected. 176 5. IANA Considerations 178 This document has no IANA actions. 180 6. Acknowledgements 182 Kevin Dempsey raised the original question that motivated this draft. 184 7. References 185 7.1. Normative References 187 [FIPS2] , "Secure Hash Standard ", FIPS PUB 180-2, ISO Standard 188 9594-8, August 2002. 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, March 1997. 193 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 194 Description Protocol", RFC 4566, July 2006. 196 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 197 Transport Layer Security (TLS) Protocol in the Session 198 Description Protocol (SDP)", RFC 4572, July 2006. 200 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 201 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 203 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 204 Security (DTLS) Extension to Establish Keys for the Secure 205 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 207 [X509] , "Information technology - Open Systems Interconnection - 208 The Directory: Public-key and attribute certificate 209 frameworks ", ITU-T Recommendation X.509, ISO Standard 210 9594-8, March 2000. 212 7.2. Informative References 214 [I-D.ietf-rtcweb-security-arch] 215 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 216 rtcweb-security-arch-07 (work in progress), July 2013. 218 Author's Address 220 Martin Thomson 221 Microsoft 222 3210 Porter Drive 223 Palo Alto, CA 94304 224 US 226 Email: martin.thomson@skype.net