From nobody Tue Jun 8 14:27:04 2021 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC96B3A3E5D for ; Tue, 8 Jun 2021 14:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Uume11qeHaG for ; Tue, 8 Jun 2021 14:26:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8345D3A3E69 for ; Tue, 8 Jun 2021 14:26:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 48EA1300BE9 for ; Tue, 8 Jun 2021 17:26:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rZ_WB1FtTcxK for ; Tue, 8 Jun 2021 17:26:47 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 1319F300B0C; Tue, 8 Jun 2021 17:26:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: Date: Tue, 8 Jun 2021 17:26:47 -0400 Cc: Theresa Enghardt , IETF Gen-ART , IETF STIR Mail List Content-Transfer-Encoding: quoted-printable Message-Id: <2780D5EE-6249-4F16-BEF3-4C83FFFB72DC@vigilsec.com> References: <162283002740.11296.9657732547938468103@ietfa.amsl.com> <22F59565-04B0-4FBD-BEBE-DBAEBCB86A89@vigilsec.com> To: "Gorman, Pierce" X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [stir] [Last-Call] Genart last call review of draft-ietf-stir-enhance-rfc8226-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 21:27:02 -0000 The document will get a new RFC number. Russ > On Jun 8, 2021, at 5:13 PM, Gorman, Pierce = wrote: >=20 > Russ and Theresa, >=20 > 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? >=20 >> =46rom 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. >=20 > 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. >=20 > Respectfully, >=20 > Pierce Gorman >=20 > -----Original Message----- > From: stir On Behalf Of Russ Housley > Sent: Saturday, June 5, 2021 3:18 PM > To: Theresa Enghardt > Cc: draft-ietf-stir-enhance-rfc8226.all@ietf.org; IETF Gen-ART = ; last-call@ietf.org; IETF STIR Mail List = > Subject: Re: [stir] [Last-Call] Genart last call review of = draft-ietf-stir-enhance-rfc8226-02 >=20 > [External] >=20 >=20 > Theresa: >=20 > Thanks for your thoughtful review. >=20 > See my responses in-line. I'll post an updated I-D when IETF Last = Call ends. >=20 >> Reviewer: Theresa Enghardt >> Review result: Ready with Issues >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area=20= >> Review Team (Gen-ART) reviews all IETF documents being processed by=20= >> the IESG for the IETF Chair. Please treat these comments just like=20= >> any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> = . >>=20 >> 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 >>=20 >> Summary: The draft is basically ready for publication as a Standards=20= >> Track RFC, but it has some clarity issues that need to be addressed = before publication. >>=20 >> Major issues: None. >>=20 >> Minor issues: >>=20 >> Abstract: >>=20 >> 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=20= >> in the abstract, introduction, or the draft in general. Is this=20 >> intentional? Is STIR the same as PASSporT, in which case it could be = replaced? >=20 > How about the replacement Abstract: >=20 > 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. >=20 >> Section 1: Introduction >>=20 >> "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." >>=20 >> 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=20 >> involved with JWT/PassporT. >=20 > 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. >=20 >> For example: >> - How does establishing authority over telephone numbers work,=20 >> broadly? Does establishing authority mean that certifying that a=20 >> telephone number belongs to, say, a specific organization? Or does=20 >> anything happen "over" something telephony-related, as in some VoIP=20= >> technology? (The "over telephone numbers" is ambiguous on first = read.)=20 >> - Is the PASSPorT a set of certificates or something else? Are these=20= >> 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,=20 >> e.g., a Web API? Are there other ways? Is the technology described=20 >> here specific to some way of "establishing authority"? - What is JWT=20= >> and what are JWT claims? - Are JWT claim constraints provided in the=20= >> certificate (PASSportT?) or are they communicated separately? Who=20 >> provides them? The draft later talks about CA, authentication = service,=20 >> verification service - It would be good to briefly name these actors=20= >> in the Introduction already and briefly describe to whom the change = in this doc applies. >=20 > Is this enough? >=20 > 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. >=20 > 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. >=20 > 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. >=20 >> Please consider adding a brief explanation why further constraints on=20= >> PASSporT claims may be necessary. >=20 > I suggest two additional paragraphs at the end of the above = Introduction: >=20 > 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. >=20 > 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. >=20 >> Section 3: Enhanced JWT Claim Constraints Syntax >>=20 >> "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=20= >> they validated by some recipient, e.g., a verification service? (A=20 >> similar statement appears in Section 7: "[...] some combinations can=20= >> prevent any PASSporT from being successfully validated by the=20 >> certificate.") >=20 > Addressing comments below changed this part of Section 3. More on = Section 7 below. >=20 >> "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=20 >> misplaced under "Enhanced JWT Claim Constraints Syntax" as it's not=20= >> describing the actual syntax. Maybe either some of this text should = be=20 >> moved to "Introduction", or a new section could be added, e.g., = titled=20 >> "Scope of Enhanced JWT Claim Constraints"? >=20 > As you can see above, I moved some of this to the end of the = Introduction. This part remains: >=20 > 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]. >=20 >> The section then goes on to describe constraints. What is the=20 >> difference between the described constrains and RFC 8226, i.e., what = is added by this doc? >=20 > I think that is now answered by the last paragraph of the = Introduction. >=20 >> Section 7: Security considerations >>=20 >> "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=20 >> be moved up to, e.g., Section 3. >=20 > 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. >=20 >> Several paragraphs here describe scenarios that prevent successful=20 >> validation of any PASSporT. What is the specific security risk here,=20= >> e.g., Denial of Service? Any other consequences? Could there be a=20 >> possibility for, e.g., a malicious actor introducing constraints that=20= >> prevent successful validation? Are any (other) attacks possible on=20 >> this technology (e.g., malicious deletion of constraints, replay = attacks), and what countermeasures exist? >=20 > 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. >=20 >> Nits/editorial comments: >>=20 >> Section 3: Enhanced JWT Claim Constraints Syntax >>=20 >> OLD: "[...] the claim values that can successfully validated by the=20= >> certificate [...]" NEW: "[...] the claim values that can be = successfully=20 >> validated by the certificate [...]" (And/or rephrase sentence, see=20 >> comment above) >=20 > Addressing above comments changed this part of Section 3. >=20 >> Section 4: Usage Examples >>=20 >> 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=20 >> can be rephrased or split?) >=20 > It is "If a CA issues a certificate to an authentication service ,,," >=20 > I got rid of the semicolon, and made two sentences. >=20 >> Section 7: Security Considerations >>=20 >> 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." >=20 > Good catch. I deleted one of them. >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > = https://nam02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fstir&data=3D04%7C01%7Cpierce.gorman%40t-= mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71a0= 9b026c%7C0%7C0%7C637585211113054217%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DIT= vmEkX683nmfZ4HH8owXKlroFxBDV8LtXkqvre3Co0%3D&reserved=3D0 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call