Connected Identity in the Session Initiation Protocol (SIP)
updates
- rfc-3261 — SIP: Session Initiation Protocol
Extracted elements (26)
Connected identity is placed in the From header field rather than a new header because the From header is the standard SIP identifier for the UAC of a request, and reusing it allows existing Authentication Service mechanisms (RFC 4474) to sign the identity without new header processing logic.
Identity is provided in a separate mid-dialog request rather than in a response because authenticating a UAS via response is generally difficult. Sending identity in a request allows normal RFC 4474 authentication techniques (Identity header field signed by an Authentication Service) to be applied.
The "from-change" option tag is introduced to provide a positive indication of support for changed From/To URIs in mid-dialog requests. Because proxies unable to tolerate a URI change are not accounted for, the tag allows the UAC to send a revised From URI only to targets that have indicated support, eliminating the need to use a Require header field.
This document deprecates the RFC 3261 rule requiring mandatory reflection of the original To and From URIs in mid-dialog requests. RFC 3261 Section 12.2.1.1 anticipated this deprecation, noting that only tags (not URIs) are used for dialog identification and that mandatory URI reflection was kept only for backwards compatibility with RFC 2543.
After a UA sends a revised From URI in a mid-dialog request, it MUST continue to be prepared to receive the old remote URI in the To header field of incoming requests at least until a request containing the revised URI in To has been received, accommodating in-flight messages.
Even when the connected identity URI does not differ from the To header field URI of the INVITE request, sending an UPDATE still allows the Authentication Service to assert authentication of that identity and confirms to the peer UA that the connected identity matches the originally dialed URI.
To cater for UAs that cannot tolerate a changed From/To URI in mid-dialog requests, the UAC SHOULD only send a request with a changed From URI to peers that have indicated support for the "from-change" option tag in their Supported header field.
A proxy that receives a mid-dialog request MUST be prepared for the To and/or From header field URIs to differ from those in the dialog-forming request and response. A proxy that can provide an Authentication Service for mid-dialog requests MUST record route if Supported: from-change is indicated in the dialog-forming request received from the UAC.
After a full dialog has been formed and the "from-change" option tag was received in a Supported header field, if an UPDATE was not already sent on the early dialog, the UA MUST issue an UPDATE request on the same dialog. The UPDATE request MUST contain the callee's (or potential callee's) identity in the URI of the From header field, or an anonymous identity if anonymity is required.
After receiving an INVITE request, a compliant UA MUST include the "from-change" option tag in the Supported header field of any dialog-forming response.
After sending a request with a revised From header field URI, the UA MUST send the same URI in the From header field of any future requests on the same dialog unless the identity changes again, and MUST be prepared to receive the revised URI in the To header field of subsequent mid-dialog requests.
An Authentication Service MUST behave in accordance with RFC 4474 when dealing with mid-dialog requests.
If a UA receives a 428, 436, 437, or 438 response to a mid-dialog request, it SHOULD regard the dialog as terminated in the case of a dialog-terminating request and SHOULD take no action for any other request.
If a UA receives a mid-dialog request in which the From header field URI differs from the previous request on that dialog and the UA sends a 2xx response, the UA MUST update the remote URI for the dialog. If any other final response is sent, the UA MUST NOT update the remote URI.
If the "from-change" option tag has been received during an INVITE-initiated dialog and the UA's identity changes compared to the last indicated identity, the UA MUST issue a request on the same dialog containing the new identity in the URI of the From header field. For this purpose the UA MUST use the UPDATE method unless a re-INVITE is already being used at the same time.
When issuing an INVITE request outside an existing dialog, a UA compliant with this specification MUST include the "from-change" option tag in the Supported header field.
When sending a mid-dialog request, a UA MUST populate the To header field URI with the current value of the remote URI for that dialog, which is subject to update per Section 4.4.2 rather than being fixed at the beginning of the dialog per RFC 3261.
Connected identity is conveyed by placing the connected user's Address of Record (AoR) in the From header field URI of a mid-dialog request (UPDATE or re-INVITE), which may differ from the URI originally present in the dialog-forming INVITE request/response.
Potential callee identity can be indicated in an early dialog via an UPDATE request, contingent on RFC 3262 (PRACK) support: the UAS sends UPDATE after receiving and responding to a PRACK following a reliable 1xx response to the INVITE.
The Identity header field (RFC 4474) is inserted by an Authentication Service on the path of the mid-dialog request to cryptographically sign the connected identity in the From header field URI. The Authentication Service is typically a record-routing proxy able to authenticate the UAC.
The UPDATE method (RFC 3311) is the primary vehicle for sending connected identity. The UAS for an INVITE sends an UPDATE after receiving the ACK to convey callee identity; re-INVITE may also be used when simultaneously needed for other purposes such as SDP renegotiation.
This specification registers the SIP option tag "from-change" in the IANA SIP Option Tags registry. The tag indicates that a UA supports changes to URIs in From and To header fields during a dialog.
A From header field URI in a mid-dialog request for which no valid Identity header field (or other means of authentication) has been received cannot be trusted except in very closed environments. However, it is recommended not to reject a mid-dialog request solely because the Identity header field is missing, as this would interfere with ongoing call operation; instead, the absence can influence user-facing information or prompt policy-driven call clearing.
A signed connected identity (From URI accompanied by a valid Identity header field) reflects the result of retargeting but says nothing about the legitimacy of that retargeting or any subsequent identity change. History information (RFC 4244) may provide additional hints about how the connected user was reached.
Anonymity can be required by a connected UA. In that case, the UA populates the From header field URI of mid-dialog requests with an anonymous identity as described in RFC 4474, rather than its actual AoR.
Use of the sips URI scheme can minimize the chances of attacks in which inappropriate connected identity information is injected, either at call establishment or during a call.