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

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

 
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