SIP Security

1
(No Transcript)
2
SIP Security

• Jonathan Rosenberg
• Chief Scientist

3
Presentation Overview

• Current SIP Security Mechanisms and Issues
• Authentication
• Reflection attack
• Multi-proxy authentication
• Forking
• Encryption
• Forwarding
• Role of Hop-by-Hop Security
• Firewall and NAT Traversal
• Media Stream Encryption

4
SIP Authentication

• Two Relationships
• UA to UA
• UA to proxy
• Authentication Mechanisms
• Basic
• Digest
• PGP
• All are Challenge-Response
• SIP Can Also Authenticate Responses
• Not widely used

Request
Challenge (nonce, realm)
ACK
Request w/credentials
5
Reflection Attack

• When using http digest for both request and
  response authentication
• The Same Shared Secret Cannot Be Used in Both
  directions
• Attacker can obtain credentials by reflecting a
  challenge in a response back in request
• Using different secrets in each direction
  eliminates attack
• Not a problem with PGP

INVWWW-Auth challenge1
401WWW-Auth challenge2Auth challenge1-auth
INVWWW-Auth challenge2
401WWW-Auth challenge3Auth challenge2-auth
INV WWW-Auth challenge1Auth challenge2-auth
6
Multi-Proxy Authentication

• Multiple Proxies On the Path May Challenge the
  User
• Useful for outsourced services
• If UAC Only Inserts Credentials for Last
  Challenge, Ping-Ponging Results
• UAC Must Accumulate Credentials for All
  Challenges to a Request
• Grammar Problem
• Authorization parameters are comma separated, as
  are values
• Multiple headers must be used

INV
401 Challenge 1
INV Credentials 1
INV Credentials 1
401 Challenge 2
401 Challenge 2
INV Credentials 2
401 Challenge 1
UAC
P1
P2
7
Forking

• Challenge Response Mechanisms and Forking Do Not
  Work Together
• Example
• A calls B
• Request forks to B1 and B2
• Both send 401
• Only one 401 is returned to A, that of B1
• A resends request with credentials for B1
• Request forks to B1 and B2

8
Forking cont.

• B2 rejects request with 401
• B1 rings
• 401 not forwarded since response not received
  from B1
• B1 accepts
• 200 OK sent, call established
• Problem B2 never rang
• Solution
• Signed requests without challenge response
• Requires PKI
• Replay prevention by remembering Call-IDs

9
SIP Encryption Capabilities

• Can Encrypt Bodies and Certain Headers
• But many headers still need to be in the clear
• PGP Based
• Overhead not a big issue since there are few
  requests per call
• Request is Signed with Public Key of User in To
  Field

10
SIP Encryption cont.

• Limitations
• Requires PKI
• Does not cover many critical headers (To, From)
• Does not work with forwarding
• Assumes advance knowledge of public key

11
One Solution Hop-by-Hop Security

• Hop by hop Security Can Resolve Many Problems in
  e2e Authentication and Encryption
• Advantages
• No need for end users to have public keys
• Only service providers
• Models current web security
• Major Limitation
• Requires transitive trust model
• But proxy is already trusted to forward the
  request

12
One Solution Hop-by-Hop Security cont.

• Specific Benefits
• Complete message encryption, including To, From
• Long-lived security associations between end
  users and proxies
• Eliminates expensive per-message verification
• Long lived security associations between proxies
• CANCEL security
• Proxy-to-proxy authentication

13
CANCEL Security

• CANCEL Has Unusual Characteristics
• Can be generated by UA or proxy
• Always refers to some other method
• Cannot Be Signed by UAC
• Might not even be generated by UAC
• DOS Attack Possible Without Authentication of
  CANCEL
• Send CANCEL from attacker to target when target
  gets INVITE
• Attacker need only eavesdrop INVITEs
• Result target can be prevented from receiving
  calls

14
CANCEL Security cont.

• Solution is Hop-by-Hop
• CANCEL is only accepted over an established SA
• CANCEL must come from same peer INVITE came from
• These rules guarantee that
• Only the entity on call setup path can send
  CANCEL
• No one can see that CANCEL was sent
• Significant improvement over unauthenticated
  CANCELs

15
Hop-by-Hop Operation

• Spec Makes No Specific Recommendations
• SIP Security Task Force is Developing Hop-by-hop
  Guidelines
• Issues
• Transport
• Keying
• Guiding Principles
• Do not solve it yourself - you will get it wrong
• Must use existing mechanisms

16
HBH How is it Done? cont.

• Recommended Transport
• ESP in transport mode
• Keying
• No clear protocol choice
• Some support for kerberos
• Kerberos Benefits
• Both public keys (new extension) and traditional
  shared secret
• Much lighter than IKE
• Already present in many enterprises

17
NAT and Firewall Traversal

• Need for Secure Traversal of SIP and its Signaled
  Sessions Through NAT and Firewall
• SIP is a Session Control Protocol
• IP address and ports appear in body of protocol
• Fundamental to SIP operation
• NAT traversal difficult
• Challenge SIP NAT Application Layer Gateway is
  Needed, But, Embedding ALG in NAT Poses Problems
• Scaling
• Separation of function
• Expertise

18
Proposed Solution for NAT and Firewall Traversal

• Separate Application Layer NAT from IP Layer NAT
• Application-Specific Devices Perform Application
  Layer NAT
• Solves expertise problem
• Separation of functions - enables growth
• Enhanced scalability
• Use application-layer load balancing techniques
• Dedicated IP NAT box can be fast
• Creates Buffering Zone to Deter DOS Attacks!

Buffering Zone
Proxy
Control
IPNAT
SIP
RTP
19
NAT and Firewall Traversal The Missing Piece

• Control Protocol Between Application Layer NATs
  and IP NAT
• Main Requirements
• Binding request give a private address, obtain a
  public address
• Binding release
• Open hole (firewall)
• Close hole (firewall)
• Group bindings

20
NAT and Firewall Traversal cont.

• Options for Developing Control Protocol
• Extension to SOCKS
• All new protocol
• Key Requirements
• Simple
• Fast
• Supports failover and reliability
• Ability to query for binding/hole lists
• Ability to push large numbers of lists
• Keepalives
• FOGLAMPS BoF in Adelaide IETF

21
Media Stream Encryption

• The Challenge
• How to establish secure media streams signaled by
  SIP?
• Critical for privacy and prevention of DOS
  attacks
• Secure means encrypted and authenticated
• Specific Obstacles
• Establishing shared session keys for media
  encryption
• Performing encryption
• Performing authentication

22
Media Stream Encryption cont.

• Potential Solutions For Establishing Shared Keys
• Solution I
• Send session key in SDP k line
• Must encrypt and authenticate SIP messages
• Relies on PGP for encryption and authentication
• Solution II
• Diffie Helman key exchange in SDP
• MUST authenticate SIP messages
• Relies on PGP for authentication only
• Solution III
• IKE or Kerberos

23
Media Stream Encryption cont.

• General Principles in Building a Solution
• Security is difficult. Do not try it on your
  own, since you will get it wrong. Use the
  protocols developed by experts with a deep
  understanding of security.
• Recommended Solution
• IKE or Kerberos for keying
• IPSEC or RTP security for encryption
• Currently under review by SIP Working Group in
  IETF

24
Media Authentication

• Recent DoS Attacks Demonstrate Need for Media
  Authentication
• Media Encryption Does Not Imply Authentication
• Difficult to validate media when decrypted
• Decryption carries high cost
• Possible Solutions
• Add message integrity check computed over just
  headers
• Add message integrity check over entire packet
• How to Add Check to RTP?
• Extension
• Padding
• Extra data at end

25
Summary

• Be Careful of Pitfalls in Existing Mechanisms
• Hop-by-Hop Security Can Help Solve Many Open
  Issues
• Firewall and NAT Traversal Remain Critical Issues
• Establishing Secure Media Streams is Needed For
  Privacy, DOS Attack Prevention

26
Information Resource

• Jonathan Rosenberg
• jdrosen_at_dynamicsoft.com
• 1 732.741.7244