1 / 9

Kumiko Ono ono.kumiko@lab.ntt.co.jp

End-to-middle Security in SIP draft-ietf-sipping-e2m-sec-reqs-04 draft-ono-sipping-end2middle-security-03. Kumiko Ono ono.kumiko@lab.ntt.co.jp. IETF61. Requirements. draft-ietf-sipping-e2m-sec-reqs-04. Changes since 03. Section 2.1: Examples of Scenarios

dorian-caldwell
Download Presentation

Kumiko Ono ono.kumiko@lab.ntt.co.jp

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-ietf-sipping-e2m-sec-reqs-04draft-ono-sipping-end2middle-security-03 Kumiko Ono ono.kumiko@lab.ntt.co.jp IETF61

  2. Requirements draft-ietf-sipping-e2m-sec-reqs-04

  3. Changes since 03 • Section 2.1: Examples of Scenarios • Removed the text that overlapped with the scope of session policies • Removed the text that described an illegal behavior of a proxy server

  4. Changes since 03 (cont’d) • Section 4: Requirements for a Solution • Added notes to describe the requirements met by session policies • Added a note to describe the requirements met by an existing mechanism, digest authentication • Changed "SHOULD" to "MAY“ REQ-CONF-4: It MAY allow a UA to request that the recipient UA disclose information to the proxy server, which requesting UA is disclosing the information to. The request itself SHOULD be secure. • Added the conditions of the requirements. • References • Divided references to normative and informative.

  5. In WG LC till Nov.20 • Feedbacks are appreciated.

  6. Mechanism draft-ono-sipping-end2middle-security-03

  7. Open Issue#1: Labeling the target body for “middle” OptionA-1. A new SIP header i.e.: “Proxy-Required-Body" Option A-2. A new parameter in a SIP header i.e.: "content-id" param in Route header Option B-1. A new MIME header i.e.: "Content-Target" Option B-2. A new parameter in a MIME header i.e.: "required-entity" param in "Content-Disposition" My Proposal: Option A-1. A new SIP header

  8. Open Issue#2: Notification with a new error code Proxy should have a way to notify a UA about e2m security utilization in addition to using UAC driven method, such as session policy package. 1) When a proxy server needs to view an encrypted data sent by UAC, it requires end-to-middle confidentiality. • An existing error code, "493 Undecipherable“ and target content type in Warning header 2) When a proxy server needs to validate the data integrity of the message, it requires end-to-middle integrity. • 403? • A new error code, such as "495 Signature required" and target content type in Warning header

  9. Next Step • Can we adopt this as a WG item?

More Related