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

System modelSystem model

SIP trapezoid

outbound proxy

a@foo.com: 128.59.16.1

registrar

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: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’’)

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:alice@atlanta.com", 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:alice@example.comAuthorization: Digest username="alice", nc=00000002, cnonce="abcd", response="6629"

REGISTERTo: sip:alice@example.comAuthorization: Digest username="alice", nc=00000001, cnonce="defg", response="9f01"

401 UnauthorizedWWW-Authenticate: Digest realm="alice@example.com", qop=auth, nonce="dcd9"

REGISTERTo: sip:alice@example.com

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: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

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 bozo@aol.com doesn't prevent calls from jerk@yahoo.com (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: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

S/MIME example (2)S/MIME example (2)INVITE sip:UserB@there.com SIP/2.0Via: SIP/2.0/UDP here.com:5060From: BigGuy <sip:UserA@here.com>To: LittleGuy <sip:UserB@there.com>Call-ID: 12345601@here.comCSeq: 1 INVITEContact: <sip:UserA@100.101.102.103>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?