Re: [stir] Roman Danyliw's Discuss on draft-ietf-stir-passport-rcd-23: (with DISCUSS and COMMENT)

[Chris Wendt <[e-mail]>]

Hi Roman,

Thanks for the very comprehensive review, comments and proposed resolutions inline.

To the rest of the working group, I don’t believe i changed any of the intent or normative intent of the document, but please pay attention to the changes to keep me honest.  There is one exception in Section 11 where i reduced the normative requirement that is discussed below.  Section 11 hasn’t been the focus of much of the discussions in the working group and the relationship aspect was really not addressed, so i think this is not going to be a much debated change, but wanted to be clear about the change.

Thanks!!

-Chris

> On Nov 29, 2022, at 9:25 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-stir-passport-rcd-23: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** 5.*. Inconsistent requirements for URIs
> 
> -- icn: appears to be any URI per Section 5.1.3.  This would make gopher://,
> ftp://, https:// all equally valid.  These have different security
> characteristics.
> 
> -- jcd: per Section 5.1.4 “is intended to directly match the Call-Info header
> field value defined in [I-D.ietf-sipcore-callinfo-rcd].” Section 4 of that
> document says it “MUST define the use HTTPS or a transport that can validate
> the integrity of the source of the resource as well as the transport channel
> through which the resource is retrieved”.
> 
> -- jcl: is an HTTPS URL (per Section 5.1.5)
> 
> Why are these different?  Support different levels of transport security?

You are correct, i fixed “icn” to specifically be an HTTPS URL vs generic URI.  jcd is not a URI, it’s a directly included JSON jcard object in the “rcd" claim.

> 
> ** Section 6.
>   Implementations MAY support additional algorithms, but MUST NOT
>   support known weak algorithms such as MD5 or SHA-1.
> 
> -- How would these additional algorithms names be canonicalized in a way that
> is interoperable?
> 
> -- How does one assess “known weak algorithms”?  What is the vetting process?

The intent is that this would be revisited in future updates to the document in IETF.  I changed the subsequent sentence from:
"In the future, the list of algorithms may be re-evaluated based on security best practices.”
to:
“Future specifications may update the list of algorithms and how they are referenced based on future security best practices."

> 
> -- (COMMENT) Please provide references to MD5 and SHA-1.

fixed

> 
> ** Section 6.*
> 
> -- Why is rcdi supported for elements that are protected by the signature
> (e.g., nam, apn, the whole jcd claim)?  Under what circumstance would it be
> used?

We did discuss this, the decision was taken to keep it open since you can accomplish the integrity protection either via just constraining the “rcdi” digests over all or parts of the rcd claims, or by using JWTClaimConstraints on the claims themselves. I don’t believe the logic for resolving the integrity or constraints makes it more complex even if there is extraneous nam/apn/jcd included so ultimately didn’t restrain it to only claim keys that include referenced content.  We also make the argument in the document that size of the JSON pointer or constraints object may be a consideration, also digests that are consistent across many PASSporTs but may have different individual elements might be a consideration (e.g. constant icn for corporation, but different employee names perhaps).  We just didn’t want to make too many assumptions and provide flexibility, without too much implementation cost.  You could make the argument having specific rules per key could be considered more complex.

> 
> -- What would it mean for the rcdi to be invalid but the signature to be valid?

I assume you mean that for the rcdi to be invalid the digest does not match the “rcdi” constrained value in the certificate.  This would be a case where the customer that is signing the RCD PASSPorT but used values that were different than the authoritative provider of the delegate certificate with the “rcdi” constrained and therefore, the PASSporT verification should be consider failed.

> 
> ** Section 6.1.3.
>   The use of
>   digest for the "/jcd" corresponding to the entire jCard array string
>   can be included as a redundant mechanism to avoid any possibility of
>   substitution, insertion attacks, or other potential techniques that
>   may be possible to avoid integrity detection.
> 
> What attacks are possible if there is NO digest for /jcd?  Under what
> circumstances is this redundancy necessary?

