- IETF RFC 4474 proposes using public key infrastructure and certificate signing to authenticate the identity of the originator of SIP messages like INVITE requests. This allows receivers to verify identities and eliminates the need for complex firewall rules between peering networks. - While it offers security and efficiency benefits, challenges include getting widespread adoption given the "chicken and egg" problem, managing certificates, and handling alterations to SIP messages by network elements that could invalidate signatures. - A reference system is needed to test interoperability, address real-world issues, and potentially revise the RFC based on lessons learned.

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.)?

6. How are Endpoints Authenticated Today (cont.)?

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 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

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

13. Example Public Key - Used to Verify Signature

14. 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

15. Authenticated Identities Simplify Peering Security enhanced while eliminating firewall rules ! 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 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

16. 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

17. 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

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 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, … 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

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 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 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 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).