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

[Michael Richardson <[e-mail]>]

I have responded to DISCUSSes from:
Alissa Cooper: https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU
Roman Danyli: https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI  
Alexey Melnikov  https://mailarchive.ietf.org/arch/msg/anima/Ul0yfnf4UlQhoI0UtlJVZ9otY7M
Adam Roach:    https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA
Eric Vyncke:  https://mailarchive.ietf.org/arch/msg/anima/O860UBbY4p3iNOZUdEYF_iNKMvs

plus comments:
Mirja Kühlewind  https://mailarchive.ietf.org/arch/msg/anima/jFuz6ugS-_1bf0HG46vMjf3UNaw
Magnus Westlund: https://mailarchive.ietf.org/arch/msg/anima/g1c17bHiBUMuhCmw4RDoHoN_1zE
and noted comments from Barry and Warren.

and this is for Ben Kaduk's DISCUSS, which got buried, and I think is the last.

I'm going to use this email to deal with Ben's comments which I think we
already dealt with other edits, then I'll deal with low-hanging fruit, and
then decide how to deal with the desire for a high-level security analysis.

Benjamin Kaduk via Datatracker <[e-mail]> wrote:
    > (5) RFC7951 is cited for the audit log response, but I cannot find the
    > underlying YANG module that is JSON-encoded using the RFC 7951
    > procedures.  Furthermore, I don't think the "nonce" handling (with
    > explicit "NULL" string where base64-encoded binary data might be
    > expected) would be consistent with the 7951 rules.

We did not resort to a YANG data model for the auditlog responses, so I spent
a few minutes mystified by your complaint... then:
We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 (JSON)!
(Those numbers are annoyingly similar. And we actually made this mistake
before, I wonder if this was collatoral damage from a global search and replace)

    > (6) In Section 7.2:

    >    The pledge can choose to accept vouchers using less secure methods.
    > These methods enable offline and emergency (touch based) deployment use
    > cases:

    >    1.  The pledge MUST accept nonceless vouchers.  This allows for a
    > use

    > It's very unclear to me what this "MUST" means, especially so given
    > that the entire section 7 is declared to be non-normative.  Is it that
    > the client "can choose" whether it "MUST accept nonceless vouchers"?
    > That would seem to make the MUST basically ineffective.




    > More broadly, if the entire Section 6 is non-normative, why is there
    > any normative language in it?

First, I think you mean section 7?
If so, the reason for normative language is because, we want to say, "if you
do X, then you MUST do it this way".

Second, we have referenced some pieces of section 7.2 from section 9.
We think that there are significant security issues by accepting nonceless
vouchers, which we discuss in 11.1.   A variation of the protocol is when
the manufacturer programs the pledge to ALWAYS accept nonceless vouchers.
There could otherwise be some more complex (proprietary, or documented later
on) evaluation of whether to accept a nonceless voucher. For instance, the
MASA could sign them with a different key, perhaps one stored in an HSM.

A key point is that the Manufacturer/MASA knows exactly the rules that the
Pledge has been coded to, and we don't need to agree on all these rules to
get interoperability. Originally, we didn't even think we needed to
standardize the voucher, just the voucher-request; but it was the desire to
audit them on the Registrar that changed our mind.

    > (7) the new /enrollstatus and /voucher_status well-known EST endpoints
    > are not registered in Section 8.1

Good catch, we have since been told by the .well-known designated expert that
either we create a new registry, or we just ask IANA to point the "est"
definition at RFC7030 and this document.  Most .well-known entries do not
have registries.

I haven't heard a clear opinion as to which we should do.

    > (7.1) I think we also need to register the
    > "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace.

added.

    > (8) The versioning mechanism for Pledge BRSKI Status Telemetry is
    > underspecified, including the interaction with new registered values.

This was updated based upon comments from Adam.

    > (9) The versioning mechainsm for the MASA audit log response is
    > underspecified, including whether a registry of field names is
    > appropriate.

This was updated based upon comments from Adam.

    > (10) The term PKIX seems to be incorrectly used a few times; it refers
    > to the Internet PKI, and so things like a private PKI internal to a
    > manufacturer would probably not be best described as such.  Such
    > private PKIs can of course still reuse the protocols and mechanisms
    > developed for PKIX, and it's accurate to describe them as such.

I would never call the Internet PKI "PKIX".
I'd call it WebPKI, or CAB.
PKIX is the set of IETF specifications that made X509v3 useful.
(And why I try never to use "X509"...)

I couldn't find a reference to private PKI, so maybe I mis-understand.

    > (11) In a few places we describe the voucher-request in terms of its
    > YANG structure but do not say that it has to be wrapped in a signed CMS
    > object as is done for the RFC 8366 voucher.

