Paul, > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 25 June 2008 13:05 > To: Elwell, John > Cc: Dan Wing; Vijay K. Gurbani; [email protected] > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > > Elwell, John wrote: > > >> 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. > > John, > > I know that is what you would like to see on your phone. > But that doesn't mean there is a plausible way for it to happen. > > We are discussing transitive trust here. Why would the SP trust > siemens.com when it asserts a cisco.com domain? If that turns > out to be > incorrect, and you complain, you could justifiably complain > that the SP > lied to you. They put themself at risk by trusting such an assertion > from siemens. [JRE] I am not expecting the service provider to trust siemens.com, because siemens.com is not making the assertion. The assertion from cisco.com is merely being passed on by siemens.com to the service provider. It will be the cisco.com certificate, not the siemens.com certificate.
Of course, siemens.com also has to make an assertion, it has to assert that it is siemens.com that is passing this request to the service provider, and this can be done using TLS authentication. But that says nothing about the original source of request or the caller ID. We must not get the two layers mixed up - transport layer authentication is for a single hop and SIP layer authentication is end-to-end (or end-domain-to-end-domain). 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
