1. Dept. of Computer Science
SIP Security
Henning Schulzrinne
Dept. of Computer Science
Columbia University
January 2002

2. Overview System model Threats and promises Approaches
lower-layer (L3, L4)
application-layer
borrowed and modified
new, SIP-specific
short-term vs. long-term
Denial-of-service attacks

3. System model SIP trapezoid outbound proxy registrar
registrar

4. Threats Bogus requests (e.g., fake From) Modification of content
REGISTER Contact
SDP to redirect media
Insertion of requests into existing dialogs: BYE, re-INVITE
Denial of service (DoS) attacks
Privacy: SDP may include media session keys
Inside vs. outside threats
Trust domains – can proxies be trusted?

5. Threats third-party passive man-in-middle (MIM) active man-in-middle
not on path
can generate requests
passive man-in-middle (MIM)
listen, but not modify
active man-in-middle
replay
cut-and-paste

6. Protection e-e: UA to UA h-h: hop-by-hop (UA to proxy, proxy-to proxy)
e-m: UA-to-middle (proxy)
m-m: proxy-to-proxy

7. L3/L4 security options IPsec TLS Provides keying mechanism
but IKE is complex and has interop problems
works for all transport protocol (TCP, SCTP, UDP, …)
no credential-fetching API
TLS
provides keying mechanism
good credential binding mechanism
no support for UDP; SCTP in progress

8. Hop-by-hop security: TLS
Server certificates well-established for web servers
Per-user certificates less so
return-address (class 1) certificate not difficult (Thawte, Verisign)
Server can challenge client for certificate  last-hop challenge

9. Authentication: User password
INVITE
Can appear in To, From, Request-URI
Treated as part of user name
Obviously, not secure unless e2e path encryption
Can be easily included on web page or in Contact header
But (mildly) useful for spam prevention:
users with password get to talk directly
others have to go through auto-attendant (“press 39 if you’re a human being’’)

10. Authentication: HTTP-derived mechanisms
RFC 2617 for HTTP/1.1
HTTP Basic authentication:
in RFC 2543
plain-text password:
 401 Authentication Required
WWW-Authenticate: Basic realm="WallyWorld“
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ=
Removed from RFC2543bis as insecure
Also avoids some downgrade attacks

11. HTTP Digest authentication
Challenge-response: hash nonce
 SIP/ Unauthorized
WWW-Authenticate: Digest
realm=“biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41“
 Authorization: Digest username=“bob",
qop=auth,
nc= ,
cnonce="0a4f113b",
response="6629fae49393a c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"

12. HTTP Digest authentication
Allows user-to-user (registrar) authentication
mostly client-to-server
but also server-to-client (Authentication-Info)
Also, Proxy-Authenticate and Proxy-Authorization
May be stacked for multiple proxies on path

13. HTTP Digest authentication
parameter
401/7
Auth
meaning
realm 
client domain
domain
destination
cnonce
client-chosen nonce nc
# times nonce has been used
digest-uri
qop
protection (auth, auth-int)
opaque
string echoed by client
username
user’s name in specified realm
response
H(H(A1):nonce:nc:cnonce:qop:H(A2))

14. HTTP Digest authentication
REGISTER
To:
401 Unauthorized
WWW-Authenticate: Digest
qop=auth,
nonce="dcd9"
REGISTER
To:
Authorization: Digest
username="alice",
nc= ,
cnonce="defg",
response="9f01"
REGISTER
To:
Authorization: Digest
username="alice",
nc= ,
cnonce="abcd",
response="6629"

15. HTTP Digest authentication
response = H(H(A1):nonce:nc:cnonce:qop:H(A2))
A1 = username:realm:password
A2 = method:URI or method:URI:H(body)
where H(x) = MD5(x)

16. HTTP Authentication-Info
Included in 200 response
Can be used to authenticate response
Provides next nonce (challenge)
Authentication-Info: nextnonce="abcde",
qop=auth-int, rspauth="3974"
For qop=auth-int: A2=uri:H(body)

17. Problems with Digest Auth.
Some man-in-middle attacks:
downgrade security (modify or remove qop)
chosen plaintext attacks  use cnonce
Does not protect SIP request or response headers
particularly bad for REGISTER: modify Contact header to redirect calls

18. HTTP Digest: headers Extend Digest with list of protected headers:
headers="To From Call-ID Contact"
Problem: need canonical header forms or byte-by-byte copy

19. HTTP Digest: tunneling
Tunneling: use entity body protection
REGISTER sip:example.com SIP/2.0
To:
From:
Authorization: Digest qop=auth-int,
response="284e", …
Content-Length: 123
Content-Type: message/sip
Contact:
Content-Length: 0

20. HTTP Digest: tunneling
No need for canonical form
No extensions of RFC 2617 needed
Backward-compatible – old proxies can't mess up requests
Header duplication: To, From, Call-ID, Content-Length, Content-Type

21. Last hop authentication
UAS may want to ascertain identity of last proxy
last proxy implements call filtering – did the call really go through there?
Proposals
401 challenge with limited Via
HMAC (H(shared secret,request))
proxy must know to do this (but unavoidable)
replay and cut-and-paste prevention?
multiple proxies?

22. End-to-end authentication
What do we need to prove?
Person sending BYE is same as sending INVITE
Person calling today is same as yesterday
Person is indeed "Alice Wonder, working for Deutsche Bank"
Person is somebody with account at MCI Worldcom

23. End-to-end authentication
Why end-to-end authentication?
prevent phone/IM spam
nuisance callers
trust: is this really somebody from my company asking about the new widget?
Problem: generic identities are cheap
filtering doesn't prevent calls from (new day, sam person)

24. End-to-end authentication and confidentiality
Shared secrets
only scales (N2) to very small groups
OpenPGP chain of trust
S/MIME-like encapsulation
CA-signed (Verisign, Thawte)
every end point needs to have list of Cas
need CRL checking
ssh-style

25. Ssh-style authentication
Self-signed (or unsigned) certificate
Allows active man-in-middle to replace with own certificate
always need secure (against modification) way to convey public key
However, safe once established

26. S/MIME example INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP here.com:5060
From: BigGuy
To: LittleGuy
Call-ID:
CSeq: 1 INVITE
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: message/sip

27. S/MIME example (2) INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP here.com:5060
From: BigGuy
To: LittleGuy
Call-ID:
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 147
v=0 …
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
7GhIGfHfYT64VQbnj756
--boundary42--

28. Other SIP security issues
REFER security
authenticate Referred-By header content
Proxy trust
proxies have to see To, From, Call-ID and URI
prevent outgoing branch to be unprotected
indication
can't enforce

29. DOS attacks CPU complexity: get SIP entity to perform work
Memory exhaustion: SIP entity keeps state (TCP SYN flood)
Amplification: single message triggers group of message to target
even easier in SIP, since Via not subject to address filtering

30. DOS attacks: amplification
Normal SIP UDP operation:
one INVITE with fake Via
retransmit 401/407 (to target) 8 times
Modified procedure:
only send one 401/407 for each INVITE
Suggestion: have null authentication
prevents amplification of other responses
E.g., user "anonymous", password empty

31. DOS attacks: memory SIP vulnerable if state kept after INVITE
Same solution: challenge with 401
Server does not need to keep challenge nonce, but needs to check nonce freshness

32. Conclusion SIP security more difficult than email or web
intermediaries (proxies)
theft of service (REGISTER)
peer-to-peer, not client-server
authenticate proxy to user
Try to re-use existing mechanisms:
IPsec and TLS
Digest authentication
S/MIME for end-to-end
HTTP EAP?