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

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 pr

oviders.• Updated reference

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 ?

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

Next Step

• Can you think of any other open issues?

• I will update this draft right after this IETF meeting.