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

From: "Elwell, John" <[email-masked]>
Date: Fri, 02 Jan 2004 16:10:57 +0000

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

---

From: David Oran <[email-masked]>
Date: Sat, 03 Jan 2004 14:13:24 -0500

These arguments are good ones.
Even if they weren't good I'd still be in favor of what John proposes, 
because it's eminently reasonable and provides desperately needed 
functionality for which we currently have no alternative machinery.

Dave.

--On Friday, January 2, 2004 4:10 PM +0000 "Elwell, John" 
<[email-masked]> wrote:

> 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.
>
> trusts, it can use the information in the P-Asserted-Identity header
> field, if any, as if it had authenticated the user itself."
> user who answered the call. RFC 3325 is supposed to meet the requirement
> of RFC3324.
>
> 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.
>
> requirements for identity information in a response. However, RFC 3323
> does indeed address privacy in responses. See last paragraph of section 3:
> 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."
> 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.
>

---

From: Tom Taylor <[email-masked]>
Date: Sat, 03 Jan 2004 19:27:28 -0500

I would also support this usage.