Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)
Extracted elements (21)
Target-Dialog differs from In-Reply-To: In-Reply-To references a past call attempt for human UI threading, while Target-Dialog references a currently active dialog for machine-driven authorization. In-Reply-To implies cause-and-effect; Target-Dialog only implies awareness for authorization purposes.
Target-Dialog is preferred over sending dialog-creating requests (like REFER) within an existing dialog because sending inside the dialog causes difficulties in determining dialog lifecycle, usages, and which messages belong to which application usage. Sending outside the dialog is cleaner but requires an authorization mechanism, which Target-Dialog provides.
The UAC is required to use Require: tdialog rather than just including the header, so it can distinguish a 403 caused by the UAS not understanding the extension (retry within the dialog) from a 403 caused by the UAS understanding but choosing to deny (do not retry within the dialog).
The mechanism works across NAT boundaries only if the URI of the target user agent has the GRUU property, meaning any Internet entity can use it to reach the specific UA instance that generated the response to the original dialog-creating request.
The Target-Dialog header field is allowed in requests (R) for INVITE, SUBSCRIBE, and REFER methods; it is not applicable to ACK, BYE, CANCEL, OPTIONS, REGISTER, PUBLISH, PRACK, UPDATE, NOTIFY, INFO, or MESSAGE.
A UAC SHOULD include a Target-Dialog header field in a request sent outside any existing dialog when the UAC believes the request may not be authorized unless it can prove awareness of an existing dialog's identifiers, and the request does not otherwise prove such awareness, and the UAS is known to support Target-Dialog.
If dialog identifiers in Target-Dialog match a dialog not created with a sips URI, the UAS MAY authorize the request, but authorization is optional because any eavesdropper on the original dialog path would have had access to those identifiers.
If the dialog identifiers don't match any existing dialog, or if both 'remote-tag' and 'local-tag' parameters are not present, the Target-Dialog header field MUST be ignored, and authorization MAY be determined by other means.
If the fourth UAC condition (UAS known to support Target-Dialog) is not met, the UAC SHOULD NOT use this specification. Instead, if it is currently within a dialog with the UAS, it SHOULD attempt to send the request within the existing target dialog.
If the Target-Dialog header field is present and the callid, remote-tag, and local-tag match an existing dialog established using a sips URI, the UAS SHOULD authorize the request if it would authorize any entity on the path of the original dialog-creating request.
Proxy behavior is unaffected by this specification; proxies need not process or modify the Target-Dialog header field.
The callid value in the Target-Dialog header field MUST equal the Call-ID of the target dialog. The 'remote-tag' parameter MUST be present and contain the tag viewed as remote by the recipient. The 'local-tag' parameter MUST be present and contain the tag viewed as local by the recipient.
The UAC request SHOULD include a Require header field containing the tdialog option tag, so that the UAC can differentiate between a 403 caused by lack of extension support and a 403 caused by the UAS choosing not to authorize despite proven dialog awareness.
User agents compliant with this specification SHOULD include the tdialog option tag in a Supported header field in all dialog-forming requests and responses, so that potential senders can discover support before sending a Target-Dialog request outside the dialog.
The Target-Dialog header field carries the dialog identifiers (Call-ID, local-tag, remote-tag) of an existing SIP dialog. It is used in dialog-creating requests sent outside of any existing dialog to prove the sender's awareness of that dialog for authorization purposes.
The 'tdialog' SIP option tag identifies support for the Target-Dialog header field extension. When present in a Require header field, it mandates recipient support; when present in a Supported header field, it indicates sender support.
IANA registers the SIP option tag 'tdialog' per the guidelines in Section 27.1 of RFC 3261. The tag identifies the Target-Dialog header field extension; presence in Require mandates support, presence in Supported indicates sender support.
IANA registers the 'Target-Dialog' SIP header field (RFC 4538, no compact form) and two header field parameters for Target-Dialog: 'local-tag' and 'remote-tag', both with no predefined values, per the processes of RFC 3968.
For Target-Dialog-based authorization to be secure, the original SIP dialog MUST have been established using a sips URI (providing TLS on each hop) so that eavesdroppers cannot learn the dialog identifiers. Additionally, dialog identifiers must be cryptographically random per RFC 4086; weak pseudorandom identifiers are guessable and insufficient to prevent attackers from predicting them.
RFC 3261 requires global uniqueness for Call-ID and 32 bits of cryptographic randomness per tag. Given typical dialog durations of up to a day, this randomness is assessed as adequate against guessing attacks, but only when true cryptographic randomness (per RFC 4086) is used, not weak PRNGs.
Target-Dialog header field grammar: 'Target-Dialog = "Target-Dialog" HCOLON callid *(SEMI td-param)' where td-param includes remote-param ('remote-tag' EQUAL token), local-param ('local-tag' EQUAL token), or generic-param. The callid value is taken from RFC 3261.