Subject: RE: [Sip] comments on connected-identity

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Nov 2006 14:43:25 +0000

Jonathan,

Thanks for your comments. I have attempted to handle most of them in the
post-meeting update of the draft, to appear shortly, but in a few cases I
have had to err on the cautious side because it has been through WGLC. The
comments missing from below are accepted:

> 
> > This document extends the use of the From header field to 
> allow it to
> >  convey "connected identity" information (the identity of the 
> > connected user) in either direction within the context of 
> an existingINVITE-initiated dialog.
> 
> Is there a reason this is limited to INVITE-initiated 
> dialogs? There are
> use cases for SUBSCRIBE (though admittedly more corner cases).
[JRE] Yes, I saw these more as corner cases, although it wouldn't do any
harm to permit its use with SUBSCRIBE-initiated dialogs. As this has been
through WGLC I would like some other opinions on whether to add this
possibility.

> 
> > The provision of the identity of the responder in a response 
> > ("response identity") is outside the scope of this document.
> 
> I think its worth two sentences that explains why; I can just imagine
> implementors asking why they need to send another reuqest 
> when they can
> just modify the To in the response.
[JRE] I propose to add just the following: "Note that even if identity were
to be conveyed somehow in a response, there would in general be difficulty
authenticating the UAS except in cases where the UA is connected to its
proxy by TLS and has already been authenticated. Providing identity in a
separate request allows normal authentication techniques." Is this
sufficient?

> 
> > The Identity header field is inserted by a suitable Authentication
> > Service on the path of the mid-dialog request, typically at a proxy
> > that record routes and is able to authenticate the UAC.
> 
> "typically" isn't strong enough; indeed there is a 
> requirement that the
> proxy providing the authtnication service has to record-route. Suggest
> removing "typically".
[JRE]The point is, it doesn't have to be at a proxy - the UAC itself could
provide this service, particularly if it is a gateway. How about "Unless
provided at the UAC, the Authentication Service must be at a proxy that
record routes and is able to authenticate the UAC"?

> 
> > It is assumed that deployed
> >    proxies will already be able to tolerate a change of 
> URI, since this
> >    has been expected for a considerable time.  To cater for 
> any UAs that
> >    are not able to tolerate a change of URI, a new option tag "from-
> >    change" is introduced for providing a positive 
> indication of support
> >    in the Supported header field.  
> 
> These two sentences are somewhat contradictory. The first 
> says that its 
> been long enough that this is not a problem anymore for 
> proxies. If so, 
> why is it a problem for UAs which require an option tag?
> 
> I'm curious if we have evidence of any deployed UA at this point that 
> would break by a change in URI.
> 
> I'm not objecting to the option tag; I just want to make sure 
> we really 
> have a need for it.
[JRE] This has been in here for some time. I think there was a feeling that
the population of dialog stateful proxies will be much smaller than the
population of UAs, and also that proxies would perhaps be more likely to be
kept up to date. Perhaps that is a wild assumption, but at the time people
seemed to want to be more cautious where UAs were concerned. Also the option
tag has the useful additional property that it advises a proxy to record
route (if not doing so anyway) so that it can deploy an Authentication
Service on mid-dialog requests.

> 
> > fter a full dialog has
> >    been formed (after sending a 2xx provisional response the INVITE
> >    request), if the "from-change" option tag has been received in a
> >    Supported header field and an UPDATE request has not already been
> >    sent on the early dialog, the UA MUST issue an UPDATE 
> request on the
> >    same dialog.  In either case the UPDATE request MUST contain the
> >    callee's (or potential callee's) identity in the URI of the From
> >    header field (or an anonymous identity if anonymity is required).
> 
> I find the "MUST send UPDATE" questionable here. I reserve MUST for 
> things which break if you don't do them. Clearly, nothing 
> breaks here if 
> you don't do this. So I don't think you can do more than SHOULD here.
[JRE] An older version did indeed have "SHOULD", but was changed. This is
possibly the most essential requirement in the whole spec. What is the point
of claiming support for this spec if you don't send an UPDATE request at
least in this situation?

> 
> > A proxy that is able to provide an Authentication Service or a
> >    Verifier for mid-dialog requests MUST record route if Supported:
> >    from-change is indicated in the dialog forming request.
> 
> I think this rule is really just for authentication services. If the 
> verifier is in the UA clearly it doesn't need to record-route.
[JRE] I tend to agree. There could be a verifier at a proxy, and that proxy
is free to record route if it wishes, but I guess we don't need to prescribe
that here. So agreed.

> 
> 
> > 5.2.  Sending revised connected identity during a call
> > 
> >    In this example a call is established between Alice and 
> Bob, where
> >    Bob (not shown) lies behind a B2BUA.  Bob's identity is 
> conveyed by
> >    an UPDATE request.  Then call transfer occurs in the 
> B2BUA, such that
> >    Alice becomes connected to Carol (also not shown), and a 
> re-INVITE
> >    request is issued allowing the session to be 
> renegotiated.  The B2BUA
> >    provides the Authentication Service and thus generates 
> the Identity
> >    header field in the re-INVITE request to provide 
> authentication of
> 
> I don't want to encourage b2bua and this form of transfer, so 
> I'd prefer 
> that this section be recast as using a pstn gateway.
[JRE] This is just an example of what occurs in practice, this being one of
the use cases that connected-identity can solve. I will make it clear that
the B2BUA is performing 3PCC techniques according to RFC 3725 and cite
click-to-dial as an example application.

> 
> > A.2.  Existing methods for providing authenticated identity 
> information
> 
> This appendix doesn't really add much value. I'd suggest removing it.
[JRE] I have no objection - it is largely historic, which is why it was
relegated to an appendix. If anyone objects to its removal, please shout.

> 
> If anything, the main question folks will have is why not just use 
> P-A-ID in the 18x or 2xx. As you may know despite RFC 3325 rules that 
> say this is not allowed, IMS has gone ahead and specified that anyway 
> for connected identity.
[JRE] True, although it shouldn't be used unless there is a means of
authenticating the responder (e.g., based on TLS), so it has limitations in
theory, even if these limitations are ignored in practice. In fact I think
RFC 3325 should be updated to clarify this (i.e. allow PAI in a response in
appropriate circumstances). Likewise PAI can be used in a mid-dialog request
to indicate a change of identity. But PAI is asserted identity and relies on
transitive trust, whereas the objective of connected-identity is to provide
an authenticated identity based on RFC 4474. I will add some text at the end
of the Introducation section to say why response identity is inappropriate.

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