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

2. Overview System model Threats and promises Approaches lower-layer (L3, L4) application-layer borrowed and modified  HTTP Digest new, SIP-specific short-term vs. long-term Agreeing on security mechanism Denial-of-service attacks Privacy

3. System model SIP trapezoid outbound proxy a@foo.com: 128.59.16.1 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 Inside vs. outside threats Trust domains – can proxies be trusted?

5. Threats third-party 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 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  subject to DOS by faking RST

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

9. TLS security: SIPS URI SIPS scheme added in RFC 3261 sips:alice@example.com All requests must use TLS, except in callee's domain does not guarantee that every proxy checks bonafides of next hop

10. Authentication: User password INVITE sip:alice:secret@example.com 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’’)

11. 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 RFC 3261 as insecure Also avoids some downgrade attacks

12. HTTP Digest authentication Challenge-response: hash nonce  SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm=“biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41“  Authorization: Digest username=“bob", realm=“biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri=“sip:alice@atlanta.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

13. 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

14. HTTP Digest authentication parameter 401/7 Auth meaning realm  client domain domain  destination algorithm  hash algorithm: MD5, MD5-sess nonce  server-chosen nonce cnonce  client-chosen nonce nc  # times nonce has been used digest-uri  destination 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))

15. HTTP Digest authentication REGISTER To: sip:alice@example.com Authorization: Digest username="alice", nc=00000002, cnonce="abcd", response="6629" REGISTER To: sip:alice@example.com Authorization: Digest username="alice", nc=00000001, cnonce="defg", response="9f01" 401 Unauthorized WWW-Authenticate: Digest realm="alice@example.com",realm="alice@example.com qop=auth, nonce="dcd9" REGISTER To: sip:alice@example.com

16. 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)

17. 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)

18. Problems with Digest Authentication Replay attacks Masquerade attacks: fool client into providing credentials 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

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

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

21. 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

22. Extensions to Digest draft-undery-sip-auth-01 Authentication-Info header added "realm" parameter inserted by UAS to protect responses future nonces Proxy-Authentication-Info inserted by proxy to protect response future nonces message/sip and message/sipfrag for protecting headers using qop=auth-int

23. Enhanced SIP Digest: nonce computation nonce algorithm not specified in RFC 2617 nonce="(alg,type) time-stamp "-" H(time-stamp ":" request-uri ":" private-key)" Client compares alg,type to those in nonce  complain if different Server also checks nonce

24. Agreeing on security procedures draft-ietf-sip-sec-agree-04 discovery and negotiation of security mechanism: HTTP Digest, Digest with integrity, IPsec, S/MIME, TLS, EAP,... avoid bid-down attacks Security-Client, Security-Server, Security-Verify

25. Security discovery: message flow OPTIONS sip:proxy.example.com SIP/2.0 Security-Client: tls Security-Client: digest-integrity Require: sec-agree Proxy-Require: sec-agree SIP/2.0 494 Security Agreement Required Security-Server: ipsec-ike;q=0.1 Security-Server: tls;q=0.2 UAC proxy INVITE sip:proxy.example.com SIP/2.0 Security-Verify: ipsec-ike;q=0.1 Security-Verify: tls;q=0.2 Route: sip:callee@domain.com Require: sec-agree Proxy-Require: sec-agree

26. Security discovery Relies on verification and that even weakest mechanism offers integrity protection attacker can remove strong crypto from client or server capability indication! detected during verification Does not prevent denial-of-service attacks e.g., make client and server incompatible

27. 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 1. 401 challenge with limited Via 2. HMAC (H(shared secret,request)) proxy must know to do this (but unavoidable) replay and cut-and-paste prevention? multiple proxies?

28. 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

29. 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 bozo@aol.com doesn't prevent calls from jerk@yahoo.com (new day, sam person)

30. End-to-end authentication and confidentiality Shared secrets only scales ( N 2 ) 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

31. 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

32. 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: 12345601@here.com CSeq: 1 INVITE Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: message/sip

33. 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: 12345601@here.com 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--

34. 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

35. 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

36. 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

37. 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

38. Privacy and User Identity More sophisticated version of caller-ID debate Caller wants privacy, callee (and network) wants assured identity Caller has several identities: billing identity (often, Digest identity)  1 recognizable identities

39. Asserted identity Similar to Calling Identity Delivery (CLID) Calling Identity Delivery Blocking call trace From hiding does not distinguish network & end user Hiding From may prevent call-trace Trusted network: identities valid within trust domain authenticates users spec(T) describes procedures

40. Asserted identity Add header P-Asserted-Identity: "Alice" Inserted by proxy, after authentication trust domain ReceiveSend insidekeep outsidere- authenticate & create depends on Privacy header

41. Asserted identity: privacy Privacy: id requests no delivery of asserted identity outside trust domain default behavior depends on spec(T)

42. Generalized privacy Primarily, address-of-records (AORs) AOR domains may be operated by employers ( sip:Werner.Siemens@siemens.de ) traditional service providers ( sip:alice@telekom.de ) user itself ( sip:henning@schulzrinne.org ) thus, network may be untrusted! "..., privacy entails the restriction of the distribution of a specific identity and related personal information from some particular party or parties that are potentially recipients of the message." (draft-sip-privacy-general)

43. Generalized privacy Several facets: "network" (proxies) end system hide user tracing, spam in untrusted networks "tip line" reveal billing, obtain services, spam prevention prevent filtering

44. Anonymity want to receive future requests? want to receive future calls? hide response information, e.g., Contact headers or after redirection caller can't anticipate final destination: tel: may become SIP again  can't rely on dumb black phone proxies and forwarding cannot automatically withhold identity: proxy may refuse service ("open relay") UAS may refuse to answer

45. User-provided privacy From header as Anonymous RFC 3261: Tag as identifier, so can be changed and does not have to be unique Use tag as domain part of Call-ID Don't use user name in Contact for single- user hosts message/sip encrypted as S/MIME hide from intermediaries only direct encrypted connection

46. Headers with privacy implications User identityFrom, Reply-To, Contact User addressVia, Contact, Call-ID PropertiesOrganization, Subject, Call- Info EquipmentServer, User- Agent, Warning

47. Privacy header none explicitly request no privacy services header privacy service to obscure Via, Contact,... session SDP  media anonymizer user apply user-level privacy: anonymize From, Contact, Call-ID,...; strip unnecessary header fields critical reject if privacy services cannot be provided

48. Privacy services Outbound proxy third-party service via pre-loaded route use Proxy-Require: privacy

49. Authentication and privacy Selective revealing of information (e.g., user name) Careful: bogus challengers!  require TLS server authentication before responding to challenge doesn't work (well) for multi-hop challenges cannot know whether and how downstream hop authenticated identity of proxy SIPS URI?

50. 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 privacy Try to re-use existing mechanisms: IPsec and TLS Digest authentication S/MIME for end-to-end HTTP EAP?