Presentation To Vo Ip Round Table V2Presentation Transcript
Opportunities and Challenges for Authenticated Identities within VoIP Call Control John Nix VP, Technology Development InCharge Systems, Inc. April 7, 2008
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
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"
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
How are Endpoints Authenticated Today (cont.)?
How are Endpoints Authenticated Today (cont.)?
Benefits / Drawbacks of Current Authentication
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.
"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.
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.
Significant Complexity of Firewall Rules for a Peering Federation Enterprise A.1.a Proxy Server 1 Proxy Server 2 Proxy Server 3 Peering Federation Level 1 Service Providers Level 2 Service Providers Level 3 Enterprises / End Users 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 2 Proxy 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.b Proxy Server 1 Proxy Server 2 Proxy Server 3
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).
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.
Verified Identity Using IETF RFC 4474
Example Public Key - Used to Verify Signature
Signing & Verification Internet End-point or originating operator signs INVITE Peering / Transport Federation Validates signed INVITE and routes accordingly Terminating IP net / gateway validates signed INVITE and delivers call User / Server validates INVITE, blocks SPIT … Example Signing & Remote Validation Validation Service or local application. Uses public-certificate from locally provisioned or remote repository Signing Service or local application. Uses private key SS7 VoIP SIP X
Save Provisioning on 6 Interfaces by Trusting Signed Invites
Costly Management & Auditing tasks at every interface
Only originating peer must sign and all others can validate
Always in sync; no hassle with number & location portability
Without Signed Messages Internet X Peer.-Fed. SS7 PSTN SIP X 6 * Provisioning Interfaces Signed Messages Save Internet X Peer.-Fed. SS7 PSTN SIP X ICS Sign Validate
Example Message Flow Through Peering Federation Terminating Service Provider Originating Service Provider Proxy Server Proxy Server Authenticate Identity Management Authenticate Identity Management Peering Fabric Certificate Authority Authentication Proxy Peering Fabric UA / Service Provider Requests Key CA Returns Public Key and Certificate UA Sends Invite to Termination Point Client Decrypts Certificate Sign with CA Private Key User Agent User Agent
A "Holy Grail" of VoIP - Direct Communication, Likely Requiring IPv6 CN Firewall 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
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.
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.
Example "Support" Systems Required to Deploy RFC 4474 on a Wide Scale
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, …
Back Office Functions Supported User Applications Management, Provisioning, Auditing, Information Repository ICS Provisioning Signing Services Validation Services Peering-Fed. Provision Authorize Orig.- / Term.- Svc. Provider Sign, Authorize Enterprises Direct Peering Encryption End - User Sign, SPAM SMS, Encryption Real Time Hosting or User Services
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."
One of Many "Real-World" Call Flows 3725 IP-IP BICS Go2Call Radius Go2Call Database Asterisk 01 Asterisk 02 Asterisk 03 VoIP Phone NAT
Example Changes in SIP Message:
NAT will likely translate ports
Asterisk or IP-IP may transcode media, change
timestamp,substitute call-ID tags, change
Any of the above will break the signature per the RFC
Another "Real World" Issue - Caller ID and "Display Name" on Cisco Gateways
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.
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).