Subject: [Sip] comments on draft-elwell-sip-connected-identity-00

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 20:05:52 -0500

Thanks for putting this together. As I have posted previously, I support 
work in this area.

On the mechanism itself, I prefer the approach that the connected-party 
identity is conveyed in the To header field in the response of the 
dialog forming request. This DOES mean that you will modify the URI in 
the response from the request. Though they are supposed to be the same 
(and also in subsequent requests in the reverse direction), 3261 
recognizes that this may change. Note Section 12.2.1.1:

       Usage of the URI from the To and From fields in the original
       request within subsequent requests is done for backwards
       compatibility with RFC 2543, which used the URI for dialog
       identification.  In this specification, only the tags are used for
       dialog identification.  It is expected that mandatory reflection
       of the original To and From URI in mid-dialog requests will be
       deprecated in a subsequent revision of this specification.

To support modifying the identity, an UPDATE can be sent with a new From 
header field.

I do believe an UPDATE without an SDP is acceptable. Indeed, the 
original design of UPDATE was to allow both session updates and other 
updates. UPDATE had been conceived as a fix to the HERFP problem as 
well, in which case its purpose was to update non-session stuff. Note 
that, if an UPDATE contains no SDP, there would be no SDP in the 200 OK. 
Unlike INVITE< there is no ACK which would allow an offer/answer 
exchange to start with an offer in a response.

Using To/From means that we don't need to invent new header fields and 
define a variation of the authentication service which is the same in 
every way as the one in draft-ietf-sip-identity, but differs in the 
field names. We can just reuse the identity service as defined.

I think its important to mention in the security considerations section 
that this mechanism provides no protection whatsoever against malicious 
forwarding. It provides no way to know whether the call went to the 
intended recipient or not. The only way to determine whether or not the 
response identity is to be trusted is based on the trustworthiness of 
the domain that has signed the response. This does mean that a 
subscriber could provide their own authentication service and place an 
Identity in a response; such identities should be stripped out and 
re-created by the proxy for the domain. However, if a domain does not 
perform such stripping (presumably because it doesnt implement response 
identity at all), the user can assert whatever identity they like within 
domains for which they can obtain a certificate. Of course, that is no 
different than request identity.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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