16 CFR Part 310: Telemarketing Sales Rule #00045 

Submission Number:
00045 
Commenter:
Warren  Bent
Organization:
InCharge Systems
State:
Illinois
Initiative Name:
16 CFR Part 310: Telemarketing Sales Rule

As correctly stated in the Summary of the FTC's 16 CFR Part 10 TSR request for comment, "The use of Caller ID information, however, has changed with the growing availability of technologies that allow callers to alter the number that appears on the recipient’s Caller ID display." The primary source of this increased capability of call originators to alter the Caller ID is the growing adoption of Voice over Internet Protocol (VoIP), primarily deploying a standards-based signaling protocol for creating and terminating calls on an IP network known as Session Initiation Protocol (SIP) that was created by the Internet Engineering Task Force (IETF). The IETF subsequently recognized the same general problem with SIP that represents the basis of the more specific issue the Commission is now seeking to address. Specifically, the IETF adopted RFC 4474 (“Enhancements for Authenticated Identity Management in SIP”), a standard designed to address the problem the IETF described in the Summary of the standard as, “the existing security mechanisms in SIP are inadequate for cryptographically assuring the identity of the end users that originate SIP requests”. In other words, this problem exists because SIP stipulates that an originator of a VoIP call can express an “identity” for themselves, including the ability to assert a Caller ID of the originators choosing, while the recipient of a such a call has no way to verify that the Caller ID has been accurately populated by the originator. It is this ability for the call originator to readily manipulate or alter the Caller ID that will be displayed to the recipient by easily populating such information themselves that provides the mechanism for the type of “spoofing” that the Commission goes on to observe in the Summary section of the request for comment when accurately stating, “Many businesses now have access to technologies that allow them to transmit Caller ID numbers that are not associated with their geographical location, or that, when dialed, connect the caller to a voice mail service. Users of these technologies also have the ability to cause the recipient’s Caller ID equipment to display a telephone number that is not in service as the source of the call, or create the appearance that the call is coming from someone who is not affiliated with the actual caller”. Perhaps even more onerous is that the latter portion of the Commissions above observation means that this same mechanism allows call originators to manipulate their Caller ID to display an originating number that appears to the recipient as if the call is coming from a legitimate source that is trusted by the recipient (perhaps the recipients bank, for example). What the Commission is seeking to address is the broader need for IP communications to transition from “Trust by Wire” established by the legacy PSTN to “Trust by Authentication” in the new world of IP communications. Fortunately, IETF RFC 4474 provides a standards-based approach for solving the problem outlined above by implementing a “Trust by Authentication” solution. In the Introduction section of RFC 4474, the authors state, that “in the telephone network today (referencing the legacy PSTN), one can receive a call from someone with whom one has no previous association, and still have a reasonable assurance that the person's displayed Caller-ID is accurate. A cryptographic approach, like the one described in this document, can probably provide a much stronger and less-spoofable assurance of identity than the telephone network provides today.” RFC 4474 describes the solution in more detail, which is simplified in the Summary section of the standard by stating, “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. The implementation of RFC 4474 could be accomplished if the Commission amended existing