One document matched: draft-ietf-mmusic-4572-update-07.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-mmusic-4572-update-07.txt" updates="4572" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="SDP Fingerprint Attribute">
SDP Fingerprint Attribute Usage Clarifications
</title>
<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas</city>
<region></region>
<code>02420</code>
<country>Finland</country>
</postal>
<phone></phone>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date year="2016" />
<area>RAI</area>
<abstract>
<t>
This document updates RFC 4572 by clarifying the usage of multiple SDP 'fingerprint'
attributes with a single SDP media description ("m= line"). The document also updates the preferred cipher
suite with a stronger cipher suite.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
RFC 4572 <xref format="default" pageno="false" target="RFC4572"/> specifies
how to establish Transport Layer Security (TLS) connections using
the Session Description Protocol (SDP) <xref format="default" pageno="false"
target="RFC4566"/>.
</t>
<t>
RFC 4572 defines the SDP 'fingerprint' attribute, which is used to carry a secure hash
value (fingerprint) associated with a certificate. However, RFC 4572 is currently unclear on whether
multiple 'fingerprint' attributes can be associated with a single SDP media description ("m= line")
<xref format="default" pageno="false" target="RFC4566"/>, and the associated semantics.
Multiple fingerprints are needed if an endpoints wants to provide fingerprints associated with
multiple certificates. For example, with RTP-based media, an endpoint might use different
certificates for RTP and RTCP.
</t>
<t>
RFC 4572 also specifies a preferred cipher suite. However, the currently preferred
cipher suite is considered outdated, and the preference needs to be updated.
</t>
<t>
RFC 4572 mandates that the hash function used to calculate the fingerprint is the same
hash function used to calculate the certificate signature. That requirement might
prevent usage of newer, stronger and more collision-safe hash functions for calculating
certificate fingerprints. This change also requires that multiple 'fingerprint' attributes can
be associated with a single "m=" line, so that implementations are able to provide fingerprints
calculated using updated hash functions alongside those that are needed to interoperate
with existing implementations.
</t>
<t>
This document updates RFC 4572 <xref format="default" pageno="false" target="RFC4572"/>
by clarifying the usage of multiple SDP 'fingerprint' attributes. It is clarified that
multiple 'fingerprint' attributes can be used to carry fingerprints, calculated using
different hash functions, associated with a given certificate, and to carry fingerprints
associated with multiple certificates. The fingerprint matching procedure, when multiple
fingerprints are provided, are also clarified. The document also updates the preferred
cipher suite with a stronger cipher suite, and removes the requirement to use the same
hash function for calculating a certificate fingerprint and certificate signature.
</t>
<t>
NOTE: Even though this document updates the procedures in RFC 4572, it does not make
existing implementations non-compliant with RFC 4572. The updated
procedures in this document have been defined in order to be backward compatible with
the procedures in RFC 4572.
</t>
</section>
<section title="Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"></xref>.
</t>
</section>
<section title="Update to RFC 4572">
<t>
This section updates section 5 of RFC 4572.
</t>
<section title="Update to the sixth paragraph of section 5">
<figure>
<artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[
OLD TEXT:
A certificate fingerprint MUST be computed using the same one-way
hash function as is used in the certificate's signature algorithm.
(This ensures that the security properties required for the
certificate also apply for the fingerprint. It also guarantees that
the fingerprint will be usable by the other endpoint, so long as the
certificate itself is.) Following RFC 3279 [7] as updated by RFC
4055 [9], therefore, the defined hash functions are 'SHA-1' [11]
[19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11]
, 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA
registry of Hash Function Textual Names, specified in Section 8,
allows for addition of future tokens, but they may only be added if
they are included in RFCs that update or obsolete RFC 3279 [7].
Self-signed certificates (for which legacy certificates are not a
consideration) MUST use one of the FIPS 180 algorithms (SHA-1,
SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm,
and thus also MUST use it to calculate certificate fingerprints.
NEW TEXT:
Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the
defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11],
'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and
'MD2' [13], with 'SHA-256' preferred. A new IANA registry of Hash
Function Textual Names, specified in Section 8, allows for addition
of future tokens, but they may only be added if they are included
in RFCs that update or obsolete RFC 3279 [7].
]]></artwork>
</figure>
</section>
<section title="New paragraphs to the end of section 5">
<figure>
<artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[
NEW TEXT:
Multiple SDP fingerprint attributes can be associated with an m-
line. This can occur if multiple fingerprints have been calculated
for a certificate using different hash functions. It can also
occur if one or more fingerprints associated with multiple
certificates have been calculated. This might be needed if multiple
certificates will be used for media associated with an m- line
(e.g. if separate certificates are used for RTP and RTCP), or where
it is not known which certificate will be used when the
fingerprints are exchanged. In such cases, one or more fingerprints
MUST be calculated for each possible certificate. An endpoint
MUST, as a minimum, calculate a fingerprint using both the 'SHA-256'
hash function algorithm and the hash function used to generate the
signature on the certificate for each possible certificate.
Including the hash from the signature algorithm ensures
interoperability with strict implementations of RFC 4572.
Either of these fingerprints MAY be omitted if the endpoint includes
a hash with a stronger hash algorithm that it knows that the peer
supports, if it is known that the peer does not support the hash
algorithm, or if local policy mandates use of stronger algorithms.
If fingerprints associated with multiple certificates are
calculated, the same set of hash functions MUST be used to
calculate fingerprints for each certificate associated with the
m- line.
For each used certificate, an endpoint MUST be able to match at
least one fingerprint, calculated using the hash function that the
endpoint supports and considers most secure, with the used
certificate. If the checked fingerprint does not match the used
certificate, the endpoint MUST NOT establish the TLS connection. In
addition, the endpoint MAY also check fingerprints calculated using
other hash functions that it has received for a match. For each
hash function checked, one of the received fingerprints calculated
using the hash function MUST match the used certificate.
NOTE: The SDP fingerprint attribute does not contain a reference to
a specific certificate. Endpoints need to compare the fingerprint
with a certificate hash in order to look for a match.
]]></artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>
This document improves security. It updates the preferred hash function cipher suite
from SHA-1 to SHA-256. By clarifying the usage and handling of multiple fingerprints, the
document also enables hash agility, and incremental deployment of newer, and more secure,
cipher suites.
</t>
</section>
<section anchor="section.iana" title="IANA Considerations">
<t>
IANA is requested to add a reference to this document
for the att-field (both session and media level) registration "fingerprint"
in Session Description Protocol (SDP) Parameters registry.
</t>
</section>
<section title="Acknowledgements">
<t>
Martin Thomson, Paul Kyzivat, Jonathan Lennox and Roman Shpount provided valuable comments and input on this document.
</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
<t>Changes from draft-ietf-mmusic-4572-update-05
<list style="symbols">
<t>Change of document title.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-4572-update-05
<list style="symbols">
<t>Added a requirement to generate a fingerprint that matches the signature.</t>
<t>Added text clarifying that updates do not make existing implementations non-compliant with RFC 4572.</t>
<t>IANA Considerations text added.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-4572-update-04
<list style="symbols">
<t>Removed prevously added requirement that endpoint must calcuate
at least one fingerprint using a hash function that was also used
by the peer.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-4572-update-03
<list style="symbols">
<t>Mandatory (except in specific situations) to provide a fingerprint calculated using SHA-256.</t>
<t>When an endpoint receives fingerprints from its peer, the endpoint must (except in specific
situations) calculate at least one fingerpint using a hash function that was also used by the peer.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-4572-update-02
<list style="symbols">
<t>Editorial fixes based on comments from Martin Thomson.</t>
<t>Non-used references removed.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-4572-update-01
<list style="symbols">
<t>Changes based on comments from Martin Thomson.</t>
<t>- Editorial fixes</t>
<t>Changes in handling of multiple fingerprints.</t>
<t>- Sender must send same set of hash functions for each offered certificate.</t>
<t>- Receiver must check the hash function it considers most secure for a match. It may check other hash functions.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-4572-update-00
<list style="symbols">
<t>Changes in handling of multiple fingerprints.</t>
<t>- Number of fingerprints calculated for each certificate does not have to match.</t>
<t>- Clarified that receiver shall check check fingerprints using hash algorithms it considers safe.</t>
<t>- Additional text added to security considerations section.</t>
</list>
</t>
<t>Changes from draft-holmberg-mmusic-4572-update-01
<list style="symbols">
<t>Adopted WG document (draft-ietf-mmusic-4572-update-00) submitted.</t>
<t>IANA considerations section added.</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.4572"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:30 |