[email protected] wrote: > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Authors : Max Pritikin > Michael C. Richardson > Michael H. Behringer > Steinthor Bjarnason > Kent Watsen > Filename : draft-ietf-anima-bootstrapping-keyinfra-19.txt
> A diff from the previous version is available at:
>
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-19
While the 18 to 19 diff is probably of interest to those who have most
recently reviewed the document a diff against version 16 is probably most
useful to those who last read during the WGLC.
https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-16&url2=draft-ietf-anima-bootstrapping-keyinfra-19
We believe that we dealt with all of the review comments raised during WGLC
and reviews, and we are ready to proceed to the IESG.
The reviews are at:
secdir:
https://mailarchive.ietf.org/arch/browse/anima/?gbt=1&index=NGsR9xGIL7k_j06FXkI_GBeJZMo
genart: https://mailarchive.ietf.org/arch/msg/anima/iVg7MRMdBQBVFA5VFiksYFHchBU
iotdir: https://mailarchive.ietf.org/arch/msg/anima/1N7AR8hqu2oIWuTFFd9OQOab8SI
The issues that were opened are at:
https://github.com/anima-wg/anima-bootstrap/issues?utf8=%E2%9C%93&q=is%3Aissue+
In most cases, we have used the #issue notation that github (and trac, and..)
supports in order to link the diffs that we made to the issue number.
Major changes:
1) new section 5.3: Registrar Authorization of Pledge
2) new section 3.1: Nonceless Voucher Requests
3) new section 8: Applicability to the Autonomic Control Plane (plus
other details in the document)
4) new section 9: Privacy Considerations:
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60
9.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60
9.2. What BRSKI-MASA reveals to the manufacturer . . . . . . . 61
9.3. Manufacturers and Used or Stolen Equipment . . . . . . . 63
9.4. Manufacturers and Grey market equipment . . . . . . . . . 64
9.5. Some mitigations for meddling by manufacturers . . . . . 64
5) additions to Security Considerations:
10.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 66
10.4. Manufacturer Maintainance of trust anchors . . . . . . . 69
Issues that we have not dealt with using text.
If you want to re-open the ticket, please go ahead, but please also bring
some text that is in-scope for ANIMA ACP:
https://github.com/anima-wg/anima-bootstrap/issues/112
add discussion of each major mode of the protocol #112
* We are focused on the proximity assertion that we think is the most
secure version of the protocol. We have described this in detail.
* We have expanded discussion about the nonceless (offline) mechanism
that vouchers can use.
* There are some additional ways the protocol can be used, but we
feel that they should be dealt with in other documents.
https://github.com/anima-wg/anima-bootstrap/issues/110
gen art issue #22: permanent vouchers... feature or bug. explain further
* we think that further discussion about this is needed.
* this is a "major mode" that belongs in an operational document.
https://github.com/anima-wg/anima-bootstrap/issues/79
security review issue 6: ship and forget not supported
* a new major mode, which we do not support, and we don't know how.
* it is out of scope for ANIMA.
* we did add text that existing mechanisms (craft consoles) continue
to be available.
https://github.com/anima-wg/anima-bootstrap/issues/82
security review issue 7: what if MASA always issues vouchers
* "It is mentioned in
section 6.4, which recommend that manufacturers should not do that.
What
are the consequences if they still do?"
-> it's hard to say what will happen if implementers violate the
protocol.
Some other set of assumptions need to be made about how many
violations the other components do.
https://github.com/anima-wg/anima-bootstrap/issues/83
security review issue 8: device refuses to be imprinted
* we think the answer is that the customer ships it back.
* we provide telemetry as to success, but if the device is broken,
it's broken.
https://github.com/anima-wg/anima-bootstrap/issues/86
security review issue 13: individualization
* the issue asks about the per-device step in manufacturing.
*** we think that this is out-of-scope for ANI use ***
* we considered talking about technology like:
https://en.wikipedia.org/wiki/Physical_unclonable_function
but ultimately, that's just another way to do TPM, so
skirts the question.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
