Transcript SIP Security Henning Schulzrinne Dept. of Computer Science Columbia University

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
Agreeing on security mechanism
Denial-of-service attacks
Privacy
System model
outbound proxy
SIP trapezoid
[email protected]:
128.59.16.1
registrar
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?
Threats

third-party



passive man-in-middle (MIM)




not on path
can generate requests
listen, but not modify
active man-in-middle
replay
cut-and-paste
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
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
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
TLS security: SIPS URI

SIPS scheme added in RFC 3261



sips:[email protected]
All requests must use TLS, except in
callee's domain
does not guarantee that every proxy
checks bonafides of next hop
Authentication: User password






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
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
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:[email protected]",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
HTTP Digest authentication

Allows user-to-user (registrar)
authentication



mostly client-to-server
but also server-to-client (AuthenticationInfo)
Also, Proxy-Authenticate and ProxyAuthorization

May be stacked for multiple proxies on
path
HTTP Digest authentication
parameter
401/7
Auth
meaning
realm


client domain
domain

algorithm


hash algorithm: MD5, MD5-sess
nonce


server-chosen nonce
cnonce

client-chosen nonce
nc

# times nonce has been used
digest-uri

destination
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 authentication
401 Unauthorized
WWW-Authenticate: Digest
realm="[email protected]",
qop=auth,
nonce="dcd9"
REGISTER
To: sip:[email protected]
REGISTER
To: sip:[email protected]
Authorization: Digest
username="alice",
nc=00000001,
cnonce="defg",
response="9f01"
REGISTER
To: sip:[email protected]
Authorization: Digest
username="alice",
nc=00000002,
cnonce="abcd",
response="6629"
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)
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)
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
HTTP 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: 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: 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 Digest


draft-undery-sip-auth-01
Authentication-Info header




Proxy-Authentication-Info



added "realm" parameter
inserted by UAS to protect responses
future nonces
inserted by proxy to protect response
future nonces
message/sip and message/sipfrag for
protecting headers using qop=auth-int
Enhanced SIP Digest: nonce
computation




nonce algorithm not specified in RFC
2617
nonce="(alg,type) time-stamp "-"
H(time-stamp ":" request-uri ":" privatekey)"
Client compares alg,type to those in
nonce  complain if different
Server also checks nonce
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
Security discovery: message
flow
UAC
proxy
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:[email protected]
Require: sec-agree
Proxy-Require: sec-agree
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
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
1.
2.
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?
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
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 [email protected] doesn't prevent
calls from [email protected] (new day, sam
person)
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
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
S/MIME example
INVITE 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)
INVITE 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
Contact: <sip:[email protected]>
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--
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
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
DOS attacks: amplification

Normal SIP UDP operation:



Modified procedure:


one INVITE with fake Via
retransmit 401/407 (to target) 8 times
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: 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 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 identity

Similar to




From hiding does not distinguish network &
end user


Calling Identity Delivery (CLID)
Calling Identity Delivery Blocking
call trace
Hiding From may prevent call-trace
Trusted network:



identities valid within trust domain
authenticates users
spec(T) describes procedures
Asserted identity

Add header
P-Asserted-Identity: "Alice" <sip:[email protected]>

Inserted by proxy, after authentication
trust
domain
inside
Receive
Send
keep
keep
outside
redepends on
authenticate Privacy
& create
header
Asserted identity: privacy



Privacy: id
requests no delivery of asserted identity
outside trust domain
default behavior depends on spec(T)
Generalized privacy


Primarily, address-of-records (AORs)
AOR domains may be operated by





employers (sip:[email protected])
traditional service providers
(sip:[email protected])
user itself (sip:[email protected])
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 privacy

Several facets:
"network"
(proxies)
end system
hide
user tracing,
spam in
untrusted
networks
"tip line"
reveal
billing, obtain
services, spam
prevention
prevent filtering
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
User-provided privacy

From header as
Anonymous <sip:[email protected]>




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 singleuser hosts
message/sip encrypted as S/MIME


hide from intermediaries only
direct encrypted connection
Headers with privacy
implications
User identity
From, Reply-To,
Contact
User address
Via, Contact,
Call-ID
Properties
Organization,
Subject, CallInfo
Server, UserAgent, Warning
Equipment
Privacy header
none
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 services



Outbound proxy
third-party service via pre-loaded route
use
Proxy-Require: privacy
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?
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?