1 / 6

End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04

End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04. Kumiko Ono ono.kumiko@lab.ntt.co.jp. IETF62. Status. Mechanism I-D Has been implemented Service Providers will need this more, as S/MIME gets widely deployed.

bessie
Download Presentation

End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. End-to-middle Security in SIPdraft-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.

More Related