SIP Requirements for SRTP Keying - PowerPoint PPT Presentation

About This Presentation
Title:

SIP Requirements for SRTP Keying

Description:

Bob's phone. with SRTP. INVITE SRTP. INVITE SRTP. NAK. Bob's voicemail. RTP only. INVITE SRTP ... MUST/SHOULD support shared-key conferencing? ... – PowerPoint PPT presentation

Number of Views:473
Avg rating:3.0/5.0
Slides: 38
Provided by: danw70
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: SIP Requirements for SRTP Keying


1
SIP Requirements forSRTP Keying
  • Dan Wingdwing_at_cisco.com
  • IETF 66

v4
2
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

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
Bob
INVITE
SRTP
OK
INVITE
INVITE
Alice
Atlanta
Biloxi
OK
OK
INVITE
OK
SRTP
Carol
Alice/Bob and Alice/Carolneed different keys
6
Review SIP Retargeting
  • Offerer doesnt know final target

Bob
INVITE
INVITE
Alice
Proxy
3xx redirect
OK
INVITE
Carol
OK
draft-ietf-sip-certs
7
SIP Forking Retargeting Requirements (1/3)
  • Forking and Retargeting MUST be possible when all
    endpoints are SRTP?
  • Retargeting offerer doesnt 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
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)
12
Avoid Clipping
  • MUST/SHOULD avoid clipping without additional SIP
    signaling?
  • Without PRACK (RFC3262)
  • Without Security Preconditions (-mmusic-securitypr
    econdition)

13
3. Best-Effort Encryption
14
Best Effort Encryption
  • Retargeting If one party doesnt 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 doesnt cure

15
Best Effort Encryption
Bobs phonewith SRTP
INVITE SRTP
INVITE SRTP
Alice
Proxy
CANCEL
INVITE SRTP
NAK
Bobs voicemail RTP only
NAK
Bobs phoneRTP only
INVITE SRTP
INVITE SRTP
Alice
Proxy
NAK
OK
Bobs voicemailwith SRTP
16
Best Effort Encryption
  • MUST provide mechanism for non-SRTP-aware
    answerers to use RTP?

17
4. Shared-Key Conferencing
18
Shared-Key Conferencing
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, thats why were doing SRTP
  • SHOULD/MUST protect against active attack?

23
6. Perfect Forward Secrecy
24
Perfect Forward Secrecy
  • Disclosure of private key doesnt 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!
  • ExampleOffer 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 isnt 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 RTPs 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
Write a Comment
User Comments (0)
About PowerShow.com