Dan, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dan Wing > Sent: 24 June 2008 22:45 > To: 'Vijay K. Gurbani' > Cc: [email protected] > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 24, 2008 2:30 PM > > To: Dan Wing > > Cc: [email protected] > > Subject: Re: [Sip] Toward the Evolution of SIP and Related > > Working Groups > > > > Dan Wing wrote: > > > That wasn't my intent. > > > > Dan: OK; sorry. > > No worries. > > > >> Otherwise, for certificate-based authentication > > >> between proxies, some of what you write above is discussed in > > >> the sip-domain-certs draft. > > > > > > Yes, some of it is there. Can that draft be extended to talk > > > about validating the From of requests (and maybe responses, I'm > > > not sure) that come from over a TLS-authenticated connection? Or > > > would that be out of scope for it? > > > > I believe that validating the From would be out of scope as > > the draft currently stands. The draft does discuss how a > > receiving proxy (i.e., the one that did the passive accept) > > may authenticate the sender (see S7.4, > > http://tools.ietf.org/html/draft-ietf-sip-domain-certs-00#sect > > ion-7.4), > > but this discussion does not normatively involve the From > > header. > > Right. > > > 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.
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
