draft-ietf-mmusic-4572-update-05.txt   draft-ietf-mmusic-4572-update-06.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4572 (if approved) June 10, 2016 Updates: 4572 (if approved) September 23, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: December 12, 2016 Expires: March 27, 2017
Updates to RFC 4572 Updates to RFC 4572
draft-ietf-mmusic-4572-update-05.txt draft-ietf-mmusic-4572-update-06.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 with a stronger document also updates the preferred cipher suite with a stronger
cipher suite, and removes the requirement to use the same hash cipher suite, and removes the requirement to use the same hash
function for calculating a certificate fingerprint that is used to function for calculating a certificate fingerprint that is used to
calculate the certificate signature. calculate the certificate signature.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 12, 2016. This Internet-Draft will expire on March 27, 2017.
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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 8
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].
RFC 4572 defines the SDP 'fingerprint' attribute, which is used to RFC 4572 defines the SDP 'fingerprint' attribute, which is used to
carry a secure hash value (fingerprint) associated with a carry a secure hash value (fingerprint) associated with a
certificate. However, RFC 4572 is currently unclear on whether certificate. However, RFC 4572 is currently unclear on whether
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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 with a stronger cipher suite, and updates the preferred cipher suite with a stronger cipher suite, and
removes the requirement to use the same hash function for calculating removes the requirement to use the same hash function for calculating
a certificate fingerprint and certificate signature. a certificate fingerprint and certificate signature.
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.
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 5, line 4 skipping to change at page 5, line 4
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. An endpoint MUST be calculated for each possible certificate. An endpoint
MUST, as a minimum, calculate a fingerprint using the 'SHA-256' MUST, as a minimum, calculate a fingerprint using both the 'SHA-256'
hash function algorithm for each possible certificate, unless the hash function algorithm and the hash function used to generate the
endpoint knows that the peer supports a stronger algorithm, or signature on the certificate for each possible certificate.
unless the endpoint knows that the peer has not been upgraded to Including the hash from the signature algorithm ensures
support the 'SHA-256' algorithm, or unless the endpoint is used for interoperability with strict implementations of RFC 4572.
a service, or within an environment that mandates usage of a Either of these fingerprints MAY be omitted if the endpoint includes
stronger algorithm. 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 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 the checked fingerprint does not match the used certificate. If the checked fingerprint does not match the used
certificate, the endpoint MUST NOT establish the TLS connection. In certificate, the endpoint MUST NOT establish the TLS connection. In
addition, the endpoint MAY also check fingerprints calculated using addition, the endpoint MAY also check fingerprints calculated using
other hash functions that it has received for a match. For each other hash functions that it has received for a match. For each
hash function checked, one of the received fingerprints calculated hash function checked, one of the received fingerprints calculated
using the hash function MUST match the used certificate. 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
agility, and incremental deployment of newer, and more secure, cipher agility, and incremental deployment of newer, and more secure, cipher
suites. suites.
5. IANA Considerations 5. IANA Considerations
This document makes no requests from IANA. 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.
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-05
o Added a requirement to generate a fingerprint that matches the
signature.
o Added text clarifying that updates do not make existing
implementations non-compliant with RFC 4572.
o IANA Considerations text added.
Changes from draft-ietf-mmusic-4572-update-04 Changes from draft-ietf-mmusic-4572-update-04
o Removed prevously added requirement that endpoint must calcuate at o Removed prevously added requirement that endpoint must calcuate at
least one fingerprint using a hash function that was also used by least one fingerprint using a hash function that was also used by
the peer. the peer.
Changes from draft-ietf-mmusic-4572-update-03 Changes from draft-ietf-mmusic-4572-update-03
o Mandatory (except in specific situations) to provide a fingerprint o Mandatory (except in specific situations) to provide a fingerprint
calculated using SHA-256. calculated using SHA-256.
 End of changes. 13 change blocks. 
40 lines changed or deleted 59 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/