Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) [COMMENTS]

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Nov 2019 15:47:54 -0400

I may post this as -30 on Monday, or I may wait as your requested changes are
minor.   https://tinyurl.com/y6op6z5y

Benjamin Kaduk <[email-masked]> wrote:
    >> The original purpose of the subjectKeyIdentifier was to indicate which
    >> keypair the client (pledge) had attempted to enroll. Upon successful
    >> enrollment, a new TLS connection is started (usually), which proves that the
    >> enrollment is success, and so no KeyIdentifier is needed.
    >> In the case of a failure, the existing TLS connection is maintained, so
    >> the server (Registrar) can associate the failure with the previous attempt
    >> to enroll.
    >> This change (removing the subjectKeyIdentifier) was made in -05, but the
    >> prose was not updated. The use of a subjectKeyIdentifier, which might no
    >> longer be a SHA-1 hash of a public key, is problematic, as the CSR does
    >> not include an appropriate KeyIdentifier, so the server would be left
    >> trying to calculate it, using the default (and now obsolete) SHA-1
    >> mechanism. Including the KeyIdentifier has proved more trouble than
    >> benefit.

    > The removal of SKI seems okay, but I'm still looking for something like
    > "the body of the POST is a JSON object with the following [whoops, I forget
    > the right terminology for name/value pairs]"

I have added some text, and some CDDL.
+   enrollstatus-post = {
+       "version": uint,
+       "status": bool,
+       "reason": text,
+       ? "reason-context" : { $$arbitrary-map }
+     }
+   }
+
+                Figure 18: CDDL for enrollment status POST
+

    >> Esko has complained that we have 14 open issues; that's probably negligence
    >> on my part about not closing them as we solved the issues.
    >> So we also closed all but three "auth48" tickets that had been opened.
    >>
    >> > Section 2.5.1
    >>
    >> >    The pledge is the device that is attempting to join.  The pledge can
    >> > talk to the Join Proxy using link-local network connectivity.  In most
    >> > cases, the pledge has no other connectivity until the pledge completes
    >> > the enrollment process and receives some kind of network credential.
    >>
    >> > I'd consider s/can talk to/is assumed to talk to/.
    >>
    >> okay.  some have complained this isn't strong enough.
    >> Maybe MUST talk to?

    > I don't have a strong opinion on this, but it feels like something that
    > will probably be different for ACP vs. other deployments -- MUST feels
    > right for ACP but is probably not universal.

I am leaving the text as I put it above.

    >> > How painful would it be to require 1.3 at this point?  RFC 8446 has
    >> > been out for more than a year, and the TLS WG is leaning on me to
    >> > tighten up on this...
    >>
    >> Yes, but how many FIPS-140 validated TLS 1.3 implementations are there that
    >> are drop-in available to router platforms with 3-5 year R&D cycles?
    >> OpenSSL is FIPS for 1.0.1 and 1.0.2 which do not include TLS 1.3, for
    >> instance (which is 1.1.x).

    > I take it that FIPS-140 validation is required for those $100k BFRs, then?

That's what implementers said awhile ago.

    >> WolfSSL has FIPS-140 for TLS 1.3 (to read the press releases), and some
    >> entities could drop it in, but others might have license issues.
    >>
    >> How about if I change the text to say:
    >>
    >> Use of TLS 1.3 (or newer) is encouraged.
    >> TLS 1.2 or newer is REQUIRED on the Pledge side.
    >> TLS 1.3 (or newer) SHOULD be available on the Registrar server interface,
    >> and the Registrar client interface, but TLS 1.2 MAY be used.
    >> TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS
    >> 1.2 MAY be used.

    > That's an okay compromise on the 1.3-encouragement front, but I don't think
    > that everyone will read "Foo server interface" and "Foo client interface"
    > in the same way.

ok.

    > editorial nits on the linked diff:

    > Section 2.5.3 talks about the set of MASA that are trusted being limited
    > by the MASA TA database, but in the paragraph about the BRSKI-EST client
    > TA database.

2.5.3.  Domain Registrar

   ...
   The registrar uses an Implicit Trust Anchor database for
   authenticating the BRSKI-MASA connection's MASA TLS Server
   Certificate.  Configuration or distribution of trust anchors is out-
   of-scope for this specification.

   The registrar uses a different Implicit Trust Anchor database for
   authenticating the BRSKI-EST connection's Pledge TLS Client
   Certificate.  Configuration or distribution of the BRSKI-EST client
   trust anchors is out-of-scope of this specification.  Note that the
   trust anchors in/excluded from the database will affect which
   manufacturers' devices are acceptable to the registrar as pledges,
   and can also be used to limit the set of MASAs that are trusted for
   enrollment.

I'm not seeing the issue.  We split up paragraphs to clarify things, but
maybe we failed.

    > s/described Appendix B/described in Appendix B/ (sorry, section number
    > not visible from diff; maybe 40% through the diff)

fixed.

    > Section 5.4 is missing an "for" in "SHOULD be used for authentication of
    > the MASA".

fixed.

    > s/accesptable/acceptable/

fixed.

    > Figure 17 is introduced as an "abstract example", though it seems more
    > of a concrete one after this diff.

fixed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Nov 2019 16:14:22 -0400

Benjamin Kaduk <[email-masked]> wrote:
    doc> although it results in additional network traffic.  The relying MASA
    doc> implementation MAY leverage internal state to associate this request
    doc> with the original, and by now already validated, voucher-request so
    doc> as to avoid an extra crypto validation.
    >>
    >> > It seems that doing so would turn the voucher-request into a bearer
    >> > token for retrieving audit-log information (if the MASA accepts
    >> > unauthenticated clients).
    >>
    >> That's what's intended.

    > I can see why that functionality is needed, but it seems likely to
    > introduce some privacy and/or security considerations to document.  It's a
    > bit too late in the day for me to reason through them, though.

To be clear: any registrar which has ever formed a valid voucher-request MAY
retrieve the audit-log at regular intervals to verify the status of the
device.  The words, "now already validated" means that the MASA agreed with
the voucher-request.  Most implementations are going to log the
voucher-request as part of the internal audit log, so a memcmp() on that is enough.

This would reveal new owners.  Whether the new owner is legitimate or not is
not something we can answer: it might be that the device has been stolen, or
maybe it's legitimately lent, rented, sold, etc.

    >> > Section 11
    >>
    >> > I am somewhat embarassed that I did not previously note that the
    >> > mechanism used to generate the domainID needs to be
    >> > second-preimage-resistant or an attacker can claim to be a registrar for
    >> > a domain that already exists.
    >>
    >> Right now, that's in:
    >>
    >> 5.8.2.  Calculation of domainID
    >>
    >> The domainID is a binary value (a BIT STRING) that uniquely
    >> identifies a Registrar by the "pinned-domain-cert"
    >>
    >> If the "pinned-domain-cert" certificate includes the
    >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
    >> used as the domainID.  If not, the SPKI Fingerprint as described in
    >> [RFC7469] section 2.4 is to be used.  This value needs to be
    >> calculated by both MASA (to populate the audit-log), and by the
    >> Registrar (to recognize itself).
    >>
    >> We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to
    >> replace it appropriately.

    > That's all good and admirable; I'm suggesting that we add a note in the
    > security considerations of this document noting that we rely on the
    > domainID (however determined) to be second-preimage-resistant.

I've added this to the security considerations as 11.2.

    doc> Although the nonce used by the Pledge in the voucher-request does not
    doc> require a strong cryptographic randomness, the use of TLS in all of
    doc> the protocols in this document does.
    >>
    >> > We discuss the need for strong randomness in the nonce in Section 11.3,
    >> > so it's not clear this is actually true.
    >>
    >> We don't think that the voucher nonce has to be of the same quality as something that
    >> goes into a KDF.  It is at the level of TCP Sequeunce number, not seed for
    >> generating a private key...

    > I mean, we literally say "Reducing the possibility of this is why the
    > pledge is mandated to generate a strong random or pseudo-random number
    > nonce."  So to also say "the nonce [...] does not require a strong
    > cryptographic randomness" seems to be in conflict with the former
    > statement.
    > Are you saying that "strong random" and "strong cryptographic random" mean
    > different things, or am I misreading the document in some other way?

I take your point, and I guess we were splitting hairs.
I'll just rephrase it to remove the Although statement.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [