Hannes, > -----Original Message----- > From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] > Sent: 26 June 2008 09:26 > To: Elwell, John > Cc: Tschofenig, Hannes (NSN - FI/Espoo); Paul Kyzivat; > [email protected]; Dan Wing > Subject: Re: [Sip] Toward the Evolution of SIP and Related > Working Groups > > Comments inline: > > Elwell, John wrote: > > Hannes, > > > > > >> -----Original Message----- > >> From: Tschofenig, Hannes (NSN - FI/Espoo) > >> [mailto:[EMAIL PROTECTED] > >> Sent: 25 June 2008 14:00 > >> To: Elwell, John; Paul Kyzivat > >> Cc: [email protected]; Dan Wing > >> Subject: RE: [Sip] Toward the Evolution of SIP and Related > >> Working Groups > >> > >> > >> Consider the following scenario: > >> > >> +-----------+ +-----------+ > >> |SIP | |SIP | > >> +------>|Proxy |<---------->|Proxy |<------+ > >> | |Server X | TLS |Server Y | | > >> | +-----------+ +-----------+ | > >> | | > >> | TLS or TLS or | > >> | SIP Digest SIP Digest | > >> | | > >> | | > >> v v > >> +-----------+ +-----------+ > >> |SIP | |SIP | > >> |User Agent | RTP |User Agent | > >> |Alice | <=================================> |Bob | > >> +-----------+ +-----------+ > >> > >> > >> When there are no further proxies between X and Y then Y has the > >> information that Alice was authenticated by X. Proxy Y > would pass that > >> info on to Bob. Bob trusts Y. > >> > >> Obviously, the two VoIP providers may have a far more complicated > >> infrastructure with multiple proxies but they all belong > to the same > >> domain and could be seen from external as just one box. > >> > >> The same would not work when there are more proxies > between X and Y. > >> However, these guys that prefer such a deployment belong > more to the > >> chain of trust camp rather than the end-to-end / email > alike peering > >> camp. It is rather unlikely that you get their support for > getting SIP > >> Identity to work in their networks. > >> > >> So, do we have an indication that some folks plan to use > SIP Identity > >> for their deployment? > >> > > [JRE] Well, what about enterprise via service provider to > enterprise? As > > an enterprise provider, I would like to be able to use SIP > identity, but > > a precondition is that it gets through that intermediate service > > provider(s). > > > > > Why would like to pick a service provider in the first place? Why are > they deploying B2BUAs? > > If you really want todo that then pick one that does not damage your > security. You are the customer and you decide. > > If you want to pick such as service provider then why does > the chain of > trust not work for you? Hopefully you trust the provider you > have chosen. [JRE] I might trust my service provider, but I might not trust (or even know of) the peer enterprise's service provider. And what if the two service providers use indirect peering rather than direct peering? That is the problem, there can be just too many domains along the path of a call, particularly a call that gets forwarded. It seems too hard to figure out for every possible scenario how to get hop-by-hop to work, when an end-domain-to-end-domain solution would always work if there is no interference from intermediate domains.
> > .... just trying to figure out what the typical deployment > cases are and > why we don't see any of this in XMPP. > > > > >> Wouldn't it be better to rely on something like SIP CERT > for a better > >> end-to-end security mechanism (ignoring for a moment that SIP > >> CERT also > >> uses SIP Identity for "simplified deployment" reasons whereby > >> one has to > >> state that the usage of SIP Identity for SUBSCRIBE/NOTIFY > might have > >> different B2BUA aspects). > >> > > [JRE] You have lost me there. What is SIP CERT? Can you > point me at a > > draft? > > > http://tools.ietf.org/html/draft-ietf-sip-certs-06 [JRE] I don't understand - how does sip-certs provide end-to-end authentication? It might help me to locate a certificate that is used in some authentication mechanism such as Identity, but it doesn't itself provide an authentication mechanism. John > > Ciao > Hannes > > > 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 > > > > _______________________________________________ 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
