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

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:jon.peterson@neustar.biz] 
Sent: 05 April 2006 02:05
To: Elwell, John; sip@ietf.org
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:user31@freesipservice.example.com), 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:john.elwell@siemens.com]
Sent: Monday, April 03, 2006 11:46 PM
To: sip@ietf.org
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 