SIP SecuritySIP Security

Henning Schulzrinne Dept. of Computer Science

Columbia UniversityJuly 2002

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

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)

only useful for positive filtering Server can challenge client for

certificate last-hop challenge

TLS security: SIPS URITLS 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

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 RFC 3261 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

algorithm hash algorithm: MD5, MD5-sess

nonce server-chosen nonce

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 Problems with Digest AuthenticationAuthentication 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: 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

Extensions to DigestExtensions 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

Enhanced SIP Digest: Enhanced SIP Digest: nonce computationnonce 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 Agreeing on security proceduresprocedures

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: Security discovery: message flowmessage flow

OPTIONS sip:proxy.example.com SIP/2.0 Security-Client: tlsSecurity-Client: digest-integrityRequire: sec-agreeProxy-Require: sec-agree

SIP/2.0 494 Security Agreement RequiredSecurity-Server: ipsec-ike;q=0.1Security-Server: tls;q=0.2

UAC proxy

INVITE sip:proxy.example.com SIP/2.0Security-Verify: ipsec-ike;q=0.1Security-Verify: tls;q=0.2Route: sip:callee@domain.comRequire: sec-agreeProxy-Require: sec-agree

Security discoverySecurity 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 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

Privacy and User IdentityPrivacy 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 identityAsserted 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

Asserted identityAsserted identity

Add headerP-Asserted-Identity: "Alice" <sip:alice@example.com>

Inserted by proxy, after authenticationtrust domain

Receive Send

inside keep keep

outside re-authenticate & create

depends on Privacy header

Asserted identity: privacyAsserted identity: privacy

Privacy: id requests no delivery of asserted

identity outside trust domain default behavior depends on

spec(T)

Generalized privacyGeneralized 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)

Generalized privacyGeneralized privacy

Several facets:

"network"(proxies)

end system

hide user tracing, spam in untrusted networks

"tip line"

reveal billing, obtain services, spam prevention

prevent filtering

AnonymityAnonymity 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 privacyUser-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

Headers with privacy Headers with privacy implicationsimplications

User identity From, Reply-To, Contact

User address Via, Contact, Call-ID

Properties Organization, Subject, Call-Info

Equipment Server, User-Agent, Warning

PrivacyPrivacy header headernone 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 servicesPrivacy services

Outbound proxy third-party service via pre-loaded

route use

Proxy-Require: privacy

Authentication and privacyAuthentication 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?

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 privacy

Try to re-use existing mechanisms: IPsec and TLS Digest authentication S/MIME for end-to-end HTTP EAP?