Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response

From: "Elwell, John" <[email-masked]>
Date: Tue, 06 Jun 2006 20:17:47 +0100

The requirements have indeed been described in the tispan-requirements
draft, but clearly there is still some misunderstanding. Let me try to shed
some light, although my background is enterprise rather than carrier and I
don't pretend to understand all practices of PSTN or NGN.

A PSTN carries two identities in each direction - one that has been
"authenticated" or "screened" by the PSTN and one that has been received
from outside the PSTN and has not been screened. The first type of identity
is used for billing, authorisation etc. within the PSTN, and may also be
delivered to the customer premises equipment. The second type of identity is
used only for delivery to the customer premises equipment. What the customer
premises equipment does with the two types of identities is not really
specified, but I think enterprise networks (e.g., based on QSIG) would
normally use only the first type of identity for passing through the
enterprise network to the end user.

I believe TISPAN has ambitions to support these two types of identity in
NGN, so this leads to the question how to carry the two identities in SIP.

For the INVITE request, the first caller identity is carried in the
P-Asserted-Identity header, the first node in the NGN having authenticated
the source of the request by some means (e.g., through the certificate
supplied during TLS handshake). The second caller identity is carried in the
From header. Obviously the latter is open to falsification unless supported
by an Identity header. With the Identity header, the second caller identity
would be far more useful to the destination customer premises equipment.

For the reverse direction, the first callee identity is carried in the
P-Asserted-Identity header, I believe. There are fewer authentication
options, but I guess TLS-based authentication is still a possibility. So the
question is how to supply the second callee identity.

Option 1. Modify the To header in the INVITE response. There have been
objections to this. Also it would not be authenticated, so it would not be
nearly as useful as the second identity in the request, which can be
authenticated by the Identity header.

Option 2. Use the Reply-To header or some new header in the INVITE response.
The objections concerning modifying the To header go away, but again it
would not be authenticated, so it would not be nearly as useful as the
second identity in the request.

Option 3. Use the From header in conjunction with the Identity header in a
request in the reverse direction, as specified in the Connected-Identity
draft. This seems to solve the problem, except that it may make interworking
with PSTN signalling more difficult since PSTN expects the second identity
in the "answer" message. If a solution to this signalling interworking can
be found, I think option 3 would clearly be the best solution.

John

