Dan, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dan Wing > Sent: 25 June 2008 16:55 > To: Elwell, John; 'Vijay K. Gurbani' > Cc: [email protected] > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > > > > Furthermore, trying to match sender identity as carried in > > > > From to the TLS-level connection identity as carried in the > > > > certificate does not work well in the the hop-by-hop model. > > > > For instance, the sender's From may as well be [EMAIL PROTECTED], but > > > > the last upstream proxy that opened up a connection to the > > > > recipient could be some intermediary (proxy.com) not in the > > > > a.com domain, thus making it impossible to enforce that the > > > > From must match the identity of the last upstream proxy in the > > > > certificate. > > > > > > Agreed. > > > > > > > Did you have some alternate or new thoughts on this to see if > > > > we can hash out something that would still be in the context > > > > of the domain-certs draft? As it stands, Scott and I are about > > > > to submit a final post WGLC revision on it by next week. > > > > > > I don't think extending domain-cert's scope would be wise -- > > > rather, I do think this is a separate problem. The separate > > > problem is that with *some domains* you connect to (and do > > > domain-certs validation with), you trust them to claim and > > > use any old "From" they want -- because with those domains > > > you trust them to have done some validation of their previous > > > hop, who validated their previous hop, etc. This is how > > > you would configure a SIP trunk with a service provider, for > > > example. > > > > > > However, if you are communicating directly with another > > > organization then you would not want to allow them to assert > > > any identity they wished, because the only identity you expect > > > them to send you requests with a From that had their own > > > identity (@microsoft.com, @boeing.com, etc.) -- that is, > > > the identity of their own employees. You do not expect them > > > to assert the identity belonging to some other company. You > > > would not extend the transitive trust to them. > > [JRE] It depends. I ([EMAIL PROTECTED]) receive a call from > > [EMAIL PROTECTED], and because I am working at home, the > siemens.com proxy > > forwards it to my home via a service provider. The service > > provider now > > needs to accept [EMAIL PROTECTED] (rather than [EMAIL PROTECTED]) as the > > source of the call. At home I would expect to receive > [EMAIL PROTECTED] as > > caller ID. > > So the title of the document would be "Validating SIP From Considered > Harmful". After writing that document, do you feel the > community would > then see the need for designing a B2BUA-survivable identity > mechanism?? [JRE] It's not the best starting point - rather a long train of thought to get to the conclusion. However, it is one of the many factors in this complicated equation.
John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
