rfc9888v1.txt   rfc9888.txt 
skipping to change at line 231 skipping to change at line 231
prevent the CPS from learning the identity of the caller (or callee) prevent the CPS from learning the identity of the caller (or callee)
to the degree possible. However, in this service provider case, the to the degree possible. However, in this service provider case, the
CPS is operated by the service provider of the callee (or an entity CPS is operated by the service provider of the callee (or an entity
operating on their behalf) and, as such, the information that appears operating on their behalf) and, as such, the information that appears
in the PASSporT is redundant with call signaling that the terminating in the PASSporT is redundant with call signaling that the terminating
party will receive anyway (see Section 10 for potential data party will receive anyway (see Section 10 for potential data
minimization concerns). Therefore, the service provider out-of-band minimization concerns). Therefore, the service provider out-of-band
framework does not attempt to conceal the identity of the originating framework does not attempt to conceal the identity of the originating
or terminating party from the CPS. or terminating party from the CPS.
An out-of-band authentication service (OOB-AS) forms a secure An OOB-AS forms a secure connection with the target CPS. This may
connection with the target CPS. This may happen at the time a call happen at the time a call is being placed or it may be a persistent
is being placed or it may be a persistent connection if there is a connection if there is a significant volume of traffic sent over this
significant volume of traffic sent over this interface. The OOB-AS interface. The OOB-AS SHOULD authenticate itself to the CPS via
SHOULD authenticate itself to the CPS via mutual TLS (see [RFC9325]) mutual TLS (see [RFC9325]) using its STIR credential [RFC8226], the
using its STIR credential [RFC8226], the same one it would use to same one it would use to sign calls; this helps mitigate the risk of
sign calls; this helps mitigate the risk of flooding that more-open flooding that more-open OOB implementations may face. Furthermore,
OOB implementations may face. Furthermore, the use of mutual TLS the use of mutual TLS prevents attackers from replaying captured
prevents attackers from replaying captured PASSporTs to the CPS. A PASSporTs to the CPS. A CPS makes its own policy decision as to
CPS makes its own policy decision as to whether it will accept calls whether it will accept calls from a particular OOB-AS, and at what
from a particular OOB-AS, and at what volumes. volumes.
A CPS can use this mechanism to authorize service providers who A CPS can use this mechanism to authorize service providers who
already hold STIR credentials to submit PASSporTs to a CPS, but already hold STIR credentials to submit PASSporTs to a CPS, but
alternative mechanisms would be required for any entities that do not alternative mechanisms would be required for any entities that do not
hold a STIR credential, including gateway or transit providers who hold a STIR credential, including gateway or transit providers who
want to submit PASSporTs. See Section 7 for more on their behavior. want to submit PASSporTs. See Section 7 for more on their behavior.
Service provider out-of-band PASSporTs do not need to be encrypted Service provider out-of-band PASSporTs do not need to be encrypted
for storage at the CPS, although the use of TLS to prevent for storage at the CPS, although the use of TLS to prevent
eavesdropping on the connection between the CPS and OOB-ASs is eavesdropping on the connection between the CPS and OOB-ASs is
skipping to change at line 369 skipping to change at line 369
The security considerations of [RFC8816] apply to this document, The security considerations of [RFC8816] apply to this document,
including concerns about potential denial-of-service vectors and including concerns about potential denial-of-service vectors and
traffic analysis. However, that specification's model focused a traffic analysis. However, that specification's model focused a
great deal on the privacy implications of uploading PASSporTs to a great deal on the privacy implications of uploading PASSporTs to a
third-party web service. This document mitigates those concerns by third-party web service. This document mitigates those concerns by
making the CPS one of the parties to call setup (or an entity making the CPS one of the parties to call setup (or an entity
contractually acting on their behalf). That said, any architecture contractually acting on their behalf). That said, any architecture
in which PASSporTs are shared with a federated or centralized CPS in which PASSporTs are shared with a federated or centralized CPS
raises potential concerns about data collection [RFC7258]. Moreover, raises potential concerns about data collection [RFC7258]. Moreover,
any additional information included in a PASSporT that is not in a PASSporT, any additional information that is not strictly
strictly redundant with the contents of a SIP request increases data redundant with the contents of a SIP request increases data
collection concerns; while baseline [RFC8225] PASSporTs only contain collection concerns; baseline [RFC8225] PASSporTs only contain
information otherwise in the SIP request. Existing and future information redundant with the SIP request. Existing and future
extensions (e.g., the "origid" field described in [RFC8588]) might extensions (e.g., the "origid" field described in [RFC8588]) might
leak further information. leak further information.
Unlike [RFC8816], this document proposes the use of STIR certificates Unlike [RFC8816], this document proposes the use of STIR certificates
to authenticate transactions with a CPS as well as signatures for CPS to authenticate transactions with a CPS as well as signatures for CPS
advertisements. This presumes an environment where STIR certificates advertisements. This presumes an environment where STIR certificates
are issued by trust anchors that are already trusted by the CPS, are issued by trust anchors that are already trusted by the CPS,
potentially to gateways and similar services. Common STIR potentially to gateways and similar services. Common STIR
deployments use Service Provider Codes (SPCs) instead of telephone deployments use SPCs instead of telephone number ranges to identify
number ranges to identify service providers today; determining service providers today; determining whether a given SPC entitles a
whether a given SPC entitles a service provider to access PASSporTs service provider to access PASSporTs for a given telephone number is
for a given telephone number is not trivial, but is a necessary not trivial, but is a necessary component of this CPS architecture.
component of this CPS architecture. Otherwise, if anyone with a STIR Otherwise, if anyone with a STIR certificate were able to publish or
certificate were able to publish or access PASSporTs for any access PASSporTs for any telephone number, this could lead to an
telephone number, this could lead to an undesirable environment where undesirable environment where effectively anyone with a STIR
effectively anyone with a STIR certificate could acquire PASSporTs certificate could acquire PASSporTs for calls in progress to any
for calls in progress to any service provider. service provider.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 3 change blocks. 
24 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.48.