SIP Authentication

Sankha Subhra Dey (SSD)

Computer Science,

Columbia University

VoIP Security

Prof. Henning Schulzrinne

November 5, 2008

Discussion Topics

Overviews
SIP
Authentication
Authentication mechanisms
TLS Overview
HTTP digest, S/MIME
Issues with SIP authentication mechanisms
 SIP: Overview
SIP is an application layer protocol
Text-based
Based on a request-response model
End users negotiate stream details using SDP
All clients register with a registrar server for a domain
Main Functions
Invite users to sessions
Find the users current location, match with their capabilities and
preferences
in order to deliver invitation
Carry opaque session descriptions
Modification of sessions
Termination of sessions
 SIP: Authentication
How do we define authentication?
Identifying an object

Knowing that the identity of an object is same as what the object claims

Used to identify the following cases:

REGISTER

INVITE

Re-INVITE

BYE

Mechanisms
HTTP digest authentication (RFC 3261)
Basic authentication (deprecated, will not be discussed)
Transport layer mechanism
Using S/MIME for authentication
 Some possible attacks in the absence of SIP
authentication

Replay Attacks
Simple

Replay a timestamped message (can be detected)

Replay a message that did not reach destination (cannot be detected)

Registration Hijacking
Request Spoofing
INVITE

BYE

CANCEL

 SIP Digest Authentication
Both ends use the same shared secret key.
The key is used to encrypt certain information
such as the users password.
Originated from HTTP, and is often called
HTTP digest.
RFC 3261 describes how digest authentication
is applied to SIP.
 Digest Authentication Mechanism
Server receives INVITE request
Server sends a PAR response containing a realm,
algorithm and a nonce value (among other fields)
Realm is the associated domain

Nonce is a random number (prevents replay)

Algorithm to be used for digest calculation (say, MD5)

Client computes a response using the nonce and the

username and a secret password
The password is assumed to be stored by the server as
well
Client sends back original request with computed
response
 Digest Authentication Mechanism
(contd.)
Other important header components and motivation behind
them:
Nonce: could be a digest of client IP address and a time-stamp

Prevents replay attacks (attacker must use correct IP address

before the time stamp expires)
Cnonce (optional): generated, stored and sent to the server by client

Client can vary the input to this hash rather than let the server
choose it
Server must include it in response
Nonce-count: server maintains its own copy of this count

Protects against replay attacks

Qop (optional): Quality of protection (auth: authentication, auth-int:

authentication and integrity)

Username and password: unique information known only by the client

and the server

 Digest Authentication Calculation

Request-digest = <> <KD (H (A1), unq (nonce-value)

: nc-value
: unq (cnonce-value)
: unq (qop-value)
: H (A2)
) <>
where
A1 = unq (username-value) : unq (realm-value) : passwd
A2 = Method : digest-uri-value
KD (secret, data) = string obtained by applying the digest
algorithm on data with secret
H (data) = string obtained by applying the checksum algorithm to
the data
unq (X) = value of quoted string X, without the surrounding quotes
 SIP REGISTER with DIGEST Authentication

User Agent Proxy Server

REGISTER <<AoR>> (with out credentials)

407 Proxy Authentication Required

REGISTER <<AoR>> (password encrypted with key)

200 OK
 SIP INVITE with DIGEST Authentication

UA Proxy Server UA
INVITE <<user1@domain1>> (without credentials)

407 Proxy Authentication Required

ACK

INVITE <<user1@domain1>> (with encrypted password)

100 Trying

INVITE <<user1@domain1>> (password removed)

 TLS: Overview
Transport Layer Security (TLS) is a version of Secure
Sockets Layer
TLS/SSL is the basis for web security
HTTPS = HTTP over TLS/SSL
Functions
Server to client (optionally, vice versa) authentication using

public keys
Negotiation of shared private session key

Encryption of all messages once the connection has been

established
 Secure SIP using sips
SIPS is a low cost means of encryption.
It specifies TLS (transport layer security) over
TCP
Not subject to tear down attacks
Same technology used for SSL. A SIPS call will fail
rather than complete insecurely.
Example - <sips: alice@atlanta.com>

 Using S/MIME for authentication

Carry replicates of SIP header fields inside a MIME body.

Enables authentication by signing the replicated header
fields
Helps to verify the identity of the sender

RFC 3261
Replication of all header fields inside a MIME part.
Problems with this proposal
SIP header fields might get altered by
intermediate SIP entities.
Using S/MIME
Problems with RFC 3261 S/MIME proposal (contd.)
Makes it difficult for recipients to identify the
legal or malicious changes.
SIP messages can be large in size,
causes overhead for processing and
transporting of messages

Solution: RFC 3893

Proposed to overcome these problems (discussed in

my previous presentation on SIP Identity)

Issues with authentication mechanisms
Digest authentication
Lack of securing all headers and parameters
Only protects Request URI and method fields
Requires preexisting user configurations on server

SIP over TLS

Only allows hop-by-hop authentication

S/MIME
Public keys difficult to distribute and maintain
 Summary
Overview of SIP and Authentication
HTTP digest authentication
Overview of TLS
Secure SIP using sips
Using S/MIME for authentication
Issues with SIP authentication mechanisms
 Information Sources
RFC 3261(2002)

RFC 2671 (1999)

Jonathan Rosenberg, Dynamicsoft, at VoN Developer's

Conference, 2001
(www.jdrosen.net/papers/devconfw2001_proxies.ppt)
Stephen Kingham, SIP workshop, Tokyo, 2005
(www.apan.net/meetings/tokyo2006/presentation/sip-DNS-Authentication-
Peering-SRK1.ppt)
Qi Qiu,Study of Digest Authentication for SIP
(www.site.uottawa.ca/~bob/gradstudents/DigestAuthenticationReport.pdf)