1. End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04 Kumiko Ono ono.kumiko@lab.ntt.co.jp IETF62

2. Status Mechanism I-D –Has been implemented –Service Providers will need this more, as S/MIME gets widely deployed. Currently only few S/MIME-supporting UAs are out there. Cert management in SIP (sipping-cert) will change this. Requirements I-D –Going under IESG review

3. Changes from -03 Deleted the open issue about labeling a body destined for “middle” –A new SIP header “Proxy-Required-Body” Changed a response code for requiring a signature –A new response “495 Signature required” Changed how to protect a label and its constraint –-03: Signature for a body which includes a label within sipfrag was SHOULD. –-04: TLS is now SHOULD and the signature for sipfrag is MAY. A proxy server trusted to provide SIP routing is generally trusted to process all SIP headers. Therefore, hop-by-hop security is reasonable for the protection. Deleted the open Issue about removing a label by proxy before forwarding –It is allowed to remove a label depending on security policies of providers. Updated reference

4. Open Issue #1 How should the error message indicate the Content-Type which needs a signature to be attached for data integrity? e.g., a body, body parts in multipart/mixed Conclusion: –For data integrity, signature for a body part alone is not sufficient. We always need signature for a whole body. –However, should the signature be inside, outside, or both, when encrypted ?

5. Open Issue #2 How should a proxy tell a UA to disclose a body while protecting data integrity? Option 1: A new error response for combined reasons. Option 2: An existing response with Warning header Option 3: Existing responses –Instructing a UA one task at time –Causes more messages than Option 1&2. My proposal: Option 2

6. Next Step Can you think of any other open issues? I will update this draft right after this IETF meeting.