I will review this; previous versions (prior to ~20) provided for both signed
and unsigned voucher requests, and we removed this feature.
I added some phrases to sentences in section 3:

       <t>
-        A pledge forms the "pledge voucher-request" and submits it to the
-        registrar.
+        A pledge forms the "pledge voucher-request", signs it with it's
+        IDevID and submits it to the registrar.
       </t>
 
       <t>
-        The registrar in turn forms the "registrar voucher-request", and
-        submits it to the MASA.
+        The registrar in turn forms the "registrar voucher-request",
+        signs it with it's Registrar keypair and submits it to the MASA.
       </t>

    > (12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the
    > domainID calculation?

What we really want is a hash of the registrar's key/cert.
We don't want to list it literally in the auditlog as it divulges too much.
We just want the RFC5280 Subject Key Identifier (4.2.1.2), but since both
the Registrar and the MASA need to calculate this value, we had to be
specific as to how it is done.  If there is a better reference with better
agility, please let us know.
If the Registrar could be depended upon to always provide the extension, then
we could use the extension contents directly.

    > (13) In Section 5.5.1:

    >    As described in [RFC8366] vouchers are normally short lived to avoid
    > revocation issues.  If the request is for a previous (expired) voucher
    > using the same registrar then the request for a renewed voucher SHOULD
    > be automatically authorized.  The MASA has sufficient

    > I don't understand what "for a previous (expired) voucher" means.  Is
    > it something like "containing the same content as a previous voucher
    > request for which a voucher was issued", with the presumption that the
    > voucher expired before the pledge could successfully imprint, so it
    > needs to try again?  Or does this extend to longer timescales, like a
    > device that gets deployed for a couple years and is then reset to
    > factory settings and has to rebootstrap but is still by the same
    > registrar?

It is intended for both uses.
Either to be able to easily extend a short-lived voucher, or to get another
one years later.  The MASA does not need to actually use the included
history; it can ignore it completely and make an entirely new decision.

    > (14) In Section 5.6:

    >                             The server MUST answer with a suitable 4xx
    > or 5xx HTTP [RFC2616] error code when a problem occurs.  In this case,
    > the response data from the MASA MUST be a plaintext human- readable
    > (ASCII, English) error message containing explanatory information
    > describing why the request was rejected.

    > It seems hard to support this stance on internationalization in 2019.

We don't believe that this response will go anywhere other than logs,
for software suppliers to evaluate.  Localizing these error message causes
more problems in my experience than benefit.  90% of the information is in
the 4xx/5xx code.

    > (15) In Section 5.9.4:

    >    To indicate successful enrollment the client SHOULD re-negotiate the
    > EST TLS session using the newly obtained credentials.  This occurs by
    > the client initiating a new TLS ClientHello message on the existing TLS
    > connection.  The client MAY simply close the old TLS session and start
    > a new one.  The server MUST support either model.

    > Is this supposed to be sending a new TLS ClientHello in the application
    > data channel or as a new handshake message (aka "renegotiation")?  The
    > latter is not possible in TLS 1.3 and is generally disrecommended
    > anyways even in TLS 1.2.  I would strongly suggest to remove the
    > "renegotiation" option and just leave "close the connection and start a
    > new connection/handshake".

Okay, fixed to say:

           <t>To indicate successful enrollment the client SHOULD re-negotiate
           the EST TLS session using the newly obtained credentials. This
-          occurs by the client initiating a new TLS ClientHello message on the
-          existing TLS connection. The client MAY simply close the old TLS
-          session and start a new one. The server MUST support either
+          occurs by the client closing the existing TLS connection, and
+          starting a new one. The server MUST support either
           model.</t>

    > Appendix C

    > I don't know how important file "[e-mail]"
    > is, but it seems a tad generic.

I changed ietf-mud-extension to ietf-mud-brski-masaurl-extension.

    > Appendix D

    > [Just checking that Michael wants sandelman.ca embedded in the final
    > RFC]

I don't have a problem with it. There is an error:
   3726:d=9  hl=2 l=  55 prim: UTF8STRING        :#<SystemVariable:0x00000

where a variable name rather than it's value went into a certificate, and I
will probably re-run it again before AUTH48.  We haven't gotten 100%
interoperability proven yet inside FairHair Alliance, so I can't be sure it's
all correct.

I'll stop here, and continue in a new email.

This is an rfcdiff from the already-wrapped JSON to the proposed -23 that
includes all the changes from the various DISCUSSes up to now:
  https://tinyurl.com/y2qhjwh8


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