Dept. of Computer Science 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 SIP trapezoid outbound proxy registrar 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 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

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

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", 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 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))

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 Contact: sip:alice@128.59.16.1 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?