1 / 50

SIP Security

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

vita
Télécharger la présentation

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

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

  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 • 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 • subject to DOS by faking RST

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

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

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

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

  12. 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"

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

  14. HTTP Digest authentication

  15. 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"

  16. 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)

  17. 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)

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

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

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

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

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

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

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

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

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

  27. 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?

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

  29. 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)

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

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

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

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

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

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

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

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

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

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

  40. Asserted identity • Add header P-Asserted-Identity: "Alice" <sip:alice@example.com> • Inserted by proxy, after authentication

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

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

  43. Generalized privacy • Several facets:

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

  45. User-provided privacy • From header as Anonymous <sip:anonymous@anonymous.invalid> • 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

  46. Headers with privacy implications

  47. Privacy header

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

  49. 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?

  50. 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?

More Related