> -----Original Message-----
> From: Jesske, R [mailto:[email-masked]] 
> Sent: 01 June 2006 09:42
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Elwell, John; 
> [email-masked]; [email-masked]
> Subject: AW: AW: AW: [Sip] Connected-identity and changing 
> the To header f ield ina response
> 
> The two identities are used for PBX services.
> Example
> If a user calls a special hotline for e.G. Computer Services. 
> +496151830.
> This is the main number of a PBX with several extensions. The 
> user will be at least connected to an Service Expert 
> (Extension No: +496151831111).
> So now there is a Public Id (+496151830) that is trusted and 
> the all billing is bind to. (TISPAN uses the P-Asserted-Identity)
> and a private not secure id of the Expert. Advantage is that 
> the Caller has now the ability to see the real connected 
> number where the expert can now called directly.
> 
> This service is widely used within the PSTN/ISDN world and is 
> known as COLP (Connected Line Identification Presentation) 
> Specifies in ITU-T Q.731.5 and in ETSI ETSI EN 300 094 (free 
> downloadable at portal.etsi.org).
> 
> We have described the Requirements in 
> draft-jesske-sipping-tispan-requirements-01 and did some 
> analysis in the past in draft-jesske-sipping-tispan-analysis-00.txt
> 
> Best Regards
> 
> Roland
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Cullen Jennings [mailto:[email-masked]] 
> > Gesendet: Donnerstag, 1. Juni 2006 09:11
> > An: Jesske, Roland
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]
> > Betreff: Re: AW: AW: [Sip] Connected-identity and changing 
> > the To header field ina response
> > 
> > 
> > 
> > What things use these two identities, what do they get used 
> for, and  
> > what security assumptions come around them. That type of 
> information  
> > would help people on this list understand the problem.
> > 
> > On May 31, 2006, at 10:28 PM, Jesske, R wrote:
> > 
> > > Paul,
> > > in the past we lookes also on the Reply-to header. But per  
> > > definition it is the address where the user want to be 
> connected.  
> > > So it is not in each case the real conected identity. But 
> the COLP  
> > > (TIP) service could be used in the same way.
> > > So if it would be possible to use Reply-to header in 
> Responses, if  
> > > people are willing and we as TISPAN can narrow it then 
> only to the  
> > > real connected identity (within our walled garden service  
> > > definition) I would be happy.
> > >
> > > Best Regards
> > >
> > > Roland
> > >
> > >> -----Ursprüngliche Nachricht-----
> > >> Von: Paul Kyzivat [mailto:[email-masked]]
> > >> Gesendet: Mittwoch, 31. Mai 2006 17:04
> > >> An: Jesske, Roland
> > >> Cc: [email-masked]; [email-masked]; [email-masked];
> > >> [email-masked]; [email-masked]
> > >> Betreff: Re: AW: [Sip] Connected-identity and changing the To
> > >> header field ina response
> > >>
> > >>
> > >>
> > >>
> > >> Jesske, R wrote:
> > >>> These are the requirements we already expressed in our
> > >> draft draft-jesske-sipping-tispan-requirements-02:
> > >>>
> > >>>    REQ-TIP-1: In addition to any network asserted identity,
> > >> it must be
> > >>>               possible for the callee to indicate in a SIP
> > >> response an
> > >>>               additional identity where the user is
> > >> reachable for future
> > >>>               direct communications.  Note that the
> > >> requirement refers
> > >>>               to the user, not to the same instance of the
> > >> User Agent.
> > >>>    REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be
> > >> formatted as a
> > >>>               SIP URI [2] or TEL URL [3].  A translation
> > >> between SIP URI
> > >>>               and TEL URL by the network is not requested.
> > >>>    REQ-TIP-3: The identity mentioned in REQ-TIP-1 is
> > >> considered an end
> > >>>               user supplied information that is not 
> > asserted by the
> > >>>               network.
> > >>>
> > >>>
> > >>> As you can see we do not need any authenticated identity in
> > >> the response. For the authenticated identity we are using the
> > >> P-Asserted-Identity. So we have two identities in a Response.
> > >>> For our purposes the user provided identity in a final 200
> > >> OK response is sufficient. So that avoids confusion within
> > >> forking cases.
> > >>
> > >> I haven't been paying close attention to this. What 
> header are you
> > >> planning to use to carry this callee provided identity?
> > >>
> > >> The Reply-To header would seem to be appropriate for this
> > >> purpose, but
> > >> unfortunately, according to table 2 of 3261, it is only
> > >> allowed in INVITE.
> > >>
> > >> 	Paul
> > >>
> > >>> Roland
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> -----Ursprüngliche Nachricht-----
> > >>>> Von: Cullen Jennings [mailto:[email-masked]]
> > >>>> Gesendet: Montag, 22. Mai 2006 17:32
> > >>>> An: Jesske, Roland
> > >>>> Cc: John Elwell; [email-masked]; Roland Jesske; Christer
> > >>>> Holmberg (JO/LMF)
> > >>>> Betreff: Re: [Sip] Connected-identity and changing the To
> > >>>> header field ina response
> > >>>>
> > >>>>
> > >>>>
> > >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote:
> > >>>>
> > >>>>> John,
> > >>>>> it is that we don't can get an connected identity within
> > >> the final
> > >>>>> response of the initial INVITE.
> > >>>>> Your draft proposes a mid dialog request for getting this
> > >>>> information.
> > >>>>> That is not usable for the TIP service.
> > >>>> I think this is part of what I am not understanding. 
> What is the
> > >>>> requirement here?
> > >>>>
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >>
> > 
> 
> _______________________________________________
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Jun 2006 16:27:47 -0400

