> -----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. I do wish there was more interest in cryptographic end-to-end identity that survives through B2BUAs operated by service providers. It is the end goal; service provider B2BUAs/SBCs are not going away! -d _______________________________________________ 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
