Upload
clem
View
33
Download
1
Embed Size (px)
DESCRIPTION
SIP Requirements for SRTP Keying. Dan Wing [email protected] 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 - PowerPoint PPT Presentation
Citation preview
2
SIP Requirements for SRTP Keying
1. SIP Forking and Retargeting2. Avoid Clipping Media Before SDP Answer3. Best-Effort Encryption4. Shared-Key Conferencing5. Attack Protection6. Perfect Forward Secrecy7. Future Algorithms8. Computational Effort when Forking9. Self-Signed Certificates10. Rekeying11. SSRC/ROC signaling12. Clock Synchronization
3
Presentation Format
• 3 minutes: Present requirement• 2 minutes: Microphone Discussion• 1 minute: Hum vote MUST/SHOULD/MAY
– Votes drive requirements for protocol design
4
1. SIP Forking and Retargeting
5
Review: SIP Forking
Alice Atlanta Biloxi
Bob
INVITE INVITE
INVITE
OK
OK
OK
Carol
INVITE OK
SRTP
SRTP
Alice/Bob and Alice/Carolneed different keys
6
• Offerer doesn’t know final target
Review: SIP Retargeting
draft-ietf-sip-certs
Alice Proxy
Bob
INVITE
INVITE
3xx redirect
OK
Carol
INVITE
OK
7
SIP Forking & Retargeting Requirements (1/3)
• Forking and Retargeting MUST be possible when all endpoints are SRTP?– Retargeting: offerer doesn’t know final target
8
SIP Forking & Retargeting Requirements (2/3)
• Forking and Retargeting MUST allow establishing SRTP or RTP with mixed of SRTP- and RTP-capable targets
9
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?
10
2. Avoid Clipping Media Before SDP Answer
11
Avoid Clipping Media Before SDP Answer
Alice Biloxi BobINVITE
INVITE
SRTP (before SDP Answer)
Provisional ACK (Ringing)
OK (containing SDP answer)
OK (containing SDP answer)
SRTP (Two-Way)
(Bob answers)avoidclipping
Provisional ACK (Ringing)
12
Avoid Clipping
• MUST/SHOULD avoid clipping without additional SIP signaling?– Without PRACK (RFC3262)– Without Security Preconditions (-mmusic-
securityprecondition)
13
3. Best-Effort Encryption
14
• 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
15
Best Effort Encryption
Alice Proxy
Bob’s phoneRTP onlyINVITE SRTP
INVITE SRTP
OK
Bob’s voicemailwith SRTP
NAK
Alice Proxy
Bob’s phonewith SRTPINVITE SRTP
INVITE SRTP
NAK
Bob’s voicemail RTP only
INVITE SRTP
NAK
CANCEL
16
Best Effort Encryption
Offer Answerer Session
RTP RTP RTP
RTP SRTP RTP
SRTP RTP RTP
SRTP SRTP SRTP
• MUST provide mechanism for non-SRTP-aware answerers to use RTP?
17
4. Shared-Key Conferencing
18
Shared-Key Conferencing
Alice Bob Sam
ConferenceBridge
AliceTalks
Different SRTP key for each participant
Unique key conferencing
Key=B Key=S
Alice Bob Sam
Router or Conference
Bridge
Multicast or unicast
Shared key conferencing
AliceTalks
Key=C Key=C
19
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?
20
4. Attack Protection
21
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
22
Attack Protection Requirements
• MUST protect against passive attack?– afterall, that’s why we’re doing SRTP
• SHOULD/MUST protect against active attack?
23
6. Perfect Forward Secrecy
24
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?
25
7. Future Algorithm Negotiation
26
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
27
8. Computational Effort when Forking
28
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.
29
9. Self-Signed Certificates
30
Self-Signed Certificate
• Endpoints might have self-signed certificates
• MUST operate with self-signed certificates
31
10. Rekeying
32
Rekeying
• MUST support rekeying
• SHOULD/MUST support rekeying without a re-INVITE?– We have separate dialogs, but additional
signaling isn’t desirable
33
11. SSRC and Rollover Counter (ROC)
34
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?
35
12. Clock Synchronization
36
Clock Synchronization
• MUST NOT require synchronized clocks?
37
The End