draft-ietf-mmusic-4572-update-03.txt   draft-ietf-mmusic-4572-update-04.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4572 (if approved) May 21, 2016 Updates: 4572 (if approved) June 7, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: November 22, 2016 Expires: December 9, 2016
Updates to RFC 4572 Updates to RFC 4572
draft-ietf-mmusic-4572-update-03.txt draft-ietf-mmusic-4572-update-04.txt
Abstract Abstract
This document updates RFC 4572 by clarifying the usage of multiple This document updates RFC 4572 by clarifying the usage of multiple
SDP 'fingerprint' attributes with a single TLS connection. The SDP 'fingerprint' attributes with a single TLS connection. The
document also updates the preferred cipher suite to be used, and document also updates the preferred cipher suite with a stronger
removes the requirement to use the same hash function for calculating cipher suite, and removes the requirement to use the same hash
a certificate fingerprint that is used to calculate the certificate function for calculating a certificate fingerprint that is used to
signature. calculate the certificate signature.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2016. This Internet-Draft will expire on December 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Update to RFC 4572 . . . . . . . . . . . . . . . . . . . . . 3 3. Update to RFC 4572 . . . . . . . . . . . . . . . . . . . . . 3
3.1. Update to the sixth paragraph of section 5 . . . . . . . 3 3.1. Update to the sixth paragraph of section 5 . . . . . . . 3
3.2. New paragraphs to the end of section 5 . . . . . . . . . 4 3.2. New paragraphs to the end of section 5 . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
RFC 4572 [RFC4572] specifies how to establish Transport Layer RFC 4572 [RFC4572] specifies how to establish Transport Layer
Security (TLS) connections using the Session Description Protocol Security (TLS) connections using the Session Description Protocol
(SDP) [RFC4566]. (SDP) [RFC4566].
skipping to change at page 3, line 12 skipping to change at page 3, line 12
calculated using updated hash functions alongside those that are calculated using updated hash functions alongside those that are
needed to interoperate with existing implementations. needed to interoperate with existing implementations.
This document updates RFC 4572 [RFC4572] by clarifying the usage of This document updates RFC 4572 [RFC4572] by clarifying the usage of
multiple SDP 'fingerprint' attributes. It is clarified that multiple multiple SDP 'fingerprint' attributes. It is clarified that multiple
'fingerprint' attributes can be used to carry fingerprints, 'fingerprint' attributes can be used to carry fingerprints,
calculated using different hash functions, associated with a given calculated using different hash functions, associated with a given
certificate, and to carry fingerprints associated with multiple certificate, and to carry fingerprints associated with multiple
certificates. The fingerprint matching procedure, when multiple certificates. The fingerprint matching procedure, when multiple
fingerprints are provided, are also clarified. The document also fingerprints are provided, are also clarified. The document also
updates the preferred cipher suite to be used, and removes the updates the preferred cipher suite with a stronger cipher suite, and
requirement to use the same hash function for calculating a removes the requirement to use the same hash function for calculating
certificate fingerprint and certificate signature. a certificate fingerprint and certificate signature.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Update to RFC 4572 3. Update to RFC 4572
This section updates section 5 of RFC 4572. This section updates section 5 of RFC 4572.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Self-signed certificates (for which legacy certificates are not a Self-signed certificates (for which legacy certificates are not a
consideration) MUST use one of the FIPS 180 algorithms (SHA-1, consideration) MUST use one of the FIPS 180 algorithms (SHA-1,
SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm,
and thus also MUST use it to calculate certificate fingerprints. and thus also MUST use it to calculate certificate fingerprints.
NEW TEXT: NEW TEXT:
Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the
defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11], defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11],
'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and
'MD2' [13], with 'SHA-256' preferred. A new IANA registry of Hash 'MD2' [13], with 'SHA-256' preferred. A new IANA registry of Hash
Function Textual Names, specified in Section 8, allows for addition Function Textual Names, specified in Section 8, allows for addition
of future tokens, but they may only be added if they are included of future tokens, but they may only be added if they are included
in RFCs that update or obsolete RFC 3279 [7]. in RFCs that update or obsolete RFC 3279 [7].
3.2. New paragraphs to the end of section 5 3.2. New paragraphs to the end of section 5
NEW TEXT: NEW TEXT:
Multiple SDP fingerprint attributes can be associated with an m- Multiple SDP fingerprint attributes can be associated with an m-
line. This can occur if multiple fingerprints have been calculated line. This can occur if multiple fingerprints have been calculated
for a certificate using different hash functions. It can also for a certificate using different hash functions. It can also
occur if one or more fingerprints associated with multiple occur if one or more fingerprints associated with multiple
certificates have been calculated. This might be needed if multiple certificates have been calculated. This might be needed if multiple
certificates will be used for media associated with an m- line certificates will be used for media associated with an m- line
(e.g. if separate certificates are used for RTP and RTCP), or where (e.g. if separate certificates are used for RTP and RTCP), or where
it is not known which certificate will be used when the it is not known which certificate will be used when the
fingerprints are exchanged. In such cases, one or more fingerprints fingerprints are exchanged. In such cases, one or more fingerprints
MUST be calculated for each possible certificate. MUST be calculated for each possible certificate. An endpoint
MUST, as a minimum, calculate a fingerprint using the 'SHA-256'
hash function algorithm for each possible certificate, unless the
endpoint knows that the peer supports a stronger algorithm, or
unless the endpoint knows that the peer has not been upgraded to
support the 'SHA-256' algorithm, or unless the endpoint is used for
a service, or within an environment that mandates usage of a
stronger algorithm.
When an endpoint receives one or more fingerprints from its peer,
and is about to calculate its own fingerprints, unless
the endpoint has other ways of knowing what hash functions the peer
supports the endpoint MUST calculate at least one fingerprint using
a hash function that was also used by the peer to calculate a
fingerprint. In addition, the endpoint MAY calculate fingerprints
using hash functions that were not used by the peer.
If fingerprints associated with multiple certificates are If fingerprints associated with multiple certificates are
calculated, the same set of hash functions MUST be used to calculated, the same set of hash functions MUST be used to
calculate fingerprints for each certificate associated with the calculate fingerprints for each certificate associated with the
m- line. m- line.
For each used certificate, an endpoint MUST be able to match at For each used certificate, an endpoint MUST be able to match at
least one fingerprint, calculated using the hash function that the least one fingerprint, calculated using the hash function that the
endpoint supports and considers most secure, with the used endpoint supports and considers most secure, with the used
certificate. If there is no match, the endpoint MUST NOT establish certificate. If the checked fingerprint does not match the used
the TLS connection. In addition, the endpoint MAY also check certificate, the endpoint MUST NOT establish the TLS connection. In
fingerprints calculated using other hash functions that it has addition, the endpoint MAY also check fingerprints calculated using
received for a match. For each hash function checked, one of the other hash functions that it has received for a match. For each
received fingerprints MUST match the used certificate. 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 NOTE: The SDP fingerprint attribute does not contain a reference to
a specific certificate. Endpoints need to compare the fingerprint a specific certificate. Endpoints need to compare the fingerprint
with a certificate hash in order to look for a match. with a certificate hash in order to look for a match.
4. Security Considerations 4. Security Considerations
This document improves security. It updates the preferred hash This document improves security. It updates the preferred hash
function cipher suite from SHA-1 to SHA-256. By clarifying the usage function cipher suite from SHA-1 to SHA-256. By clarifying the usage
and handling of multiple fingerprints, the document also enables hash and handling of multiple fingerprints, the document also enables hash
skipping to change at page 6, line 14 skipping to change at page 6, line 26
6. Acknowledgements 6. Acknowledgements
Martin Thomson, Paul Kyzivat, Jonathan Lennox and Roman Shpount Martin Thomson, Paul Kyzivat, Jonathan Lennox and Roman Shpount
provided valuable comments and input on this document. provided valuable comments and input on this document.
7. Change Log 7. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-4572-update-03
o Mandatory (except in specific situations) to provide a fingerprint
calculated using SHA-256.
o 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.
Changes from draft-ietf-mmusic-4572-update-02 Changes from draft-ietf-mmusic-4572-update-02
o Editorial fixes based on comments from Martin Thomson. o Editorial fixes based on comments from Martin Thomson.
o Non-used references removed. o Non-used references removed.
Changes from draft-ietf-mmusic-4572-update-01 Changes from draft-ietf-mmusic-4572-update-01
o Changes based on comments from Martin Thomson. o Changes based on comments from Martin Thomson.
 End of changes. 11 change blocks. 
20 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/