Subject: [Anima-bootstrap] keyinfra-03 review

From: peter van der Stok <[email-masked]>
Date: Wed, 17 Aug 2016 08:51:25 +0200

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 16 Aug 2016 23:59:40 -0700

Thank you very much, Peter!

On Wed, Aug 17, 2016 at 08:51:25AM +0200, peter van der Stok wrote:
> 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.
> 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.
> ???Bootstrapping  ??? secure???. Remove, does not help.
> Page 5: DomainID. Remove ???(a string value ??? is used)???. This 
> information does not help me.
> The general message I receive, is ???constrained networks??? are out of 
> Section 3.1 I don???t understand: ???A new entity???. been configured??? 
> Why not; I assume the protocol detects this behaviour.
> 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.
> 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? 
> it is configured with the relevant information like the Registrar???s 
> address.
> Section 3.3.3 Claims for an unauthenticated Registrar are only???; Is this 
> a viable approach?
> Section 3.5 As the devices have a common trust anchor??? Please make 
> devices more explicit.
> What does ???having sufficient connectivity??? mean?
> What is an ???air-gapped??? network? Referring in the text to fig 5 and fig 
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

-- 
---
Toerless Eckert, [email-masked]

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Wed, 17 Aug 2016 08:58:54 +0000

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-masked]] On Behalf Of peter van der Stok
Sent: Wednesday, August 17, 2016 8:51 AM
To: Anima-bootstrap <[email-masked]>
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

________________________________
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.