Download - Presentation To Vo Ip Round Table V2
1
Opportunities and Challenges for Authenticated Identities within VoIP Call
Control
John Nix
VP, 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 Internet 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
ValidationService or local application. Uses public-certificate
from locally provisioned or remote repository
SigningService or local application.
Uses private key
SigningService or local application.
Uses private key
15
Authenticated Identities Simplify Peering
Security enhanced while eliminating firewall rules !
Without Signed MessagesWithout Signed Messages
InternetInternet
XPeer.-Fed.
SS7PSTN SIP
X
6 * ProvisioningInterfaces
Signed Messages SaveSigned Messages Save
InternetInternet
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
[1ab2:034f::ccdd:4e8b]:22335[1ab2:034f::ccdd:4e8b]:22335
[2008:0db8::1455:57cd]:12346
[1ab2:034f::ccdd:4e8b]:22335[1ab2:034f::ccdd:4e8b]:22335
[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
[1ab2:034f::ccdd:4e8b]:5060[1ab2:034f::ccdd:4e8b]: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, ManagementEnrollment / DN-AssignmentAuth.:2 Channel, Multi-FactorGenerate Account, Key-PairsManage Public Repository
Real Time ServicesCode Stubs or Proxy Function
Customer Application SupportAuthenticate (sign invites)Trust Replaces ProvisioningSPIT, 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).