Skip to main content

Updates to RFC 4572
draft-ietf-mmusic-4572-update-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8122.
Author Christer Holmberg
Last updated 2016-05-04
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8122 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-mmusic-4572-update-00
Network Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Updates: 4572 (if approved)                                  May 4, 2016
Intended status: Standards Track
Expires: November 5, 2016

                          Updates to RFC 4572
                  draft-ietf-mmusic-4572-update-00.txt

Abstract

   This document updates RFC 4572 by clarifying the usage of multiple
   SDP 'fingerprint' attributes with a single TLS connection.  The
   document also updates the preferred cipher suite to be used, and
   removes the requirement to use the same hash function for calculating
   the certificate fingerprint that is used to calculate the certificate
   signature.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 5, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Holmberg                Expires November 5, 2016                [Page 1]
Internet-Draft             Updates to RFC 4572                  May 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Update to RFC 4572  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Update to the sixth paragraph of section 5  . . . . . . .   3
     3.2.  New paragraphs to the end of section 5  . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   RFC 4572 [RFC4572] specifies how to establish Transport Layer
   Security (TLS) connections using the Session Description Protocol
   (SDP) [RFC4566].

   RFC 4572 defines the SDP 'fingerprint' attribute, which is used to
   carry a secure hash value associated with a certificate.  However,
   RFC 4572 is currently unclear on whether multiple 'fingerprint' can
   be associated with a single SDP media description ("m= line")
   [RFC4566], and the associated semantics.  Multiple 'fingerprint'
   attributes are needed when an endpoint wants to provide multiple
   fingerprint, using different hash functions, for a certificate.
   Multiple 'fingerprint' attributes are also needed if an endpoint
   wants to provide fingerprints associated with multiple certificates.
   For example, with RTP-based media, an endpoint might use different
   certificates for RTP and RTCP.

   RFC 4572 also specifies a preferred cipher suite.  However, the
   currently preferred cipher suite is considered outdated, and the
   preference needs to be updated.

   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 document updates RFC 4572 [RFC4572] by clarifying the usage of
   multiple SDP 'fingerprint' attributes with a single TLS connection.
   The document also updates the preferred cipher suite to be used, and

Holmberg                Expires November 5, 2016                [Page 2]
Internet-Draft             Updates to RFC 4572                  May 2016

   removes the requirement to use the same hash function for calculating
   the certificate fingerprint and certificate signature.

2.  Conventions

   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 [RFC2119].

3.  Update to RFC 4572

   This section updates section 5 of RFC 4572.

3.1.  Update to the sixth paragraph of section 5

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].

Holmberg                Expires November 5, 2016                [Page 3]
Internet-Draft             Updates to RFC 4572                  May 2016

3.2.  New paragraphs to the end of section 5

 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 algorithms. It can also
     occur if multiple certificates might be used (e.g. separate
     certificates for RTP and RTCP). In such cases, the same number of
     fingerprints MUST be calculated for each certificate, and for each
     certificate the same set of hash algorithms MUST be used.

     An endpoint MUST be able to match at least one of the received
     fingerprints with the cerficiate(s) to be used. If there is no
     match, the endpoint MUST NOT establish the TLS connection.

     NOTE: The SDP fingerprint attribute does not contain a reference to
     a specific certificate. Endpoints need to compare all fingerprints
     with the cerficiate hash when looking for a match.

4.  Security Considerations

   This document improves security.

5.  IANA Considerations

   This document makes no requests from IANA.

6.  Acknowledgements

   Martin Thompson, Paul Kyzivat and Jonathan Lennox provided valuable
   comments and input on this document.

7.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-holmberg-mmusic-4572-update-01

   o  Adopted WG document (draft-ietf-mmusic-4572-update-00) submitted.

   o  IANA considerations section added.

Holmberg                Expires November 5, 2016                [Page 4]
Internet-Draft             Updates to RFC 4572                  May 2016

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572,
              DOI 10.17487/RFC4572, July 2006,
              <http://www.rfc-editor.org/info/rfc4572>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com

Holmberg                Expires November 5, 2016                [Page 5]