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

["Christer Holmberg \(JO/LMF\)" <[e-mail]>]

Hi Jon, 

The answer is yes.

Regards,

Christer



-----Original Message-----
From: Peterson, Jon [mailto:[e-mail]] 
Sent: 5. huhtikuuta 2006 11:32
To: Christer Holmberg (JO/LMF); Elwell, John; [e-mail]
Subject: RE: [Sip] Connected-identity and changing the To header field
inaresponse


Just for my edification, Additional Connected Number is one of the
Generic Number options that can appear in ANM (or CON)? Or is this
something else?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Christer Holmberg (JO/LMF)
> [mailto:[e-mail]]
> Sent: Wednesday, April 05, 2006 12:34 AM
> 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