RE: [Sip] Connected-identity and changing the To header field ina response

["Drage, Keith (Keith)" <[e-mail]>]

As far as I understand the requirment, the issue is the need to be able to transport two identities for connected, with different assertions.

If P-Asserted-Identity is used for one of them, and this is possible as the TISPAN people are looking at an NGN based on trust domain, then this is the assertion by the edge of the trust domain, i.e. the edge of the public network, as to who the user is.

However in a number of more complex interconnection scenarios, particularly involving enterprise networks, and in imitation of the ISDN, that number may not be sufficient to dial back to the user (it may end up on an attendent console in the enterprise network instead). Therefore the enterprise network needs to be able to assert a number as well as to who it believes the end user is. That is the second number that is being talked about by TISPAN.

In the ISDN the level of confidence in this number will vary from country to country. Some countries, e.g. USA, allow anybody to use it. Others restrict it to specific enterprise networks only.

As to whether the connected-identity draft is the right way to solve this, well in my view that depends on the identity solution that enterprise networks end up using. I have seen some input favouring the use the sip-identity solution in enterprise networks rather than P-Asserted-Identity. Therefore it may well be reasonable that the number delivered by identity mechanisms can represent the second number needed by TISPAN, in addition to the first number provided by the P-Asserted-Identity.

I would note that I remember talking about this need for multiple numbers in Las Vegas (SIP ad-hoc), and was told that P-Asserted-Identity would be kept simple and any more complex requirements would be met by the sip-identity draft. 

regards

Keith

> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: 15 May 2006 04:48
> To: Roland Jesske; Christer Holmberg (JO/LMF)
> Cc: [e-mail]; John Elwell; Jon Peterson
> Subject: Re: [Sip] Connected-identity and changing the To header field
> ina response
> 
> 
> 
> Can someone explain to me why it is that the TIP requirement can not  
> be solved with the connected-identity draft? I do understand it may  
> not be the way some people desire to solve this problem but first of  
> all I am just trying to understand what parts of the requirements we  
> can't meet with this.
> 
> Thanks, Cullen
> 
> 
> On Apr 5, 2006, at 10:48 PM, Elwell, John wrote:
> 
> > Roland,
> >
> > Yes, there was indeed a misunderstanding, but my draft was not  
> > written with
> > TISPAN requirements in mind. It was written to solve the problem of
> > authenticated identity, or rather to extend the present 
> concept of the
> > Identity header to mid-dialog requests and show how that can be  
> > used to
> > solve certain problems.
> >
> > The Terminating Identity Presentation (TIP) requirement 
> from TISPAN  
> > needs to
> > be addressed by some other means. I don't think modifying the To  
> > header is
> > appropriate. Whereas RFC 3261 anticipates deprecating fixed 
> To/From  
> > header
> > field URIs throughout a dialog (i.e., it anticipates that these  
> > will be
> > allowed to change mid-dialog), it says nothing to warn of any  
> > future removal
> > of the requirement that the To header field URI in the response be  
> > the same
> > as that in the request.
> >
> > Therefore it seems that whatever solution you adopt for 
> solving the  
> > TISPAN
> > TIP problem, it would have little in common with the connected- 
> > identity
> > draft.
> >
> > John
> >
> >
> >> -----Original Message-----
> >> From: Roland Jesske [mailto:[e-mail]]
> >> Sent: 05 April 2006 14:33
> >> To: Christer Holmberg (JO/LMF); Elwell, John; Peterson, Jon;
> >> [e-mail]
> >> Subject: RE: [Sip] Connected-identity and changing the To
> >> header field ina response
> >>
> >> John,
> >> there it looks like a misunderstanding. Thought all
> >> requirements from IETF and TISPAN can be solved within your draft.
> >>
> >> As you saw he additional connected identity is a requirement
> >> comming from TISPAN and that was discussed in also in
> >> Vancover. In draft-sasaki-sipping-tispan-adhoc-summary-00.txt
> >> it is mentioned.
> >>
> >> Terminating Identification Presentation(TIP)- The working group
> >>       requests that this requirement be better defined and  
> >> documented.
> >>       It is also suggested that TISPAN consider reading
> >>       draft-rosenberg-sip-identity-privacy-00 as it may solve the
> >>       problem of calling into an 800 number, getting an 
> operator, and
> >>       being able to call back that operator and still protect the
> >>       privacy of the operator.
> >>       In addition, work is progressing on
> >>       draft-elwell-sip-connected-identity-00.
> >>
> >> So using the PAI does not need to go deeper into
> >> draft-rosenberg-sip-identity-privacy-00, but looking into 
> your draft.
> >> And looking within your draft using the dialogUriChange
> >> element we thought we have the solution if this can be done
> >> within the final Response of the initial INVITE.
> >>
> >> Best Regards
> >>
> >> Roland
> >>
> >>
> >>
> >>> -----Ursprüngliche Nachricht-----
> >>> Von: "Elwell, John" <[e-mail]>
> >>> Gesendet: 05.04.06 14:56:20
> >>> An:  [e-mail]
> >>> Betreff: RE: [Sip] Connected-identity and changing the To
> >> header field ina response
> >>
> >>
> >>> Christer,
> >>>
> >>> This "additional connected number" is not a requirement
> >> that I have been
> >>> trying to address. Was this among the requirements that
> >> TISPAN brought into
> >>> the IETF recently?
> >>>
> >>> John
> >>>
> >>>> -----Original Message-----
> >>>> From: Christer Holmberg (JO/LMF)
> >>>> [mailto:[e-mail]]
> >>>> Sent: 05 April 2006 08:34
> >>>> To: Elwell, John; Peterson, Jon; [e-mail]
> >>>> Subject: RE: [Sip] Connected-identity and changing the To
> >>>> header field inaresponse
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> In PSTN terms we are talking about that the TO header shall
> >>>> be mapped to
> >>>> the additional connected number, and that does NOT need to be
> >>>> authorized
> >>>> in the same way as the connected number.
> >>>>
> >>>> And, whether the interworking node sends this value to PSTN
> >>>> is of course
> >>>> based on local policy, based on trust etc.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>> ________________________________
> >>>>
> >>>> From: Elwell, John [mailto:[e-mail]]
> >>>> Sent: 5. huhtikuuta 2006 10:01
> >>>> To: Peterson, Jon; [e-mail]
> >>>> Subject: RE: [Sip] Connected-identity and changing the To
> >> header field
> >>>> inaresponse
> >>>>
> >>>>
> >>>> Jon,
> >>>>
> >>>> Thanks for this excellent summary of the issue, which I fully
> >>>> agree with
> >>>> and which unfortunately seems to need restating at regular
> >>>> intervals. It
> >>>> appears that the chief motivation of those asking for
> >> something in the
> >>>> response is to facilitate interworking with PSTN (by
> >>>> including it in the
> >>>> 200 response so that it can be mapped directly to the
> >> PSTN "connected"
> >>>> message). As you say, such a response is always going to be
> >>>> unauthenticated, and I don't think that meets the
> >> requirements of PSTN
> >>>> interworking. Far better to figure out a way of using an
> >> authenticated
> >>>> connected identity in an UPDATE message for mapping to
> >> PSTN connected
> >>>> identity.
> >>>>
> >>>> Of course, in trusted networks there may be other means for
> >>>> ensuring the
> >>>> authenticity of an identity in a response, just as there is
> >>>> in a request
> >>>> using P-Asserted-Identity. Unfortunately RFC3325 is
> >> unclear on the use
> >>>> of PAI in responses, although in practice I think it is
> >> used and is
> >>>> probably OK if the last hop is secured by TLS so that previous
> >>>> authentication of the UAS can be relied on for making the
> >> assertion. I
> >>>> think if those trusted networks really need a solution
> >> for response
> >>>> identity, PAI would be a better avenue to explore (taking
> >> into account
> >>>> the risks). But not for the Internet. I am becoming more and more
> >>>> convinced that diluting the connected-identity draft with a weak
> >>>> solution for response identity would be the wrong way to go.
> >>>>
> >>>> John
> >>>>
> >>>>
> >>>> ________________________________
> >>>>
> >>>> 	From: Peterson, Jon [mailto:[e-mail]]
> >>>> 	Sent: 05 April 2006 02:05
> >>>> 	To: Elwell, John; [e-mail]
> >>>> 	Subject: RE: [Sip] Connected-identity and changing the To header
> >>>> field in aresponse
> >>>> 	
> >>>> 	
> >>>> 	Yes, I was asked for clarification on this point after the
> >>>> meeting, and I'll be providing it here. As you surmised, it
> >>>> is not that
> >>>> RFC3261 relies on the addr-spec of the To or From header 
> field for
> >>>> transaction identification, or something. In fact, I would have
> >>>> essentially the same concerns about any proposal that provided an
> >>>> additional header (say, a 'Connected-Party' header) in
> >> responses to
> >>>> dialog-forming requests which was understood to clobber
> >> the To header
> >>>> field and identify the AoR of the party who was reached after
> >>>> retargeting of the request took place.
> >>>> 	
> >>>> 	Starting with the goals of this approach: what sort of UAC
> >>>> decisions or behavior do we hope to enable through
> >> sending a response
> >>>> with a modified To header field? As far as I can
> >> understand, we either
> >>>> want to render this AoR to the user of a UAC (so the user
> >> can react in
> >>>> one way or another), or input the AoR to some sort of
> >> policy manager
> >>>> (e.g. blacklist/whitelist) that might make a decision
> >> about whether or
> >>>> not the session should continue -prior- to session
> >>>> establishment. If we
> >>>> don't care about this occurring prior to session 
> establishment, of
> >>>> course, then we could go with the connected-identity
> >> draft as it is
> >>>> written today.
> >>>> 	
> >>>> 	A little refresher on my sipping-retarget draft: The core
> >>>> problem with any scheme for connected party is figuring
> >> out how you'd
> >>>> decide whether or not a particular respondent is authorized.
> >>>> This is the
> >>>> argument of 2.2.1 of sipping-retarget, the "unanticipated
> >> respondent"
> >>>> problem. When we think about what sorts of policy decisions
> >>>> we expect a
> >>>> human or automata to make when receiving a response with identity
> >>>> information, we have to acknowledge that the UAC has no
> >> way of knowing
> >>>> which respondents are or are not authorized to respond to the
> >>>> request in
> >>>> question. Since the UAC has no insight into any
> >> retargeting that has
> >>>> taken place, the UAC has to assume that virtually any
> >> response is a
> >>>> potentially legitimate one. As such, there is little room for any
> >>>> meaningful policy decision when receiving a response.
> >> This problem is
> >>>> further compounded by the fact that the UAS may have
> >> several possible
> >>>> legitimate AoRs it could claim (I have a UA that
> >> registers its contact
> >>>> address under 3 separate SIP services simultaneously), and of
> >>>> course the
> >>>> fact that AoRs may be pretty uninformative (e.g.
> >>>> sip:[e-mail]), all of which complicate
> >>>> authorization decisions. Solving this problem is on the same
> >>>> footing as
> >>>> solving the request-history problem set.
> >>>> 	
> >>>> 	With that background, the problems with providing this connected
> >>>> party information in responses (via the To header or what
> >>>> have you) are
> >>>> roughly as follows:
> >>>> 	
> >>>> 	a) The "unanticipated respondent" problem is especially an issue
> >>>> for response identity because not all responses are
> >> success responses.
> >>>> If you end up connecting to a party (receiving a 200), you can
> >>>> potentially rely on human factors to help you identify 
> who you are
> >>>> talking to (after all, Carol can always answer Bob's phone
> >>>> regardless of
> >>>> who SIP thinks you connected to) and/or use the connected party
> >>>> information to change how you might address the party on the
> >>>> other side.
> >>>> With a 403 response, you are in a very different
> >> predicament - how is
> >>>> UAC or user behavior supposed to change based on the 
> connected URI
> >>>> attributed to a 403, given the unanticipated respondent
> >> problem? For
> >>>> provisional responses, the issues become even worse - we
> >> then get into
> >>>> the wonders of forking, multiple provisional responses
> >> from multiple
> >>>> sources asserting different To header fields - in short,
> >> nothing which
> >>>> makes it any easier to render a "responding" AoR to a user,
> >>>> for example.
> >>>> Response identity, in so far as it deals with non-final,
> >>>> non-successful
> >>>> responses, opens up the "unconnected party" problem set. I
> >>>> think this is
> >>>> just the wrong framing of the problem. You want to know who you
> >>>> connected to, not who you didn't connect to.
> >>>> 	
> >>>> 	b) Getting a signature over the To header field in responses
> >>>> would be difficult. In full awareness of Mr. Elwell's
> >> note below that
> >>>> certain parties are interested in "(unauthenticated) 
> identity in a
> >>>> response", if this information is going to be put to any
> >>>> purpose, cause
> >>>> any change in human or UAC behavior, I have a hard time 
> seeing how
> >>>> anyone could defend it being unsecured. If you want a human or an
> >>>> automata to make a policy decision based on the AoR in
> >> the To header
> >>>> field of the response, some sort of response identity
> >>>> signature would be
> >>>> necessary to prevent obvious impersonation attacks
> >> designed to thwart
> >>>> authorization decisions. With all due respect to the authors of
> >>>> draft-cao-sip-response-identity/auth, I'm not sure this 
> problem is
> >>>> readily solved. Making sure that an appropriate
> >> authentication service
> >>>> is in the path of responses is problematic, since responses must
> >>>> traverse exactly the same path as requests. I played around
> >>>> with this a
> >>>> lot in the early phases of SIP identity, and at the end
> >> of the day, I
> >>>> had to conclude that the only way to make this work was
> >> to eliminate
> >>>> retargeting. Since providing connected-identity in
> >> responses assumes
> >>>> that retargeting has taken place, it wouldn't exactly be
> >>>> getting off on
> >>>> the right foot. Constraining inbound request routing to a
> >> domain such
> >>>> that responses will traverse an authentication service, or
> >>>> forcing a UAS
> >>>> to participate in the Identity scheme, is likely to
> >> require mandatory
> >>>> option-tags or comparable mechanisms that will limit the
> >> applicability
> >>>> of response identity and more or less eliminate its
> >> opportunistic use.
> >>>> 	
> >>>> 	c) The inability to reject a response. Take the easiest case -
> >>>> let's say that the UAC receives a final success response,
> >> say a 200
> >>>> response, with a modified To header field from a party that is
> >>>> blacklisted by UAC policy. What exactly is the UAC supposed
> >>>> to do? Send
> >>>> a 403? One cannot reject responses. Maybe a CANCEL? As
> >> section 9.1 of
> >>>> RFC3261 says, CANCEL "has no effect on requests that have already
> >>>> generated a final response." Drop the request on the floor?
> >>>> You'll just
> >>>> receive retransmissions. All you can do is ACK it, since the
> >>>> dialog has
> >>>> already been formed, and then send a BYE. In other words,
> >> a session
> >>>> -will- be established, there simply isn't an opportunity
> >> for policy to
> >>>> be put into effect prior to session establishment. Also,
> >> consider the
> >>>> need for the new responses defined in the sip-identity
> >> draft, like say
> >>>> the 438 response - if the UAC receives a 200 response with a
> >>>> potentially
> >>>> repairable error in the Identity header, how can it
> >> express that error
> >>>> to the UAS, since it can't send responses to a response?
> >>>> 	
> >>>> 	Given the above, why does the UAC need to know who has been
> >>>> reached in the response, rather than in a request after
> >> the dialog has
> >>>> been formed? As (c) illustrates, in the 200 response case a
> >>>> session will
> >>>> be established anyway, so sharing the identity of the
> >> connected party
> >>>> after session establishment doesn't actually miss some
> >> opportunity for
> >>>> applying policy - moreover, an UPDATE or similar request
> >> that provides
> >>>> the connected-identity information could be rejected by the
> >>>> session-originating UA in a manner that is helpful to the
> >>>> session-terminating UA (e.g., a 438 response could be
> >> sent). If we go
> >>>> with the mechanism in the connected-identity draft, problem (b)
> >>>> disappears, since request routing is far more malleable
> >> than response
> >>>> routing. Additionally, the connected-identity draft
> >> wisely does not
> >>>> attempt to solve "unconnected party" problems from (a),
> >> which are the
> >>>> least tractable of the unanticipated respondent problems. Rather,
> >>>> connected-identity provides an indication more along the
> >>>> lines of, "your
> >>>> dialog was established, however that might have happened,
> >> and this is
> >>>> who is on the other side".
> >>>> 	
> >>>> 	Furthermore, any solution that tried to put the
> >>>> connected-identity information into responses would be
> >> providing an
> >>>> imprimatur of legitimacy to those responses - presuming 
> they had a
> >>>> signature, UACs would validate it, and provided it
> >> checked out, they
> >>>> would be tempted say "this is a legitimate response."
> >> Nothing could be
> >>>> further from the truth, as sipping-retarget illustrates.
> >> Legitimacy of
> >>>> responses cannot be determined by UACs in the absence of
> >>>> something like
> >>>> request-history.
> >>>> 	
> >>>> 	Finally, I like having one Identity header, and for the meaning
> >>>> of that Identity header to *always* be that it is a
> >> signature over the
> >>>> From header field issued by the domain identified by the host
> >>>> portion of
> >>>> the addr-spec of the From header field. The current
> >> connected-identity
> >>>> header draft provides that property.
> >>>> 	
> >>>> 	Jon Peterson
> >>>> 	NeuStar, Inc.
> >>>>
> >>>> 		-----Original Message-----
> >>>> 		From: Elwell, John [mailto:[e-mail]]
> >>>> 		Sent: Monday, April 03, 2006 11:46 PM
> >>>> 		To: [e-mail]
> >>>> 		Subject: [Sip] Connected-identity and changing the To
> >>>> header field in aresponse
> >>>> 		
> >>>> 		
> >>>>
> >>>> 		During discussion of draft-elwell-connected-identity in
> >>>> Dallas, somebody put forward the opinion that it would be
> >> dangerous to
> >>>> change the To header field URI in a response (i.e., make
> >> it different
> >>>> from the From header field URI in the request). My
> >> assumption at the
> >>>> time was that it would undermine the transaction concept
> >> in SIP, yet
> >>>> reading what RFC3261 has to say about transactions, the value
> >>>> of the To
> >>>> header field URI in a response does not appear to be involved in
> >>>> coupling a response to a request. Therefore I assume the
> >> person who
> >>>> indicated the danger (which was not challenged at the
> >>>> meeting) has other
> >>>> reasons in mind. I would greatly appreciate opinions on
> >> the wisdom or
> >>>> otherwise of allowing the To header field URI to change.
> >> It seems that
> >>>> from discussion of connected-identity there is a desire from
> >>>> some parts
> >>>> of the community to include an (unauthenticated) identity in
> >>>> a response.
> >>>>
> >>>> 		John
> >>>>
> >>>
> >>> _______________________________________________
> >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the core SIP Protocol
> >>> Use [e-mail] for questions on current sip
> >>> Use [e-mail] for new developments on the 
> application of sip
> >>
> >>
> >> _______________________________________________________________
> >> SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
> >> kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
> >>
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [e-mail] for questions on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip