SIP Security Henning Schulzrinne Dept. of Computer Science

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

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

System model outbound proxy SIP trapezoid [email protected] : 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 Inside vs. outside threats Trust domains – can proxies be trusted?

Threats third-party passive man-in-middle (MIM) not on path can generate requests 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 subject to DOS by faking RST

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

TLS security: SIPS URI SIPS scheme added in RFC 3261 sips:[email protected] All requests must use TLS, except in callee's domain does not guarantee that every proxy checks bonafides of next hop

Authentication: User password INVITE sip:alice:[email protected] 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 RFC 3261 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:[email protected]", 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 algorithm hash algorithm: MD5, MD5-sess nonce server-chosen nonce cnonce client-chosen nonce nc # times nonce has been used digest-uri destination 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))

HTTP Digest authentication 401 Unauthorized WWW-Authenticate: Digest realm "[email protected]", qop auth, nonce "dcd9" REGISTER To: sip:[email protected] REGISTER To: sip:[email protected] Authorization: Digest username "alice", nc 00000001, cnonce "defg", response "9f01" REGISTER To: sip:[email protected] Authorization: Digest username "alice", nc 00000002, cnonce "abcd", response "6629"

HTTP Digest authentication response H(H(A1):nonce:nc:cnonce:qop:H(A 2)) 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 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

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

HTTP Digest: tunneling 2. Tunneling: use entity body protection REGISTER sip:example.com SIP/2.0 To: sip:[email protected] From: sip:[email protected] Authorization: Digest qop auth-int, response "284e", Content-Length: 123 Content-Type: message/sip REGISTER sip:example.com SIP/2.0 Contact: sip:[email protected] To: sip:[email protected] From: sip:[email protected] 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

Extensions to Digest draft-undery-sip-auth-01 Authentication-Info header Proxy-Authentication-Info 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 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

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

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:[email protected] Require: sec-agree Proxy-Require: sec-agree

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

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. 2. 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 [email protected] doesn't prevent calls from [email protected] (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:[email protected] SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy sip:[email protected] To: LittleGuy sip:[email protected] Call-ID: [email protected] 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:[email protected] SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy sip:[email protected] To: LittleGuy sip:[email protected] Call-ID: [email protected] CSeq: 1 INVITE Contact: sip:[email protected] 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: Modified procedure: one INVITE with fake Via retransmit 401/407 (to target) 8 times 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

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

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

Asserted identity Add header P-Asserted-Identity: "Alice" sip:[email protected] Inserted by proxy, after authentication trust domain inside outside Receive Send keep reauthentica te & create keep depends on Privacy header

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

Generalized privacy Primarily, address-of-records (AORs) AOR domains may be operated by employers (sip:[email protected]) traditional service providers ( sip:[email protected]) user itself (sip:[email protected]) 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 Several facets: "network" end (proxies) system hide user tracing, spam in untrusted networks "tip line" reveal billing, obtain services, spam prevention prevent filtering

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

User-provided privacy From header as Anonymous sip:[email protected] 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

Headers with privacy implications User identity User address Properties Equipment From, ReplyTo, Contact Via, Contact, Call-ID Organization, Subject, CallInfo Server, UserAgent, Warning

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 Outbound proxy third-party service via pre-loaded route use Proxy-Require: privacy

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?

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?