Re: [Anima-bootstrap] keyinfra-03 review

[Toerless Eckert <[e-mail]>]

Thank you very much, Peter!

On Wed, Aug 17, 2016 at 08:51:25AM +0200, peter van der Stok wrote:
> 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
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

-- 
---
Toerless Eckert, [e-mail]