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

["Elwell, John" <[e-mail]>]

Cullen,

I guess what I meant in my message below was the following. If for TIP there
is a need to put the identity in a response to the INVITE request, then that
should not be part of the Connected-Identity draft. However, if the existing
mechanism in the Connected-Identity draft is sufficient to solve TIP, then
that is fine by me.

John 

> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]] 
> Sent: 15 May 2006 04:48
> To: Roland Jesske; Christer Holmberg (JO/LMF)
> Cc: Elwell, John; Jon Peterson; [e-mail]
> 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