Dear all Also forwarding the review to Anima since I think Peter raises some interesting points which requires more clarification. - How is the proxy selected, by whom and how is it configured within the autonomous domain? - Is the relaying of TLS through the proxy finalized. There are vague references to multiple options like IPIP and TCP circuit proxy. Is the intention to support only one or have one mandatory with multiple other proxy types supported by the Registrar? The reason I ask is because a DTLS relaying method is well defined within an external standardization body and would like to know if that can be supported end-to-end with the Registrar.
In addition to Peter's comments what I additionally miss from the current draft are - There is no authorization of the Registrar to request device audit tokens, making it easy for anyone to steal devices between the installation and commissioning phase (which can be quite long in certain installations). The idea of an ownership tracker based on sales data is completely impractical in many industry domains. This leaves a commissioner who arrives at a location with a prospect that he cannot commission the devices anymore since they have been already stolen and needs to recall the installation guys back to factory reset devices (which means ladders, removing false ceiling, or to simply unnecessary costs). - In many situations (like new buildings) a Enterprise domain registrar doesn't exist and there is a need to bring devices into a temporary domain (like a commissioning tool acting as the registrar) to be later transferred to a real domain when available. However the draft seems to completely ignore any handover requirements and solutions which are very relevant in practice to make this useful. Kind regards Sandeep Dr. Sandeep S. Kumar Senior Scientist - Security, Philips Lighting Research, Eindhoven, The Netherlands. -----Original Message----- From: Anima-bootstrap [mailto:[email protected]] On Behalf Of peter van der Stok Sent: Wednesday, August 17, 2016 8:51 AM To: Anima-bootstrap <[email protected]> Subject: [Anima-bootstrap] keyinfra-03 review 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 [email protected] https://www.ietf.org/mailman/listinfo/anima-bootstrap ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
