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

From: "Elwell, John" <[email-masked]>
Date: Tue, 08 Nov 2005 06:38:27 +0000

Jonathan,

Thanks for your comments - see below.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 08 November 2005 01:06
> To: IETF SIP List
> Subject: [Sip] comments on draft-elwell-sip-connected-identity-00
> 
> 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.
[JRE] I would very much like to go in this direction, but I feared there was
too much opposition at an earlier IETF.

> 
> 
> 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.
[JRE]Good points.

> 
> -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
> 

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Nov 2005 13:59:21 -0500

inline.

> too much opposition at an earlier IETF.

I recall controversy as well, but I can't think of a reason why this 
wouldn't work. Can anyone?

-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