Re: [Sip] Toward the Evolution of SIP and Related Working Groups

["Elwell, John" <john.elwell at siemens.com>]

Dan, 

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of Dan Wing
> Sent: 24 June 2008 22:45
> To: 'Vijay K. Gurbani'
> Cc: sip at ietf.org
> Subject: Re: [Sip] Toward the Evolution of SIP and Related 
> Working Groups
> 
> > -----Original Message-----
> > From: Vijay K. Gurbani [mailto:vkg at alcatel-lucent.com] 
> > Sent: Tuesday, June 24, 2008 2:30 PM
> > To: Dan Wing
> > Cc: sip at ietf.org
> > 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 user at a.com, 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 (john at siemens.com) receive a call from
dan at cisco.com, 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 dan at cisco.com (rather than xxx at siemens.com) as the
source of the call. At home I would expect to receive dan at cisco.com 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip