Subject: [Anima] Technical comments on draft-ietf-anima-bootstrapping-keyinfra-09

From: William Atwood <[email-masked]>
Date: Sat, 10 Feb 2018 22:04:05 -0500

As a result of trying to understand (and then to model) the protocol
flow for BRSKI, I have made a review of
draft-ietf-anima-bootstrapping-keyinfra-09.  The following are my
technical comments.  A separate list of suggested minor editorial
changes has been sent to the authors.

  Bill

Section 1, para 3, lines 4-5.  "is a minor extension to the voucher
format (see Section 3)."  What "voucher format"?  I guess that you mean
the voucher format defined in draft-ietf-anima-voucher.  I suggest some
additional precision here.

Lines 4-5.  Why is this "minor extension" defined here, and not in
draft-ietf-anima-voucher?  Would it not be better to have all (currently
known) voucher formats in one place?

Section 2.3, para 2, line 1.  "previously defined fields"  Where are
these defined?  Are they previously defined in this document?  Are they
previously defined in some other document?  (If so, give reference.)

In general, this paragraph and its two bullets might be understandable
by someone who is well familiar with X.509, but they are opaque to
someone who is not (i.e., this reviewer).  I believe that your message
would be much clearer if you first defined (or explained) what is in the
X.509 certificate (that you are going to use), and then specified the
constraints/extensions that you are going to impose.

Here is my (possibly incorrect) understanding:

<begin understanding>
The X.509 certificate contains a "subject" field, which in turn contains
a DN encoding.  (What is "DN"?  Please define the acronym.)  For a
voucher, this DN encoding MUST include the "serialNumber" attribute.

The X.509 certificate also contains a "subject-alt" field.  For a
voucher, this field SHOULD contain a "HardwareModuleName".

Three possible mappings are given to produce the "serial-number" field
in the voucher.

A new extension for the X.509 IDevID certificate contains a URI pointing
to the MASA.  IRIs MUST be mapped to URIs in a specific way.
<end understanding>

However, I had to struggle to come to this understanding.  Hopefully,
new text can be introduced to ensure that future readers will come to
this understanding more quickly.  After all, if our goal is to ensure
correct implementations of the spec, it would be helpful if the spec
were clear and specific.

Section 2.3, para 5, line 4.  In this document, the string ".well-known"
appears variously as ".well-known", "./well-known", and "/.well-known".
If these are in fact intentional, then the differences should be
explained.  Otherwise, a consistent form should be ensured throughout
the document.  Given that I do not know what is correct, or if they are
intended to be different, I have not signaled these cases in my General
Comments.  You will have to do a search to discover all the instances.

Section 2.6, para 1.  I find this entire paragraph puzzling.  I believe
that more text is required here, in the hope that the use cases will be
clearer.  Perhaps the use cases need to be stated first, followed by the
allowed actions.

Section 3, para 1, line 6.  What is the meaning of
'"proximity-registrar-cert" leaf'?  What is the leaf a leaf of?  If this
refers to some YANG module, please cite the YANG module.

Section 3.2, Example (2).  Does this example illustrate _a_ Registrar
voucher-request, or does it illustrate the Registrar voucher-request
that would be used to forward Example (1)?  If the former, why is the
nonce identical?  If the latter, it should be explained that certain
other fields are carried forward as well.

Section 4.1, para 2, bullet 2, line 3.  "may" -> "MAY"  (This "may"
seems to be normative.)

Para 7, line 2.  "should" -> "SHOULD"

Section 5, para 8, bullet 1.  The reference to RFC6125 appears to be
normative, and so RFC 6125 should be added to the list of (normative)
references.

Section 5.4, para 9.  This paragraph gives a series of actions that are
described in the introductory material as "validation checks".  However,
the first bullet is describing a renewal action, not a validation check.
 I suggest that the phrase "The MASA validation checks before issuing a
voucher are as follows:" be replaced with "The MASA performs the
following actions and validation checks before issuing a voucher:"

Section 5.8, para 2, line 1.  "the following EST"  (I have no idea where
these "following" items are.  The subsequent subsections are clearly not
extensions, so I cannot determine what is being referenced here.  Since
this is a "recommendation", it is important that it be clear to the
reader what is intended.

Para 2.  This paragraph is quite opaque to me.  I cannot follow the
logic of the sequence of statements.  Does the second sentence imply
"one-at-a-time" operation, or something else?  In the third sentence,
requests will "look the same" as what?  Each other, something else?

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Feb 2018 15:09:34 -0500

tl:dr: https://github.com/anima-wg/anima-bootstrap/pull/41
       https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-10&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/bill-atwood-comments/dtbootstrap-anima-keyinfra.txt
        or: https://goo.gl/pXNghv

    > additional precision here.

Added another reference to anima-voucher document at the end of the paragraph.

    > known) voucher formats in one place?

No, because anima-voucher is used by the RESTCONF work in the NETCONF WG, and
they have no use for the voucher-request.

    > someone who is not (i.e., this reviewer).  I believe that your message

so, I think that understanding something about PKIX (X509) and EST is
unavoidable, and I don't think we should clutter the document explaining
those parts.

    > Comments.  You will have to do a search to discover all the instances.

./well-known is a typo.  I've put / in front of every use.
/.well-known refers to rfc5785.
RFC7030 (EST) all lives under /.well-known/est.
I've added a reference to 5785 at the first use of /.well-known.

    > clearer.  Perhaps the use cases need to be stated first, followed by the

Max, I have added a paragraph to explain the legacy situation that the "Cloud
        <t>
          There are transitional situations where devices may be
          deployed into legacy networks that use proprietary
          bootstrapping mechanisms based upon the base EST (<xref
          target="RFC7030"/>).  The same device may also be deployed
          into an ANIMA environment.  This may be due to incremental
          replacement of a legacy situation with ANIMA.
        </t>
        <t>
          There are additionally some greenfield situations involving an
          entirely new installation where a device may have some kind of
          management uplink that it can use (such as via 3G network for
          instance).   In such a future situation, the device might use
          this management interface to learn that it should
          configure itself by to-be-determined mechanism (such as an Intent)
          to become the local registrar.
        </t>
        <t>
          In order to support this scenario, the Pledge MAY contact a well
          known URI of a cloud Registrar if a

    > refers to some YANG module, please cite the YANG module.

So the title of the section is "Voucher-Request artifact", and the entire
section is about the YANG module ietf-voucher-request.  I have added one
phrase: "defined in this section"

    > other fields are carried forward as well.

The nonce, created-on and assertion are carried forward.
I have changed the text to say:

                The 'prior-signed-voucher-request' leaf is populated with the Pledge's
                voucher-request (such as the prior example).  The pledge's
                voucher-request, if a signed artifact with a CMS format
                signature is a binary object.  In the JSON encoding used
                here it must be base64 encoded. The nonce, created-on and
                assertion is carried forward. serial-number is extracted from
                the pledge's Client Certificate from the TLS connection. See
                <xref target="RequestVoucherFromMASA"/>.</t></list></t>

    > Section 4.1, para 2, bullet 2, line 3.  "may" -> "MAY"  (This "may"

Yes, thank you.

    > Para 7, line 2.  "should" -> "SHOULD"

done.

    > normative, and so RFC 6125 should be added to the list of (normative)

Added.

    > following actions and validation checks before issuing a voucher:"

changed.

    > this is a "recommendation", it is important that it be clear to the

Changed to:
        <t>The Pledge is also RECOMMENDED to implement the EST automation
        extensions described below. They

Max, I think that this is a "SHOULD"

    > requests will "look the same" as what?  Each other, something else?

I think that I don't know which paragraph you are referring to.

    > Distinguished Professor Emeritus  fax:   +1 (514) 848-2830

Onward to your other editorial comments.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Feb 2018 17:49:49 -0500

> flow for BRSKI, I have made a review of

Bill also did an extensive grammar review, which was invaluable.
The URL: https://goo.gl/pXNghv now shows all the changes as they are all
pushed onto the same pull request.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 14 Feb 2018 23:14:28 +0000

Much thanks for Michael Richardson for putting these diffs together. Comments inline,

> On Feb 14, 2018, at 1:09 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

A simpler case could be, 

“There exist operationally open network wherein device gains unauthenticated access to the internet at large. In these use cases the management domain for the device needs to be discovered within the larger internet. These are less likely within the anima scope but may be more important in the future."

(I’ve added this comment within github as well in prep for the pull request)

> Max, I think that this is a “SHOULD"

RFC2119 indicates these are equivalent. I bow to your sense of grammar on this. Use of SHOULD is clearer:
"The Pledge SHOULD implement…”

> I think that I don't know which paragraph you are referring to.

This is the para in question:
          Although EST allows clients to obtain multiple certificates by sending
          multiple CSR requests BRSKI mandates use of the CSR Attributes request
          and mandates that the Registrar validate the CSR against the expected
          attributes. This implies that client requests will "look the same” …

The point here is that if the client does CSR Attributes and the “Registrar validate[s] the CSR against the expected attributes” then it is not possible to leverage this specific connection to request multiple different client certificates (because of the above requirements). As a result a BRSKI initiated EST connection will result in a single client certificate. If the above is followed and expected every request from the client to the server ‘will look the same’ and every certificate issued will look the same. 

Solutions would include: tearing down the session and starting a new EST session to obtain more complex certs for other, non-anima, purposes. Or expanding on the CSRAttributes and validation logic to allow for multiple certs. None of which are necessary for anima. 

- max

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima