Subject: [Gen-art] Genart last call review of draft-ietf-stir-enhance-rfc8226-02

From: Theresa Enghardt via Datatracker <[email-masked]>
Date: Fri, 04 Jun 2021 11:07:07 -0700

Reviewer: Theresa Enghardt
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-stir-enhance-rfc8226-02
Reviewer: Theresa Enghardt
Review Date: 2021-06-04
IETF LC End Date: 2021-06-10
IESG Telechat date: Not scheduled for a telechat

Summary: The draft is basically ready for publication as a Standards Track RFC,
but it has some clarity issues that need to be addressed before publication.

Major issues: None.

Minor issues:

Abstract:

Please expand JWT on first use.
Assuming PASSporT is an acronym, please expand it on first use.
The phrase "STIR certificates" appears in the title, but is not used in the
abstract, introduction, or the draft in general. Is this intentional? Is STIR
the same as PASSporT, in which case it could be replaced?

Section 1: Introduction

"Section 8 of [RFC8226] provides a certificate extension to constrain
   the JWT claims that can be included in the PASSporT [RFC8225].  If
   the signer includes a JWT claim outside the constraint boundaries,
   then the recipient will reject the entire PASSporT."

That's basically copied straight out of the Abstract (or the other way round).
Please provide some basic context for those who are not deeply involved with
JWT/PassporT.

For example:
- How does establishing authority over telephone numbers work, broadly? Does
establishing authority mean that certifying that a telephone number belongs to,
say, a specific organization? Or does anything happen "over" something
telephony-related, as in some VoIP technology? (The "over telephone numbers" is
ambiguous on first read.) - Is the PASSPorT a set of certificates or something
else? Are these X.509 certificates or some other kind of certificates? Is the
technology described in this doc independent of the format of the certificate?
- Does the actual process of "establishing authority" happen over, e.g., a Web
API? Are there other ways? Is the technology described here specific to some
way of "establishing authority"? - What is JWT and what are JWT claims? - Are
JWT claim constraints provided in the certificate (PASSportT?) or are they
communicated separately? Who provides them? The draft later talks about CA,
authentication service, verification service - It would be good to briefly name
these actors in the Introduction already and briefly describe to whom the
change in this doc applies.

Please consider adding a brief explanation why further constraints on PASSporT
claims may be necessary.

Section 3: Enhanced JWT Claim Constraints Syntax

"The Enhanced JWT Claim Constraints certificate extension limits the
   PASSporT claims and the claim values that can successfully validated
   by the certificate that contains the extension."
Are the claims and claim values validated BY the certificate? Aren't they
validated by some recipient, e.g., a verification service? (A similar statement
appears in Section 7: "[…] some combinations can prevent any PASSporT from
being successfully validated by the certificate.")

"Certificate issuers
   permit all claims by omitting the Enhanced JWT Claim Constraints
   certificate extension from the extension field of the certificate
   [RFC5280].  The certificate extension is non-critical, applicable
   only to end-entity certificates, and defined with ASN.1 [X.680].  The
   syntax of the JWT claims in a PASSporT is specified in [RFC8225]."
As this paragraph defines the scope of the extension, it seems misplaced under
"Enhanced JWT Claim Constraints Syntax" as it's not describing the actual
syntax. Maybe either some of this text should be moved to "Introduction", or a
new section could be added, e.g., titled "Scope of Enhanced JWT Claim
Constraints"?

The section then goes on to describe constraints. What is the difference
between the described constrains and RFC 8226, i.e., what is added by this doc?

Section 7: Security considerations

"Certificate issuers should not include an entry in mustExclude for
   the "rcdi" claim for a certificate that will be used with the
   PASSporT Extension for Rich Call Data defined in
   [I-D.ietf-stir-passport-rcd].  Excluding this claim would prevent the
   integrity protection mechanism from working properly."
Is this supposed to be a normative SHOULD? If it is, perhaps it should be moved
up to, e.g., Section 3.

Several paragraphs here describe scenarios that prevent successful validation
of any PASSporT. What is the specific security risk here, e.g., Denial of
Service? Any other consequences? Could there be a possibility for, e.g., a
malicious actor introducing constraints that prevent successful validation? Are
any (other) attacks possible on this technology (e.g., malicious deletion of
constraints, replay attacks), and what countermeasures exist?

Nits/editorial comments:

Section 3: Enhanced JWT Claim Constraints Syntax

OLD: "[…] the claim values that can successfully validated by the certificate
[…]" NEW: "[…] the claim values that can be successfully validated by the
certificate […]" (And/or rephrase sentence, see comment above)

Section 4: Usage Examples

OLD: "If a CA issues to an authentication service certificate that
          includes an Enhanced JWT Claim Constraints certificate extension […]"
Is this either:
NEW: "If a CA issues to an authentication service a certificate that
          includes an Enhanced JWT Claim Constraints certificate extension […]"
Or is it:
NEW: "If a CA issues an authentication service certificate that
          includes an Enhanced JWT Claim Constraints certificate extension […]"
(This sentence is very long and not easy to parse in general, maybe it can be
rephrased or split?)

Section 7: Security Considerations

This paragraph appears twice, unless I'm missing a subtle difference:
"   Certificate issuers must take care when imposing constraints on the
   PASSporT claims and the claim values that can successfully validated;
   some combinations can prevent any PASSporT from being successfully
   validated by the certificate.  For example, an entry in mustInclude
   and an entry in mustExclude for the same claim will prevent
   successful validation on any PASSporT."

---

From: Russ Housley <[email-masked]>
Date: Sat, 5 Jun 2021 16:18:04 -0400

Theresa:

Thanks for your thoughtful review.

See my responses in-line.  I'll post an updated I-D when IETF Last Call ends.

> the same as PASSporT, in which case it could be replaced?

How about the replacement Abstract:

   RFC 8226 specifies the use of certificates for Secure Telephone
   Identity Credentials, and these certificates are often called "STIR
   Certificates".  RFC 8226 provides a certificate extension to
   constrain the JSON Web Token (JWT) claims that can be included in the
   Personal Assertion Token (PASSporT) as defined in RFC 8225.  If the
   PASSporT signer includes a JWT claim outside the constraint
   boundaries, then the PASSporT recipient will reject the entire
   PASSporT.  This document updates RFC 8226 to define an additional way
   that the JWT claims can be constrained.

> Please provide some basic context for those who are not deeply involved with

I do think that it makes sense to expand the Introduction to say more about STIR certificates, but I do not think that the Introduction should repeat too much of RFC 8226.

> change in this doc applies.

Is this enough?

   The use of certificates [RFC5280] in establishing authority over
   telephone numbers is described in [RFC8226].  These certificates are
   often called "STIR Certificates".  STIR certificates are an important
   element of the overall system that prevents the impersonation of
   telephone numbers on the Internet.

   Section 8 of [RFC8226] provides a certificate extension to constrain
   the JSON Web Token (JWT) claims that can be included in the Personal
   Assertion Token (PASSporT) [RFC8225].  If the PASSporT signer
   includes a JWT claim outside the constraint boundaries, then the
   PASSporT recipient will reject the entire PASSporT.

   This document defines an enhanced JWTClaimConstraints certificate
   extension, which provides all of the capabilities available in the
   original certificate extension as well as an additional way to
   constrain the allowable JWT claims.  That is, the enhanced extension
   can provide a list of claims that are not allowed to be included in
   the PASSporT.

> Please consider adding a brief explanation why further constraints on PASSporT

I suggest two additional paragraphs at the end of the above Introduction:

   The Enhanced JWT Claim Constraints certificate extension is needed to
   limit the authority when a parent STIR certificate delegates to a
   subordinate STIR certificate.  For example,
   [I-D.ietf-stir-cert-delegation] describes the situation where service
   providers issue a STIR certificate to enterprises or other customers
   to sign PASSporTs, and the Enhanced JWT Claim Constraints certificate
   extension can be used to prevent specific claims from being included
   in PASSporTs and accepted as valid by the PASSporT recipient.

   The JWT Claim Constraints certificate extension defined in [RFC8226]
   provides a list of claims that must be included in a valid PASSporT
   as well as a list if permitted values for selected claims.  The
   Enhanced JWT Claim Constraints certificate extension defined in this
   document includes those capabilities and adds a list of claims that
   must not be included in a valid PASSporT.

> being successfully validated by the certificate.")

Addressing comments below changed this part of Section 3.  More on Section 7 below.

> new section could be added, e.g., titled "Scope of Enhanced JWT Claim

As you can see above, I moved some of this to the end of the Introduction.  This part remains:

   The Enhanced JWT Claim Constraints certificate extension is non-
   critical, applicable only to end-entity certificates, and defined
   with ASN.1 [X.680].  The syntax of the JWT claims in a PASSporT is
   specified in [RFC8225].

> between the described constrains and RFC 8226, i.e., what is added by this doc?

I think that is now answered by the last paragraph of the Introduction.

> Is this supposed to be a normative SHOULD? If it is, perhaps it should be moved

I do not think so.  I have been coordinating with the authors of draft-ietf-stir-passport-rcd, and both documents will warn implementers about the situation.

> constraints, replay attacks), and what countermeasures exist?

If the malicious actors can sign certificates, then these constraints will be the least of the worries.  I think that is covered by the pointer to RFC 5280.

> certificate […]" (And/or rephrase sentence, see comment above)

Addressing above comments changed this part of Section 3.

> (This sentence is very long and not easy to parse in general, maybe it can be

It is "If a CA issues a certificate to an authentication service ,,,"

I got rid of the semicolon, and made two sentences.

>   successful validation on any PASSporT."

Good catch.  I deleted one of them.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Jun 2021 17:26:47 -0400

The document will get a new RFC number.

Russ

> On Jun 8, 2021, at 5:13 PM, Gorman, Pierce <[email-masked]> wrote:
> 
> Russ and Theresa,
> 
> Please forgive my ignorance, but is the intent to issue an RFC 8226bis?  Or is the intent that the I-D result in a new numbered RFC which updates 8226?
> 
>> From reading various things I've learned, I think, that new RFCs and updates to existing RFCs begin life as an Internet-Draft which may or may not be adopted by a working group as a work item.  If adopted by the group, the author/editor continues development of the I-D until such time as it expires or is promoted to last call, et cetera.  The end result in many cases are new numbered RFCs which may obsolete or update existing RFCs as appropriate.  The STIR RFC 4474 had a 4474bis version that remained unchanged for some years before being obsoleted by RFC 8224 for which it was a conceptual foundation and that is now a key component of the STIR/SHAKEN set of standards required to be used by US VoIP service providers by law and federal mandate.
> 
> The reason I ask was because of some of the conversation at the last (I think) interim meeting and on the e-mail distribution where proposed changes were suggested to be submitted as a new I-D.  This -02 version may be the same sort of thing but confusion/ignorance on my part about naming and procedures made me want to ask.
> 
> Respectfully,
> 
> Pierce Gorman
> 
> -----Original Message-----
> From: stir <[email-masked]> On Behalf Of Russ Housley
> Sent: Saturday, June 5, 2021 3:18 PM
> To: Theresa Enghardt <[email-masked]>
> Cc: [email-masked]; IETF Gen-ART <[email-masked]>; [email-masked]; IETF STIR Mail List <[email-masked]>
> Subject: Re: [stir] [Last-Call] Genart last call review of draft-ietf-stir-enhance-rfc8226-02
> 
> [External]
> 
> 
> Theresa:
> 
>> Review Team (Gen-ART) reviews all IETF documents being processed by 
>> the IESG for the IETF Chair.  Please treat these comments just like 
>> any other last call comments.
>> 
>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637585211113043953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QbFtT%2FIZ0CUXQB%2B0LUm3zIzgWqQQ%2BTk%2BNUJtuJelda8%3D&amp;reserved=0>.
>> 
>> Summary: The draft is basically ready for publication as a Standards 
>> Track RFC, but it has some clarity issues that need to be addressed before publication.
>> 
>> Major issues: None.
>> 
>> Minor issues:
>> 
>> Abstract:
>> 
>> The phrase "STIR certificates" appears in the title, but is not used 
>> in the abstract, introduction, or the draft in general. Is this 
>> intentional? Is STIR the same as PASSporT, in which case it could be replaced?
> 
>> Please provide some basic context for those who are not deeply 
>> involved with JWT/PassporT.
> 
>> - How does establishing authority over telephone numbers work, 
>> broadly? Does establishing authority mean that certifying that a 
>> telephone number belongs to, say, a specific organization? Or does 
>> anything happen "over" something telephony-related, as in some VoIP 
>> technology? (The "over telephone numbers" is ambiguous on first read.) 
>> - Is the PASSPorT a set of certificates or something else? Are these 
>> X.509 certificates or some other kind of certificates? Is the technology described in this doc independent of the format of the certificate?
>> - Does the actual process of "establishing authority" happen over, 
>> e.g., a Web API? Are there other ways? Is the technology described 
>> here specific to some way of "establishing authority"? - What is JWT 
>> and what are JWT claims? - Are JWT claim constraints provided in the 
>> certificate (PASSportT?) or are they communicated separately? Who 
>> provides them? The draft later talks about CA, authentication service, 
>> verification service - It would be good to briefly name these actors 
>> in the Introduction already and briefly describe to whom the change in this doc applies.
> 
> Is this enough?
> 
>> Please consider adding a brief explanation why further constraints on 
>> PASSporT claims may be necessary.
> 
>> Are the claims and claim values validated BY the certificate? Aren't 
>> they validated by some recipient, e.g., a verification service? (A 
>> similar statement appears in Section 7: "[...] some combinations can 
>> prevent any PASSporT from being successfully validated by the 
>> certificate.")
> 
>> As this paragraph defines the scope of the extension, it seems 
>> misplaced under "Enhanced JWT Claim Constraints Syntax" as it's not 
>> describing the actual syntax. Maybe either some of this text should be 
>> moved to "Introduction", or a new section could be added, e.g., titled 
>> "Scope of Enhanced JWT Claim Constraints"?
> 
>> The section then goes on to describe constraints. What is the 
>> difference between the described constrains and RFC 8226, i.e., what is added by this doc?
> 
>> Is this supposed to be a normative SHOULD? If it is, perhaps it should 
>> be moved up to, e.g., Section 3.
> 
>> Several paragraphs here describe scenarios that prevent successful 
>> validation of any PASSporT. What is the specific security risk here, 
>> e.g., Denial of Service? Any other consequences? Could there be a 
>> possibility for, e.g., a malicious actor introducing constraints that 
>> prevent successful validation? Are any (other) attacks possible on 
>> this technology (e.g., malicious deletion of constraints, replay attacks), and what countermeasures exist?
> 
>> OLD: "[...] the claim values that can successfully validated by the 
>> certificate [...]" NEW: "[...] the claim values that can be successfully 
>> validated by the certificate [...]" (And/or rephrase sentence, see 
>> comment above)
> 
>>         includes an Enhanced JWT Claim Constraints certificate extension [...]"
>> Is this either:
>>         includes an Enhanced JWT Claim Constraints certificate extension [...]"
>> Or is it:
>>         includes an Enhanced JWT Claim Constraints certificate extension [...]"
>> (This sentence is very long and not easy to parse in general, maybe it 
>> can be rephrased or split?)
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&amp;data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637585211113054217%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ITvmEkX683nmfZ4HH8owXKlroFxBDV8LtXkqvre3Co0%3D&amp;reserved=0
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: "Gorman, Pierce" <[email-masked]>
Date: Tue, 8 Jun 2021 21:13:48 +0000

Russ and Theresa,

Respectfully,

Pierce Gorman

-----Original Message-----
From: stir <[email-masked]> On Behalf Of Russ Housley
Sent: Saturday, June 5, 2021 3:18 PM
To: Theresa Enghardt <[email-masked]>
Cc: [email-masked]; IETF Gen-ART <[email-masked]>; [email-masked]; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] [Last-Call] Genart last call review of draft-ietf-stir-enhance-rfc8226-02

[External]

Theresa:

Is this enough?

Russ

---

From: Theresa Enghardt <[email-masked]>
Date: Fri, 11 Jun 2021 10:33:01 -0700

Dear Russ,

Thanks, your proposed changes looks good to me.

Best,
Theresa

---

From: Theresa Enghardt <[email-masked]>
Date: Fri, 11 Jun 2021 10:39:07 -0700

Dear Pierce,

Once published, this I-D will result in a new numbered RFC, which 
updates 8226. Note that this is exactly the procedure to issue an RFC 
8226bis (i.e., a -bis document is always a new numbered RFC, and the 
published RFC 8226 does not change).

Apologies if I misunderstood your question or if I'm missing any 
relevant context such as other drafts in the STIR WG etc, in which case 
I'd ask Russ and/or other STIR folks to chime in.

Best,
Theresa

---

From: Robert Sparks <[email-masked]>
Date: Fri, 11 Jun 2021 12:48:14 -0500

I think Pierce's question was whether _this_ document, once published as 
an RFC, obsoletes (and replaces) 8226. It does not. It only updates 
8226, as noted on the first page, and in the metadata captured in the 
datatracker.

There is not an 8226bis effort underway at this time.

I've set the Reply-To for this message to just the STIR list. If there's 
any need to continue this thread, lets have the conversation there.

RjS - with STIR co-chair hat on

On 6/11/21 12:39 PM, Theresa Enghardt wrote:
> relevant context such as other drafts in the STIR WG etc, in which 
> case I'd ask Russ and/or other STIR folks to chime in.
>
> Best,
> Theresa
>
>
>> Please forgive my ignorance, but is the intent to issue an RFC 
>> 8226bis?  Or is the intent that the I-D result in a new numbered RFC 
>> which updates 8226?
>>
>> >From reading various things I've learned, I think, that new RFCs and 
>> updates to existing RFCs begin life as an Internet-Draft which may or 
>> may not be adopted by a working group as a work item.  If adopted by 
>> the group, the author/editor continues development of the I-D until 
>> such time as it expires or is promoted to last call, et cetera.  The 
>> end result in many cases are new numbered RFCs which may obsolete or 
>> update existing RFCs as appropriate.  The STIR RFC 4474 had a 4474bis 
>> version that remained unchanged for some years before being obsoleted 
>> by RFC 8224 for which it was a conceptual foundation and that is now 
>> a key component of the STIR/SHAKEN set of standards required to be 
>> used by US VoIP service providers by law and federal mandate.
>>
>> The reason I ask was because of some of the conversation at the last 
>> (I think) interim meeting and on the e-mail distribution where 
>> proposed changes were suggested to be submitted as a new I-D.  This 
>> -02 version may be the same sort of thing but confusion/ignorance on 
>> my part about naming and procedures made me want to ask.
>>
>> Respectfully,
>>
>> Pierce Gorman
>>
>> Cc: [email-masked]; IETF Gen-ART 
>> <[email-masked]>; [email-masked]; IETF STIR Mail List 
>> <[email-masked]>
>> I do think that it makes sense to expand the Introduction to say more 
>> about STIR certificates, but I do not think that the Introduction 
>> should repeat too much of RFC 8226.
>>
>>> For example:
>>> X.509 certificates or some other kind of certificates? Is the 
>> I do not think so.  I have been coordinating with the authors of 
>> draft-ietf-stir-passport-rcd, and both documents will warn 
>> implementers about the situation.
>>
>>> this technology (e.g., malicious deletion of constraints, replay 
>>> attacks), and what countermeasures exist?
>> If the malicious actors can sign certificates, then these constraints 
>> will be the least of the worries.  I think that is covered by the 
>> pointer to RFC 5280.
>>
>>> Nits/editorial comments:
>>>

---

From: "Gorman, Pierce" <[email-masked]>
Date: Fri, 11 Jun 2021 18:05:04 +0000

Thank you Theresa.  Russ also said a new numbered RFC updating 8226, but I appreciate the additional procedural detail you provide.  You've both answered my question.  Thank you.

Best regards,

Pierce

-----Original Message-----
From: Theresa Enghardt <[email-masked]> 
Sent: Friday, June 11, 2021 12:39 PM
To: Gorman, Pierce <[email-masked]>
Cc: [email-masked]; IETF Gen-ART <[email-masked]>; IETF STIR Mail List <[email-masked]>; [email-masked]; Russ Housley <[email-masked]>
Subject: Re: [Last-Call] [stir] Genart last call review of draft-ietf-stir-enhance-rfc8226-02

[External]

Dear Pierce,

Once published, this I-D will result in a new numbered RFC, which updates 8226. Note that this is exactly the procedure to issue an RFC 8226bis (i.e., a -bis document is always a new numbered RFC, and the published RFC 8226 does not change).

Apologies if I misunderstood your question or if I'm missing any relevant context such as other drafts in the STIR WG etc, in which case I'd ask Russ and/or other STIR folks to chime in.

Best,
Theresa

On 6/8/21 2:13 PM, Gorman, Pierce wrote:
>> provides them? The draft later talks about CA, authentication 
>> service, verification service - It would be good to briefly name 
>> these actors in the Introduction already and briefly describe to whom the change in this doc applies.
> Is this enough?
>
>> describing the actual syntax. Maybe either some of this text should 
>> be moved to "Introduction", or a new section could be added, e.g., 
>> titled "Scope of Enhanced JWT Claim Constraints"?
>> Is this supposed to be a normative SHOULD? If it is, perhaps it 
>> should be moved up to, e.g., Section 3.
>> certificate [...]" NEW: "[...] the claim values that can be 
>> successfully validated by the certificate [...]" (And/or rephrase 
>> sentence, see comment above)
>> (This sentence is very long and not easy to parse in general, maybe 
>> it can be rephrased or split?)
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fstir&amp;data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637585211113054217%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ITvmEkX683nmfZ4HH8owXKlroFxBDV8LtXkqvre3Co0%3D&amp;reserved=0
>