> On Nov 17, 2016, at 3:10 AM, Eliot Lear <l...@cisco.com> wrote: > > 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 [like] 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.
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 > > Also, we're wondering what effort it would be to move to CBOR for > transactions. > > Eliot > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
