SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.
-
Upload
paula-holt -
Category
Documents
-
view
214 -
download
2
Transcript of SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.
![Page 1: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/1.jpg)
SIP SecuritySIP Security
Henning Schulzrinne Dept. of Computer Science
Columbia UniversityJanuary 2002
![Page 2: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/2.jpg)
OverviewOverview 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
![Page 4: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/4.jpg)
ThreatsThreats 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?
![Page 5: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/5.jpg)
ThreatsThreats
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
![Page 6: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/6.jpg)
ProtectionProtection
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
![Page 7: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/7.jpg)
L3/L4 security optionsL3/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
![Page 8: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/8.jpg)
Hop-by-hop security: TLSHop-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
![Page 9: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/9.jpg)
Authentication: User Authentication: User passwordpassword 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’’)
![Page 10: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/10.jpg)
Authentication: HTTP-derived Authentication: HTTP-derived mechanismsmechanisms
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
![Page 11: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/11.jpg)
HTTP Digest HTTP Digest authenticationauthentication 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"
![Page 12: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/12.jpg)
HTTP Digest HTTP Digest authenticationauthentication
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
![Page 13: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/13.jpg)
HTTP Digest HTTP Digest authenticationauthenticationparameter 401/
7Auth meaning
realm client domain
domain destination
cnonce 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(A1):nonce:nc:cnonce:qop:H(A2))
![Page 14: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/14.jpg)
HTTP Digest HTTP Digest authenticationauthentication
REGISTERTo: sip:[email protected]: Digest username="alice", nc=00000002, cnonce="abcd", response="6629"
REGISTERTo: sip:[email protected]: Digest username="alice", nc=00000001, cnonce="defg", response="9f01"
401 UnauthorizedWWW-Authenticate: Digest realm="[email protected]", qop=auth, nonce="dcd9"
REGISTERTo: sip:[email protected]
![Page 15: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/15.jpg)
HTTP Digest HTTP Digest authenticationauthentication
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)
![Page 16: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/16.jpg)
HTTP Authentication-InfoHTTP 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)
![Page 17: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/17.jpg)
Problems with Digest Auth.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
![Page 18: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/18.jpg)
HTTP Digest: headersHTTP 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
![Page 19: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/19.jpg)
HTTP Digest: tunnelingHTTP 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
![Page 20: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/20.jpg)
HTTP Digest: tunnelingHTTP 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
![Page 21: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/21.jpg)
Last hop authenticationLast 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. 401 challenge with limited Via2. HMAC (H(shared secret,request))
proxy must know to do this (but unavoidable)
replay and cut-and-paste prevention? multiple proxies?
![Page 22: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/22.jpg)
End-to-end authenticationEnd-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
![Page 23: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/23.jpg)
End-to-end authenticationEnd-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)
![Page 24: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/24.jpg)
End-to-end authentication End-to-end authentication and confidentialityand 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
![Page 25: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/25.jpg)
Ssh-style authenticationSsh-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
![Page 26: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/26.jpg)
S/MIME exampleS/MIME exampleINVITE 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
![Page 27: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/27.jpg)
S/MIME example (2)S/MIME example (2)INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP here.com:5060From: BigGuy <sip:[email protected]>To: LittleGuy <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 147
v=0…--boundary42Content-Type: application/pkcs7-signature; name=smime.p7sContent-Transfer-Encoding: base64Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6…7GhIGfHfYT64VQbnj756
--boundary42--
![Page 28: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/28.jpg)
Other SIP security issuesOther 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
![Page 29: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/29.jpg)
DOS attacksDOS 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
![Page 30: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/30.jpg)
DOS attacks: amplificationDOS 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
![Page 31: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/31.jpg)
DOS attacks: memoryDOS 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
![Page 32: SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.](https://reader038.fdocuments.in/reader038/viewer/2022110321/56649f575503460f94c7c23a/html5/thumbnails/32.jpg)
ConclusionConclusion 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?