draft-ono-sipping-end2middle-security-00 1 End-to-middle Security in SIP Kumiko Ono NTT Corporation July 17, 2003

draft-ono-sipping-end2middle-security-00 2 Problems RFC3261’s end-to-end encryption may conflict with some features provided by intermediaries. –They may reject or drop encrypted data without notifying the UAs. –They may unable to offer certain features that should be provided to users. SIP needs “end-to-middle encryption” that can work with end-to-end encryption using S/MIME.

draft-ono-sipping-end2middle-security-00 3 Use cases of “end-to-middle security” 1.Logging services Instant message logging or other logging for enterprise use (e.g. financial or healthcare industries) 2.Hotspot services Connecting to home SIP server via partially-trusted proxy (e.g. from a Internet café) 3.Session-policy by J. Rosenberg This could be used as a mechanism for parts of the session-policy setup under certain specific conditions. 4.Transcoding by G. Camarillo Provide secure way to setup transcoding services??

draft-ono-sipping-end2middle-security-00 4 Reference models Case #1 The 1 st -hop SIP proxy is trusted by the user. The trustworthiness of the next-hop SIP proxy is unknown. Case #2 The user communicates with a trusted SIP proxy, but the trustworthiness of the 1 st -hop SIP proxy is not known to the user. UAC UAS UAC UAS

draft-ono-sipping-end2middle-security-00 5 Example of Case #1 Worried patient or nurse Hospital’s proxyVisited network’s proxy Doctor who is out playing golf A user needs to urgently and securely contact a doctor and also must log SDP at hospital proxy server. (This is hospital policy.)

draft-ono-sipping-end2middle-security-00 6 Example of Case #2 Fund manager on a business trip in Japan Enterprise network’s logging proxy Internet café’s proxy, SIP public phone or WiFi roaming services A colleague at headquarters The fund manager wants to protect his instant messages that include confidential financial information from being inspected by the hostile proxy.

draft-ono-sipping-end2middle-security-00 7 Relationship to Session-Policy One possible mechanism to implement for part of the session policy feature. In session-policy, proxies express the session policies. Proxy server policies, not user policies, can be defined. In end-to-middle security, users can securely request services that are provided by proxies for a session.

draft-ono-sipping-end2middle-security-00 8 Proposed Mechanism This approach allows a UA to disclose message data to selected intermediaries while protecting the data from being seen by other intermediaries. End-to-middle encryption uses for “S/MIME CMS EnvelopedData” for multiple destinations. The EnvelopedData structure contains; –Data encrypted with a content-encryption-key (CEK). –The CEK encrypted with two different key-encryption- keys, that are public keys. One for the opposite-side UA (end-to-end). One for the selected proxy (end-to- middle). This approach can use S/MIME SignedData to additionally provide integrity.

draft-ono-sipping-end2middle-security-00 9 Open Issues How does a UA request proxies to inspect an S/MIME body? How does a UA request the opposite-side UA to reuse the content-encryption-key? How does this draft interact with M. Barnes’ middle-to-end header security draft ?

draft-ono-sipping-end2middle-security Next Steps Is there sufficient interest in the SIPPING WG to continue this work? Should I split this draft into the following? –Requirements for end-to-middle security –Mechanism for end-to-middle security –Mechanism for bidirectional key exchange for S/MIME

draft-ono-sipping-end2middle-security Thanks!! Please send feedback to Kumiko Ono