third alternative (was RE: [Sip] RE: Identity after reinvite)

["Peterson, Jon" <[e-mail]>]

I would like to suggest a third alternative:

3) Change nothing about in To/From. Requests in the backwards direction in a
dialog may go through the authentication service of the domain indicated in
the host portion of the From header of the request. If that is not possible,
do not supply request identity for such messages.

While this seem like a non-starter in retargeting cases, requests get
retargeted for a reason. If the dialog-forming request was appropriately
delivered to the domain indicated in the Request-URI (biloxi.example.com),
and that domain chose to forward the request to another domain
(chicago.example.com), it did so because some entity was authorized to add
the chicago URI as a contact for the biloxi URI. In other words, this
approach views retargeting as if the callee's UA were actually registered at
biloxi "through" chicago, and that when the UA receives a dialog-forming
request, it is the To header that determines who should assert identity for
new requests in the backwards direction. In cases where the user contacted
at chicago does not possess credentials to authenticate themselves to
biloxi, I think it would be fair to say that requests in the backwards
direction should not get an Identity header. To go any further, I think,
requires us to solve the response identity problem. This approach is, I
think, forward-compatible with any reasonable solution to the response
identity problem, though.

The primary challenge of this approach is insuring that requests in the
backwards direction will actually go through the authentication service of
biloxi.com, since in many cases they ordinarily might not. If biloxi.com
Record-Routes its auth service in the dialog-forming request, this would
provide the right assurance (and seems plausible from a deployment
perspective); however, if chicago.com also Record-Routes itself, for
example, then the callee will not be able to form a direct TLS connection to
biloxi.com. It is also possible that the callee's UA could force a Route
header to connect to biloxi.com first, but this requires the callee's UA to
be identity-aware, which is undesirable when sip-identity is applied
opportunistically.

But it isn't immediately clear how this is any different from normal cases
of request identity outside the scope of a dialog. There are any number of
possible reasons why the calling UA might not be able to connect directly
via TLS to its auth service (including interposing intermediaries and/or the
inability of the UA to force a Route through their auth service), and the
draft currently just says that we shouldn't provide Identity when we cannot
get the needed relationship between the UA and auth service. I've gotten a
lot of feedback (from Paul, Kumiko and others) that we should try to weaken
the requirement for direct TLS, and I intend to add some text to the next
version about some specific ways in which it is still acceptable to provide
identity even if a direct TLS connection cannot be formed. Certain forms of
weakness there could be beneficial to this approach.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: Tuesday, November 16, 2004 9:30 AM
> To: Jonathan Rosenberg; Jon Peterson
> Cc: Paul H Kyzivat; [e-mail]
> Subject: Re: [Sip] RE: Identity after reinvite
> 
> 
> On 11/16/04 12:05 AM, "Jonathan Rosenberg" <[e-mail]> wrote:
> 
> > The solution, which rfc3261 warns of, is that a UA has to 
> put its actual
> > identity in the From field URI, not what it saw in the To 
> field of the
> > original request. This will break all compatibility with 
> rfc2543, but
> > will work with other rfc3261 compliant endpoints, since the 
> URI is no
> > longer used for dialog identification.
> 
> At this point, I really see two paths forward for the connected party
> problem.
> 
> 1) We do as suggested above and allow everything in the From 
> and To other
> than the tags to be changed in a Re-INVITE or UPDATE.
> 
> 2) We create a new thing that is like invite with replaces 
> but add a new tag
> that is called say "subsumes". So if A and B have a dialog, 
> or early dialog,
> and one of them wants to change a From. The UA sends an 
> INVITE for a new
> dialog, indicates it replaces the old dialog, and indicates 
> that it subsumes
> it. The subsumes flag would mean that any existing media session, qos
> reservations, etc did not change and got moved to the new dialog. 
> 
> 

_______________________________________________
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