draft-ono-sipping-end2middle-security-00 1 end-to-middle security in sip kumiko ono...

draft-ono-sipping-end2middle-security-00

1

End-to-middle Security in SIP

Kumiko Ono

[email protected]

NTT Corporation

July 17, 2003


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.


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??


4

Reference modelsCase #1The 1st-hop SIP proxy is trusted by the user. The trustworthiness of the next-hop SIP proxy is unknown.

Case #2The user communicates with a trusted SIP proxy, but the trustworthiness of the 1st-hop SIP proxy is not known to the user.

UAC UAS UAC UAS


5

Example of Case #1

Worried patient or nurse

Hospital’s proxy Visited 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.)


6

Example of Case #2

Fund manager on a business trip in Japan

Enterprise network’s logging proxyInternet 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.


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

[email protected].

draft-ono-sipping-end2middle-security-00 1 end-to-middle security in sip kumiko ono...

Documents