PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-02
Network Working Group J. Peterson
Internet-Draft Neustar
Intended status: Informational March 5, 2018
Expires: September 6, 2018
PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-02.txt
Abstract
This document extends PASSporT, which conveys cryptographically-
signed information about the people involved in personal
communications, to include an indication that a call has been
diverted from its original destination to a new one. This
information can greatly improve the decisions made by verification
services in call forwarding scenarios.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Peterson Expires September 6, 2018 [Page 1]
Internet-Draft PASSporT Diverted March 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PASSporT 'div' Claim . . . . . . . . . . . . . . . . . . . . 3
3.1. Nesting the original PASSporT in 'div' . . . . . . . . . 5
4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authentication Service Behavior . . . . . . . . . . . . . 6
4.2. Verification Service Behavior . . . . . . . . . . . . . . 6
5. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 7
6. Extending 'div' to work with Service Logic Tracking . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
PASSporT [RFC8225] is a token format based on JWT [RFC7519] for
conveying cryptographically-signed information about the people
involved in personal communications; it is used with STIR [RFC8224]
to convey a signed assertion of the identity of the participants in
real-time communications established via a protocol like SIP. This
specification extends PASSporT to include an indication that a call
has been diverted from its originally destination to a new one.
Although the STIR problem statement [RFC7340] is focused on
preventing the impersonation of the caller's identity, which is a
common enabler for threats such as robocalling and voicemail hacking
on the telephone network today, it also provides a signature over the
called number as the authentication service sees it. As [RFC8224]
Section 12.1 describes, this protection over the contents of the To
header field is intended to prevent a class of cut-and-paste attacks.
If Alice calls Bob, for example, Bob might attempt to cut-and-paste
the Identity header field in Alice's INVITE into a new INVITE that
Bob sends to Carol, and thus be able to fool Carol into thinking the
call came from Alice and not Bob. With the signature over the To
header field value, the INVITE Carol sees will clearly have been
destined originally for Bob, and thus Carol can view the INVITE as
suspect.
However, as [RFC8224] Section 12.1.1 points out, it is difficult for
Carol to confirm or reject these suspicions based on the information
Show full document text