Authenticated Identites in VoIP Call Control

1

Opportunities and Challenges for Authenticated Identities within VoIP Call

Control

John NixVP, Technology Development

InCharge Systems, Inc.April 7, 2008

2

Overview

• How is authentication handled today?• Benefits and drawbacks of current authentication.• Example case-study: VoIP Peering• Proposed alternative: IETF RFC 4474• Why is it relevant for the "Holy Grail" of VoIP?• Real-world challenges for adoption of RFC 4474• Questions and Demonstration in VoIP Lab

3

How are Endpoints Authenticated Today?

Orig. Device

Proxy Server

Corresponding Node

Proxy Server

Corresponding

Node

INVITE

INVITE

"200 OK"

"200 OK"

"200 OK"

Media

Public Internet

NAT/FW NAT/FW

Communications

Service

INVITE

"Bob"

4

How are Endpoints Authenticated Today (cont)?

• Most service providers issue a pre-shared key (i.e. "password") with user agents

• User agents Register with a proxy server• Upon requests such as "REGISTER" or "INVITE", proxy server issues a challenge (nonce)

• User agent calculates an MD5 (or SHA) hash of the "password" and nonce

• Proxy server accepts requests with correct hash

5

How are Endpoints Authenticated Today (cont.)?

REGISTER Bob -> SIP Server REGISTER sip: 001122DDEEFF.go2call.com SIP/2.0 Via: SIP/2.0/UDP client.unknownlocation1.example.com:5061; branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sips:[email protected]>;tag=a73kszlfl To: Bob <sips:[email protected]> Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sip:[email protected]> Content-Length: 0 SIP Server -> Bob SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP client.unknownlocation1.example.com:5061; branch=z9hG4bKnashds7;received=192.0.2.201 From: Bob <sip:[email protected]>;tag=a73kszlfl To: Bob <sip:[email protected]>;tag=1410948204 Call-ID: [email protected] CSeq: 1 REGISTER WWW-Authenticate: Digest realm="go2call.com", qop="auth", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0

6

How are Endpoints Authenticated Today (cont.)?

REGISTER Bob -> SIP Server REGISTER sip: 001122DDEEFF.go2call.com SIP/2.0 Via: SIP/2.0/UDP client.unknownlocation1.example.com:5061; branch=z9hG4bKnashd92 Max-Forwards: 70 From: Bob <sip:[email protected]>;tag=ja743ks76zlflH To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 2 REGISTER Contact: <sip:[email protected]> Authorization: Digest username="bob", realm="go2call.com" nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", uri="sip: 001122DDEEFF.go2call.com", response="dfe56131d1958046689d83306477ecc" Content-Length: 0 200 OK SIP Server -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP client.unknownlocation1.example.com:5061; branch=z9hG4bKnashd92;received=192.0.2.201 From: Bob <sip:[email protected]>;tag=ja743ks76zlflH To: Bob <sip:[email protected]>;tag=37GkEhwl6 Call-ID: [email protected] CSeq: 2 REGISTER Contact: <sip:[email protected]>;expires=60 Content-Length: 0

7

Benefits / Drawbacks of Current Authentication

• Benefits- It "works". Most large-scale VoIP networks implement

this approach (Vonage, Yahoo, etc.)- Is relatively secure, with frequent new nonces.- "Fits" current NAT/FW environment. UA from different

networks can't readily reach each other directly due to intermediate NATs and firewalls.

• Drawbacks- "Password" or equivalently "secret" key must be

distributed and maintained on both servers and UA.- Creates isolated "islands" of trust. When a call is

passed to another network, significant issues arise.

8

More Drawbacks of Current Authentication

• A single call may pass through multiple networks (UA1 to Service Provider 1 to Peering Federation to Service Provider 2 to UA2)

• Receiver of call has no independently verifiable information about originator. Could be "SPIT".

• "Security" is maintained between SP and Peering Federation primarily via access lists and firewall rules.

• Ultimately, the transition to IPv6 allows UA to signal each other directly. Such direct signaling will require new authentication.

9

Significant Complexity of Firewall Rules for a Peering Federation

Note: Any time a proxy server or SBC is moved, changed, added, or deleted, then all firewall rules needs to be updated

Service Provider A

Proxy

Server 1 Proxy

Server 2Proxy

Server 3

Service Provider B

Proxy

Server 1 Proxy

Server 2 Proxy

Server 3

Service Provider C

Proxy

Server 1 Proxy

Server 2 Proxy

Server 3

Service Provider A.1

Proxy

Server 1 Proxy

Server 2 Proxy

Server 3

Service Provider A.2

Proxy

Server 1 Proxy

Server 2 Proxy

Server 3

Enterprise A.1.a

Proxy

Server 1 Proxy

Server 2 Proxy

Server 3

Enterprise A.1.b

Proxy

Server 1 Proxy

Server 2 Proxy

Server 3

Peering Federation

Level 1 Service Providers

Level 2 Service Providers

Level 3 Enterprises / End Users

10

Alternative to Firewall Rules - Open but Calls require a Prefix

• Large, distributed VoIP networks can bypass firewall rules, but require a "PIN" or "Prefix".

• It works, but can be commercially risky. Net2Phone's gateways were open but required a prefix to pass calls to the PSTN.

• Since signaling is commonly UDP (i.e., not connection oriented), a hacker used "brute force attack" to guess the prefix and stole ~$1 million of service.

• Prefixes won't work for networks with any untrusted nodes (or entities not fully controlled).

11

Proposed Solution for Authentication and Identity - IETF RFC 4474

• Utilizes well-established PKI techniques, including X.509 certs for pub & private keys

• Originator of SIP Message (INVITE, REGISTER, etc.) signs the message with a private key.

• Receiver of SIP Message can lookup the public key, calculate the signature, and if the signature matches then identity is verified.

• A few of the significant benefits:- Short-term: Eliminates need for many firewall rules. - Provides framework for direct communication between

endpoints w/ IPv6. This is a "holy grail" of VoIP. However, this benefit is still likely 4-8 years away.

12

Verified Identity Using IETF RFC 4474

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:[email protected]> Identity: "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" Identity-Info: <https://atlanta.example.com/atlanta.cer>;alg=rsa-sha1 Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

13

Example Public Key - Used to Verify Signature

Certificate: Data: Version: 3 (0x2) Serial Number: 19428 (0x4be4) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, ST=Illinois, L=Glen Ellyn, O=InCharge Systems, OU=VOIP CA, CN=inchargesys.com/[email protected] Validity Not Before: Aug 22 14:14:06 2008 GMT Not After : Aug 20 14:14:06 2018 GMT Subject: O=InCharge Systems, OU=phone number, CN=5152025010 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (512 bit) Modulus (512 bit): 00:b7:c6:37:b0:92:bb:7a:c5:a8:28:c7:1d:03:ea: fd:3b:e0:6a:c1:f2:f3:08:09:ef:d3:df:a6:0a:27: 57:9f:59:77:b9:f7:ee:c3:5c:86:e1:f4:9b:1b:fd: ef:17:00:56:cd:c9:ee:c1:ec:99:dc:32:0d:cc:68: b2:85:2c:7e:5f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Client, Object Signing X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment Netscape Comment: inCharge Certificate X509v3 Subject Key Identifier: 57:75:F6:61:3F:D1:C2:8F:E8:17:1D:90:9A:5C:D6:73:7D:7C:79:F6 X509v3 Authority Key Identifier: keyid:09:0E:41:91:34:29:7E:E5:46:CF:63:8D:86:17:36:C3:CF:2C:C4:8C DirName:/C=US/ST=Illinois/L=Glen Ellyn/O=InCharge Systems/OU=VOIP CA/CN=inchargesys.com/[email protected] serial:80:9C:9E:60:E3:8F:5F:85 Signature Algorithm: md5WithRSAEncryption bb:a8:f1:fc:f3:b4:bc:73:5f:b0:e6:86:55:1a:bd:a2:9c:69: f1:dc:4e:2c:b7:a8:f7:15:81:64:88:30:b8:9a:c8:51:49:f4:

14

Signing & Verification

SS7VoIP SIP InternetX

End-point or originatingoperator signs INVITE

Peering / TransportFederation Validatessigned INVITE androutes accordingly

Terminating IP net /gateway validates signed

INVITE and delivers call

User / Server validates INVITE,

blocks SPIT …

Example Signing & Remote Validation

ValidationService or local application. Uses public-certificate

from locally provisioned or remote repository

SigningService or local application.

Uses private key

15

Authenticated Identities Simplify Peering

Security enhanced while eliminating firewall rules !

Without Signed Messages

Internet

XPeer.-Fed.

SS7PSTN SIP

X

6 * ProvisioningInterfaces

Signed Messages Save

Internet

XPeer.-Fed.

SS7PSTN SIP

X

ICSSign

Validate

• Save Provisioning on 6 Interfaces by Trusting Signed Invites● Costly Management & Auditing tasks at every interface

• Value Proposition● Only originating peer must sign and all others can validate● Always in sync; no hassle with number & location portability

16

Example Message Flow Through Peering Federation

Terminating Service ProviderOriginating Service Provider

Proxy ServerProxy Server

Authenticate

Identity Management

Authenticate

Identity Management

Peering Fabric

Certificate AuthorityAuthentication

Proxy Peering Fabric

UA / Service Provider Requests Key

CA Returns Public Key and Certificate

UA Sends Invite to Termination Point

Client Decrypts Certificate

Sign withCA Private

Key

User Agent

User Agent

17

A "Holy Grail" of VoIP - Direct Communication, Likely Requiring IPv6

CN

Firew

all

Corresponding

Node

IP Address

Public Internet

MN FW

First Media Stream

Second Media Stream

RTCP Stream 1

RTCP Stream 2

Mobile Network

[2008:0db8::1455:57cd]:12345

2008:0db8::1455:57cd

[2008:0db8::1455:57cd]:12345

[2008:0db8::1455:57cd]:12346

[2008:0db8::1455:57cd]:12346

[2008:0db8::1455:57cd]:12345

[1ab2:034f::ccdd:4e8b]:22334[1ab2:034f::ccdd:4e8b]:22334

1ab2:034f::ccdd:4e8b

[2008:0db8::1455:57cd]:12346


[2008:0db8::1455:57cd]:12346


[1ab2:034f::ccdd:4e8b]:22334

[2008:0db8::1455:57cd]:12345

[1ab2:034f::ccdd:4e8b]:22334

Signaling (via DNS/Enum)[2008:0db8::1455:57cd]:5060

[2008:0db8::1455:57cd]:5060


18

Summary of Benefits of RFC 4474

• Provides authenticated identity of originator.• More secure than caller ID on PSTN. • Generally, more efficient than "security by firewalls".

• Can be enabler for direct communication between endpoints, using Enum or even DNS

- Firewalls will remain in IPv6, but UA can listen for signaling on port 5060 and firewall can then pass authenticated calls.

- IPv6 is still >4 years away. About 30 /8 IPv4 networks remain and IANA is giving out about 8 a year.

19

Challenges for RFC 4474

• "Chicken or the Egg" problem. It won't be an adopted standard until people use it, but people won't use until it's deployed.

• Creates needs for cert. creation, management, distribution, etc. (ICS focuses on this market).

• Multiple intermediate NATs/Proxies/Firewalls/ SBCs alter the SIP messages, including body

- Per the 4474 Spec., altering the message breaks sig.

• Need to start "interop" testing, work through issues and submit revisions to RFC 4474.

• "Real world" issues still need to be addressed.

20

Example "Support" Systems Required to Deploy RFC 4474 on a Wide Scale

Back Office Functions

Supported User Applications

Management,Provisioning,Auditing,

Information Repository

ICS Provisioning

Signing Services Validation ServicesP

eering

-Fed

.P

rovisionA

uthorize

Orig

.- / Term

.-S

vc. Pro

vider

Sign, A

uthorize

En

terprises

Direct P

eeringE

ncryption

En

d - U

serS

ign, SP

AM

SM

S, E

ncryption

Real Time Hosting or User Services

Provisioning, Management● Enrollment / DN-Assignment● Auth.:2 Channel, Multi-Factor● Generate Account, Key-Pairs● Manage Public Repository

Real Time Services● Code Stubs or Proxy Function

Customer Application Support● Authenticate (sign invites)● Trust Replaces Provisioning● SPIT, SMS, Encryption,

Community Services, Collaboration, …

21

Key Assumption for IETF RFC 4474

• Since it is a foundational assumption of this mechanism that the users trust their local domain to vouch for their security, they must also trust the service not to violate the integrity of their message without good reason. Note that RFC 3261, Section 16.6, states that SIP proxy servers "MUST NOT add to, modify, or remove the message body."

22

One of Many "Real-World" Call Flows

3725 IP-IP BICS

Go2CallRadius

Go2CallDatabase

Asterisk01

Asterisk02

Asterisk03

VoIP Phone

NATExample Changes in SIP Message:

• NAT will likely translate ports• Asterisk or IP-IP may transcode media, change

timestamp,substitute call-ID tags, change IP address

• Any of the above will break the signature per the RFC

23

Another "Real World" Issue - Caller ID and "Display Name" on Cisco Gateways

INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 85.31.54.134:5060;branch=z9hG4bKB0DC01613 Remote-Party-ID: "13125068683" <sip:[email protected]>;party=calling;screen=no;privacy=off From: "13125068683" <sip:[email protected]>;tag=4DE4288-11EE To: <sip:[email protected]> Date: Fri, 23 Mar 2007 17:06:33 GMT Call-ID: [email protected] Supported: 100rel,timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 2948265561-3633779163-2407640414-2256630647 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Max-Forwards: 70 Timestamp: 1174669593 Contact: <sip:[email protected]:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 307 v=0 o=CiscoSystemsSIP-GW-UserAgent 2924 6733 IN IP4 85.31.54.134 s=SIP Call c=IN IP4 85.31.54.134 t=0 0 m=audio 19572 RTP/AVP 18 0 8 101 c=IN IP4 85.31.54.134 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16

• RFC 4474 does not compute signature over "display name"• However, "display name" is the PSTN caller ID on Cisco GWs• Consequently, INVITE could be properly signed, but then PSTN caller ID faked.

24

Need for a Reference System - Solve "Real World" Issues and Revise RFC

• Ultimately, there will be a tradeoff between practicality and security.

• Need for a reference systems. ICS is planning to provide a hosted reference demonstration system in approximately 6 weeks.

• Based upon "interop" testing and real-world use, draft revisions to RFC 4474 will likely be submitted by end of 2009.

• An ultimate objective is to provide secure signaling directly between endpoints. (i.e. eliminated need for peering).