Subject: [Anima] additional information and JSON/CBOR

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Nov 2016 11:10:57 +0100

Hi authors,

The Fairhair folk would like some clarity on the following statement in
Section 3.1.7:

>    Functionality to provide generic "configuration" information is
>    supported.  The parsing of this data and any subsequent use of the
>    data, for example communications with a Network Management System is
>    out of scope but is expected to occur after bootstrapping enrollment
>    is complete.

Many of us this, but we need to know how to hook in.  Specifically we're
aiming to provide the address of the resource directory, preferably in a
way that is signed by the registrar.

Also, we're wondering what effort it would be to move to CBOR for
transactions.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Nov 2016 11:11:45 +0100

On 11/17/16 11:10 AM, Eliot Lear wrote:
> Many of us this, 

Sorry- word missing is "like".

Eliot

> but we need to know how to hook in.  Specifically we're
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Nov 2016 21:31:02 +0900

> Also, we're wondering what effort it would be to move to CBOR for

Moving from JSON to CBOR is zero effort if you just do it to gain runtime efficiency or use the better datatypes.

If you want to use the last bit of on-the-wire efficiency, you also want to replace the string-based keys (“IDevIDAuthorityKeyIdentifier”) with integers (say, 7).  That requires some housekeeping; i.e. that is no longer zero-effort.

(The examples in the current draft aren’t always really JSON, but that can be easily fixed.
I usually try to run a publishing pipeline that validates all the examples.)

Grüße, Carsten

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 17 Nov 2016 22:21:13 +0000

> On Nov 17, 2016, at 3:10 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi authors,
> 
> Many of us [like] this, but we need to know how to hook in.  Specifically we're

This has been derailed a bit by the voucher conversation so thank you for bringing it back up. 

The “optional config information” is entirely a potential protocol optimization — which is why it has fallen to the wayside during architectural and alignment discussions (-02 has some more info but its minor so lets just build from -04). 

Let me explain by using the diagram from -04 figure 6:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-04#section-5
(slightly modified for clarity - i’ll make these changes in the doc) 

              +-----------+ +----------+ +-----------+ +----------+
              | Pledge    | | Circuit  | |           | |          |
              |           | | Proxy    | | Registrar | | MASA     |
              |           | |          | |           | |          |
              ++----------+ +--+-------+ +-----+-----+ +--------+-+
               |               |               |                |
               |               |               |                |
               |               |               | /requestvoucher|
               |               |  (nonce       +---------------->
               |               |  unknown)     <----------------+
               |               |               | /requestlog    |
               |               |               +---------------->
               |               |               <----------------+
               |   TLS hello   |  TLS hello    |                |
   Establish   +---------------C--------------->                |
   TLS         |               |               |                |
   connection  |               | Server Cert   |                |
               <---------------C---------------+                |
               | Client Cert   |               |                |
               |               |               |                |
   HTTP REST   | POST /requestvoucher          |                |
   Data        +----------------------nonce---->   (discard     |
               |            voucher            |   nonce)       |
               <-------------------------------+                |
               | (optional config information) |                |
               |               .               |                |
               |               .               |                |

Here we show the flow with nonce-less Audit Vouchers. I chose this flow to highlight that there is *no* realtime communications with the vendor MASA service during actual BRSKI bootstrapping with the client.

The optimization goal: to distribute some config information to the Pledge!
Without optimization the Pledge needs to discover a management system and authenticate it and download the config information via that path. 

Some potential methods in order of integrated optimization:

Possibility-1) The REST response containing the voucher MAY be a a content-type of "multipart/mixed” consisting of two parts: one part is the voucher and the other part is the config information. The Pledge MUST complete s5.3.1 “authentication of the Provisional TLS connection” before accepting and parsing the 2nd part.

Possibility-2) Same as REST response #1 except that the second part “MUST be a signed msg within the PKI hierarchy of the domain as established by the Voucher”.  

Possibility-3) Introduce a followup REST message that the Pledge MAY use to obtain the configuration after s5.3.1 is complete. This allows the TLS connection to be maintained and optimizes the flow but keeps the distinct REST api calls from being overloaded. It is most consistent with section 5.7 and is probably the approach I’d prefer. Using persistent connections this is close to the optimization provided by 1 or 2 and allows for simpler handling on the Pledge. 

It would not be fair to discuss this without touching on how netconf zero-touch draft addresses this issue. The data structure used in draft-ietf-netconf-zerotouch-09 is called “boostrap-information” and it contains an optional “configuration”. This is the equivalent data. How it is protected is discussed in section 6.4 and can be summarized as a similar flow: authenticate the voucher, then use the voucher information to authenticate the signed configuration information. Section 6.3 appears to cover the idea that the bootstrap=information might not be signed although it isn’t clear if the authenticated identity of the bootstrap-server is used for the “Able to bootstrap off any source” conditional or if it simply fails open. Regardless the similarities to the above discussion should be clear. 

- max

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Nov 2016 09:16:08 +0900

Eliot Lear <[email-masked]> wrote:
    >     but we need to know how to hook in.  Specifically we're aiming to
    > provide the address of the resource directory, preferably in a way that
    > is signed by the registrar.

I feel that I'm missing some context, so let me repeat.
You'd like to have a link to a resource directory, and you'd like to have it
signed by registrar.  I just want quibble slightly: while the registrar MAY
be the CA, it isn't always directly the CA, it doesn't necessary have that
kind of CA abilities.  On the other hand, "signed by the registrar" could
mean that it came through the (D)TLS connection from the Registrar, so maybe
that's enough.

In which case, let me repeat part of Max's response:

max> Possibility-3) Introduce a followup REST message that the Pledge MAY use
max> to obtain the configuration after s5.3.1 is complete. This allows the
max> TLS connection to be maintained and optimizes the flow but keeps the
max> distinct REST api calls from being overloaded. It is most consistent
max> with section 5.7 and is probably the approach I’d prefer. Using
max> persistent connections this is close to the optimization provided by 1
max> or 2 and allows for simpler handling on the Pledge.

I definitely prefer that keeping up.  I would suggest that a TLS resumption
ticket be obtained and stored long term.

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