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?
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).
Ciao
Hannes
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>Behalf Of ext Elwell, John
>Sent: 25 June, 2008 15:40
>To: Paul Kyzivat
>Cc: [email protected]; Dan Wing
>Subject: Re: [Sip] Toward the Evolution of SIP and Related
>Working Groups
>
>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
>
_______________________________________________
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
