[Anima-bootstrap] keyinfra-03 review

[peter van der Stok <[e-mail]>]

Hi Max,

In Berlin you asked for more reviews of the keyinfra (bootstrapping) 
draft.
Below my efforts from a constrained device/network point of view.
I hope the review helps to get the validity of this document for the 
constrained world better understood.

Greetings,

Peter

__________________________________________________________________________________________________________________

Anima-bootstrapping-keyinfra-03
In general:
I think this is quite an important document to standardize autonomous 
security bootstrapping in the control plane, but its relation to 
constrained devices could be improved and clarified.
I found it difficult to review the document because there is much 
overlapping text that describes the same protocol or function but in 
different words. Also I recommend the use of consistent terminology. For 
example, the terms new entity, device and new device, probably denoting 
the same thing, are used throughout the document. A consistent choice 
would help the reader. The terms vendor service, MASA, or just vendor 
could be aligned in figures and text.  As a result this is a quite 
high-level review, in which I mainly try to point out ways to improve 
the readability.
In more detail:
There are two authorizations in the document: a provisional one and a 
definite one. Giving them different names and referring to them by these 
names would help. For the moment a reader has to guess what “authorized” 
means in different parts of the text. The term Zero-touch approach could 
be explained in section 1.1.
Page 4.
The 4 questions at the top of page 4 need rephrasing. Especially the 
words “who”, “mine”, “it”, and “I” are ambiguous.
Suggest to remove in the second paragraph: “The domain’s decisions …. 
Auditable fashion”. This is difficult to follow and needs information 
provided later.
Optimal security (remove optimal)
“Bootstrapping  … secure”. Remove, does not help.
Last phrase before 1.1: reduce to: Support of alternative key 
infrastructures is discussed.
Page 5: DomainID. Remove “(a string value … is used)”. This information 
does not help me.
Pledge: to at the factory (which one to or at?)
  belongs with this network (you mean domain?)
section 1.2. I find the discussion in this section very hard to follow. 
The general message I receive, is “constrained networks” are out of 
scope (NO 802.15.4); unless you execute only parts of the bootstrapping 
protocol. But executing parts of the protocol is not allowed. On the 
other hand an argument is made about the size of the messages being 
prohibitive; but it is not clear what sizes we discuss. Later in the 
document (section 5.7.5) a discussion about CoAP and DTLS follows; but 
the relation with this section is unclear.
My suggestion is to clarify the end state expected from the key 
distribution as explained in section 3.1.7. Explain that constrained 
devices may need this state, mention the intended use of coap (section 
3.2.1) and point out where the bootstrapping communication may be long 
(transport of certificates) and will need the block option of CoAP.
Page 9: Is ownership tracker part of MASA? In the rest of the document 
its existence seems not essential.
Section 3. The first paragraph about autonomic fashion should go to 
section 1, where the relation with ACP could be clarified. In general: 
Ignoring non autonomic aspects will help the readability of this 
document.
Figure 2 is quite helpful, but why is there a figure 5 and 6 on pages 29 
and 30; and what are the differences?
Section 3.1 I don’t understand: “A new entity…. been configured” Why 
not; I assume the protocol detects this behaviour.
Page 12: identify itself AND authenticate Registrar (they have equal 
importance)
Page 13: point 3: why the text about nonce? This will be treated several 
times later in the text.
Point 4: Very confusing to me. Many terms are used that are explained 
much later, like: Audit token, ownership voucher, Registrar server 
certificate.
Point 5 “e.g. EST”. Why e.g. it seems to be the only option later in the 
text. If not can it be made more explicit that other methods are 
supported.
Section 3.1.1 Discovery. The standardization of the discovery of the 
proxy (registrar) does not seem necessary to me. The bootstrapping 
protocol is not affected at all when different discovery protocols are 
used. Just citing GRASP and mDNS as examples within their context seems 
more than sufficient to me.
Section 3.1.2 phrase 1; to what? does the new entity identify itself?
Paragraph 2: What is the bootstrapping protocol server here? The proxy 
or the Registrar? Is it the data received from the registrar that is not 
trusted? But the data from the new entity is trusted? And why is a TLS 
connection needed, if no data is trusted?
Page 15, last phrase before 3.1.3: bootstrapping server -> registrar? 
New device -> new entity?
Section 3.1.3. Is this where EST is started? Might be helpful to 
indicate which parts are already fixed by EST.
The phrase: “Since client authentication occurs during TLS handshake” is 
confusing. Is this the TLS handshake discussed under 3.1.2 or a new one? 
Neither is it clear if this is the provisional authentication or the 
final one.
This section in general needs more clarification and description of the 
flow on how redirections to a different Registrar works.
Section 3.1.4 why cite the non autonomic (and non used) enrolment 
protocols?
The audit token provides sufficient information to continue, but the 
ownership voucher does not?
Section 3.1.5. Why this last paragraph about time distribution?
Section 3.1.6 mentions audit token and ownership voucher; but only 
discusses audit token afterwards to start RFC7030 process.
Section 3.1.7 specifies the final purpose of the key distribution? IMO 
part of this text should go to the introduction to motivate the 
bootstrapping protocol and also show its validity for constrained 
devices and networks.
3.2 facilitates communication between ???. According to figure 2 the 
registrar is not necessarily configured on the Proxy.
What is a control plane CPU? Probably text has gone missing.
Not clear from the text how/why a device becomes a proxy and by whom/how 
it is configured with the relevant information like the Registrar’s 
address.
Section 3.2.1 The choice between DTLS and TLS appears all of the sudden. 
All former text discussed TLS; I suggest that a different section is 
dedicated to use of CoAP, describes the http/TLS to coap/dtls mapping, 
and the draft consistently uses TLS for clarity. Section 3.2.1. is then 
more dedicated to the discovery and keeping proxy stateless.
Section 3.2.2 suggests multiple options to proxy the connection to the 
Registrar. Can other methods be used beyond that are listed here.
Section 3.3.1 should the out of band be cited here? The draft describes 
autonomic behaviour.
End of section 3.3.2; why the emphasis on homenet?
Section 3.3.3, 2nd paragraph; examples might be handy?
Section 3.3.3 Claims for an unauthenticated Registrar are only…; Is this 
a viable approach?
Section 3.4 Factory provider?
Section 3.5 As the devices have a common trust anchor… Please make 
devices more explicit.
Section 3.5.1. device -> new entity
The new entity can validate the domain membership after joining? You 
mean it can act as proxy?
Section 3.6 Network access Control? Where does this term come from?
What does “having sufficient connectivity” mean?
Section 4.4 Zero-touch is an unknown term.
Already enrolled devices -> proxies.
Section 4.5 What are central control functions?
Section 5 repeats much of earlier sections. I suggest to remove text in 
earlier sections (or make more abstract) to minimize duplication.
What is an “air-gapped” network? Referring in the text to fig 5 and fig 
6 and pointing out the differences helps readability.
Here my review stops; The technology seems already quite solid if the 
proxy behaviour with IPIP encapsulation of the TLS messages are better 
clarified. The text needs quite some editing to remove duplication, 
improve consistency, and remove many of the design decision discussions. 
I hope my comments may help.

Greetings,

Peter

-- 
Peter van der Stok