320 likes | 492 Views
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.
E N D
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
System model outbound proxy SIP trapezoid a@foo.com: 128.59.16.1 registrar
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?
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
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
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
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
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’’)
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
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"
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
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"
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)
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)
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
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
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
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
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?
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
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)
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
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
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
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--
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
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
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
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
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?