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

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

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