Subject: Protocol Action: SIP: Session Initiation Protocol to Proposed Standard Date: Thu, 07 Mar 2002 15:36:38 -0500 From: The IESG To: IETF-Announce: ;;:@cs.columbia.edu; CC: RFC Editor , Internet Architecture Board , sip@ietf.org, mmusic@ietf.org The IESG has approved publication of the following Internet-Drafts as Proposed Standards: o SIP: Session Initiation Protocol o Reliability of Provisional Responses in SIP o SIP: Locating SIP Servers o SIP-Specific Event Notification o An Offer/Answer Model with SDP These documents are the product of the Session Initiation Protocol Working Group and the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Allison Mankin and Scott Bradner Technical Summary This set of documents obsoletes RFC 2543 in defining the Session Initiation Protocol (SIP). Working Group Summary The SIP Working Group conducted an extensive discussion of all changes developed from RFC 2543 to this document set. The MMUSIC and SIP Working Groups both did extensive review of An Offer-Answer Model with SDP, which was developed as a needed feature for SIP use of Session Description Protocol (SDP) bodies, but which the MMUSIC validated as an SDP semantic. There was largely very strong consensus for the documents, throughout exhaustive review managed by the editors, despite the large amount of material encompassed. Consensus was strong to add an Internet threat analysis for SIP use to the document. However, a vocal group of participants preferred to minimize security features in SIP in favor of design of configurations with trust ("walled garden" style). Eventually consensus was achieved on non-walled garden security, including mandatory-to-implement TLS support in proxies and servers, and elimination of Basic (plaintext passwords) from the long-standing SIP User Agent Client (UAC) HTTP Authentication design. A rougher consensus formed around the requirement for end-to-end security support. The specification defines optional-to-implement S/MIME providing end-to-end integrity and confidentiality for both SIP headers and bodies. After more opportunities for implementation, the IESG expects that the requirement level of the S/MIME support will be upgraded in a future update. Protocol Quality As noted, the documents were reviewed extensively. Allison Mankin reviewed them for the IESG, along with targeted reviewing by a number of the other Area Directors. Eric Rescorla provided detailed security review. The draft on Location of SIP Servers was first considered by the IESG in a stand-alone Last Call some time ago. This version was carefully reviewed for the IESG by a number of Area Directors, and also by Leslie Daigle and Michael Mealling. Notes to RFC Editor: 1. Please add the following text in two places in draft-ietf-sip-rfc2543bis-09.txt Note that currently there does not exist an exact IETF definition of case-insensitivity applied to the whole ISO 10466 character set, thus implementations should avoid dependencies on non-ASCII case-matching rules (or lack thereof) until an IETF definition and specification exists. 1. In Section 7.3.1, following the text below: Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. 2. In Section 19.1.4, as a continuation of the following bullet o Comparison of the userinfo of SIP and SIPS URIs is case- sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other defined otherwise. 2. In draft-ietf-sip-rfc2543bis-09.txt, Section 20.12, third paragraph, please change "coding" to "encoding". 3. In draft-ietf-sip-srv-06.txt, please make the following substitution: OLD: For NAPTR records with SIPS protocol fields, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. NEW: For NAPTR records with SIPS protocol fields, the domain name in the query and the domain name in the replacement field MUST NOT be rooted in a different domains (that is, if the query is for 'example.com', the answer must not return a replacement field with a domain suffix other than 'example.com', such as '_sips._tcp.differentdomain.com'). Similarly, for SIPS queries the domain name in the SRV query and the domain name in the target in the SRV record MUST NOT be rooted in different domains. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. 4. Please replace the Abstract section of draft-ietf-sip-100rel-06.txt with the following: The Session Initiation Protocol (SIP) is a transactional request-response protocol for the initiation, management, and termination of sessions. SIP provides two types of responses to a request. Final responses, which are in the range of 200 to 699, complete the transaction, and are sent reliably by SIP. Provisional responses, also known as informational responses, precede the final response, and provide status or progress information to the requestor. SIP does not provide reliability for these responses end-to-end. However, many applications of SIP have arisen which require these messages to be sent reliably end-to-end. This specification defines an extension to SIP using a new request method, called PRACK, which can be used to guarantee reliability of provisional responses. 5. The IESG agrees with the RFC Editor that the acronyms SIP and SDP should be expanded where they are used in the titles and abstracts.