SIP Security Henning Schulzrinne Dept of Computer Science

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

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

System model outbound proxy SIP trapezoid a@foo. com: 128. 59. 16. 1 registrar

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

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

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

L 3/L 4 security options n IPsec J L n Provides keying mechanism but IKE is complex and has interop problems works for all transport protocol (TCP, SCTP, UDP, …) no credential-fetching API TLS J J L L provides keying mechanism good credential binding mechanism no support for UDP; SCTP in progress subject to DOS by faking RST

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

TLS security: SIPS URI n SIPS scheme added in RFC 3261 n n n 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

Authentication: User password n n n INVITE sip: alice: secret@example. com Can appear in To, From, Request-URI Treated as part of user name Obviously, not secure unless e 2 e path encryption Can be easily included on web page or in Contact header But (mildly) useful for spam prevention: n n 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 n n RFC 2617 for HTTP/1. 1 HTTP Basic authentication: n n in RFC 2543 plain-text password: 401 Authentication Required WWW-Authenticate: Basic realm="Wally. World“ Authorization: Basic QWxh. ZGRpbjpvc. GVu. IHNlc 2 Ft. ZQ= n n Removed from RFC 3261 as insecure Also avoids some downgrade attacks

HTTP Digest authentication n Challenge-response: hash nonce SIP/2. 0 401 Unauthorized WWW-Authenticate: Digest realm=“biloxi. com", qop="auth, auth-int", nonce="dcd 98 b 7102 dd 2 f 0 e 8 b 11 d 0 f 600 bfb 0 c 093", opaque="5 ccc 069 c 403 ebaf 9 f 0171 e 9517 f 40 e 41“ Authorization: Digest username=“bob", realm=“biloxi. com", nonce="dcd 98 b 7102 dd 2 f 0 e 8 b 11 d 0 f 600 bfb 0 c 093", uri=“sip: alice@atlanta. com", qop=auth, nc=00000001, cnonce="0 a 4 f 113 b", response="6629 fae 49393 a 05397450978507 c 4 ef 1", opaque="5 ccc 069 c 403 ebaf 9 f 0171 e 9517 f 40 e 41"

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

HTTP Digest authentication parameter 401/7 Auth meaning realm client domain algorithm hash algorithm: MD 5, MD 5 -sess nonce server-chosen nonce 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(A 1): nonce: nc: cnonce: qop: H(A 2))

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

HTTP Digest authentication n n response = H(H(A 1): nonce: nc: cnonce: qop: H(A 2)) A 1 = username: realm: password A 2 = method: URI or method: URI: H(body) where H(x) = MD 5(x)

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

Problems with Digest Authentication n Replay attacks Masquerade attacks: fool client into providing credentials Some man-in-middle attacks: n n n downgrade security (modify or remove qop) chosen plaintext attacks use cnonce Does not protect SIP request or response headers n particularly bad for REGISTER: modify Contact header to redirect calls

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

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="284 e", … 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 J J J L 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

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

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

Agreeing on security procedures n n 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

Security discovery: message flow UAC proxy 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 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

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

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

End-to-end authentication n What do we need to prove? n n 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 n Why end-to-end authentication? n n prevent phone/IM spam nuisance callers trust: is this really somebody from my company asking about the new widget? Problem: generic identities are cheap n filtering bozo@aol. com doesn't prevent calls from jerk@yahoo. com (new day, sam person)

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

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

S/MIME example INVITE sip: User. B@there. com SIP/2. 0 Via: SIP/2. 0/UDP here. com: 5060 From: Big. Guy <sip: User. A@here. com> To: Little. Guy <sip: User. B@there. com> Call-ID: 12345601@here. com CSeq: 1 INVITE Content-Type: multipart/signed; protocol="application/pkcs 7 -signature"; micalg=sha 1; boundary=boundary 42 --boundary 42 Content-Type: message/sip

S/MIME example (2) INVITE sip: User. B@there. com SIP/2. 0 Via: SIP/2. 0/UDP here. com: 5060 From: Big. Guy <sip: User. A@here. com> To: Little. Guy <sip: User. B@there. com> Call-ID: 12345601@here. com CSeq: 1 INVITE Contact: <sip: User. A@100. 101. 102. 103> Content-Type: application/sdp Content-Length: 147 v=0 … --boundary 42 Content-Type: application/pkcs 7 -signature; name=smime. p 7 s Content-Transfer-Encoding: base 64 Content-Disposition: attachment; filename=smime. p 7 s ghy. Hh. HUujh. Jhj. H 77 n 8 HHGTrfvbnj 756 tb. B 9 HG 4 VQpfy. F 467 Gh. IGf. Hf. YT 6 … 7 Gh. IGf. Hf. YT 64 VQbnj 756 --boundary 42 --

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

DOS attacks n n n 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 n even easier in SIP, since Via not subject to address filtering

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

DOS attacks: memory n n n 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

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

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

Asserted identity n Add header P-Asserted-Identity: "Alice" <sip: alice@example. com> n Inserted by proxy, after authentication trust domain inside Receive Send keep outside redepends on authenticate Privacy & create header

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

Generalized privacy n n Primarily, address-of-records (AORs) AOR domains may be operated by n n n 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)

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

Anonymity n n 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: n n n tel: may become SIP again can't rely on dumb black phone proxies and forwarding cannot automatically withhold identity: n n proxy may refuse service ("open relay") UAS may refuse to answer

User-provided privacy n From header as Anonymous <sip: anonymous@anonymous. invalid> n n 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 user name in Contact for singleuser hosts message/sip encrypted as S/MIME n n hide from intermediaries only direct encrypted connection

Headers with privacy implications User identity From, Reply-To, Contact User address Via, Contact, Call-ID Properties Organization, Subject, Call. Info Server, User. Agent, Warning Equipment

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

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

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

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