There is a security hole in the SIP protocol. According to John Nix, VP, technology at InCharge Systems, there is a fundamental problem with SIP. A recipient of a phone call cannot "know"" the verified identity of the calling party (e.g. a true caller ID). The solution is defined in IETF RFC 4474, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)."The Session Initiation Protocol (SIP) needs work. No matter how well the initial authors try, there are always additions to standards. So standards beget standards. The IETF abstract description of the RFC 4474 standard is:
The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.
Currently, the three primary methods for securing SIP calls are:
* A pre-shared key or password between phones and service providers * Setting up firewall rules between nodes * Use TLS (like HTTPS) and similar encryption between nodes
These methods do not solve the identity problem of SIP without RFC 4474 implementation.
The introduction to the IETF RFC 4474 document states:
This document provides enhancements to the existing mechanisms for authenticated identity management in the Session Initiation Protocol (SIP, RFC 3261). An identity, for the purposes of this document, is defined as a SIP URI, commonly a canonical address-of-record (AoR) employed to reach a user (such as "sip:[email protected]").
RFC 3261 stipulates several places within a SIP request where a user can express an identity for themselves, notably the user-populated From header field. However, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately, in the absence of some sort of cryptographic authentication mechanism.
RFC 3261 stipulates several places within a SIP request where a user can express an identity for themselves, notably the user-populated From header field. However, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately, in the absence of some sort of cryptographic authentication mechanism.
John Nix presented the issues and solutions at the VoIP Roundtable, April 7, 2009, held at the IIT VoIP Lab. His topic was "Authenticated Identities in VoIP Call Control--Opportunities and Challenges". His presentation can be found at http://voip.itm.iit.edu/Roundtable-presos/Nix-John-ICS-04072009.pdf.
The RFC 4474 standard implements Public Key Infrastructure (PKI). This provides an authenticated identity for the originator of a VoIP call. The mechanism requires a "trusted third party."
Enterprises can use a VPN for secure softphone VoIP calls from public or to other networks to access the enterprise IPT system. Creating a VPN for an IP phone is more problematic. The problem increases with the advent of mobile VoIP devices. One solution is to have the VoIP call pass through the PSTN to the other VoIP/IPT system. This is a cost that can be avoided with the use of RFC 4474.
The design eliminates the need for islands of trust so that networks can securely interconnect like a service provider and enterprise IPT system. The design reduces the firewall overhead. It can also eliminate the cost of passing calls through the PSTN.
This is all new to enterprise. The initial users of RFC 4474 will probably be the service providers. InCharge will be selling certificates directly to service providers for implementation of RFC 4474. Certificates will be sold to enterprise through channels.
The enterprise wants secure identification of VoIP callers over the Internet. Later, as more enterprises adopt VoIP/IPT, there will be federated arrangements; one enterprise's IP phone wants to connect to another enterprise's IP phone. Eventually the use of RFC 4474 will become important to the enterprise.
So do not look for this solution to come your desk soon. Do understand that there is an identification problem that you vendor has probably not mentioned. Look into how your vendor presently performs and validates identification. You may be disappointed by their solution.
