< draft-ietf-stir-passport-rcd-11.txt   draft-ietf-stir-passport-rcd-12.txt >
Network Working Group C. Wendt Network Working Group C. Wendt
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: September 30, 2021 Neustar Inc. Expires: January 13, 2022 Neustar Inc.
March 29, 2021 July 12, 2021
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-11 draft-ietf-stir-passport-rcd-12
Abstract Abstract
This document extends PASSporT, a token for conveying This document extends PASSporT, a token for conveying
cryptographically-signed call information about personal cryptographically-signed call information about personal
communications, to include rich meta-data about a call and caller communications, to include rich meta-data about a call and caller
that can be signed and integrity protected, transmitted, and that can be signed and integrity protected, transmitted, and
subsequently rendered to users. This framework is intended to extend subsequently rendered to the intended called party. This framework
caller and call specific information beyond human-readable display is intended to include and extend caller and call specific
name comparable to the "Caller ID" function common on the telephone information beyond human-readable display name comparable to the
network. The JSON element defined for this purpose, Rich Call Data "Caller ID" function common on the telephone network. The JSON
(RCD), is an extensible object defined to either be used as part of element defined for this purpose, Rich Call Data (RCD), is an
STIR or with SIP Call-Info to include related information about calls extensible object defined to either be used as part of STIR or with
that helps people decide whether to pick up the phone. This signing SIP Call-Info to include related information about calls that helps
of the RCD information is also enhanced with a integrity mechanism people decide whether to pick up the phone. This signing of the RCD
that is designed to protect the authoring and transport of this information is also enhanced with a integrity mechanism that is
information between authoritative and non-authoritative parties designed to protect the authoring and transport of this information
generating and signing the Rich Call Data for support of different between authoritative and non-authoritative parties generating and
usage and content policies. signing the Rich Call Data for support of different usage and content
policies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 30, 2021. This Internet-Draft will expire on January 13, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 16 10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 16
10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 16 10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 16
10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 16 10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 16
10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 16 10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 16
11. Further Information Associated with Callers . . . . . . . . . 16 11. Further Information Associated with Callers . . . . . . . . . 16
12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 17 12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 19 12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 19
13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 19 13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 19
14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 20 14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 20
14.1. Authentication Service Behavior . . . . . . . . . . . . 20 14.1. Authentication Service Behavior . . . . . . . . . . . . 20
14.2. Verification Service Behavior . . . . . . . . . . . . . 20 14.2. Verification Service Behavior . . . . . . . . . . . . . 21
15. Using "rcd" as additional claims to other PASSporT extensions 22 15. Using "rcd" as additional claims to other PASSporT extensions 22
15.1. Procedures for applying "rcd" as claims only . . . . . . 22 15.1. Procedures for applying "rcd" as claims only . . . . . . 22
15.2. Example for applying "rcd" as claims only . . . . . . . 22 15.2. Example for applying "rcd" as claims only . . . . . . . 23
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 23 17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 24
17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 24 17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 24
17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 24 17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 24
18. Security Considerations . . . . . . . . . . . . . . . . . . . 24 18. Security Considerations . . . . . . . . . . . . . . . . . . . 25
18.1. The use of JWT Claim Constraints in delegate 18.1. The use of JWT Claim Constraints in delegate
certificates to exclude unauthorized Claims . . . . . . 25 certificates to exclude unauthorized claims . . . . . . 25
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.1. Normative References . . . . . . . . . . . . . . . . . . 25 19.1. Normative References . . . . . . . . . . . . . . . . . . 25
19.2. Informative References . . . . . . . . . . . . . . . . . 27 19.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
PASSporT [RFC8225] is a token format based on JWT [RFC7519] for PASSporT [RFC8225] is a token format based on JWT [RFC7519] for
conveying cryptographically-signed information about the parties conveying cryptographically-signed information about the parties
involved in personal communications; it is used to convey a signed involved in personal communications; it is used to convey a signed
assertion of the identity of the participants in real-time assertion of the identity of the participants in real-time
communications established via a protocol like SIP [RFC8224]. The communications established via a protocol like SIP [RFC8224]. The
STIR problem statement [RFC7340] declared securing the display name STIR problem statement [RFC7340] declared securing the display name
of callers outside of STIR's initial scope, so baseline STIR provides of callers outside of STIR's initial scope, so baseline STIR provides
no features for caller name. This specification documents an no features for caller name. This specification documents an
optional mechanism for PASSporT and the associated STIR procedures optional mechanism for PASSporT and the associated STIR procedures
which extend PASSporT objects to protect additional elements which extend PASSporT objects to protect additional elements
conveying richer information: information that is intended to be conveying richer information: information that is intended to be
rendered to an end user to assist a called party in determining rendered to assist a called party in determining whether to accept or
whether to accept or trust incoming communications. This includes trust incoming communications. This includes the name of the person
the name of the person on one side of a communications session, the on one side of a communications session, the traditional "Caller ID"
traditional "Caller ID" of the telephone network, along with related of the telephone network, along with related display information that
display information that would be rendered to the called party during would be rendered to the called party during alerting, or potentially
alerting, or potentially used by an automaton to determine whether used by an automaton to determine whether and how to alert a called
and how to alert a called party. party.
Traditional telephone network signaling protocols have long supported Traditional telephone network signaling protocols have long supported
delivering a 'calling name' from the originating side, though in delivering a 'calling name' from the originating side, though in
practice, the terminating side is often left to derive a name from practice, the terminating side is often left to derive a name from
the calling party number by consulting a local address book or an the calling party number by consulting a local address book or an
external database. SIP similarly can carry this information in a external database. SIP similarly can carry this information in a
'display-name' in the From header field value from the originating to 'display-name' in the From header field value from the originating to
terminating side, or alternatively in the Call-Info header field. terminating side, or alternatively in the Call-Info header field.
However, both are unsecured fields that really cannot be trusted in However, both are unsecured fields that really cannot be trusted in
most interconnected SIP deployments, and therefore is a good starting most interconnected SIP deployments, and therefore is a good starting
skipping to change at page 5, line 43 skipping to change at page 5, line 43
Constraints specifically guide the verifier within the certificate Constraints specifically guide the verifier within the certificate
used to sign the PASSporT for the inclusion (or exclusion) of used to sign the PASSporT for the inclusion (or exclusion) of
specific claims and their values, so that the content intended by the specific claims and their values, so that the content intended by the
signer can be verified to be accurate. signer can be verified to be accurate.
Both of these mechanisms, integrity digests and JWT Claims Both of these mechanisms, integrity digests and JWT Claims
Constraints, can be used together or separately depending on the Constraints, can be used together or separately depending on the
intended purpose. The first category of purpose is whether the rich intended purpose. The first category of purpose is whether the rich
call data conveyed by the RCD passport is pass-by-value or passed-by- call data conveyed by the RCD passport is pass-by-value or passed-by-
reference; i.e., is the information contained in the passport claims reference; i.e., is the information contained in the passport claims
and therefor integrity protected by the passport signature, or is the and therefore integrity protected by the passport signature, or is
information contained in an external resource referenced by a URI in the information contained in an external resource referenced by a URI
the RCD PASSporT. The second category of purpose is whether the in the RCD PASSporT. The second category of purpose is whether the
signer is authoritative or has responsibility for the accuracy of the signer is authoritative or has responsibility for the accuracy of the
RCD based on the policies of the eco-system the RCD PASSporTs are RCD based on the policies of the eco-system the RCD PASSporTs are
being used. being used.
The following table provides an overview of the framework for how The following table provides an overview of the framework for how
integrity should be used with RCD. (Auth represents authoritative in integrity should be used with RCD. (Auth represents authoritative in
this table) this table)
+----------+---------------------+--------------------------------+ +----------+---------------------+--------------------------------+
| Modes | No external URIs | Includes URI refs | | Modes | No external URIs | Includes URI refs |
+----------+---------------------+--------------------------------+ +----------+---------------------+--------------------------------+
| Auth | 1: No integrity req | 2: RDC Integrity | | Auth | 1: No integrity req | 2: RDC Integrity |
+----------+---------------------+--------------------------------+ +----------+---------------------+--------------------------------+
| Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. | | Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. |
+----------+---------------------+--------------------------------+ +----------+---------------------+--------------------------------+
The first and simplest mode is exclusively for when all RCD content The first and simplest mode is exclusively for when all RCD content
is directly included as part of the claims (i.e. no external is directly included as part of the claims (i.e. no external
reference URIs are included in the content, for example, "photo" or reference URIs are included in the content) and when the signer is
"logo" properties that aren't directly encoded into the JSON of the authoritative over the content. In this mode, integrity protection
jCard) and when the signer is authoritative over the content. In is not required and the set of claims is simply protected by the
this mode, integrity protection is not required and the set of claims signature of the standard PASSporT [RFC8225] and SIP identity header
is simply protected by the signature of the standard PASSporT [RFC8224] procedures. The second mode is an extension of the first
[RFC8225] and SIP identity header [RFC8224] procedures. The second where the signer is authoritative and a "rcd" claim contents include
mode is an extension of the first where the signer is authoritative a URI identifying external resources. In this mode, an RCD Integrity
and a "rcd" claim contents include a URI identifying external or "rcdi" claim MUST be included. This integrity claim is defined
resources. In this mode, an RCD Integrity or "rcdi" claim MUST be later in this document and provides a digest of the "rcd" claim
included. This integrity claim is defined later in this document and content so that, particularly for the case where there are URI
provides a digest of the "rcd" claim content so that, particularly references in the RCD, the content of that RCD can be comprehensively
for the case where there are URI references in the RCD, the content validated that it was received as intended by the signer of the
of that RCD can be comprehensively validated that it was received as PASSporT.
intended by the signer of the PASSporT.
The third and fourth mode cover cases where there is a different The third and fourth mode cover cases where there is a different
authoritative entity responsible for the content of the RCD, separate authoritative entity responsible for the content of the RCD, separate
from the signer of the PASSporT itself, allowing the ability to have from the signer of the PASSporT itself, allowing the ability to have
forward control at the time of the creation of the certificate of the forward control at the time of the creation of the certificate of the
allowed or vetted content included in or referenced by the RCD claim allowed or vetted content included in or referenced by the RCD claim
contents. The primary framework for allowing the separation of contents. The primary framework for allowing the separation of
authority and the signing of PASSporTs by non-authorized entities is authority and the signing of PASSporTs by non-authorized entities is
detailed in [I-D.ietf-stir-cert-delegation] although other cases may detailed in [I-D.ietf-stir-cert-delegation] although other cases may
apply. As with the first and second modes, the third and fourth apply. As with the first and second modes, the third and fourth
skipping to change at page 10, line 48 skipping to change at page 10, line 48
included to avoid any possibility of substitution or insertion included to avoid any possibility of substitution or insertion
attacks that may be possible to avoid integrity detection, even attacks that may be possible to avoid integrity detection, even
though unlikely. Each URI referenced in the jCard array string MUST though unlikely. Each URI referenced in the jCard array string MUST
have a corresponding JSON pointer string key and digest value. have a corresponding JSON pointer string key and digest value.
In the case of the use of a "jcl" URI reference to an external jCard, In the case of the use of a "jcl" URI reference to an external jCard,
the procedures are similar to "jcd" with the exception and the minor the procedures are similar to "jcd" with the exception and the minor
modification to JSON pointer, where "/jcl" is used to refer to the modification to JSON pointer, where "/jcl" is used to refer to the
external jCard array string and any following numeric array indexes external jCard array string and any following numeric array indexes
added to the "jcl" (e.g. "/jcl/1/2/3") are treated as if the added to the "jcl" (e.g. "/jcl/1/2/3") are treated as if the
externally referenced jCard was part of the overall "rcd" claim JSON externally referenced jCard was directly part of the overall "rcd"
object. The following example illustrates a "jcl" version of the claim JSON object. The following example illustrates a "jcl" version
above "jcd" example. of the above "jcd" example.
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets", "nam": "Q Branch Spy Gadgets",
"jcl": "https://example.com/qbranch.json" "jcl": "https://example.com/qbranch.json"
}, },
"rcdi": { "rcdi": {
"/jcl": "sha256-30SFLGHL40498527", "/jcl": "sha256-30SFLGHL40498527",
"/jcl/1/3/3": "sha256-12938918VNJDSNCJ", "/jcl/1/3/3": "sha256-12938918VNJDSNCJ",
"/jcl/1/4/3": "sha256-VNJDSNCJ12938918", "/jcl/1/4/3": "sha256-VNJDSNCJ12938918",
"/jcl/1/5/3": "sha256-4049852730SFLGHL" "/jcl/1/5/3": "sha256-4049852730SFLGHL"
skipping to change at page 12, line 17 skipping to change at page 12, line 17
3. For any URI referenced content, the content can either be a 3. For any URI referenced content, the content can either be a
string as in jCard JSON objects or binary content. For example, string as in jCard JSON objects or binary content. For example,
image and audio files contain binary content. If the content is image and audio files contain binary content. If the content is
binary format it should be Base64 encoded to create a string, binary format it should be Base64 encoded to create a string,
otherwise the direct string content of the file is used to create otherwise the direct string content of the file is used to create
the digest. the digest.
6.2. JWT Claim Constraint for "rcd" claims only 6.2. JWT Claim Constraint for "rcd" claims only
For the third mode described in the integrity overview section of For the third mode described in the integrity overview section of
this document, where only JWT Claim Constraint for "rcd" claims, this document, where only JWT Claim Constraint for "rcd" claims
without an "rcdi" claim, is required, the procedure should be, when without an "rcdi" claim is required, the procedure should be, when
creating the certificate to include a constraint on inclusion of the creating the certificate, to include a JWT Claim Constraint on
"rcd" claim as well as the contents of that claim. inclusion of an "rcd" claim as well as the contents of the certified
"rcd" claim.
The certificate JWT Claims Constraint MUST include the following: The certificate JWT Claims Constraint MUST include the following:
o a "mustInclude" for the "rcd" claim and a "permittedValues" equal o a "mustInclude" for the "rcd" claim and a "permittedValues" equal
to the created "rcd" claim value string. to the created "rcd" claim value string.
The "permitedValues" for the "rcd" claim may contain multiple The "permitedValues" for the "rcd" claim may optionally contain
entries, to support the case where the certificate holder is multiple entries, to support the case where the certificate holder is
authorized to use different sets of rich call data. authorized to use different sets of rich call data.
7. JWT Claim Constraint usage for "rcd" and "rcdi" claims 7. JWT Claim Constraint usage for "rcd" and "rcdi" claims
The integrity overview section of this document describes a fourth The integrity overview section of this document describes a fourth
mode where both "rcdi" and JWT Claim Constraints is used. The use of mode where both "rcdi" and JWT Claim Constraints is used. The use of
this mode implies the signing of an "rcdi" claim is required to be this mode implies the signing of an "rcdi" claim is required to be
protected by the authoritative certificate creator using JWT Claims protected by the authoritative certificate creator using JWT Claims
Constraints in the certificate. The intension of the use of both of Constraints in the certificate. The intension of the use of both of
these mechanisms is to constrain the signer to construct the "rcd" these mechanisms is to constrain the signer to construct the "rcd"
and "rcdi" claims with the "rcd" jCard object including reference and "rcdi" claims with the "rcd" jCard object including reference
external content via URI. Once both the contents of the "rcd" claim external content via URI. Once both the contents of the "rcd" claim
and any linked content is certified by the party that is and any linked content is certified by the party that is
authoritative for the certificate being created and the construction authoritative for the certificate being created and the construction
of the "rcdi" claim is complete, the "rcdi" claim is linked to the of the "rcdi" claim is complete, the "rcdi" claim is linked to the
STIR certificate associated with the signature in the PASSporT via STIR certificate associated with the signature in the PASSporT via
JWT Claim Constraints as defined in [RFC8226] Section 8. It should JWT Claim Constraints as defined in [RFC8226] Section 8. It should
be recognized that the "rcdi" set of digests is intended to be unique be recognized that the "rcdi" set of digests is intended to be unique
for only a specific combination of "rcd" content and URI referenced for only a specific combination of "rcd" content and URI referenced
external content, and therefore provides the integrity mechanism for external content, and therefore provides a robust integrity mechanism
an authentication service being performed by a non-authoritative for an authentication service being performed by a non-authoritative
party. party. This would often be associated with the use of delegate
certificates [I-D.ietf-stir-cert-delegation] for the signing of calls
by the calling party directly as an example, even though they aren't
considered an "authorized party" in the STIR certificate eco-system.
The certificate JWT Claims Constraint MUST include both of the The certificate JWT Claims Constraint MUST include both of the
following: following:
o a "mustInclude" for the "rcd" claim, which simply constrains the o a "mustInclude" for the "rcd" claim, which simply constrains the
fact that an "rcd" should be included if there is a "rcdi" fact that an "rcd" should be included if there is a "rcdi"
o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
to the created "rcdi" claim value string. to the created "rcdi" claim value string.
skipping to change at page 16, line 37 skipping to change at page 16, line 37
Compact form of an "rcd" PASSporT claim has some restrictions but Compact form of an "rcd" PASSporT claim has some restrictions but
mainly follows standard PASSporT compact form procedures. For re- mainly follows standard PASSporT compact form procedures. For re-
construction of the "nam" claim the string for the display-name in construction of the "nam" claim the string for the display-name in
the From header field. For re-construction of the "jcl", the Call- the From header field. For re-construction of the "jcl", the Call-
Info header as with purpose "jcard" defined in Info header as with purpose "jcard" defined in
[I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be
used as part of compact form. used as part of compact form.
10.2. Compact form of the "rcdi" PASSporT claim 10.2. Compact form of the "rcdi" PASSporT claim
Compact form of an "rcdi" PASSPorT claim is not supported, so if Compact form of an "rcdi" PASSporT claim is not supported, so if
"rcdi" is required compact form should not be used. "rcdi" is required compact form should not be used.
10.3. Compact form of the "crn" PASSporT claim 10.3. Compact form of the "crn" PASSporT claim
Compact form of a "crn" PASSporT claim shall be re-constructed using Compact form of a "crn" PASSporT claim shall be re-constructed using
the "call-reason" parameter of a Call-Info header as defined by the "call-reason" parameter of a Call-Info header as defined by
[I-D.ietf-sipcore-callinfo-rcd]. [I-D.ietf-sipcore-callinfo-rcd].
11. Further Information Associated with Callers 11. Further Information Associated with Callers
skipping to change at page 19, line 20 skipping to change at page 19, line 20
A third-party PASSporT contains an "iss" element to distinguish its A third-party PASSporT contains an "iss" element to distinguish its
PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs
are signed with credentials that do not have authority over the are signed with credentials that do not have authority over the
identity that appears in the "orig" element of the PASSporT claims. identity that appears in the "orig" element of the PASSporT claims.
The presence of "iss" signifies that a different category of The presence of "iss" signifies that a different category of
credential is being used to sign a PASSporT than the [RFC8226] credential is being used to sign a PASSporT than the [RFC8226]
certificates used to sign STIR calls; it is instead a certificate certificates used to sign STIR calls; it is instead a certificate
that identifies the source of the "rcd" data. How those credentials that identifies the source of the "rcd" data. How those credentials
are issued and managed is outside the scope of this specification; are issued and managed is outside the scope of this specification;
the value of "iss" however MUST reflect the Subject Name field of the the value of "iss" however MUST reflect the Subject Name field of the
certificate used to sign a third-party PASSporT. Relying parties in certificate used to sign a third-party PASSporT. The explicit
STIR have always been left to make their own authorization decisions mechanism for reflecting the Subject Name field of the certificate is
about whether to trust the signers of PASSporTs, and in the third- out of scope of this document and left to the certificate governance
party case, where an entity has explicitly queried a service to policies that define how to map the "iss" value in the PASSporT to
acquire the PASSporT object, it may be some external trust or the Subject Name field in the certificate. Relying parties in STIR
business relationship that induces the relying party to trust a have always been left to make their own authorization decisions about
PASSporT. whether to trust the signers of PASSporTs, and in the third-party
case, where an entity has explicitly queried a service to acquire the
PASSporT object, it may be some external trust or business
relationship that induces the relying party to trust a PASSporT.
An example of a Third Party issued PASSporT claims object is as An example of a Third Party issued PASSporT claims object is as
follows. follows.
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12025551001"]}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"iss":"Zorin Industries", "iss":"Zorin Industries",
"rcd":{"nam":"James St. John Smythe"} } "rcd":{"nam":"James St. John Smythe"} }
skipping to change at page 20, line 4 skipping to change at page 20, line 7
party cases, this admits of some complexity: the Communications party cases, this admits of some complexity: the Communications
Service Provider (CSP) to which a number was assigned might in turn Service Provider (CSP) to which a number was assigned might in turn
delegate the number to a reseller, who would then sell the number to delegate the number to a reseller, who would then sell the number to
an enterprise, in which case the CSP might have little insight into an enterprise, in which case the CSP might have little insight into
the caller's name. In third party cases, a caller's name could the caller's name. In third party cases, a caller's name could
derive from any number of data sources, on a spectrum between public derive from any number of data sources, on a spectrum between public
data scraped from web searches to a direct business relationship to data scraped from web searches to a direct business relationship to
the caller. As multiple PASSporTs can be associated with the same the caller. As multiple PASSporTs can be associated with the same
call, potentially a verification service could receive attestations call, potentially a verification service could receive attestations
of the caller name from multiple sources, which have different levels of the caller name from multiple sources, which have different levels
of granularity or accuracy. Therefore, PASSporTs that carry "rcd" of granularity or accuracy. Therefore, third-party PASSporTs that
data MUST also carry an indication of the relationship of the carry "rcd" data MUST also carry an indication of the relationship of
generator of the PASSporT to the caller in the form of the "iss" the generator of the PASSporT to the caller in the form of the "iss"
claim. As stated in the previous section, the use of "iss" MUST claim. As stated in the previous section, the use of "iss" MUST
reflect the Subject Name of the certificate used to sign a third- reflect the Subject Name of the certificate used to sign a third-
party PASSporT to represent that relationship. party PASSporT to represent that relationship.
14. Using "rcd" in SIP 14. Using "rcd" in SIP
This section specifies SIP-specific usage for the "rcd" claim in This section specifies SIP-specific usage for the "rcd" claim in
PASSporT, and in the SIP Identity header field value. Other using PASSporT, and in the SIP Identity header field value. Other using
protocols of PASSporT may define their own usages for the "rcd" protocols of PASSporT may define their own usages for the "rcd"
claim. claim.
skipping to change at page 20, line 30 skipping to change at page 20, line 33
An authentication service creating a PASSporT containing a "rcd" An authentication service creating a PASSporT containing a "rcd"
claim MAY include a "ppt" for "rcd" or not. Third-party claim MAY include a "ppt" for "rcd" or not. Third-party
authentication services following the behavior in Section 12.1 MUST authentication services following the behavior in Section 12.1 MUST
include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any
SIP authentication services MUST add a "ppt" parameter to the SIP authentication services MUST add a "ppt" parameter to the
Identity header containing that PASSporT with a value of "rcd". The Identity header containing that PASSporT with a value of "rcd". The
resulting Identity header might look as follows: resulting Identity header might look as follows:
Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9
dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt
w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=;
info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt=rcd info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;
ppt="rcd"
This specification assumes that by default, a SIP authentication This specification assumes that by default, a SIP authentication
service derives the value of "rcd", specifically only for the "nam" service derives the value of "rcd", specifically only for the "nam"
key value, from the display-name component of the From header field key value, from the display-name component of the From header field
value of the request, alternatively for some calls this may come from value of the request, alternatively for some calls this may come from
the P-Asserted-ID header. It is however a matter of authentication the P-Asserted-ID header. It is however a matter of authentication
service policy to decide how it populates the value of "nam" key, service policy to decide how it populates the value of "nam" key,
which MAY also derive from other fields in the request, from customer which MAY also derive from other fields in the request, from customer
profile data, or from access to external services. If the profile data, or from access to external services. If the
authentication service generates a "rcd" claim containing "nam" with authentication service generates a "rcd" claim containing "nam" with
skipping to change at page 25, line 11 skipping to change at page 25, line 25
Since computation of "rcdi" digests for URIs requires the loading of Since computation of "rcdi" digests for URIs requires the loading of
referenced content, it would be best practice to validate that referenced content, it would be best practice to validate that
content at the creation of the "rcdi" or corresponding JWT claim content at the creation of the "rcdi" or corresponding JWT claim
constraint value by checking for content that may cause issues for constraint value by checking for content that may cause issues for
verification services or that doesn't follow the behavior defined in verification services or that doesn't follow the behavior defined in
this document, e.g. unreasonably sized data, the inclusion of this document, e.g. unreasonably sized data, the inclusion of
recursive URI references, etc. recursive URI references, etc.
18.1. The use of JWT Claim Constraints in delegate certificates to 18.1. The use of JWT Claim Constraints in delegate certificates to
exclude unauthorized Claims exclude unauthorized claims
While this can apply to any PASSporT that is signed with a STIR While this can apply to any PASSporT that is signed with a STIR
Delegate Certificates [I-D.ietf-stir-cert-delegation], it is Delegate Certificates [I-D.ietf-stir-cert-delegation], it is
important to note that when constraining PASSporTs to include important to note that when constraining PASSporTs to include
specific claims or contents of claims, it is also important to specific claims or contents of claims, it is also important to
consider potential attacks by non-authorized signers that may include consider potential attacks by non-authorized signers that may include
other potential PASSporT claims that weren't originally vetted by the other potential PASSporT claims that weren't originally vetted by the
authorized entity providing the delegate certificate. The use of JWT authorized entity providing the delegate certificate. The use of JWT
claims constraints as defined in [I-D.housley-stir-enhance-rfc8226] claims constraints as defined in [I-D.housley-stir-enhance-rfc8226]
for preventing the ability to include claims beyond the claims for preventing the ability to include claims beyond the claims
skipping to change at page 25, line 39 skipping to change at page 26, line 7
19.1. Normative References 19.1. Normative References
[I-D.housley-stir-enhance-rfc8226] [I-D.housley-stir-enhance-rfc8226]
Housley, R., "Enhanced JWT Claim Constraints for STIR Housley, R., "Enhanced JWT Claim Constraints for STIR
Certificates", draft-housley-stir-enhance-rfc8226-00 (work Certificates", draft-housley-stir-enhance-rfc8226-00 (work
in progress), January 2021. in progress), January 2021.
[I-D.ietf-sipcore-callinfo-rcd] [I-D.ietf-sipcore-callinfo-rcd]
Wendt, C. and J. Peterson, "SIP Call-Info Parameters for Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
Rich Call Data", draft-ietf-sipcore-callinfo-rcd-01 (work Rich Call Data", draft-ietf-sipcore-callinfo-rcd-02 (work
in progress), November 2020. in progress), February 2021.
[I-D.ietf-stir-cert-delegation] [I-D.ietf-stir-cert-delegation]
Peterson, J., "STIR Certificate Delegation", draft-ietf- Peterson, J., "STIR Certificate Delegation", draft-ietf-
stir-cert-delegation-03 (work in progress), July 2020. stir-cert-delegation-04 (work in progress), February 2021.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006, DOI 10.17487/RFC4627, July 2006,
skipping to change at page 27, line 14 skipping to change at page 27, line 29
19.2. Informative References 19.2. Informative References
[ATIS-1000074] [ATIS-1000074]
ATIS/SIP Forum NNI Task Group, "Signature-based Handling ATIS/SIP Forum NNI Task Group, "Signature-based Handling
of Asserted information using toKENs (SHAKEN) of Asserted information using toKENs (SHAKEN)
<https://access.atis.org/apps/group_public/ <https://access.atis.org/apps/group_public/
download.php/32237/ATIS-1000074.pdf>", January 2017. download.php/32237/ATIS-1000074.pdf>", January 2017.
[I-D.ietf-stir-oob] [I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band Rescorla, E. and J. Peterson, "Secure Telephone Identity
Architecture and Use Cases", draft-ietf-stir-oob-07 (work Revisited (STIR) Out-of-Band Architecture and Use Cases",
in progress), March 2020. draft-ietf-stir-oob-07 (work in progress), March 2020.
[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>.
Authors' Addresses Authors' Addresses
Chris Wendt Chris Wendt
Comcast Comcast
 End of changes. 24 change blocks. 
78 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/