Subject: RE: [Sipping] comments on draft-peterson-sipping-retarget

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Mar 2005 16:47:15 -0500

Some more inline below, but note that I really believe we should focus on getting agreement on the problems and resulting requirements before we start whipping out our solutions. While the solution you sketch below has good applicability to some of the problems discussed in sipping-retarget, it might not be applicable to all of them.

> I thought about this a bit more. If alice is calling [email-masked] and 
> receives a 3xx, to demonstrate it is valid it should be signed by either 
> example.com. (Or [email-masked].) There would have to be a new 
> mechanism for an intermediary to do this. 

If there were "response identity" in SIP, its purpose would be to provide such signatures, yes. In my original note, I was thinking of the simpler case where the UAC simply has a direct TLS connection to the intermediary that is sending the 3xx. In other words, there doesn't need to be any response identity mechanism as such for the redirection approach to provide this particular property (though it has other drawbacks that would need to be resolved).

> If there was such a mechanism, then why can't example.com also sign the 
> response of a retargeted request? (E.g. the first response that 
> establishes a dialog.) This would signify that a party responsible for 
> example.com approves of whatever destination this request reached.

If we flushed this out, I suspect the requirements for such a mechanism would end up being equivalent to request history. As you explore the solution space for the problems that are identified in sipping-retarget, request history is certainly one possibility.

> Suppose example.com retargetted to [email-masked].  Assuming that is 
> an AoR, its likely the request will in fact be retargeted twice - first 
> by example.com toward [email-masked], and then by example.org to 
> charlie's phone. In that case, the response could be signed by both 
> example.com and example.org, indicating that they both approve of the 
> path taken. It is quite likely that example.com would require the 
> signature of example.org before it would apply its own signature.

Cullen and I discussed approaches along these lines when we were working on sip-identity-02. There were a number of reasons why we didn't go down this path. One is that it is possible for there to be many retargets (i.e., Max-Forwards) in the path of a request, each of which would require a corresponding history entry and signature. In the request-history work, after many years of thrashing at requirements, it became clear that a signature per retargeting was too onerous a requirement to be fulfilled with a plausible mechanism in terms of message size and complexity. The considerations in 2.3 of sipping-retarget also weighed on our minds a bit back then.

> Note that these signatures aren't quite the same as those of the 
> identity draft. These are just assertions by a responsible party for a 
> domain that it has been involved and the transaction is according to its 
> expectations.

Well, I think it would need to be understood to be a bit more specific than that if we hope it to allow for any useful authorization policies, but it would be something along those lines, yes.

> There could also be a connected-party-id for charlie, signed by 
> example.org. This may be used by alice just to understand to whom she is 
> talking, or to disconnect if she is dissatisfied. It could also be used 
> by example.com in deciding whether to apply its signature to 
> the response. 

Any request-history-like approach would need to have some sort of connected-party-id attribute, and a very strict causal chain demonstrating how the original Request-URI was transformed by successive retargetings into the final connected-party-id, yes.

Jon Peterson
NeuStar, Inc.

> 	Paul
> 
> Paul Kyzivat wrote:
> > 
> > 
> > Peterson, Jon wrote:
> > 
> >>> The introduction also talks about the primary problem 
> being that you 
> >>> can't trust the intermediaries to properly retarget. 
> However, if you 
> >>> can't trust the proxies, you can't trust them to redirect 
> instead of 
> >>> retarget...
> >>
> >>
> >> The differences are enormous, actually, in so far as you 
> can actually 
> >> see -which- intermediary redirects, but you cannot determine which 
> >> intermediary retargets. Because you can see which 
> intermediary it is, 
> >> you can determine whether or not they are actually authorized to 
> >> change the target of the request. I don't think you can be said to 
> >> trust an entity taking an action during routing the call 
> if you don't 
> >> even know who that entity is...
> > 
> > 
> > How is it that the UAC can *see* which intermediary redirected?
> > 
> >     Paul
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2005 19:22:24 -0500

Jon - more inline.

	Paul

> Some more inline below, but note that I really believe we should focus on getting agreement on the problems and resulting requirements before we start whipping out our solutions. While the solution…

Fair enough. (No solution is going to be applicable to all of them.)

> If there were "response identity" in SIP, its purpose would be to provide such signatures, yes. In my original note, I was thinking of the simpler case where the UAC simply has a direct TLS connect…

I didn't realise from reading the draft that was your assumption.

> If we flushed this out, I suspect the requirements for such a mechanism would end up being equivalent to request history. As you explore the solution space for the problems that are identified in s…

Well, that would be enough to convince me of the futility of the 
approach. :-(

As I was writing I realized there was some relationship to H-I, and 
thought about mentioning it, but decided not to.

> Cullen and I discussed approaches along these lines when we were working on sip-identity-02. There were a number of reasons why we didn't go down this path. One is that it is possible for there to…

A difference is that I only had in mind carrying signatures by parties 
on the route chosen, not all the other places considered. Nor is it 
evident to me that the signatures for more than one intermediate node 
ever need be in the response. Each intermediate that retargeted should 
be putting its signature in the response, and could remove any already 
there. (If one was there, it would be of interest in determining if the 
retarget went as planned and so might gate the new signature.)

Actually there could end up being two signatures - one for the 
intermediate node that retargeted away from the original R-URI, and 
another attesting to the validity of the connected-party-id.

So what I would get is:

- example.com says your request to [email-masked] was routed to its 
satisfaction

- example.org certifies that [email-masked] is the connected party.

 From this you are allowed to conclude that example.com acting on bob's 
wishes, wanted you to talk to carol.