draft-ietf-mmusic-4572-update-02.txt   draft-ietf-mmusic-4572-update-03.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4572 (if approved) May 18, 2016 Updates: 4572 (if approved) May 21, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: November 19, 2016 Expires: November 22, 2016
Updates to RFC 4572 Updates to RFC 4572
draft-ietf-mmusic-4572-update-02.txt draft-ietf-mmusic-4572-update-03.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 to be used, 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 that is used to calculate the certificate a certificate fingerprint that is used to calculate the certificate
signature. 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 November 19, 2016. This Internet-Draft will expire on November 22, 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative 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].
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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
'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, e.g. for cases where 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. separate certificates for RTP and RTCP), or where it is not (e.g. if separate certificates are used for RTP and RTCP), or where
known which certificate will be used when the fingerprints are it is not known which certificate will be used when the
exchanged. In such cases, one or more fingerprints MUST be fingerprints are exchanged. In such cases, one or more fingerprints
calculated for each possible certificate. MUST be calculated for each possible certificate.
If fingerprints associated with multiple certificates are If fingerprints associated with multiple certificates are
calculated, the same set of fingerprints (using the same hash calculated, the same set of hash functions MUST be used to
functions) MUST be calculated for each certificate associated calculate fingerprints for each certificate associated with the
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 there is no match, the endpoint MUST NOT establish
the TLS connection. In addition, the endpoint MAY also check other the TLS connection. In addition, the endpoint MAY also check
fingerprints (calculated using other hash functions) that it has fingerprints calculated using other hash functions that it has
received for a match. For each hash function checked, one of the received for a match. For each hash function checked, one of the
received fingerprints MUST match the used certificate. received fingerprints 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
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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-02
o Editorial fixes based on comments from Martin Thomson.
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.
o - Editorial fixes o - Editorial fixes
o Changes in handling of multiple fingerprints. o Changes in handling of multiple fingerprints.
o - Sender must send same set of hash functions for each offered o - Sender must send same set of hash functions for each offered
certificate. certificate.
skipping to change at page 6, line 46 skipping to change at page 7, line 5
hash algorithms it considers safe. hash algorithms it considers safe.
o - Additional text added to security considerations section. o - Additional text added to security considerations section.
Changes from draft-holmberg-mmusic-4572-update-01 Changes from draft-holmberg-mmusic-4572-update-01
o Adopted WG document (draft-ietf-mmusic-4572-update-00) submitted. o Adopted WG document (draft-ietf-mmusic-4572-update-00) submitted.
o IANA considerations section added. o IANA considerations section added.
8. References 8. Normative References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006, DOI 10.17487/RFC4572, July 2006,
<http://www.rfc-editor.org/info/rfc4572>. <http://www.rfc-editor.org/info/rfc4572>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
8.2. Informative References
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), January 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-29 (work in progress), April 2016.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 14 change blocks. 
44 lines changed or deleted 23 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/