From: The IESG To: IETF-Announce Message-Id: Date: Tue, 14 Feb 2006 17:05:59 -0500 Cc: mmusic chair , Internet Architecture Board , mmusic mailing list , mmusic chair , RFC Editor Subject: [MMUSIC] Protocol Action: 'SDP: Session Description Protocol' to Proposed Standard The IESG has approved the following document: - 'SDP: Session Description Protocol ' as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact person is Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-26.txt Technical Summary This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. In particular, this document provides a new version of SDP that incorporates fixes and extensions that have been designed in the MMUSIC WG since the publication of the original SDP specification, RFC2327. This document is not SDPng, which fundamentally re-examines the problem space of SDP and arrives at a new solution. Rather, this document collects increment fixes to SDP that are critical to its proper operation, and merit inclusion in the core standard. Working Group Summary The MMUSIC working group supported publication of this document. Protocol Quality This document was reviewed by Allison Mankin and Jon Peterson. RFC-Editor Note Please append to the start of Section 9: OLD: 9. SDP Grammar NEW: 9. SDP Grammar This section provides a grammar for SDP. It uses a variant of ABNF [4]. In this variant, contrary to section 2.3 of [4], strings are *not* case-insensitive, and must match exactly the case specified. Security Considerations, last paragraph: OLD: Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. NEW: Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. Moreover, the k= line provides no way to indicate or negotiate cryptographic key algorithms, and as it provides for only a single symmetric key, rather than separate keys for confidentiality and integrity, its utility is severely limited. Use of the k= line is NOT RECOMMENDED, and any usage of the k= line MUST address these shortcomings.