IETF RFC 5876 PDF

Introduction

The Session Initiation Protocol (SIP) is specified in RFC 3261 [RFC3261]. RFC 3325 [RFC3325] specifies a mechanism for conveying the asserted identity of the originator of a SIP request within a Trust Domain. This is achieved by means of the P-Asserted-Identity header field, which is specified for use in requests using a number of SIP methods, in particular the INVITE method. In addition, the P-Preferred-Identity header field can be used to indicate a preference for which identity should be asserted when there is a choice.

RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a User Agent Client (UAC) in the same Trust Domain as the first proxy. Also, RFC 3325 does not specify the use of the P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE [RFC3311], REGISTER, MESSAGE [RFC3428], and PUBLISH [RFC3903]. This document extends RFC 3325 by allowing inclusion of the P-Asserted-Identity header field by a UAC in the same Trust Domain as the first proxy and allowing use of P-Asserted-Identity and P-Preferred-Identity header fields in any request except ACK and CANCEL. The reason for these two exceptions is that ACK and CANCEL requests cannot be challenged for digest authentication.

RFC 3325 allows the P-Asserted-Identity and P-Preferred-Identity header fields each to contain at most two URIs, where one is a SIP or SIPS URI [RFC3261] and the other is a TEL URI [RFC3966]. This may be unduly restrictive in the future, for example, if there is a need to allow other URI schemes, if there is a need to allow both a SIP and a SIPS URI, or if there is a need to allow more than one URI with the same scheme (e.g., a SIP URI based on a telephone number and a SIP URI that is not based on a telephone number). This document therefore provides forwards compatibility by mandating tolerance to the receipt of unexpected URIs.

This document does not alter the fact that the asserted identity mechanism has limited applicability, i.e., within a Trust Domain. For general applicability, including operation outside a Trust Domain (e.g., over the public Internet) or between different Trust Domains, a different mechanism is needed. RFC 4474 [RFC4474] specifies the Identity header field, in conjunction with the From header field, to provide authenticated identity in such circumstances. RFC 4916 [RFC4916] specifies the use of RFC 4474 in mid-dialog requests, in particular, in requests in the reverse direction to the dialogforming request as a means of providing authenticated connected identity.

RFC 3325 is unclear on the use of P-Asserted-Identity in responses. In contrast to requests, there is no means in SIP to challenge a User Agent Server (UAS) to provide SIP digest authentication in a response. As a result, there is currently no standardised mechanism whereby a proxy can authenticate a UAS. Since authenticating the source of a message is a prerequisite for asserting an identity, this document does not specify the use of the P-Asserted-Identity header field in responses. This may be the subject of a future update to RFC 3325. Also, this document does not specify the use of the P-Preferred-Identity header field in responses, as this would serve no purpose in the absence of the ability for a proxy to insert the P-Asserted-Identity header field.