Elwell, John wrote:
> draft, but clearly there is still some misunderstanding.

Yup.

> Let me try to shed

Thanks for trying.

> enterprise network to the end user.

So what you are saying is that some trouble is taken to carry both of 
these identities, but at least in the case you cite the 2nd isn't ued 
for anything. Do I have that right?

Is there a use case where it *is* used?

If it isn't used, then why should a lot of effort be expended to 
replicate it?

Even if both are delivered to the peer user equipment, what plausible 
actions are there for the equipment to take, when presented with one 
address that is trusted, and one that is advertised as not to be 
trusted? And I think there are variants when one or the other is not 
available.

1) if only one is available, display that one.
    if both are available, display the trusted one.

    a) indicate whether the number is trusted or not
    b) provide no indication of trustedness.

2) if only one is available, display it.
    If both are available, display the untrusted one.

    a) and b) as in 1.

3) if both are available, display both.
    indicate which is the trusted one.

Of those, 3) might be good, if the device is capable of this. But few 
devices have such capability.

It is hard to choose between 1 and 2, because the number of interest may 
vary with context. The example Roland gives only works for 2 (or 3). But 
it will be very hard for a service provider to decide to display an 
untrusted number in preference to a trusted number. So I doubt that 
service would work in practice.

There is some benefit in displaying the untrusted number if the trusted 
number is unavailable (blocked). But I suspect in practice that won't 
happen - the untrusted number will also be blocked.

Another possibility is that both numbers are trusted, but to different 
degrees. For instance, within my own company I trust the numbers 
provided by other callers from the same company (pbx). But those self 
declared numbers might not be trusted by a peer outside the company pbx. 
However I don't think that requires this feature. It can be handled by 
one P-Asserted-ID used inside the company, that is replaced when going 
outside the company.

So, I'm still looking for the use case that makes this feature worth 
bothering with.

> would be far more useful to the destination customer premises equipment.

With the Identity header, there need be no other identity. What is the 
value of having both Identity, and a P-Asserted-ID with a different value?

	Paul

---

From: Feng Cao <[email-masked]>
Date: Tue, 6 Jun 2006 13:34:00 -0700 (PDT)

Please see comments inline:

> authenticated by the Identity header.

Agreed.

> second identity in the request.

It'd better to divide this option into two. One is to use Reply-To,
the other is to use one new header. For "Reply-To", you had pointed out
the drawbacks.

To use one new header, it is straightforward to add authentication
as well as the identity into this new header. Please see our draft
http://www.ietf.org/internet-drafts/draft-cao-sip-response-identity-00.txt
the new header can also indicate if the authentication is needed and
which authentication method is used.

It is worth noting that either of these two approaches is more generic,
because the response directly carries the identity.

> be found, I think option 3 would clearly be the best solution.

It is worth noting that connected-id can only happen in the mid-call
scenarios, which is just a subset compared with the solution in the
above option.

--Feng

---

From: David R Oran <[email-masked]>
Date: Wed, 7 Jun 2006 11:02:07 -0400

> be found, I think option 3 would clearly be the best solution.
Option 4: Use a Body, since this is strictly end-to-end and various  
forms of connected identity may be useful.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Jun 2006 11:41:05 -0400

What I am starting to discern here is a desire for multiple identities 
in the same message that are asserted by different authorities. 
P-Asserted-Identity clearly can't do that. I guess there potentially 
could be multiple instances of sip identity, though the logistics of 
getting that asserted could be difficult. It has been suggested here 
that P-Asserted-ID and sip identity could be used together to provide 
two identities.

In any case, the value proposition is different if the multiple 
identities are all authenticated to the satisfaction of the recipient, 
rather than one of them being untrustworthy.

So, am I right in thinking the goal is for multiple identities, 
authenticated by different parties?

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Jun 2006 06:59:45 -0700

In the reverse direction, why not use UPDATE?

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Jun 2006 07:00:56 -0700

> which authentication method is used.

I don't think this draft would help solve the problem.