End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04
description
Transcript of End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04
![Page 1: End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04](https://reader036.fdocuments.net/reader036/viewer/2022083006/56813d17550346895da6d5d3/html5/thumbnails/1.jpg)
End-to-middle Security in SIPdraft-ono-sipping-end2middle-security-04
Kumiko Ono
IETF62
![Page 2: End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04](https://reader036.fdocuments.net/reader036/viewer/2022083006/56813d17550346895da6d5d3/html5/thumbnails/2.jpg)
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
![Page 3: End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04](https://reader036.fdocuments.net/reader036/viewer/2022083006/56813d17550346895da6d5d3/html5/thumbnails/3.jpg)
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
![Page 4: End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04](https://reader036.fdocuments.net/reader036/viewer/2022083006/56813d17550346895da6d5d3/html5/thumbnails/4.jpg)
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 ?
![Page 5: End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04](https://reader036.fdocuments.net/reader036/viewer/2022083006/56813d17550346895da6d5d3/html5/thumbnails/5.jpg)
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
![Page 6: End-to-middle Security in SIP draft-ono-sipping-end2middle-security-04](https://reader036.fdocuments.net/reader036/viewer/2022083006/56813d17550346895da6d5d3/html5/thumbnails/6.jpg)
Next Step
• Can you think of any other open issues?
• I will update this draft right after this IETF meeting.