SIP Musings Henning Schulzrinne SIP Summit – Las Vegas May 8, 2002.
SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.
-
Upload
paula-holt -
Category
Documents
-
view
215 -
download
2
Transcript of SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University January 2002.
SIP SecuritySIP Security
Henning Schulzrinne Dept. of Computer Science
Columbia UniversityJanuary 2002
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
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?
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
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
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
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
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’’)
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
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"
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
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))
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]
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)
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)
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
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
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
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
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?
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
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)
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
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
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
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--
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
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
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
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
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?