End-to-middle Security in SIP

1
End-to-middle Security in SIP

• Kumiko Ono
• ono.kumiko_at_lab.ntt.co.jp
• NTT Corporation
• July 17, 2003

2
Problems

• RFC3261s 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.

3
Use cases of end-to-middle security

• Logging services
• Instant message logging or other logging for
  enterprise use
• (e.g. financial or healthcare industries)
• Hotspot services
• Connecting to home SIP server via
  partially-trusted proxy (e.g. from a Internet
  café)
• Session-policy by J. Rosenberg
• This could be used as a mechanism for parts of
  the session-policy setup under certain specific
  conditions.
• Transcoding by G. Camarillo
• Provide secure way to setup transcoding services??

4
Reference models
Case 1 The 1st-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 1st-hop SIP
proxy is not known to the user.
UAS
UAC
UAS
UAC
5
Example of Case 1
A user needs to urgently and securely contact a
doctor and also must log SDP at hospital proxy
server. (This is hospital policy.)
Hospitals proxy
Visited networks proxy
Worried patient or nurse
Doctor who is out playing golf
6
Example of Case 2
The fund manager wants to protect his instant
messages that include confidential financial
information from being inspected by the hostile
proxy.
Enterprise networks logging proxy
Internet cafés proxy, SIP public phone or WiFi
roaming services
Fund manager on a business trip in Japan
A colleague at headquarters
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.

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.

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 ?

10
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

11

• Thanks!!
• Please send feedback to
• Kumiko Ono
• ono.kumiko_at_lab.ntt.co.jp.