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

[Cullen Jennings <[e-mail]>]

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