Skip to main content

IAB Response to FCC-17-89
statement-iab-response-to-fcc-17-89-00

Document Type IAB Statement
Title IAB Response to FCC-17-89
Published 2017-07-31
Metadata last updated 2023-08-09
State Active
Send notices to (None)
statement-iab-response-to-fcc-17-89-00

31 July 2017

The Internet Architecture Board Comments thanks the United States Federal Communications Commission for the opportunity to comment on their Notice of Inquiry “In the Matter of Call Authentication Trust Anchor”

The Internet Architecture Board (IAB) is chartered with a responsibility to, among other things, “pay attention to important long-term issues in the Internet, and to make sure that these issues are brought to the attention of the group(s) that are in a position to address them. The IAB is also expected to play a role in assuring that the people responsible for evolving the Internet and its technology are aware of the essential elements of the Internet architecture.” [RFC 2850, “Charter of the Internet Architecture Board (IAB),” <https://www.rfc-editor.org/rfc/rfc2850.txt>]

In accordance with that role, the IAB is pleased to be able to respond to the Federal Communications Commission Notice of Inquiry “In the Matter of Call Authentication Trust Anchor” [FCC-17-89].

The IETF STIR and ATIS/SIP Forum SHAKEN frameworks are crafted to allow the cryptographic assertion and verification that the originator of a call is authorized to use the claimed calling telephone number. Taken together, the frameworks are specific to calls that are signalled end-to-end using the Session Initiation Protocol (SIP) network.

At item 40, the NOI acknowledges that spoofed, illegal, and unwanted robocalls are a global problem.  The SHAKEN and STIR frameworks are designed to have global applicability. They assume each region has an authority that assigns telephone numbers for the region and that, ultimately, that authority is the foundation of truth for whether the originator of a call is authorized to use a given number. The frameworks use a Public Key Infrastructure (PKI) to enable a distributed authentication and verification mechanism. This infrastructure relies on the existence and maintenance of one or more trust anchors for each region. The number assigning authority is well positioned to specify those trust anchors. There must be a clear way for each regional authority to specify their trust anchors and for operators in a given region to learn the trust anchors for other regions. Item 25 in the NOI mentions that X.509 systems allow both centralized and competing self-certifying certification authorities.  The IAB notes that for the Web PKI, industry players manage a set of global trust anchors. For the PKI used by this framework, however, each regional authority is in a much better position to administer the trust anchors for their region.

The trust anchors in the X.509-based PKI required by the frameworks issue certificates to subordinate certification authorities, operators, or assignees of telephone numbers. These certification authorities issue certificates with different claims, notably attesting to the status of the holder as a service provider, or attesting to holding the assignment of a given set of telephone numbers. The SHAKEN framework intends to initially deploy certificates with the generic “service provider” attestation, without a restriction to any set of telephone numbers. This attestation allows holders to sign a SIP message that will be accepted as valid for all telephone numbers for which the certification authority is recognized as trusted for. The IAB expects that in the future certificates that are restricted to sets of, or individual, phone numbers will be necessary, so that verifiers know that the signer is authorized to speak about the calling number.  Care should be taken when establishing the governance and initial operation of these technologies to make it easy to transition away from certificates that only identify the service provider.

The SHAKEN and STIR frameworks, taken together, assume that authentication and verification is performed at elements controlled by service providers in the middle of the SIP signalling path. Item 35 in the NOI seeks comment on allowing other elements to perform these services. STIR allows the endpoints to perform their own authentication and verification. The IAB asserts there is value in allowing endpoints to perform these roles, both to allow entities who have had numbers assigned but are not service providers to use the frameworks, and to facilitate innovation in communication, particularly around improving communication security. The discussion of complexity around distributing keying material to multiple devices in the STIR documents is one of trade-offs, not a determination that the mechanisms are inherently prohibitively complex. Care should be taken in establishing the governance of these mechanisms to not prevent or hinder eventual endpoint participation in these mechanisms.

At item 42, the NOI calls out that the use of the frameworks might have privacy implications, referencing a discussion on the use of URIs in the STIR documents. Using the frameworks only have a potential privacy impact if new parties are placed in the processing path for calls. If the authentication and verification services are performed by a party that already has access to the call signalling, there are no new privacy concerns. If new parties that would not otherwise see the call signalling are used to perform the authentication or verification services, these new parties may be able to learn calling patterns between users. The discussion in the STIR documents around exposing names or place of work are relevant only to cases where the origin or destination of the call (the ‘orig’ and ‘dest’ claims, respectively) are represented in the signature objects as a URI (e.g,. <sip:some.name@somecompany.example>). That is, the type of the claims is ‘uri’. The SHAKEN framework restricts the type of the claims to be ‘tn’, which carries only a telephone number. With that restriction there is no opportunity to expose the information that a URI might contain. These concerns should be considered when choosing between a deployment model that places new parties in the signalling path versus one that does not. The IAB has no recommendation for one choice or the other.

The IAB would like to call attention to three ongoing work efforts in the IETF.

First, the ACME protocol is already deployed for use in the Web PKI. Work is ongoing to specify its use in the SHAKEN/STIR context, and can be tracked at [https://datatracker.ietf.org/group/acme/documents/].

Second, the IAB would also like to recommend that the Commission consider including protection against mis-issuance of certificates.

There is a possibility that a service provider could incorrectly issue a certificate for a number that it controls. As described above, the initial certificates anticipated in a STIR/SHAKEN deployment will not make the numbers that a service provider controls part of a delegation. That means that within a given numbering space, any service provider that can act as an authority can issue a certificate for any number in that space.

The IETF TRANS working group is nearing completion of work on a revision to Certificate Transparency (see <https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis>).  Certificate Transparency describes a way to include all certificates that a certificate authority issues in a public log. A requirement to use Certificate Transparency would allow certificate issuance to be audited.

There may be ways in which the delegation of numbers to a service provider could be integrated with Certificate Transparency. This would improve the ability to audit mis-issuance of certificates for numbers that a service provider does not control. This would require additional work. If a regional authority desires this capability, the IAB recommends taking that requirement to the IETF.

Third, the STIR working group is working on mechanisms to allow the assertions it has defined to be carried on a path other than the primary signalling path. For instance if a call originates on a SIP network, transits an SS7 network, and terminates on another SIP network, this mechanism would allow the signature attesting to the origin number to be carried out-of-band around the SS7 network and be made available to the signalling in the terminating SIP network. Progress on this effort can be followed at <https://datatracker.ietf.org/doc/draft-ietf-stir-oob>.

In conclusion, the IAB would like to reinforce that the STIR and SHAKEN frameworks are designed to address only a specific part of the overall problem of securing communications. The base mechanisms in the combined frameworks ensure only that the originator of a call is authorized to use the claimed calling telephone number. Extensions will allow assertions over more aspects of a call. (See the PassPORT extensions at <https://datatracker.ietf.org/group/stir/documents>.) The mechanisms do not directly improve or damage protection against such threats as user location tracking or denial of service. The mechanisms may be useful in a larger framework around preventing fraud. We note that the STIR mechanism provides a way to protect the specification of the media to be used during a call, which would facilitate detection of modification of the specified media parameters.

Ted Hardie

Chair, Internet Architecture Board

For the IAB