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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Apr 2006 21:05:19 -0400

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:[email-masked]), 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:[email-masked]]
Sent: Monday, April 03, 2006 11:46 PM
To: [email-masked]
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 05 Apr 2006 08:01:09 +0100

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:[email-masked]] 
Sent: 05 April 2006 02:05
To: Elwell, John; [email-masked]
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:[email-masked]), 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:[email-masked]]
Sent: Monday, April 03, 2006 11:46 PM
To: [email-masked]
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

---

From: Roland Jesske <[email-masked]>
Date: Wed, 05 Apr 2006 10:02:13 +0200

John,
You wrote: 
>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.

You aready quoted in a Mail 2. January 2006 the use of PAI in responses as written within RFC3324.

Again RFC 3324 says:
5. Parties with Network Asserted Identities

   A Network Asserted Identity identifies the originator of the message
   in which it was received.

   For example,

      a Network Asserted Identity received in an initial INVITE (outside
      the context of any existing dialog) identifies the calling party.

      a Network Asserted Identity received in a 180 Ringing response to
      such an INVITE identifies the party who is ringing.

      a Network Asserted Identity received in a 200 response to such an
      INVITE identifies the party who has answered.

Also in RFC 3325 the use is allowed as follows:

   This document adds the following entry to Table 2 of [1]:

      Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
      ------------         -----   -----   ---  ---  ---  ---  ---  ---
      P-Asserted-Identity           adr     -    o    -    o    o    -

A=
                                           SUB  NOT  REF  INF  UPD  PRA
                                           ---  ---  ---  ---  ---  ---
                                            o    o    o    -    -    -

Is this all wrong now? Is it forbidden to use a P-Asserted-Identity in Responses.

The 3GPP and TISPAN IMS are using the P-Asserted-Identity in Responses and it is not forced to use TLS. 

Is this all now wrong?

Best Regards

Roland
> -----Ursprüngliche Nachricht-----
> Von: "Elwell, John" <[email-masked]>
> Gesendet: 05.04.06 09:07:07
> An:  [email-masked]
> Betreff: 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
>  
>  
> -----------------------------------------------------------------
> Subject: RE: [Sip] Connected-identity and changing the To header field in aresponse
> 
>  
>  
> -----------------------------------------------------------------

_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 05 Apr 2006 13:49:39 +0100

Roland,

Well, I don't want to get into a long discussion about what RFC3325 allows
or disallows. It appears that current practice supports the point I am
trying to make - if you don't need a cryptographically authenticated
response identity, then PAI is sufficient within trusted environments,
provided you have some means of authenticating the responding UA (since the
UA will be outside the trusted environment). If you say that TLS is not
used, what is used instead?

John

> From: Roland Jesske [mailto:[email-masked]] 
> Sent: 05 April 2006 09:02
> To: Elwell, John; Peterson, Jon; [email-masked]
> >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.
> 
>                                            SUB  NOT  REF  INF 
>  UPD  PRA
>                                            ---  ---  ---  --- 
>  ---  ---
> The 3GPP and TISPAN IMS are using the P-Asserted-Identity in 
> Responses and it is not forced to use TLS. 
> 
> Is this all now wrong?
> 
> Best Regards
> 
> Roland
> > 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
> >  
> >  
> > 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 
> > 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:[email-masked]), 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.
> >  
> >  
> > 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 
> >

---

From: Roland Jesske <[email-masked]>
Date: Wed, 05 Apr 2006 15:18:29 +0200

John,
 what we want to have is we an additional connected number (additional connected identity) as described within www.ietf.org/internet-drafts/ draft-jesske-sipping-tispan-requirements-02.txt. (Section 3.3 ).
 It is the same as the conected and generic number within the ISUP (Q.763)
 I thought that your goal was also to have an additional connected identity (like the replaced to/from headers in requests)
 And we don't need an trusted additional connected identity. So it is a real user provided identity.
 
 Best Regards
 
 Roland

> > Gesendet: 05.04.06 14:50:08
> > An:  [email-masked]