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

2. Background Existing problems Usecases
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.
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.
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
INVITE
From: :
Content-Type: xxx
Content-Disposition: session; handling=optional; required-entity=proxy1-uri
e2m target body

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

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

10. Option 2 with integrity protection of the indicator
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
e2m target body
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.