Subject: RE: [Sip] Use of P-Asserted-Identity in a response

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sun, 4 Jan 2004 00:57:31 -0000

RFC 3325 section 9.1 and section 9.2 both extend table 2 of RFC 3261 with the new header.

Both entires leave the "where" column empty.

The key to RFC 3261 table 2 states:

      An empty entry in the "where" column indicates that the header
           field may be present in all requests and responses.

I would therefore conclude from the existing specification that both headers may appear in any response to BYE, INV, OPT, SUB, NOT, REF, i.e. those methods that either create a dialog, or are used outside a dialog.

As MESSAGE appeared after RFC 3325 I would also assume that it is allowed in the MESSAGE method, in both requests and all responses.

Note that these tables do not restrict it to 18x and 2xx responses, although for ISDN mapping purposes those responses are the useful ones. It is perfectly valid in 3xx, 4xx and 5xx responses.

Any assertion of identity in responses (and its value) is of course dependent on the specification of privacy by the UAS and on the requirements of the first proxy in the trust domain.

This usage corresponds to what has been specified in 3GPP TS 24.229 and I believe in ITU-T Q.1912.5.

regards

Keith 

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: 02 January 2004 16:11
> To: [email-masked]
> Subject: [Sip] Use of P-Asserted-Identity in a response
> 
> 
> There seem to be some differences of opinion concerning the use of
> P-Asserted-Identity (PAI) in a response. In particular, this 
> is delaying the
> progress of draft-ietf-sipping-qsig2sip, which makes use of 
> PAI in a 200 OK
> to convey the connected party identity received from the QSIG 
> network. The
> same situation is likely to be encountered when interworking 
> with other
> legacy signalling systems.
> 
> It is my opinion that PAI can be used in a 200 OK to assert 
> the identity of
> the connect party. Moreover, it can be inserted by a gateway 
> UAS and, unless
> subject to privacy, can be passed on even to untrusted 
> entities including
> the UAC.
> 
> My evidence for assuming this is as follows:
> 
> 1. RFC 3325: In section 5, 2nd paragraph it states:
> "If the proxy receives a message (request or response) from a 
> node that it
> trusts, it can use the information in the P-Asserted-Identity 
> header field,
> if any, as if it had authenticated the user itself."
> There is nowhere that forbids the use of P-Asserted-ID in a response,
> although there are places in the RFC that mention procedures 
> for a request
> without mentioning a response. In many places it talks about 
> "message",
> which, according to the text above, means request or response.
> 
> 2. RFC 3324 clause 5 clearly states that PAI in INVITE identifies the
> calling user, PAI in a 180 response the ringing user and PAI 
> in 200 OK the
> user who answered the call. RFC 3325 is supposed to meet the 
> requirement of
> RFC3324.
> 
> I have seen a number of arguments against the use of PAI in a 
> response:
> 
> a) It has been suggested that a PAI in a response represents 
> the identity of
> the entity that issued the request. This does not hold water. 
> It clearly
> would be in contradiction to clause 5 of RFC3324 and there is 
> nowhere in
> RFC3324 or RFC3325 that suggests echoing in a response the PAI in the
> request.
> 
> b)It has been suggested that there would need to be 
> corresponding privacy
> requirements for identity information in a response. However, 
> RFC 3323 does
> indeed address privacy in responses. See last paragraph of section 3:
> "It may be desirable to restrict identity information on both 
> requests and
> responses.  Initially, it might seem unusual to suggest that 
> a response has
> privacy concerns - presumably, the originator of the request 
> knows who they
> were attempting to contact, so the identity of the respondent 
> can hardly be
> confidential.  However, some personal information in 
> responses (such as the
> contact address at which the respondent is currently 
> registered) is subject
> to privacy concerns and can be addressed by these mechanisms."
> Also see section 4.2, which states:
> "...this document defines a new SIP header, Privacy, that can 
> be used to
> specify privacy handling for requests and responses."
> 
> c)It has been argued that using PAI in a response may cause 
> an existing
> implementation to do the wrong thing with respect to privacy, e.g., if
> privacy is required by the caller, a proxy may apply this to 
> the connected
> user's identity in the response as well. I don't think this 
> is a likely
> scenario in view of RFC 3323's coverage of privacy in requests and
> responses.
> 
> d)Also it has been suggested that an existing UAS may not take care to
> request privacy in a response, not realising that a proxy 
> might add a PAI.
> Again, since RFC 3323 covers privacy in both requests and 
> responses, any UA
> implementation that supports privacy in requests should also 
> support privacy
> in responses.
> 
> e) It has been pointed out that a proxy cannot reject a 
> response if the PAI
> is wrong. I don't believe this matters - it should be 
> sufficient for the
> proxy just to strip out a PAI that is wrong.
> 
> In conclusion, I see evidence that PAI can be used in a 
> response to assert
> the ID of the connected party and no solid evidence to the contrary.
> 
> John Elwell ([email-masked])
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

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