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

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

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

> -----Original Message-----
> From: Roland Jesske [mailto:[e-mail]] 
> Sent: 05 April 2006 09:02
> To: Elwell, John; Peterson, Jon; [e-mail]
> Subject: RE: [Sip] Connected-identity and changing the To 
> header field in aresponse
> 
> 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" <[e-mail]>
> > Gesendet: 05.04.06 09:07:07
> > An:  [e-mail]
> > 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
> >  
> >  
> > -----------------------------------------------------------------
> >  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
> 
> 
> _______________________________________________________________
> SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
> kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
> 

_______________________________________________
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