1 / 32

SIP Security

SIP Security. Henning Schulzrinne Dept. of Computer Science Columbia University January 2002. 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.

adamdaniel
Download Presentation

SIP Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 outbound proxy SIP trapezoid 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: SDP may include media session keys • 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

  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) • Server can challenge client for certificate  last-hop challenge

  9. 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’’)

  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/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"

  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

  14. HTTP Digest authentication REGISTER To: sip:alice@example.com 401 Unauthorized WWW-Authenticate: Digest realm="alice@example.com", qop=auth, nonce="dcd9" REGISTER To: sip:alice@example.com Authorization: Digest username="alice", nc=00000001, cnonce="defg", response="9f01" REGISTER To: sip:alice@example.com Authorization: Digest username="alice", nc=00000002, 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: 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

  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 bozo@aol.com doesn't prevent calls from jerk@yahoo.com (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 <sip:UserA@here.com> To: LittleGuy <sip:UserB@there.com> 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

  27. S/MIME example (2) INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com> To: LittleGuy <sip:UserB@there.com> Call-ID: 12345601@here.com CSeq: 1 INVITE Contact: <sip:UserA@100.101.102.103> 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?

More Related