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

[Roland Jesske <[e-mail]>]

 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
 
 
 
 
 
> > -----Ursprüngliche Nachricht-----
> > Von: "Elwell, John" <[e-mail]>
> > Gesendet: 05.04.06 14:50:08
> > An:  [e-mail]
> > Betreff: RE: [Sip] Connected-identity and changing the To header field in aresponse
> 
> 
> > 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
> > > 
> 
> 


_______________________________________________________________
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