Subject: [Anima] underspecification in handling of unsigned voucher requests

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Dec 2018 12:09:50 -0000

Max, one of the hurdles that the Fairhair Alliance interop experienced was
due to under-specification of the unsigned pledge request.  Most implemented
unsigned pledge requests because it was simpler.

In the past two weeks I was trying to implement unsigned pledge requests, and
I had a number of assumptions challenged in the process.
I am seriously of the opinion that unsigned voucher requests (whether
constrained or not) may have no value at all and should be removed.
(At least, I would like to write that they are unwelcome in the ACP
applicability section)

Assumptions I had which were not verified by our text:

1) that the unsigned voucher request should be placed into
   prior-signed-voucher-request in (parboiled: Registrar->MASA)
   voucher-request.
   The MASA can distinguish between a signed object (which may be a voucher
   request, or a prior signed voucher for renewals[%1]).

2) that the unsigned voucher request should even be copied to the MASA *AT ALL*
   We don't say anything about that.  We hardly even talk about the
   processing.
   I enclose text/diff at the bottom to change that.

3) I assumed that the proximity-registrar-cert has meaning in the unsigned
   voucher-request.  One might claim that it's presence provides no value at
   all since the request is not signed.
   The only piece that has any value would seem to be the nonce.
   So if the pledge has a clock and does not need freshness in it's voucher,
   it could use a time-limited voucher (expiry-on set), then it would
   essentially send an empty voucher-request.  This surprised me to realize.

4) If the unsigned voucher-request has no value/content, why send it on to
   the MASA at all.  I pondered this for awhile, and then remembered that
   this is a channel from the Pledge to the MASA, and that we wanted to
   permit this channel to be extensible and available for proprietary uses if
   desired.  We have this for signed voucher-requests as is.
   If we want to maintain this for unsigned voucher-requests, then we need
   to mandate that it be passed upwards.

Putting unsigned (JSON) into prior-signed-voucher-request seems wrong from a
YANG point of view: see next message on that.

[%1] - can vouchers with nonces be renewed by the MASA?  I think we will need
     clarifying text once someone has implemented this.

diff --git a/dtbootstrap-anima-keyinfra.txt b/dtbootstrap-anima-keyinfra.txt
index a5c4163..8ac806b 100644
--- a/dtbootstrap-anima-keyinfra.txt
+++ b/dtbootstrap-anima-keyinfra.txt
@@ -2062,17 +2118,30 @@ Internet-Draft                    BRSKI                    November 2018
    Example 1.

    The registrar validates the client identity as described in EST
-   [RFC7030] section 3.3.2.  If the request is signed the registrar
-   confirms that the 'proximity' asserion and associated 'proximity-
-   registrar-cert' are correct.

+   [RFC7030] section 3.3.2.  This involves validating the signatory of
+   the TLS Client Certificate.  As described in the next section, there
+   are different models for authorizing accepted devices.

+
+
+   If the request is signed the registrar confirms that the voucher-
+   request is signed by the same key as terminates the TLS connection.

+   The Registrar extracts the serial-number of the pledge from the TLS
+   Client Certificate.  It uses this serial-number to form it's voucher-
+   request.
+
+   The Registrar examines the pledge's voucher-request (verifying the
+   signature, if the request is signed) and extracts any nonce present
+   to include in it's voucher-request.  In addition, any 'proximity'
+   assertion and associated 'proximity-registrar-cert' need to be
+   verified to be correct.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Dec 2018 12:42:53 -0000

I've tried to add a new field to the (parboiled) voucher-request that
would go from the Registrar to the MASA.  This is to contain a copy of the
unsigned raw (Pledge->Registrar) voucher-request.  This is for the situation
where that request is unsigned.

Kent, I'll need some help here.  I think this may call for a YANG mount?
As I'm trying to say that at the pledge-voucher-request that there will be
an instance of voucher-request.
(I've written "binary" for the moment so that the YANG will compile)

I've also specified that the entire JSON (including the outer:
"ietf-voucher-request:voucher" should go here. I don't know if that's typical
JSON serialization.  Whether or not it goes there, the document needs to be
explicit about it.
(ps: I'd rather remove unsigned requests though)

        leaf pledge-voucher-request {
          type SOMETHING;
          description
            "When the pledge provides an unsigned voucher request, the
             Registrar includes the contents of that voucher-request verbatim
             in this field.  The serialization of the Registrar to MASA
             voucher-request is assumed to be the same as the serialization of the
             Pledge to Registrar voucher-request.

             The entire contents of the voucher-request including any outer
             ietf-voucher-request:voucher should be included in this field.

             The Registrar should not be surprised if there are additional
             attributes, private between the pledge and MASA that are included
             in this field.";
        }

+
+        <t hangText="pledge-voucher-request:">If an unsigned
+        voucher-request was received, then it is included in this field
+        rather than in the prior-signed-voucher-request field.  Within the
+        context of the ACP scope, unsigned voucher-requests are received in
+        JSON format, therefore this field is in JSON format as a dictionary.
+        It includes the outer "ietf-voucher-request:voucher" layer.
+        This is in contrast to the signed version, where the signed artifact
+        is include in a base64 format.  It is not illegal for attributes
+        unknown to a registrar to be included by the pledge.
+        </t>
+

...
+       +-- pledge-voucher-request?          binary