Dan Wing 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.
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!
The sipsec URI (http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01).
Sorry could not resist ;-)
Though that is not a panacea either since I doubt any B2BUA
operated by the service provider will agree to behave as a
transparent bit forwarder (although there are crypto-
techniques to allow intermediaries to snoop in an encrypted
stream to look only for certain keywords. But I doubt that work
is to a point that one can create a scalable production system
out of it.)
There is also some work on using IBE (see
http://tools.ietf.org/html/draft-kupwade-sip-iba-00); this draft
was discussed on the list before the PHL IETF. IIRC, the
discussions centered around problems with key escrow.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
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