This is the point of the use of integrity/constraints, in the modes where the signer is not authoritative, you need either integrity mechanism or constraint of the /jcd or constraint of the digest of the /jcd.  The attack is that you delegate a certificate without integrity or constraint and the non-authoritative signer of the RCD information changes the information and signs it.  It is a bit different than the traditional man-in-middle attack that signature protects by itself.

> 
> ** Section 6.1.4.  To have parity between the jcd and jcl, the following
> additional guidance is needed in this section: -- an integrity digest MUST be
> provided for the jcl -- all URIs referenced in the jCard MUST also have an in
> integrity digest

Added

> 
> ** Section 5.1.1 and 8.  The specification of “nam” is ambiguous.

See below

> -- Section 5.1.1. which specifies the “nam” claim makes no mentions of RFC3261

Fixed and added reference to 3325 for PAID header also

> -- Section 8 says “The key syntax of ‘nam’ follows the display-name ABNF given
> in [RFC3261].”
> 
> MUST ‘nam” conform to the ABNF of RFC3261?

Yes, and i rearranged the text to state this in section 5.1.1 vs 8 to solve what i think is the concern that those rules should be defined upfront, which i agree.

> 
> ** Section 8.2.  This section provides no guidance on how to handle rcdi values
> for non-URI values (e.g., nam)
> 
> ** Section 8.2
>   Consequently, if URIs with contents covered by integrity
>   digests are passed to another entity, the corresponding integrity
>   digest MUST also be included, for example by passing the PASSporT.
>   Entities that pass on the content without the URI do not have to pass
>   on the corresponding integrity digest.
> 
> What is the context for “passing” information?  Is that application specific
> behavior?  Why would one pass the URI+downloaded content as opposed to just the
> downloaded content?
> 
> ** Section 8.2
>   If there is any issue with completing the integrity verification
>   procedures for referenced external content, including HTTP or HTTPS
>   errors, the referenced content MUST be considered not verified.
> 
> What is the operator supposed to do with data that is “not verified”?

For all of above, i agree there is multiple concepts trying to be described and i didn’t include the fundamental procedure for verification, i rearranged this section and added text to describe that.

The points about what happens beyond verification was meant to be a discussion of, for example, if you move RCD information outside of the RCD PASSporT, like to a different PASSporT or into call-info or move referenced content to a different CDN with new URLs. These are techniques that have been discussed/defined outside of this spec.  I think it is likely best to remove this text because these are topics that aren’t directly related to the process of verification.

> 
> ** Section 9.1
>   The re-construction of the "nam" claim, if using SIP protocol, should
>   use the display-name string in the From header field.
> 
> If the display-name isn’t used, how should the “nam” claim be reconstructed?

In general, we wanted to keep this spec open to be used in other communications protocols and would expect future specifications to provide those details.  I added the following statement to the overview section "In general, PASSporT {{RFC8225}} has been defined to be a communications protocol independent technology, but it's initial usage as detailed in {{RFC8224}} is with the SIP protocol {{RFC3261}}.  There are many SIP specific references and definitions in this document, but future specifications may extend the usage of RCD PASSporTs and claims to other protocol specific usage and definitions."

> 
> ** Section 10.2
>   This may include accepting a
>   valid signature over a PASSporT even if it is signed with a
>   credential that does not attest authority over the identity in the
>   "orig" claim of the PASSporT, provided that the verification service
>   has some other reason to trust the signer.  No further guidance on
>   verification service authorization policy is given here.
> 
> I’m likely misunderstanding something in the STIR architecture.  Why is this
> text consistent with the validation practices of the first-party model.  This
> text seems to suggest that PASSports with arbitrary “orig”-s could be accepted
> regardless of the cryptographic based security mechanisms presented as the
> basis for the security model of this token.

The idea is that there is an implied trust model that has evolved in STIR (although not different than X.509 more generally) that you trust the information that is signed based on the signer identified in certificate, so for example in SHAKEN eco-system there is certificates that are trusted to validate association with the “orig” telephone number, because they chain to accepted roots as part of the authoritative SHAKEN eco-system.  For 3rd party verification it’s possible that parties may sign RCD information with other certificate credentials but it also includes an orig number but it shouldn’t be implied that this is authoritative in the 3rd party “iss” claim cases.  This is specifically for cases that a 3rd party provides information associated with TN but is not directly associated with the authoritative party over that TN.

> 
> ** Section 10 and 11.  The iss value doesn’t appear to be consistently
> specified. (a) Section 10.1 says “the value of "iss" however MUST reflect the
> Subject of the certificate used to sign a third-party PASSporT.”
> 
> (b) Section 10.1 depicts an example of ‘"iss":"Zorin Industries”’
> 
> -- Section 11 says “Therefore, third-party PASSporTs that carry "rcd" data MUST
> also carry an indication of the relationship of the generator of the PASSporT
> to the caller in the form of the "iss" claim.
> 
> The constraints of iss as described and depicted in (a) and (b) in Section 10.1
> are not consistent with (c) in Section 11.  In what way is “Zorin Industries”
> suggesting the “relationship of the generator”?

Jon and I spoke about this, this text hasn’t changed much for a while, but do agree we didn’t address the “relationship” part of the requirement, so i made a change in section 11 to modify/replace the language at the end of the paragraph to:

"Therefore, third-party PASSporTs that carry "rcd" data are RECOMMENDED to also carry an indication of the identity of the generator of the PASSporT in the form of the ‘iss’ claim."

More specific requirements can be addressed in future specifications or industry specific specifications.

> 
> ** Section 12.2
>   The general
>   verification proceedures defined in Section 8.1 should be followed,
>   but the following paragraphs describe some of the specifics needed to
>   implement a verification service using the SIP protocol.
> 
> In additional to the Section 8.1 guidance, the guidance in Section 10.2 seems
> applicable too.

Yes, i actually added this to 8.1 to fully cover this.

> 
> ** Section 13.1
>   The Verification service that receives the PASSporT, if it supports
>   this specification and chooses to, should interpret the "rcd" claim
>   as simply just an additional claim intended to deliver and/or
>   validate delivered Rich Call Data.
> 
> Please be clear on what sections govern a “rcd” claim relevant here.  Is it
> just Section 5?

Yes, clarified it includes “rcd”, “rcdi”, “crn” claims

> 
> ** Section 13.2.
>   Protected Header
>   {
>      "alg":"ES256",
>      "typ":"passport",
>      "ppt":"shaken",
>      "x5u":"https://cert.example.org/passport.cer"
>   }
> 
>   A Verification Service that supports "rcd" and "shaken" PASSporT
>   extensions is able to receive the above PASSporT and interpret both
>   the "shaken" claims as well as the "rcd" defined claim.
> 
> The text states that both the “rcd” and “shaken” Passport extensions are being
> used.  However, in the “ppt” claim only “shaken” is being named.  Section 8.1
> of RFC8225 states that “If it is necessary for an extension to PASSporT to
> require that a relying party support a particular extended claim or set of
> claims in the PASSporT object, it can do so by specifying a "ppt" element for
> the PASSporT JOSE Header.”  How is support for two simultaneous extensions
> supposed to be represented in the ppt header?

The intention is that only one “ppt” extension is supported, but STIR verification services that understand the verification of both “shaken” and “rcd” PASSporTs can use that ability if claims from other extensions appear in a particular PASSporT, the typical example being that a “shaken” PASSporT has some of the claims defined in “rcd”.  This also means the sender should have no expectation that the “rcd” claims will be able to be verified by all “shaken” supporting verification services. I cleaned up the wording a bit.

> 
> ** Section 17.  Please discuss that the dereferencing of URIs will (a)
> depending on the scheme leak, information to an on-path attacker about the
> referenced content; and (b) provide the off-path hosting providing of the
> reference content some insight into the calling patterns.
> 

Added, we do address that SIP by its nature does have a level of information that is clear-text that can use transport level security to protect between hops, but is an acknowledged practice that network hops will have access to that information as part of standard routing of calls.

> ** Section 17.
>   The process of signing information contained in a "rcd" PASSporT,
>   whether the identities, identifiers, alternate identities or
>   identifiers, images, logos, physical addresses, or otherwise should
>   follow some vetting process in which an authoritative entity should
>   follow an appropriate consistent policy defined and governed by the
>   eco-system using RCD and the STIR framework.
> 
> The lack normative language and reliance on “should” seems to allow for no
> vetting and an inconsistent process with the RCD and STIR framework.  In my
> understanding of the STIR ecosystem this would violate a basic premise of the
> ecosystem

We have discussed this on numerous occasions, i hesitate to make it a MUST in the document at this late stage, but do believe this is sort of obvious statement.

> 
> ** Section 17.
> (a) The use of JWTClaimConstraints, a mechanism defined in [RFC8226] and
>   extended in [RFC9118] to constrain any of the RCD information in the
>   public certificate by including that information in the certificate,
>   depending on the availability in the deployment of the PKI system,
>   may present a privacy issue.
> (b) The use of "rcdi" claim and digests for
>   representing JWT claim contents is RECOMMENDED for the prevention of
>   the exposure of that information through the certificates which are
>   often publically accessible and available.
> 
> -- Per (a), please explicitly state what that privacy issue might be.  Is it
> that the claim constraints might encode sensitive permittedValues?  Is the
> existence of claims sensitive?

The claims would be explicitly included in the constraint information including information about the calling party. Since the constraints are encoded in a publicly available certificate, may have a path that this information is generally available by just mining through certificate repositories.

> 
> -- Per (b), in what way does rcdi/digest “represent JWT claim content” and
> prevent exposure of information in the certificate?

If only the digest of the rcd information is constrained and included in the public certificate, then this vector of leaking information is removed.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Vincent Roca for the SECDIR review
> 
> ** This document makes multiple normative dependencies to
> draft-ietf-sipcore-callinfo-rcd.  While this document has been adopted by
> SIPCORE, it appears to have expired multiple times.  Is it expected to
> complete?  Is there acceptable risk here?  Is the reference stable enough to
> publish this document (and let it sit in the MISREF queue)?
> 
> ** Section 1.   Editorial.
> 
> As such, based on some use-cases, this document extends ...
> 
> What use cases are being referenced here?

I changed it to just say “This document extends…"

> 
> ** Section 4.
>   This document defines a mechanism
>   that allows for a direct or indirect party that controls the policy ...
> 
> Should “controls the policy” be “enforces the policy” to distinguish between
> the entity that might define it and those that might implement it (but can’t
> change it)?

Yes correct “enforces” is better word

> 
> ** Section 4.
>   The RCD integrity mechanism is
>   a process of generating a sufficiently strong cryptographic digest
>   for each resource ...
> 
> Is there anything to read into saying “sufficiently strong cryptographic
> digest” instead of just “cryptographic digest”?  Is there some gradient of
> security being suggested?

Agree, cryptographic digest is sufficient.

> 
> ** Section 5.1.2
> 
>   How the signer determines
>   that a user is authorized to present the number in question is a
>   policy decision outside the scope of this document, however, the
>   vetting of the alternate presentation number should follow the same
>   level of vetting as telephone identities or any other information
>   contained in an "rcd" PASSporT or "rcd" claims.
> 
> Is this text implicitly saying that the apn value needs to be in the TNAuthList
> of the signing certificate so that the verifier can validated that this is a
> legitimate apn?  Otherwise, can’t arbitrary apn values be included and the
> verifier wouldn’t know.

Yes and no, the details are specific to the scenario. As the text states we punt this to policies of association of TN’s to either the SPC or the TN/TN block. The expectation is that further specifications will clarify these policies if necessary.

> 
> ** Section 5.1.3.
> 
>   Note that [I-D.ietf-sipcore-callinfo-rcd] extends the specific usage
>   of "icon" in SIP in the context of the larger rich call data
>   framework with specific guidance on referencing images and image
>   types, sizes and formats.
> 
> In what way does this guidance constrain the definition of “icn”?  I’m not sure
> why this text is here.

I intended to simply say that the formats of the icons are not addressed in this document.  Similarly, 3261 call-info has “icon” and states nothing about this also, but we recognized as a working group that this has some practical interop problems that needed some level of guidance, so therefore the note.  We aren’t necessarily intending to constrain, vs more best practices guidance in the other document.  It’s simply a note with no normative implications. 

> 
> ** Section 5.1.5.  Mixing normative language is confusion.  Recommend:
> OLD
>   The
>   "jcd" or "jcl" keys MAY only appear once in the "rcd" claim but MUST
>   be mutually exclusive.
> 
> NEW
> Either a “jcd" or "jcl" MAY appear in the “rcd” claim, but not both.

Fixed

> 
> ** Section 6.  The SHA2 algorithms need a normative reference

I added reference to RFC6234.

> 
> ** Section 6.
>  The values of each key/value pair consists of a digest across either
>   the direct values or indirectly referenced resources
> 
> Consider restating this to cover there being three instances of what rcdi
> provides a digest for: content inline to the token; the content of a resource
> specified by an inline URI in the token; and the content of a resource
> specified by a URI that is in embedded in content specified by an inline URI
> (i.e., jcl).

Fixed with explicit list

> 
> ** Section 6.1.2
>   If the URI references externally linked
>   content there would need to be a JSON pointer and digest entry for
>   the content in that linked resource.
> 
> Is this the same as saying “If the URI references externally linked content
> there MUST be a JSON pointer ...”?  Please be explicit.

Yes, fixed

> 
> ** Section 6.1.2
>   ...the JSON pointer string would be "/icn" and the
>   digest string would be created using the image file data following
>   the rules of JSON pointer
> 
> What JSON pointer rules?  Section 6.1 states that “For any URI referenced
> content, the bytes of the body of the HTTP response is the input for the hash
> function”?

Yes, this was an error in stating that, you interpreted correct.  Fixed.

> 
> ** Section 6.1.2
>   Even though this is probably not the
>   typical case, an "rcdi" JSON pointer or integrity digest
> 
> Why is it a “JSON pointer _or_ integrity digest”?  What would the JSON be used
> for if not for the digest?  How would there be a digest without a pointer?

> ** Section 6.1.2
>   However, even though the direct value can be protected by the
>   signature and can be constrained directly with JWTClaimConstraints,
>   since the length of the image data is likely much larger than the
>   integrity digest, the use of the "rcdi" JSON pointer and integrity
>   digest as the constraint value in JWTClaimConstraints over the image
>   data is RECOMMENDED.
> 
> What does the length of the image data have to do with whether the rcdi is used
> or not?

This applies to both of the above points, I deleted both of these sentences, the signature does not cover the data URI content, so integrity protection would be required in any case and follow same rules as URIs more generally.

> 
> ** Section 6.2.  Editorial.
>   The "permittedValues" for the "rcd" claim can contain a single entry
>   or optionally contain multiple entries with the intent of supporting
>   cases where the certificate holder is authorized to use different
>   sets of rich call data corresponding to different call scenarios.
> 
> Please re-write this section using RFC2119 keywords to make it clear on the
> normative guidance.

Replaced “can” with “MAY"

> 
> ** Section 7.1.
> -- What is an “authoritative certificate creator” as opposed to a issuer?
> 

Yes, correct, replaced “creator” with “issuer"

> -- Integrity is being used here in a way that is different than how it is
> presented in the document.  I recommend explicitly describing that this is
> about constraining the behavior of the entity that is generating the claim
> rather than an attacker.

Clarified the language

> 
> ** Section 8.1.  Per “it has a valid signature”, where is the guidance on what
> constitutes a valid signature.  Is that a simple JWT process?

Clarified it should follow verification procedures in RFC8225

> 
> ** Section 8.1.  Per “it abides by all rules set forth in the proper
> construction of the claims”, please specify what sections define that proper
> construction.

Referenced the claims definition section of the document

> 
> ** Section 12.1
>   Note that the information that is included in
>   a signed PASSporT is RECOMMENDED to be vetted by an entity that is
>   authoritative over determining the accuracy of that information, so
>   how that information is received by the authentication service is
>   important and the use of Call-Info as a source of RCD information on
>   the authentication side is likely NOT RECOMMENDED best practice.
> 
> Can this sentence be restated?  The guidance isn't clear.

Reworded and clarified.

> 
> ** Section 13.  It isn’t clear what additional guidance is being provided to
> implementers using the rcd passport.  Specifically:
> 
>   Note: There is one very important caveat to this capability, because
>   generally if there is URI referenced content in an "rcd" PASSporT
>   there is often the requirement to use "rcdi" and JWT Claims
>   Constraints.  So, it is important for the user of this specification
>   to recognize that the certificates used should include the necessary
>   JWT Claims Constraints for proper integrity and security of the
>   values in the "rcd" claim incorporated into PASSporTs that are not
>   "rcd".
> 
> -- The use of rcdi is required in some cases, here it is suggested that “often”
> there is such a requirement
> 
> -- it isn’t clear under what circumstances the JWT Claim Constraints should be
> used

I actually removed this note, as you said, the specification is clear about when integrity is required, it was written somewhat historically during some of the discussions around these capabilities.

> 
> ** Section 16.3.  Per “Any new registrations should consist only of a name and
> a reference document”, does this mean that this is a two column registry with
> column1 = “Name” and column2 = “Reference Document”?  For consistency other
> PASSport registries seem to have column2 = “Reference”.  Recommend being
> explicit.

Added the above explicit registry language.

> 
> ** Section 17.  Are there best practices around handling URLs covered in
> Section 7 of RFC3986?

I added a reference to Section 7 of RFC3986 as a general guidance for the paying attention to the general risks of using URLs/URIs in communicating Rich call data content.

> 
> ** From idnits:
> == The document seems to lack the recommended RFC 2119 boilerplate, even if
>     it appears to use RFC 2119 keywords.
> 
>     (The document does seem to have the reference to RFC 2119 which the
>     ID-Checklist requires).
>  -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
>     defined in RFC 2119.  If it is intended as a requirements expression, it
>     should be rewritten using one of the combinations defined in RFC 2119;
>     otherwise it should not be all-uppercase.
> 
>  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
>     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
>     NOT' instead (if that is what you mean).
> 
>     Found 'MAY NOT' in this paragraph:
> 
>     The jCard object value for "jcd" MUST be a jCard JSON object that
>     MAY have URI referenced content, but that URI referenced content MAY NOT
>     further reference URIs.  Future specifications may extend this
>     capability, but as stated in [I-D.ietf-sipcore-callinfo-rcd] it
>     constrains the security properties of RCD information and the integrity
>     of the content referenced by URIs.
> 
>  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
>     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
>     NOT' instead (if that is what you mean).
> 
>     Found 'MAY NOT' in this paragraph:
> 
>     The jCard object referenced by the URI value for "jcl" MUST be a
>     jCard JSON object that MAY have URI referenced content, but that URI
>     referenced content MAY NOT further reference URIs.  Future specifications
>     may extend this capability, but as stated in
>     [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties of
>     RCD information and the integrity of the content referenced by URIs.

Changed MAY NOT to MUST NOT, this was the intent and i don’t believe will cause any disagreement on intent

> 
>  Checking references for intended status: Proposed Standard
>  ----------------------------------------------------------------------------
> 
>  ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
> 
> 
>