380 likes | 710 Views
SIP Requirements for SRTP Keying. Dan Wing dwing@cisco.com IETF 66. v4. SIP Requirements for SRTP Keying. SIP Forking and Retargeting Avoid Clipping Media Before SDP Answer Best-Effort Encryption Shared-Key Conferencing Attack Protection Perfect Forward Secrecy Future Algorithms
E N D
SIP Requirements forSRTP Keying Dan Wingdwing@cisco.com IETF 66 v4
SIP Requirements for SRTP Keying • SIP Forking and Retargeting • Avoid Clipping Media Before SDP Answer • Best-Effort Encryption • Shared-Key Conferencing • Attack Protection • Perfect Forward Secrecy • Future Algorithms • Computational Effort when Forking • Self-Signed Certificates • Rekeying • SSRC/ROC signaling • Clock Synchronization
Presentation Format • 3 minutes: Present requirement • 2 minutes: Microphone Discussion • 1 minute: Hum vote MUST/SHOULD/MAY • Votes drive requirements for protocol design
Review: SIP Forking Bob INVITE SRTP OK INVITE INVITE Alice Atlanta Biloxi OK OK INVITE OK SRTP Carol Alice/Bob and Alice/Carolneed different keys
Review: SIP Retargeting • Offerer doesn’t know final target Bob INVITE INVITE Alice Proxy 3xx redirect OK INVITE Carol OK draft-ietf-sip-certs
SIP Forking & Retargeting Requirements (1/3) • Forking and Retargeting MUST be possible when all endpoints are SRTP? • Retargeting: offerer doesn’t know final target
SIP Forking & Retargeting Requirements (2/3) • Forking and Retargeting MUST allow establishing SRTP or RTP with mixed of SRTP- and RTP-capable targets
SIP Forking & Retargeting Requirements (3/3) • Forking and Retargeting MUST/SHOULD be secured • Immediately? • Can we do RTP for “a while” and upgrade to SRTP? • Can other forks and other targets see keys?
Avoid Clipping Media Before SDP Answer Alice Biloxi Bob INVITE INVITE Provisional ACK (Ringing) SRTP (before SDP Answer) (Bob answers) Provisional ACK (Ringing) avoidclipping OK (containing SDP answer) OK (containing SDP answer) SRTP (Two-Way)
Avoid Clipping • MUST/SHOULD avoid clipping without additional SIP signaling? • Without PRACK (RFC3262) • Without Security Preconditions (-mmusic-securityprecondition)
Best Effort Encryption • Retargeting: If one party doesn’t understand RTP/SAVP, Bad Things Happen • entire call fails or • Quietly re-Invite on error • Re-alert called party • Additional signaling, additional user-noticed latency • Security Preconditions helps, but doesn’t cure
Best Effort Encryption INVITE SRTP Bob’s phonewith SRTP INVITE SRTP Alice Proxy CANCEL INVITE SRTP NAK Bob’s voicemail RTP only NAK INVITE SRTP Bob’s phoneRTP only INVITE SRTP Alice Proxy NAK OK Bob’s voicemailwith SRTP
Best Effort Encryption • MUST provide mechanism for non-SRTP-aware answerers to use RTP?
ConferenceBridge Router or Conference Bridge Alice Talks Alice Talks Key=S Key=B Key=C Key=C Alice Sam Bob Sam Alice Bob Different SRTP key for each participant Multicast or unicast Unique key conferencing Shared key conferencing Shared-Key Conferencing
Shared-Key Conferencing Requirement • Useful application: push-to-talk groups • MUST/SHOULD support shared-key conferencing? • MUST/SHOULD allow initiator to indicate the shared key? • MUST/SHOULD allow terminator to indicate shared key? • MUST/SHOULD allow either?
Attack Protection • Attacker can include SIP proxies • Passive Attacker • Attacker sniffs signaling or media streams • Active Attacker • Attacker modifies packets • SIP, SDP, or media-path packets • Example: downgrade security
Attack Protection Requirements • MUST protect against passive attack? • afterall, that’s why we’re doing SRTP • SHOULD/MUST protect against active attack?
Perfect Forward Secrecy • Disclosure of private key doesn’t disclose all previous and all future sessions • typically uses Diffie-Hellman operation • MUST be able to establish PFS?
Future Algorithm Negotiation • Computationally expensive offers are computationally expensive! • Example:Offer with MIKEY-RSA, MIKEY-RSA-R, and SRTP with AES and SRTP with AES • MUST offer multiple SRTP cipher suites without additional computational expense • SRTP with ECC • SRTP with SHA-256
Computational Effort when Forking • Forking can cause multiple Answers. If these answers require computational effort to process, the offerer can be swamped. • Offerer SHOULD (MUST?) be able to associate SDP answer with incoming SRTP flow.
Self-Signed Certificate • Endpoints might have self-signed certificates • MUST operate with self-signed certificates
Rekeying • MUST support rekeying • SHOULD/MUST support rekeying without a re-INVITE? • We have separate dialogs, but additional signaling isn’t desirable
SSRC / Rollover Counter (ROC) • Call setup entity may not always be aware of SSRC values or ROC value • Signaling SSRC duplicates RTP’s SSRC collision detection • Late joiners • Use their own SSRCs SSRCs • Need to learn ROC • MUST NOT signal SSRC SDP? • MUST NOT require signaling ROC?
Clock Synchronization • MUST NOT require synchronized clocks?