Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-cert-delegation-03: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Jon,

Now it's my turn to apologize for the longer-than-indicated RTT.  (OpenSSL
1.1.1k is a thing now, but there was some excitement involved...)

The good news is that I'm going to clear my discuss -- I do have follow-up
comments on a few points, but they're basically already written up in the
form of a new ballot position based on how I assembled them, so I think
it's simplest if I just submit that new ballot instead of covering them in
this message.  So I'll just have a handful of replies inline and reserve
the bulk of discussion for a separate thread.

On Mon, Feb 22, 2021 at 11:44:28PM +0000, Peterson, Jon wrote:
> 
> Hi Benjamin,
> 
> Thanks as usual for the detailed read (and sorry as usual for the looongg RTT) - responses inline below. I hope the new version takes care of (most) of this.
>     
>     Despite the length of the list of numbered points, this document is
>     actually in pretty good shape -- most of them just relate to
>     clarifying/correcting how this document interacts with other documents
>     rather than issues with the way this mechanism works.
>     
>     (1) Section 4 calmly asserts that "[i]n the STIR ecosystem, CA certificates
>     may be used to sign PASSporTs", but I could not find this documented in
>     RFCs 8224, 8225, or 8226.  If it is already documented somewhere, please
>     provide a reference; if it is a new property of the architecture being
>     asserted by this specification, we should be more clear about it, as
>     well as how it is not entirely consistent with cryptographic best
>     practice (see COMMENT).
>     (It is perhaps unfortunate that RFC 8225 did not talk about (extended)
>     key usage values suitable for signing PASSporTs, though it is probably
>     not appropriate to start doing so in this document.)
> 
> This idea emerged from concerns expressed in the operator community about having to manage intermediate certs independently from the certs used to sign PASSporTs. We floated this as a possibility, but weren't sure how much uptake it would see in deployment - hence we were a little glib about it. We didn't want to rule it out, but nor did we think it required a ton more explication. 
> 
> I think on balance, though, after discussing with the WG, we can safely remove it, and explore later if people want it. So it's not in the new version.

Thanks for going through these efforts in the WG; I'm glad that this could
be resolved.

>     (2) We are introducing new entities that act as X.509 CAs with this
>     mechanism.  Do we need to mandate that they provide CRLs/OCSP/etc. for
>     making revocation information available?  ("This is already covered by
>     RFC XXXX" is a fine answer, though it is probably worth a reminder in
>     the text.)
> 
> I added a little text to Section 8 about the responsibilities for certificate revocation and so on that being a CA entails. Practically speaking, in the SHAKEN ecosystem for the USA, CRLs for all participating CAs are actually managed by a centralized policy administrator, so I don't think it's appropriate for this to be normative, but hopefully it helps.
>     
>     (3) I think we are missing some exposition about how an SPC TNAuthList
>     value is treated as "encompassing" specific telephone numbers/ranges
>     controlled by the provider to which that SPC is assigned (more than just
>     a mention in passing that the CA has to have access to the industry
>     database), such that the CA cert might have the SPC form of TNAuthList
>     but the child certificate a different form.  I was also looking for some
>     discussion of the related risk of skew if the database changes, but
>     perhaps https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8226*section-10__;Kg!!N14HnBHF!o-ni9DilQAbpfleqMWUl4SWcuURZzt37mdzos7UiowvApoTGikIrdMQscFbF4Q$ 
>     cover that.  (It would be nice to have some data on the relative
>     lifetime of database mappings and certificate lifetimes, though.)
> 
> I would have thought we said that a CA cert with an SPC TNAuthList can have a child EE cert with TNs in its TNAuthList in the first sentence of 4.1, but reading your comment below, I see that sentence needs to be reworded to make that explicit (which it hopefully is now). Yes, I think the existing reference to RFC8226 10.1 is intended to address database skew.
>     
>     (4) We seem to have an internal inconsistency about whether alternative
>     certification paths are allowed -- Section 6 implies that it is a very
>     rigid procedure (and Section 7 requires
>     AuthorityKeyIdentifier/SubjectKeyIdentifier matching), but Section 8.2
>     suggests the use of cross-signing and AIA for an alternate chain
>     construction.
> 
> The whole bit about cross-signing there, much like the bit about letting CA certs sign PASSporTs, is something we've heard operators fret over, where they don't want to have to manage some huge keyring if they are getting TNs from 15 different carriers. So if an enterprise, say, inherits TN range A from Carrier1, and TN range B from Carrier2, we'd like to have a way to consolidate those into a single instrument, which is why we're interested in cross signing. That said, the text of 8.2 is pretty exploratory and non-normative in character, it is enumerating some things you could flesh out if you wanted to go down any of those paths; it is not intended to clobber the AKID/SKID matching in Section 7. I added some text to clarify that.
>     
>     (5) Section 9 contains a false statement that TLS subcerts has ways for
>     the issuer of a (TLS) delegated credential to revoke that credential.
>     https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-tls-subcerts-09*section-7.3__;Kg!!N14HnBHF!o-ni9DilQAbpfleqMWUl4SWcuURZzt37mdzos7UiowvApoTGikIrdMSqVP79zQ$  is
>     quite clear that expiration is the only mechanism to invalidate the
>     delegated credential, with the risk of stolen/leaked delegated
>     credentials limited by their short-lived nature.
> 
> Um, right you are... that one is my bad, I'm sure. I imagine that the text there was initially talking about ACME STAR and it just got glommed into subcerts. Fixed.
>     
>     (6) Section 4.1 seems to waver on where the "encompassing" check is
>     performed, leaving open the possibility that it is not performed at all.
>     I think we need to be very explicit about what is required, not just
>     what might be done or what is desirable.  This might end up needing to
>     be passing the buck ("the authority for the deployment in question will
>     specify which entity performs this validation"), but at present it seems
>     like there's a gap that needs to be filled in some manner.
> 
> I think the text is clear that we ideally want it to be performed by the certification authority, and furthermore expect it may also be performed on the authentication or verification services as a belt-and-suspenders check. But we aren't writing the CP for those CAs here, and I can imagine sane CPs that could defer it to verification, say. So passing the buck is intentional here. I guess in our limited experience so far, those CPs are being written by government-sanctioned bodies to conform with regulatory policies; I don't want to write something here that could potential conflict.
>     
>     (7) Section 8.1 has what I think is a stale statement about ACME,
>     relating to suitability of the certificate URL for use as "x5u" -- RFC
>     8555 only requres POST-AS-GET access, not the GET access that we imply.
>     (See COMMENT for additional related points.)
>     
> Reading this in light of your comment below, we're not trying to suggest that the PASSporT contain the URL returned by ACME, but instead that the URL contains an "application/pem-certificate/chain" object, and that the object is question is suitable for someone else to host a URL for. Hopefully that is now clarified.
>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     Section 3
>     
>        A user might also roam from their usual service provider to a
>        different network or administrative domain, for various reasons.
>        Most "legitimate spoofing" examples are of this form: where a user
>        wants to be able to use the main call-back number for their business
>        as a calling party number, even when the user is away from the
>        business.
>     
>     It seems like we're trying to implicitly define "legitimate spoofing"
>     here.  While this is probably effective for most readers, we might
>     consider a rewording that does not introduce an otherwise-unused new
>     term, for example:
>     
>     % Most cases where legitimate traffic is hindered by anti-spoofing
>     % protections resemble this scenario: a common case is where a user
>     % [...]
>     
> 
> Gen-ART suggested that I just define "legitimate spoofing" in the Terminology section, so, I did that.
> 
>     Section 4
>     
>        certificate that itself contains a TNAuthList object.  The parent
>        certificate needs contain a basic constraints extension with the cA
>        boolean set to "true", indicating that the subject can sign
>     
>     nit: "needs to contain"
> 
> Fixed, thanks.
>     
>        certificates.  Every STIR delegate certificate identifies its parent
>        certificate with a standard [RFC5280] Authority Key Identifier
>        extension.
>     
>     And RFC 5280 §4.2.1.2 requires that the cA:TRUE certificate sets its
>     subject key identifier, so it's safe to use authority key identifier to
>     identify the issuer, excellent.
>     
>     But, do we want to say anything about key usage here?  It seems that RFC
>     5280 fairly tightly constrains what needs to be done here, so no new
>     normative requirements would be needed, but if we are giving a reminder
>     about cA:TRUE, I will ask if that is the only reminder we want to give.
>     
> Well, we've backed out that sign-PASSporTs-with-intermediate-certs thing. I don't have any particular restrictions in mind, as really the CPs will end up governing a lot of this... is there something else we should be worried about?

I don't think there's anything else in particular that clearly needs to be
mentioned.

>        certificate's scope: it must be "encompassed."  For example, a parent
>        certificate with a TNAuthList that attested authority for the
>        numbering range [phone] through 1999 could issue a
>        certificate to one delegate attesting authority for the range
>        [phone] through 1599, and to another delegate a certificate
>        for the individual number [phone].
>     
>     I would (weakly) prefer to not use this notation for ranges that
>     requires the reader to infer that only the last four digits are
>     changing.  Could we use the full eleven-digit codes or reword match the
>     actual RFC 8226 structure ("N numbers starting at <blah>")?
> 
> In North American usage, there's a big distinction between the last four digits and the rest of the number in terms of the way number are allocated. While that isn't a global practice, it is globally familiar. So I guess I'd weakly prefer to keep it, for that reason - as you point out, nothing in the RFC8226 syntax forces it, but it's intuitive.
>     
>        Delegate certificates may also contain a basic constraints extension
>        with the cA boolean set to "true", indicating that they can sign
>        subordinate certificates for further delegates.  In the STIR
>        ecosystem, CA certificates may be used to sign PASSporTs; this
>        removes the need for creating a redundant end-entity certificate with
>        an identical TNAuthList to its parent, though if for operational or
>        security reasons certificate holders wish to do so, they may.
>     
>     (Noting that this text may change due to my discuss point,) I'd suggest
>     rewording the last sentence here to talk about how "if a CA certificate
>     could only be used to sign certificates, then a redundant end-entity
>     certificate with identical TNAuthList to its parent would be needed to
>     sign PASSporTs".  That said, though, it's general crypto best practice
>     to only use a given key for one type of operation, and "sign
>     certificates" and "sign JWTs" qualify as separate operations in this
>     sense.  While it is highly unlikely that the JSON/base64 input to be
>     signed would collide with the DER of a certificate, it's not entirely
>     clear that this "convenience" justification outweights the cryptographic
>     best practice.
> 
> We backed out the offending text.
>     
>     Section 4.1
>     
>        STIR certificates may have a TNAuthList containing one or more SPCs,
>        one or more telephone number ranges, or both.  When delegating from a
>        STIR certificate, a child certificate may inherit from its parent
>        either of the above.  Depending on the sort of numbering resources
>     
>     Does "either of" exclude "both"?
>     ensure that it always happens at least once.
>     
> Per your discuss, we'll clarify this sentence. We mean either or both. In practice, SPC->TN delegation needs to work.
> 
>        is issued, or at the time that a verification service receives an
>        inbound call, or potentially both.  It is generally desirable to
>        offload as much of this as possible to the certification process, as
>        verification occurs during call setup and thus additional network
>        dips could lead to perceptible delay, whereas certification happens
>        outside of call processing as a largely administrative function.
>     
>     Is "network dip" a term of art in this field?
> 
> I think so, but I can just change it to "transactions with a service." 
>     
>        numbers specified as the scope of a certificate.  The presence of one
>        or more SPCs and one or more sets of telephone number ranges should
>        similarly be treated additively, even if the telephone number ranges
>        turn out to be redundant to the scope of an SPC.
>     
>     Any thoughts about s/should similarly be/are similarly/?  This is the
>     architecture we have, not some thoughts about the best ways to do
>     things (AFAICT).
> 
> Fixed.
>     
>     Section 5
>     
>        signing certificate.  Authentication services SHOULD NOT use a
>        delegate certificate without validating that its scope of authority
>        is encompassed by that of its parent certificate, and if that
>        certificate has a own parent, the entire certification path SHOULD be
>        validated.
>     
>     Why are these only SHOULD?  (Probably related to my discuss point.)
> 
> It is related to your discuss (so it's addressed up there).
>     
>     Section 7
>     
>        When a STIR delegate certificate is used to sign a PASSporT, the
>        "x5u" element in the PASSporT will contain a URI indicating where a
>        certificate list is available.  While baseline JWS also supports an
>        "x5c" element specifically for certificate chains, in operational
>        practice, certification path are already being delivered in the STIR
>        environment via the "x5u" element, so this specification recommends
>        continuing to use "x5u".  That list will be a concatenation of PEM-
>     
>     I have a really hard time supporting this practice based solely on the
>     stated justification.  These elements have well-specified meanings; why
>     should we diverge from that?  Just because some people are currently
>     doing a thing we don't need to recommend that everyone does that thing
>     going forward...  (It's fine to say that some people are doing this and
>     you may want to accept it, but why go further and actively recommend
>     propagating the error?)
>     
> If existing implementations hadn't basically hard coded "x5u" so that they would just crash if they saw an "x5c", I'd be more permissive in what I'd send here. I know you're correct, and that the IETF should not recommend doing the wrong thing. I just feel like that's a higher burden to acceptance of the standard than one might think.

Ah, thanks for the additional clarification.  I'll drop this one.

>        encoded certificates of the type "application/pem-certificate-chain"
>        defined in [RFC8555].  The certificate path [RFC5280] ordering MUST
>        be organized from the trust anchor towards the signer.  The list
>        begins with the certificate used to sign the PASSporT, followed by
>        its parent, and then any subsequent grandparents, great-grandparents,
>        and so on.  The key identifier in the Authority Key Identifier
>     
>     Maybe it's just me, but I'm having a hard time squaring "organized from
>     the trust anchor towards the signer" with "begins with the certificate
>     used to sign the PASSporT" -- doesn't "from trust anchor" mean "start
>     with trust anchor"?  (Also, while I'm happy to have a rigid
>     chain-building algorithm, the requirement for
>     AuthorityKeyIdentifier/SubjectKeyIdentifier does kind of make it
>     redundant...)
> 
> Somebody suggested that we needed a chain building algorithm, at some point; agreed it seems redundant. Fixed that ordering from signer to trust anchor.
>     
>        certificates.  Note that ACME [RFC8555] requires the first element in
>        a pem-certificate-chain to be an end-entity certificate; however,
>        STIR relaxes this requirement, because CA certificates are permitted
>        to sign PASSporTs, so for STIR, the first element in a pem-
>        certificate-chain used for STIR MAY be a CA certificate.
>     
>     [cross-referencing previous question about direct message signature by
>     CA certificates]
>     
> Again, removed this text.
> 
>     Section 8
>     
>        a certification authority itself; serving as a certification
>        authority is a function requiring specialized expertise and
>        infrastructure.  [...]
>     
>     I suppose we could link to
>     https://urldefense.com/v3/__https://cabforum.org/information-for-auditors-and-assessors/__;!!N14HnBHF!o-ni9DilQAbpfleqMWUl4SWcuURZzt37mdzos7UiowvApoTGikIrdMST7Hln3g$    or
>     https://urldefense.com/v3/__https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf__;!!N14HnBHF!o-ni9DilQAbpfleqMWUl4SWcuURZzt37mdzos7UiowvApoTGikIrdMS4W5f4hw$  
>     if we wanted to scare people with exactly how specialized this stuff
>     is...
> 
> Heh.
>     
>        the terminating side.  However, some additional object in the
>        certificate outside of the TNAuthList could preserve that
>        information; this is a potential area for future work.
>     
>     Should we perhaps say that the only mechanism currently defined is to
>     have the longer certification path?
> 
> Okay, done.
>     
>        particular telephone number is encompassed by an SPC.  Alternatively,
>        a CA may acquire an Authority Token that affirms that a delegation is
>        in the proper scope.  Exactly what operational practices this entails
>     
>     nit: I know we talk about "Token Authority" in the first paragraph of
>     the section and forward-reference §8.1, but "Authority Token" is a
>     different thing, so we should probably do the same forward-reference
>     dance here.
> 
> Okay, done.
>     
>     Section 8.1
>     
>     I wonder how much detail we really want to go into here while keeping
>     the acme drafts as only informational references...
>     
>        STIR delegate certificate.  ACME returns an "application/pem-
>        certificate-chain" object with suitable for publishing as an HTTPS
>        resource for retrieval with the PASSporT "x5u" mechanism as discussed
>        in Section 7.  If the CSR presented to the ACME server is for a
>     
>     This would seem to suggest that people actually use the ACME-provided
>     URL as the "x5u" URL.  I don't remember anything in 8555 to suggest that
>     the ACME server is under any obligation to maintain this resource
>     indefinitely (or to allow GET access, vs the required POST-AS-GET), so
>     we should either disavow such a practice or document the relevant
>     considerations and preconditions for relying on the external party in
>     this way.
> 
> Addressed up in your DISCUSS; we'll reword to remove that interpretation.
>     
>        Service providers that want the capability to rapidly revoke
>        delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star]
>        mechanism to automate the process of short-term certificate expiry.
>     
>     We need to reword this.  The STAR mechanism does not provide a
>     revocation mechanism; it merely attempts to obviate the need for an
>     active revocation mechanism.
> 
> Okay - we'll rapidly age them out.
>     
>     Section 11
>     
>        placing calls.  As this information is necessarily a superset of the
>        calling party number that is openly signaled during call setup, the
>        privacy risks associated with this mechanism are not substantially
>     
>     If I understand correctly, "this information" is the information in the
>     parent CA certificate that issued the delegated STIR certificate (as
>     opposed to the delegated STIR certificate itself)?  Baseline STIR needs
>     a certificate, after all, and the new thing here is not the end-entity
>     but the (parent) CA.
> 
> No, "this information" meant the "narrow range" in the previous sentence. I mean, if a TNAuthList is only for 5 TNs, it in some sense exposes more data than a SPC does - it may let you infer that all 5 of the TNs are owned by the same administrative entity, say.

Ah, thanks for clarifying.

And thanks as well for all the other bits that I didn't specifically reply
to; they are also appreciated.

-Ben

>     Section 12
>     
>     It might be worth noting that the delegation mechanism allows for STIR
>     to be used in scenarios where unauthenticated spoofing would otherwise
>     be used, thereby improving the security of the ecosystem.
> 
> Okay.
>     
>     It also seems that RFC 8226 should have linked to the security
>     considerations of RFC 3986 for the case where the TN Authorization List
>     is included in the certificate by reference ("contents available at the
>     URI may change over time", etc.); since those topics are relevant for us
>     as well, it seems like we should at least do so ourselves even if we
>     can't retroactively make 8226 talk about it.
>     
> Okay.
> 
>     I would also suggest reiterating that since STIR certificates use the
>     TNAuthList, rather than conventional X.509 naming schemes, that the
>     "encompassing" check has to be added to the process for determining
>     whether a given certification chain is authorized and valid.  (Yes, that
>     is basically the whole point of the document, but it may be worth saying
>     again.)
> 
> Okay.
>     
>        Security Considerations.  Also see the Security Considerations of
>        [RFC8226] for general guidance on the implications of the use of
>        certificates in STIR.
>     
>     I'd suggest also calling out the discussions of revocation and the
>     risks of caching authorization information due to "skew" over time in,
>     e.g., the SPC database.
> 
> This seems to be largely the same comment as two comments above? Anyway, added a bit about revocation.
>     
>     It might also be worth a callout to Section 8 and the "specialized
>     expertise and infrastructure" involved in operating a CA.
> 
> Works for me.
>     
>     Section 14.1
>     
>     It's a little debatable whether RFC 3261 is a normative reference for
>     this document (though it certainly is for the ecosystem in which the
>     mechanism described by this document are used).
> 
> Fair enough. Moved to informative.
>     
>     Section 14.2
>     
>     As alluded to previously, the acme authority-token drafts are on the
>     borderline of normative and informative.
>     
> I think they just allude to normative behavior that is in the authority-token docs.
> 
>     I think RFC 5280 needs to be a normative reference (not least for the
>     AuthorityKeyIdentifier, SubjectKeyIdentifier, and BasicConstraints
>     extensions).
> 
> Okay
>     
>     The X.680-series references are not used in the body of the document,
>     nor is X.520.
> 
> I'm sure those were left over from the template cut-and-paste, they are now cut.
> 
> Jon Peterson
> Neustar, Inc.
>     
>     
>     
>     
> 
>