Connected Identity in the Session Initiation Protocol (SIP)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, sip mailing list <email@example.com>, sip chair <firstname.lastname@example.org> Subject: Protocol Action: 'Connected Identity in the Session Initiation Protocol (SIP)' to Proposed Standard The IESG has approved the following document: - 'Connected Identity in the Session Initiation Protocol (SIP) ' <draft-ietf-sip-connected-identity-06.txt> as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-identity-06.txt
Technical Summary Because of retargeting of a Session Initiation Protocol (SIP) dialog-forming request (changing the value of the Request-URI), the User Agent Server (UAS) can have a different identity from that in the To header field. This document provides a means for that User Agent (UA) to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an Authentication Service. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). Working Group Summary The document complements work already performed in RFC 4474 for authenticated request identity, and forms an integral part of the chartered work in this area. There is consensus in the working group to publish this document. Protocol Quality The document has been well discussed by a significant number of members of the working group. Note to RFC Editor OLD rendered in OpenSSL format NEW rendered in PEM format ^^^ OLD are captured between tags NEW are captured betwen <allOneLine> tags ^^^^^^^^^ In section 2, last paragraph in the seciton. OLD Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS except in cases where the UA is connected to its proxy by TLS and has already been authenticated. NEW Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS.