[Sipping] Re: E2M security and location conveyance

["James M. Polk" <[e-mail]>]

At 10:50 AM 2/25/2004 +0200, Gonzalo Camarillo wrote:
>Hello,
>
>in case the authors of the folloing drafts are not in touch yet, I believe 
>you should have a look at each other's work to make sure that the e2m 
>security stuff is taking into account the location conveyance 
>requirements. Specifically, Section 2 of the location conveyance draft 
>directly talks about e2m security.

yep - it appears that if the e2m security allows the hiding of the location 
information (LI) from a proxy that needs that information in order to 
properly route the call (to the ERC) - then this is a problem (and 
inconsistency between the goals of the 2 IDs/efforts).

I can imagine a case in which the proxy inserts LI into the message body 
thinking it knows where the UA is - leaving two LIs in the body (perhaps 
not labelled with who inserted each) for the ERC to figure out which to 
trust for that call

Do we suggests a special case where the UA trust all proxies in a scenario 
that the UA understands the new INVITE is to an ERC (via the sos@ 
indication or some other emergency number dialed on the (hard or soft) phone)?

We did have this special case written into the Geopriv Requirements doc 
(RFC 3693, Section 8.3) with Location Conveyance in mind.

comments


>http://www.ietf.org/internet-drafts/draft-ietf-sipping-e2m-sec-reqs-01.txt
>
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements-00.txt
>
>Thanks,
>
>Gonzalo
>
>
>This communication is confidential and intended solely for the 
>addressee(s). Any unauthorized review, use, disclosure or distribution is 
>prohibited. If you believe this message has been sent to you in error, 
>please notify the sender by replying to this transmission and delete the 
>message without disclosing it. Thank you.
>
>E-mail including attachments is susceptible to data corruption, 
>interruption, unauthorized amendment, tampering and viruses, and we only 
>send and receive e-mails on the basis that we are not liable for any such 
>corruption, interception, amendment, tampering or viruses or any 
>consequences thereof.
>


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP