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 <stir-bounces@xxxxxxxx> On Behalf Of Russ Housley
Sent: Saturday, June 5, 2021 3:18 PM
To: Theresa Enghardt <ietf@xxxxxxxxxxxxx>
Cc: draft-ietf-stir-enhance-rfc8226.all@xxxxxxxx; IETF Gen-ART
<gen-art@xxxxxxxx>; last-call@xxxxxxxx; IETF STIR Mail List
<stir@xxxxxxxx>
Subject: Re: [stir] [Last-Call] Genart last call review of
draft-ietf-stir-enhance-rfc8226-02
[External]
Theresa:
Thanks for your thoughtful review.
See my responses in-line. I'll post an updated I-D when IETF Last
Call ends.
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637585211113043953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QbFtT%2FIZ0CUXQB%2B0LUm3zIzgWqQQ%2BTk%2BNUJtuJelda8%3D&reserved=0>.
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?
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.
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.
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:
- 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?
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 claims may be necessary.
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.
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.")
Addressing comments below changed this part of Section 3. More on
Section 7 below.
"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"?
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].
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?
I think that is now answered by the last paragraph of the Introduction.
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.
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.
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?
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:
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)
Addressing above comments changed this part of Section 3.
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?)
It is "If a CA issues a certificate to an authentication service ,,,"
I got rid of the semicolon, and made two sentences.
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."
Good catch. I deleted one of them.
Russ
_______________________________________________
stir mailing list
stir@xxxxxxxx
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637585211113054217%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ITvmEkX683nmfZ4HH8owXKlroFxBDV8LtXkqvre3Co0%3D&reserved=0
