As the Security Advisor for Anima, I have reviewed
draft-ietf-anima-bootstrapping-keyinfra-03
and have the following comments:
General
—————
Device is used inconsistently, but I believe in general device in this draft is
the “target” or “new device” that is being bootstrapped, correct?
Introduction
—————
In the paragraph beginning with “A precise answer to these questions….” (at end
of page 3)
I believe “devices from a variety of vendors” includes all network devices as
well as any generic device coming into the network and require bootstrap, but
its not clear?
Not clear what “and a network infrastructure (the domain) that is operated
by parties that do not have any priviledged relationship with the
device vendors”…..who are the device vendors? I think it is the “new device”
manfufacturer or vendor?
Terminology
——————
I am presuming domain = internet domain?
Typo: “Imprint” definition “key material to identity” should be “key material
to identify”
Pledge definition: I think all references to “device” is the device needing to
be bootstrapped?
Audit Token: it would be good to describe the “manufacturer authorized signing
authority” (e.g. MASA) as I believe the MASA is in general the vendor’s
manufacturer but in general, the MASA is some authority that s the one that can
authorize the prospective devices to a particular domain (e.g. the domain of
interest). Thus the “it” in the “…that it authorizes bootstrap” is the MASA
where the domain has assigned as the trusted authority.
Section 1.2
———————
Figure 1: New Entity = New Device (these two terms seems to be used
intermittently, my nit would be to pick one for consistency)
MASA service: doesn’t the MASA also holds an authoritative view of what new
devices can join the specific domain?
Ownership Tracker: in the Figure they are shown as part of the “Vendor Service”
and “MASA”, are they abstractly all the same component but can physically be
separate entities? As it is understood there could be devices that come from
multiple vendors, there can be many instances of the “Vendor Service”….but
could also imply that within a “Vendor Service” there can be a decoupling of
the MASA and Ownership Tracker?
Section 3.1
————-—
“A New Entity MUST NOT automatically initiate bootstrapping….” how can this be
enforced? There should be some description of implications in the Security
Considerations section (e.g. there may be instances in which a New Entity may
need to go to a “factory default” state and be re-bootstrapped?)
Figure 2: “Optional” can occur in advance” ….not clear what steps can be
created in advance and how far in advance. As the New Entity requests to join,
it’s ID is not known to the Registrar, at least until the TLS connection is
established….also, the Nonce is listed as optional, but SHOULD or MUST be
required to map it to provided Join Request (e.g. it should be part of the same
sequence).
Clarity somewhere in the document should be provided as to the operionality of
which entity does the Authorization for the New Entity to be bootstrapped (e.g.
is it the MASA or the Domain Registrar)….at this point it is not clear
Figure 3: Should the box be “Identify” vs “Identity”?
Step 2: “Identify itself” : what is meant by “Although the Registrar is also
authenticated these
credentials are only provisionally accepted at this time”? I think the
Registrar is provisionally accepting the 802.1AR to protect the TLS channel, is
that the point of this sentence? But I also believe the New Device must
provisionally accept the Registrar’s cert (also indicated in Figure 2)?
Step 3: “Request to Join” maps to “Request Audit Token” in Figure 2?
Step 4: “This requires verification of…”: the New Entity does the
verification? How does it do that? There is not enough details in here to
describe how it actually does this. Perhaps these steps should be prefaces as
“Summary” or “Brief/Abbreviated” state descriptions….
Step 5: this reads a bit awkward….I think the point of this step is that it now
has enough information, for instance, knowing the domain registrar’s
certificate to be able to initiate certificate enrollment; and can do such
enrollment using RFC 7030. Correct?
Step 6: a nit: membership is based on the successful certificate enrollment of
the new entity…correct? This is correctly shown in Figure 3 :-)
Section 3.1.1
——————
1st paragraph is awkward, especially the last sentence, what is the point of
stating “Therefore or clarity a Proxy is always assumed”? I think the point is
that typically, the discovery is typically achieved through a Proxy but there
can be cases in which it “could” go to a Domain Registrar, but unlikely, thus a
Proxy is needed, right?
Typo in step “d” : there’s an extra “k” in “bootstrapks service”
Section 3.1.2
——————
“the communication protocol” to be more explicit is during the Discovery
protocol, correct?
What is the “bootstrapping protocol server” , the Domain Registrar?
Section 3.1.3
———————
What is the “bootstrapping protocol server” , the Domain Registrar? This text
seems to be inconsistent with Figure 2 as that Figure seems to indicate that
the Join Request must be responded to before EST can come into play?
Section 3.1.4
————————
Similarly, I didn’t think EST was here “yet”….the Join Response (where the
Audit Token is received by the New Entity) must be processed. It is implied
here that the Domain Registrar’s trust anchor is received. But I think there
are more explicit details to the contents of this response and how the New
Device can actually verify (not sure it can validate?) that it has the right
information to proceed with EST.
Section 3.3
———————
Would be good to have naming consistancy: Domain registrar vs. Registrar vs.
Bootstrap Server (should be kept to 1 or 2 names to avoid confusion given that
there are already several actors in the flow).
1st paragraph: Implies that the bootstrap server is the one that maintains the
authorization database/state for which entities may be bootstrapped or not?
How does the Registrar know which/what MASA to reach to for the entity? Is
there a required trust relationship between the Registrar and the MASA to
process the Audit request? I think there is a MUST for this but I don’t see it
in this section.
This section speaks to using EST, but I think the Join Request/Response are new
messages (operations) which are augmented then to EST??
Section 4
——————
Is the Domain Operator the MASA?
Figure 5 looks different than Figure 2 and should be consistent or perhaps
should be converged unless more details are to be provided in this sequence?
Security Considerations
———————————————
I need to better understand the full flow and roles of the different actors to
later be able to more fully comment on what should be in the security
considerations.
I think given the current state, this section provides a good start but would
like to see more on the considerations of trust between the different actors
(especially between the registrar and the MASA)
- Nancy
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
