1 End-to-middle Security in SIP Kumiko Ono NTT Corporation March 1, 2004 draft-ietf-sipping-e2m-sec-reqs-01.txt draft-ono-sipping-end2middle-security-01.txt draft-ono-sipping-smime-keyreuse-00.txt

2 Background Existing problems –All proxies are not always trusted by UAs to view a message body. e.g. Access via a proxy in visited network. –If e2e encryption is used, some services cannot be provided to UAs. e.g. logging services, FW control for SRTP. –If only TLS is used, visited network proxy can look some private data. e.g. user- authentication data, user-location data. Usecases –Logging services for enterprise use –Location object conveyance [It is unclear if LOC always requires all proxies to be trusted]. –FW traversal –Early media disposition –Session policy

3 Changes from ieft-sipping-e2m-sec-reqs-00 Reworked requirements to clarify the objectives; separated e2m confidentiality and integrity. Clarified the requirement for confidentiality, "The solution MUST work even with end-to-end encryption…”. –It MUST be compatible with end-to-end encryption. Shared with the end user and selected proxy, if needed. –It MUST NOT violate end-to-end encryption when the encrypted data does not need to be shared with any proxy servers. e.g., keying materials for SRTP in SDP I will add following requirement reflecting ML comment. UAs must be able to apply confidentiality and integrity protection to parts of the bodies that are only for a selected proxy.

4 Open issue for reqs. Should I add the requirement that a proxy to be allowed to delete the data that targets only for the proxy. –My proposal No (Changed from the last IETF meeting) –If the data is encrypted, UAC can set “handling=optional” in Content-Disposition to request UAS to ignore the e2m part of the body. –If the data is signed but not encrypted, the body does not contain any private data. Therefore proxy does not need to delete it. –This can keep the mechanism in RFC3261. The deleting is useful to reduce the data size, but not essential to maintain to security.

5 Proposed Mechanism This approach allows a UA to disclose message data to selected proxies while protecting the data from being seen by other proxies. End-to-middle encryption uses “S/MIME CMS envelopedData” for one/multiple recipients. –An encrypted data for recipients. Data encrypted with a content-encryption-key (CEK). The CEK encrypted with each key-encryption-key (public keys) of recipients. e.g. a proxy, multiple proxies, proxy & UA. An indicator that specifies proxies which body it should inspect. –Proposal: A new parameter in Content-Disposition –Alternative: A new SIP header and Content-ID

6 Indicator of target data for intermediaries I prefer a new param in Content-Disposition over a new SIP header and Content-ID. 1.A “required-entity” param in Content-Disposition indicates a proxy which data is required to view. No additional SIP header is required. Integrity protection of the indication is relatively simple. When there is a data for proxy, it is easier to inspect the data.  Even there is no data for proxy, all bodies are inspected to find the param. 2.A new header contains content-id which is needed to be viewed by the indicated proxy. When there is no data for proxy, it is easy to find that out.  An additional header is required.  Integrity protection of the indicator requires inner headers with signature.  When there is a data for proxy, process for SIP header in addition to search Content-ID in MIME headers are required.

7 Example of option1: a new param in Content-Disposition e2m target body INVITE From: : Content-Type: xxx Content-Disposition: session; handling=optional; required-entity=proxy1-uri

8 Example of option 2: a new SIP header with Content-ID e2m target body INVITE From: : Proxy-xxx: proxy1-uri; cid=1234 Content-Type: xxx Content-ID: 1234

9 Option 1 with integrity protection of the indicator INVITE From: : Content-Type: xxx Content-Disposition: session; handling=optional; required-entity=proxy1-uri Signature e2m target body

10 Option 2 with integrity protection of the indicator e2m target body INVITE From: : Proxy-xxx: proxy1-uri; cid=1234 Content-Type: multipart/mixed Content-Type: message/sipfrag Content-Type: xxx Content-ID: 1234 From : Proxy-xxx: proxy1-uri; cid=1234 Signature

11 Key reuse mechanism Efficient way to encrypt multiple message in a dialog. This is based on RFC3185. Please read the draft and send me your comments.

12 Next Steps I will brush up the reqs. draft –Add analysis and categorization of usecases inband or out of band data target ( only proxy or both of proxy+UA ) I plan to continue to work on the mechanism drafts in the SIPPING/SIP WG.