[Sip] Protocol Action: SIP: Session Initiation Protocol to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:


 o SIP: Session Initiation Protocol
	<draft-ietf-sip-rfc2543bis-09.txt>

 o Reliability of Provisional Responses in SIP 
	<draft-ietf-sip-100rel-06.txt> 

 o SIP: Locating SIP Servers
	<draft-ietf-sip-srv-06.txt> 

 o SIP-Specific Event Notification
	<draft-ietf-sip-events-05.txt> 

 o An Offer/Answer Model with SDP
	<draft-ietf-mmusic-sdp-offer-answer-02.txt>


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.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip