Personal Assertion Token (PASSporT)
Extension for Diverted Calls
Neustar, Inc.
1800 Sutter St., Suite 570
Concord
CA
94520
United States of America
jon.peterson@team.neustar
ART
STIR
SIP
STIR
Identity
The Personal Assertion Token (PASSporT) is specified in RFC 8225 to
convey cryptographically signed
information about the people involved in personal communications. This
document extends PASSporT 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. Also specified here is an encapsulation mechanism
for nesting a PASSporT within another PASSporT that assists relying
parties in some diversion scenarios.
This document updates RFC 8224.
Introduction
A Personal Assertion Token (PASSporT) is a token format based on the JSON
Web Token (JWT) for
conveying cryptographically signed information about the people involved
in personal communications; it is used by the Secure Telephone Identity
Revisited (STIR) protocol
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 original destination to a new one.
Although the STIR problem
statement 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 at the time that the
authentication service sees it. As 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
points out, it is difficult for Carol to confirm or reject these
suspicions based on the information she receives from the baseline
PASSporT object. The common "call forwarding" service serves as a good
example of the reality that the original called party number is not
always the number to which a call is delivered. There are a number of
potential ways for intermediaries to indicate that such a forwarding
operating has taken place. The address in the To header field value of
SIP requests is not supposed to change, according to baseline SIP
behavior ; instead, it is the
Request-URI that is supposed to be updated when a call is
retargeted. Practically speaking, however, many operational environments
do alter the To header field. The History-Info header field was created to store
the Request-URIs that are discarded by a call in transit. The SIP Diversion header field,
though historic, is still used for this purpose by some operators
today. Neither of these header fields provide any cryptographic
assurance of secure redirection, and they both record entries for minor
syntactical changes in URIs that do not reflect a change to the actual
target of a call.
Therefore, this specification extends PASSporT with an explicit
indication that the original called number in PASSporT no longer
reflects the destination to which a call is intended to be
delivered. For this purpose, it specifies a Divert PASSporT type ("div")
for use in common SIP retargeting cases; it is expected that in this
case, SIP INVITE requests will carry multiple Identity header fields,
each containing its own PASSporT. Throughout this document, PASSporTs
that contain a "div" element will be referred to as "div"
PASSporTs. Verification services and the relying parties who make
authorization decisions about communications may use this diversion
indication to confirm that a legitimate retargeting of the call has
taken place, rather than a cut-and-paste attack. For out-of-band use cases and
other non-SIP applications of PASSporT, a separate "div-o" PASSporT type
is also specified, which defines an "opt" PASSporT element for carrying
nested PASSporTs within a PASSporT. These shall in turn be referred to
in this document as "div-o" PASSporTs.
Terminology
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are
to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
The "div" PASSporT Type and Claim
This specification defines a PASSporT type called "div", which may be employed
by authentication services located at retargeting entities. All "div"
PASSporTs MUST contain a new JSON Web Token "div" claim, also specified
in this document, which indicates a previous destination for a call
during its routing process. When a retargeting entity receives a call
signed with a PASSporT, it may act as an authentication service and
create a new PASSporT containing the "div" claim to attach to the
call.
Note that a new PASSporT is only necessary when the canonical form of
the "dest" identifier (per the canonicalization procedures in ) changes due to this
retargeting. If the canonical form of the "dest" identifier is not
changed during retargeting, then a new PASSporT with a "div" claim MUST
NOT be produced.
The headers of the new PASSporTs generated by retargeting entities
MUST include the "div" PASSporT type and an "x5u" field pointing to a
credential that the retargeting entity controls. "div" PASSporTs MUST
use full form instead of compact form. The new PASSporT header will look
as follows:
A "div" PASSporT claims set is populated with elements drawn from the
PASSporT(s) received for a call by the retargeting entity; at a high
level, the original identifier for the called party in the "dest" object
will become the "div" claim in the new PASSporT. If the "dest" object of
the original PASSporT contains multiple identifiers, because it contains
one or more name/value pairs with an array as its value, the retargeting
entity MUST select only one identifier from the value(s) of the "dest"
object to occupy the value of the "div" field in the new
PASSporT. Moreover, it MUST select an identifier that is within the
scope of the credential that the retargeting entity will specify in the
"x5u" of the PASSporT header (as described below).
The new target for the call selected by the retargeting entity
becomes the value of the "dest" object of the new PASSporT. The "orig"
object MUST be copied into the new PASSporT from the original PASSporT
received by the retargeting entity. The retargeting entity SHOULD retain
the "iat" object from the original PASSporT, though if in the underlying
signaling protocol (e.g., SIP) the retargeting entity changes the date
and time information in the retargeted request, the new PASSporT should
instead reflect that date and time. No other claims or extensions are to
be copied from the original PASSporT to the "div" PASSporT.
So, for an original PASSporT claims set of the form:
If the retargeting entity is changing the target from 12155551213 to
12155551214, the claims set of a "div" PASSporT generated by the
retargeting entity would look as follows:
The combined full form PASSporT (with a signature covered by the
ES256 keys given in ) would look
as follows:
The same "div" PASSporT would result if the "dest" object of the
original PASSporT contained an array value, such as
{"tn":["12155551213","19995551234"]}, and the retargeting entity chose
to retarget from the first telephone number in the array. Every "div"
PASSporT is diverting from only one identifier.
Note that the "div" element may contain other name/value pairs than
just a destination, including a History-Info indicator (see ). After the PASSporT header and claims
have been constructed, their signature is generated per the guidance in
-- except for the credential
required to sign it. While in the ordinary construction of a PASSporT,
the credential used to sign will have authority over the identity in the
"orig" claim (for example, a certificate with authority over the
telephone number in "orig" per ), for all PASSporTs using the "div" type the
signature MUST be created with a credential with authority over the
identity present in the "div" claim. So for the example above, where the
original "dest" is "12155551213", the signer of the new PASSporT object
MUST have authority over that telephone number and need not have any
authority over the telephone number present in the "orig" claim.
Note that Identity header fields are not ordered in a SIP request,
and in a case where there is a multiplicity of Identity header fields in
a request, some sorting may be required to match "div" PASSporTs to
their originals.
PASSporTs of type "div" MUST NOT contain an "opt" (see ) element in their payload.
Using "div" in SIP
This section specifies SIP-specific usage for the "div" PASSporT type
and its handling in the SIP Identity header field "ppt" parameter
value. Other protocols using PASSporT may define behavior specific to
their use of the "div" claim.
Authentication Service Behavior
An authentication service only adds an Identity header field value
containing the "div" PASSporT type to a SIP request that already
contains at least one Identity header field value; it MUST NOT add a
"div" PASSporT to an INVITE that contains no Identity header
field. The retargeting entity SHOULD act as a verification service and
validate the existing Identity header field value(s) in the request
before proceeding; in some high-volume environments, it may instead
put that burden of validating the chain entirely on the terminating
verification service. As the authentication service will be adding a
new PASSporT that refers to an original, it MUST NOT remove the
original request's Identity header field value before forwarding.
As was stated in , the
authentication service MUST sign any "div" PASSporT with a credential
that has a scope of authority covering the identity it populates in
the "div" element value. Note that this is a significant departure
from baseline STIR authentication service behavior, in which the
PASSporT is signed by a credential with authority over the "orig"
field. The "div" value reflects the URI that caused the call to be
routed to the retargeting entity, so in ordinary operations, it would
already be the STIR entity holding the appropriate private keying
material for calls originating from that identity.
A SIP authentication service typically will derive the "dest"
element value of a "div" PASSporT from a new Request-URI that is set
for the SIP request before it is forwarded. Older values of the
Request-URI may appear in header fields like Diversion or
History-Info; this document specifies an optional interaction with
History-Info below in . Note as
well that because PASSporT operates on canonicalized telephone numbers
and normalized URIs, many smaller changes to the syntax of identifiers
that might be captured by other mechanisms that record retargeting
(like History-Info) will likely not require a "div" PASSporT.
When adding an Identity header field with a PASSporT claims set
containing a "div" claim, SIP authentication services MUST also add a
"ppt" parameter to that Identity header with a value of "div". For the
example PASSporT given in ,
the new Identity header added after retargeting might look as
follows:
;ppt="div"
]]>
Note that in some deployments, an authentication service will need
to generate "div" PASSporTs for a request that contains multiple
non-"div" Identity header field values. For example, a request
arriving at a retargeting entity might contain, in different Identity
header fields, a baseline
PASSporT and a PASSporT of type "rph" signed by a separate authority. Provided
that these PASSporTs share the same "orig" and "dest" values, the
retargeting entity's authentication service SHOULD generate only one
"div" PASSporT. If the "orig" or "dest" of these PASSporTs differ,
however, one "div" PASSporT SHOULD be generated for each non-"div"
PASSporT. Note that this effectively creates multiple chains of "div"
PASSporTs in a single request, which complicates the procedures that
need to be performed at verification services.
Furthermore, a request may also be retargeted a second time, at
which point the subsequent retargeting entity SHOULD generate one
"div" PASSporT for each previous "div" PASSporT in the request that
contains a "dest" object with the value of the current target -- but
not for "div" PASSporTs with earlier targets. Ordinarily, the current
target will be readily identifiable, as it will be in the last "div"
PASSporT in each chain, and in SIP cases, it will correspond to the
Request-URI received by the retargeting entity. Moreover, the current
target will be an identifier that the retargeting entity possesses a
credential to sign for, which may not be true for earlier
targets. Ultimately, on each retargeting, the number of PASSporTs
added to a request will be equal to the number of non-"div" PASSporTs
that do not share the same "orig" and "dest" object values.
Verification Service Behavior
, Step 5
requires that specifications defining "ppt" values describe any
additional or alternative verifier behavior. The job of a SIP
verification service handling one or more "div" PASSporTs is very
different from that of a traditional verification service. At a high
level, the immediate responsibility of the verification service is to
extract all PASSporTs from the two or more Identity header fields in a
request, identify which are "div" PASSporTs and which are not, and
then order and link the "div" PASSporTs to the original PASSporT(s) in
order to build one or more chains of retargeting.
In order to validate a SIP request using the "div" PASSporT type, a
verification service needs to inspect all of the valid Identity header
field values associated with a request, as an Identity header field
value containing "div" necessarily refers to an earlier PASSporT
already in the message. For each "div" PASSporT, the verification
service MUST find an earlier PASSporT that contains a
"dest" claim with a value equivalent to the "div" claim in each "div"
PASSporT. It is possible that this earlier PASSporT will also contain
a "div" and that it will in turn chain to a still earlier PASSporT
stored in a different Identity header field value. If a complete chain
cannot be constructed, the verification service cannot complete "div"
validation; it MAY still validate any non-"div"
PASSporTs in the request per the normal procedures in . If a chain has been successfully
constructed, the verification service extracts from the outermost
(that is, the most recent) PASSporT in the chain a "dest" field; this
will be a "div" PASSporT that no other "div" PASSporT in the SIP
request refers to. Its "dest" element value will be referred to in the
procedures that follow as the value of the "outermost "dest"
field".
Ultimately, by looking at this chain of transformations and
validating the associated signatures, the verification service will be
able to ascertain that the appropriate parties were responsible for
the retargeting of the call to its current destination. This can help
the verification service to determine that the original PASSporT in
the call was not simply used in a cut-and-paste attack and inform any
associated authorization decisions in terms of how the call will be
treated -- though, per , that decision is a matter of local policy and is
thus outside the scope of this specification.
A verification service parses a chain of PASSporTs as follows:
- The verification service MUST compare the value in the
outermost "dest" field to the target of the call. As it is
anticipated that SIP authentication services that create "div"
PASSporTs will populate the "dest" header from the retargeted
Request-URI (see ), in ordinary
SIP operations, the Request-URI is where verification services will
find the latest call target. Note, however, that after a "div"
PASSporT has been added to a SIP request, the Request-URI may have
been updated during normal call processing to an identifier that no
longer contains the logical destination of a call; in this case, the
verification service MAY compare the "dest" field to a provisioned
telephone number for the recipient.
- The verification service MUST validate the signature
over the outermost "div" PASSporT and establish that the credential
that signed the "div" PASSporT has the authority to attest for the
identifier in the "div" element of the PASSporT (per , Step 3).
- The verification service MUST validate that the "orig"
field of the innermost PASSporT of the chain (the only PASSporT in
the chain that will not be of PASSporT type "div") is equivalent to
the "orig" field of the outermost "div" PASSporT; in other words, that
the original calling identifier has not been altered by retargeting
authentication services. If the "orig" value has changed, the
verification service MUST treat the entire PASSporT
chain as invalid. The verification service MUST also
verify that all other "div" PASSporTs in the chain share the same
"orig" value. Then, the verification service validates the
relationship of the "orig" field to the SIP-level call signaling per
the guidance in , Step 2.
- The verification service MUST check the date freshness
in the outermost "div" PASSporT, per , Step 4. Furthermore, it is RECOMMENDED
that the verification service check that the "iat" field of the
innermost PASSporT is also within the date freshness interval;
otherwise, the verification service could allow attackers to replay
an old, stale PASSporT embedded in a fresh "div". However, note that
in some use cases, including certain ways that call transfers are
implemented, it is possible that an established call will be
retargeted long after it has originally been placed, and
verification services may want to allow a longer window for the
freshness of the innermost PASSporT if the call is transferred from
a trusted party (as an upper bound, a freshness window on the order
of three hours might suffice).
- The verification service MUST inspect and validate the
signatures on each and every PASSporT object in the chain between
the outermost "div" PASSporT and the innermost PASSporT. Note that
(per ) a chain may terminate at
more than one innermost PASSporT, in cases where a single "div" is
used to retarget from multiple innermost PASSporTs. Also note that
, Step 1 applies
to the chain validation process; if the innermost PASSporT contains
an unsupported "ppt", its chain MUST be ignored.
Note that the To header field is not used in the first step
above. Optionally, the verification service MAY verify that the To
header field value of the received SIP signaling is equal to the
"dest" value in the innermost PASSporT; however, as has been observed
in some deployments, the original To header field value may be altered
by intermediaries to reflect changes of target. Deployments that
change the original To header field value to conceal the original
destination of the call from the ultimate recipient should note that
the original destination of a call may be preserved in the innermost
PASSporT. Future work on "div" might explore methods to implement that
sort of policy while retaining a secure chain of redirection.
The "div-o" PASSporT Type
This specification defines a "div-o" PASSporT type that uses the
"div" claim element in conjunction with the "opt" claim element. As is the case with "div"
PASSporT type, a "div-o" PASSporT is created by an authentication
service acting for a retargeting entity, but instead of generating a
separate "div" PASSporT to be conveyed alongside an original PASSporT,
the authentication service in this case embeds the original PASSporT
inside the "opt" element of the "div-o" PASSporT. The "div-o" extension
is designed for use in non-SIP or gatewayed SIP environments where the
conveyance of PASSporTs in separate Identity header fields in
impossible, such as out-of-band STIR scenarios.
The syntax of "div-o" PASSporTs is very similar to "div". A "div-o"
PASSporT header object might look as follows:
Whereas a "div" PASSporT claims set contains only the "orig", "dest",
"iat", and "div" elements, the "div-o" additionally MUST contain an
"opt" element (see ), which
encapsulates the full form of the previous PASSporT from which the call
was retargeted, triggering the generation of this "div-o". The format of
the "opt" element is identical to the encoded PASSporT format given in
.
So, for an original PASSporT claims set of the form:
If the retargeting entity is changing the target from 12155551213 to
12155551214, the new PASSporT claims set for "div-o" would look as
follows:
While in ordinary operations, it is not expected that SIP would carry
a "div-o" PASSporT, it might be possible in some gatewaying
scenarios. The resulting full form Identity header field with a "div-o"
PASSporT would look as follows:
;ppt="div-o"
]]>
Processing "div-o" PASSporTs
The authentication and verification service procedures required for
"div-o" closely follow the guidance given in Sections and , with the
major caveats being, first, that they do store or retrieve PASSporTs
via the Identity header field values of SIP requests and, second, that
they process nested PASSporTs in the "opt" claim element. But
transposing the rest of the behaviors described above to creating and
validating "div-o" PASSporTs is straightforward.
For the "div-o" PASSporT type, retargeting authentication services
that handle calls with one or more existing PASSporTs will create a
corresponding "div-o" PASSporT for each received PASSporT. Each
"div-o" PASSporT MUST contain an "opt" claim set
element with the value of the original PASSporT from which the "div-o"
was created; as specified in , the authentication service MUST
populate the "div" claim set element of the "div-o" PASSporT with the
"dest" field of the original PASSporT. Each received PASSporT may in
turn contain its own "opt" claim set element if the retargeting
authentication service is not the first in its chain. Note that if the
retargeting authentication service is handling a call with multiple
PASSporTs, which in ordinary SIP operation would result in the
construction of multiple "div" chains, it will in effect be generating
one "div-o" PASSporT per chain.
The job of a verification service is in many ways easier for
"div-o" than for "div", as the verification service has no need to
correlate the PASSporTs it receives and assemble them into chains, as
any chains in "div-o" will be nested through the "opt"
element. Nonetheless, the verification services MUST perform the same
chain validation described in to
validate that each nested PASSporT shares the same "orig" field as its
enclosing PASSporT and that the "dest" field of each nested PASSporT
corresponds to the "div" field of its enclosing PASSporT. The same
checks MUST also be performed for freshness, signature validation, and
so on. It is similarly OPTIONAL for the verification service to
determine that the "dest" claims element of the outermost PASSporT
corresponds to the called party indication of receive telephone
signaling, where such indication would vary depending on the using
protocol.
How authentication services or verification services receive or
transport PASSporTs for "div-o" is outside the scope of this document
and dependent on the using protocol.
Definition of "opt"
The presence of an "Original PASSporT" ("opt") claims set element
signifies that a PASSporT encapsulates another entire PASSporT within
it, typically a PASSporT that was transformed in some way to create the
current PASSporT. Relying parties may need to consult the encapsulated
PASSporT in order to validate the identity of a caller. "opt", as defined
in this specification, may be used by future PASSporT extensions as well
as in conjunction with "div-o".
"opt" MUST contain a quoted full-form PASSporT, as
specified by ; it
MUST NOT contain a compact form PASSporT. For an example
of a "div-o" PASSporT containing "opt", see .
"div" and Redirection
The "div" mechanism exists primarily to prevent false negatives at
verification services when an arriving SIP request, due to intermediary
retargeting, does not appear to be intended for its eventual recipient,
because the original PASSporT "dest" value designates a different
destination.
Any intermediary that assigns a new target to a request can, instead
of retargeting and forwarding the request, redirect with a 3xx
response code. In ordinary operations, a redirection poses no
difficulties for the operations of baseline STIR: when the user agent
client (UAC) receives the 3xx response, it will initiate a new request
to the new target (typically the target carried in the Contact header
field value of the 3xx), and the "dest" of the PASSporT created for the
new request will match that new target. As no impersonation attack can
arise from this case, it creates no new requirements for STIR.
However, some UACs record the original target of a call with
mechanisms like History-Info or Diversion and may want to leverage STIR to
demonstrate to the ultimate recipient that the call has been redirected
securely, that is, that the original destination was the one that sent
the redirection message that led to the recipient receiving the
request. The semantics of the PASSporT necessary for that assertion are
the same as those for the "div" retargeting cases above. The only
wrinkle is that the PASSporT needs to be generated by the redirecting
entity and sent back to the originating user agent client within the 3xx
response.
This introduces more complexity than might immediately be
apparent. In the first place, a 3xx response can convey multiple targets
through the Contact header field value; to accommodate this, the "div"
PASSporT MAY include one "dest" object array value per Contact, but if
the retargeting entity wants to keep the Contact list private from
targets, it may need to generate one PASSporT per Contact. Bear in mind
as well that the original SIP request could have carried multiple
Identity header field values that had been added by different
authentication services in the request path, so a redirecting entity
might need to generate one "div" PASSporT for each PASSporT in the
original request. Often, this will mean just one "div" PASSporT, but for
some deployment scenarios, it could require an impractical number of
combinations. But in very complex call routing scenarios, attestation of
source identity would only add limited value anyway.
Therefore, STIR-aware SIP intermediaries that redirect requests
MAY convey one or more PASSporTs in the
backwards direction within Identity header fields. These redirecting
entities will act as authentication services for "div" as described in
. This document consequently updates
to permit carrying Identity
header fields in SIP 300-class responses. It is left to the originating
user agent to determine which Identity header fields should be copied
from the 3xx into any new requests resulting from the redirection, if
any; use of these Identity header fields by entities receiving a 3xx
response is OPTIONAL.
Finally, note that if an intermediary in the response path consumes
the 3xx and explores new targets itself while performing sequential
forking, it will effectively retarget the call on behalf of the
redirecting server, and this will create the same need for "div"
PASSporTs as any other retargeted call. These intermediaries MAY also
copy PASSporTs from the 3xx response and insert them into sequential
forking requests, if appropriate.
Extending "div" to Work with Service Logic Tracking
It is anticipated that "div" may be used in concert with History-Info in some
deployments. It may not be clear from the "orig" and "dest" values which
History-Info header a given PASSporT correlates to, especially because
some of the target changes tracked by History-Info will not be reflected
in a "div" PASSporT (see ).
Therefore, an "hi" element as defined here may
appear in "div" corresponding to the History-Info header field index
parameter value. So for a History-Info header field with an index value
of "1.2.1", the claims set of the corresponding PASSporT with "div"
might look like:
Past experience has shown that there may be additional information
about the motivation for retargeting, which relying parties might consider
when making authorization decisions about a call; see, for example, the
"reason" associated with the SIP Diversion header field. Future extensions to
this specification might incorporate reasons into "div".
IANA Considerations
JSON Web Token Claims Registrations
Per this specification, IANA has added two new claims to the
"JSON Web Token Claims" registry as defined in .
"div" registration
- Claim Name:
- div
- Claim Description:
- Diverted Target of a Call
- Change Controller:
- IESG
- Reference:
- RFC 8946
"opt" registration
- Claim Name:
- opt
- Claim Description:
- Original PASSporT (in Full Form)
- Change Controller:
- IESG
- Reference:
- RFC 8946
PASSporT Type Registrations
This specification defines two new PASSporT types for the "Personal
Assertion Token (PASSporT) Extensions" registry defined in , which resides at
. They are:
- "div", as defined in .
- "div-o", as defined in .
Privacy Considerations
There is an inherent trade-off in any mechanism that tracks, in SIP
signaling, how calls are routed through a network, as routing decisions
may expose policies set by users for how calls are forwarded,
potentially revealing relationships between different identifiers
representing the same user. Note, however, that in ordinary operations,
this information is revealed to the user agent service of the called
party, not the calling party. It is usually the called party who
establishes these forwarding relationships, and if indeed some other
party is responsible for calls being forwarded to the called party, many
times the called party should likely be entitled to information about
why they are receiving these calls. Similarly, a redirecting entity who
sends a 3xx in the backwards direction knowingly shares information
about service logic with the caller's network. However, as there may be
unforeseen circumstances where the revelation of service logic to the
called party poses a privacy risk, implementers and users of this or
similar diversion-tracking techniques should understand the
trade-off.
Furthermore, it is a general privacy risk of identity mechanisms
overall that they do not interface well with anonymization services; the
interaction of STIR with anonymization services is detailed in . Any forwarding service
that acts as an anonymizing proxy may not be able to provide a secure
chain of retargeting due to the obfuscation of the originating
identity.
Also see for
further considerations on the privacy of using PASSporTs in SIP.
Security Considerations
This specification describes a security feature and is primarily
concerned with increasing security when calls are forwarded. Including
information about how calls were retargeted during the routing process
can allow downstream entities to infer particulars of the policies used
to route calls through the network. However, including this information
about forwarding is at the discretion of the retargeting entity, so if
there is a requirement to keep an intermediate called number
confidential, no PASSporT should be created for that retargeting -- the
only consequence will be that downstream entities will be unable to
correlate an incoming call with the original PASSporT without access to
some prior knowledge of the policies that could have caused the
retargeting.
Any extension that makes PASSporTs larger creates a potential
amplification mechanism for SIP-based DDoS attacks. Since diversion
PASSporTs are created as a part of normal forwarding activity, this risk
arises at the discretion of the retargeting domain; simply using 3xx
response redirections rather than retargeting (by supplying a "div" per
) mitigates the potential
impact. Under unusual traffic loads, even domains that might ordinarily
retarget requests can switch to redirection.
SIP has an inherent capability to redirect requests, including
forking them to multiple parties -- potentially, a very large number of
parties. The use of the "div" PASSporT type does not grant any
additional powers to attackers who hope to place bulk calls; if present,
the "div" PASSporT instead identifies the party responsible for the
forwarding. As such, senders of bulk unsolicited traffic are unlikely to
find the use of "div" attractive.
References
Normative References
Informative References
Keys for Examples
The following EC256 keys are used in the signing examples given in
this document. WARNING: Do not use this key pair in production
systems.
Acknowledgments
We would like to thank , , , , , , , and
for contributions to this
document.