draft-ietf-anima-bootstrapping-keyinfra-44.txt   draft-ietf-anima-bootstrapping-keyinfra-45.txt 
ANIMA WG M. Pritikin ANIMA WG M. Pritikin
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Richardson Intended status: Standards Track M. Richardson
Expires: 25 March 2021 Sandelman Expires: 15 May 2021 Sandelman
T.T.E. Eckert T.T.E. Eckert
Futurewei USA Futurewei USA
M.H. Behringer M.H. Behringer
K.W. Watsen K.W. Watsen
Watsen Networks Watsen Networks
21 September 2020 11 November 2020
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-44 draft-ietf-anima-bootstrapping-keyinfra-45
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is Control Plane. To do this a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed X.509 bootstrapped. This is done using manufacturer-installed X.509
certificates, in combination with a manufacturer's authorizing certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a Bootstrapping a new device can occur using a routable address and a
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 March 2021. This Internet-Draft will expire on 15 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 8 skipping to change at page 3, line 8
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24
2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25
2.8. Determining the MASA to contact . . . . . . . . . . . . . 25 2.8. Determining the MASA to contact . . . . . . . . . . . . . 25
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26
3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 27 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 27
3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29
4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 32 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 33
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 34
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 37 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 37
4.3. Proxy discovery and communication of Registrar . . . . . 37 4.3. Proxy discovery and communication of Registrar . . . . . 37
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 40 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 40
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 41 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 41
5.3. Registrar Authorization of Pledge . . . . . . . . . . . . 43 5.3. Registrar Authorization of Pledge . . . . . . . . . . . . 43
5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43
5.4.1. MASA authentication of customer Registrar . . . . . . 44 5.4.1. MASA authentication of customer Registrar . . . . . . 44
5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 45 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 45
skipping to change at page 4, line 14 skipping to change at page 4, line 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 72 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 72
8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 72 8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 72
8.3. BRSKI well-known considerations . . . . . . . . . . . . . 72 8.3. BRSKI well-known considerations . . . . . . . . . . . . . 72
8.3.1. BRSKI .well-known registration . . . . . . . . . . . 72 8.3.1. BRSKI .well-known registration . . . . . . . . . . . 72
8.3.2. BRSKI .well-known registry . . . . . . . . . . . . . 73 8.3.2. BRSKI .well-known registry . . . . . . . . . . . . . 73
8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 73 8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 73
8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 73 8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 73
8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 74 8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 74
8.7. GRASP Objective Names . . . . . . . . . . . . . . . . . . 74
9. Applicability to the Autonomic Control Plane (ACP) . . . . . 74 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 74
9.1. Operational Requirements . . . . . . . . . . . . . . . . 75 9.1. Operational Requirements . . . . . . . . . . . . . . . . 76
9.1.1. MASA Operational Requirements . . . . . . . . . . . . 76 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 76
9.1.2. Domain Owner Operational Requirements . . . . . . . . 76 9.1.2. Domain Owner Operational Requirements . . . . . . . . 77
9.1.3. Device Operational Requirements . . . . . . . . . . . 77 9.1.3. Device Operational Requirements . . . . . . . . . . . 77
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 78 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 78
10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 78 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 78
10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 78 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 78
10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 79 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 79
10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 81 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 81
10.5. Manufacturers and Grey market equipment . . . . . . . . 82 10.5. Manufacturers and Grey market equipment . . . . . . . . 83
10.6. Some mitigations for meddling by manufacturers . . . . . 83 10.6. Some mitigations for meddling by manufacturers . . . . . 83
10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 84 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 84
11. Security Considerations . . . . . . . . . . . . . . . . . . . 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 85
11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 85 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 86
11.2. DomainID must be resistant to second-preimage attacks . 86 11.2. DomainID must be resistant to second-preimage attacks . 86
11.3. Availability of good random numbers . . . . . . . . . . 86 11.3. Availability of good random numbers . . . . . . . . . . 87
11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 87 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 87
11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 88 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 88
11.6. Manufacturer Maintenance of trust anchors . . . . . . . 89 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 89
11.6.1. Compromise of Manufacturer IDevID signing keys . . . 90 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 91
11.6.2. Compromise of MASA signing keys . . . . . . . . . . 91 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 91
11.6.3. Compromise of MASA web service . . . . . . . . . . . 93 11.6.3. Compromise of MASA web service . . . . . . . . . . . 93
11.7. YANG Module Security Considerations . . . . . . . . . . 94 11.7. YANG Module Security Considerations . . . . . . . . . . 94
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 94
13.1. Normative References . . . . . . . . . . . . . . . . . . 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 94
13.2. Informative References . . . . . . . . . . . . . . . . . 98 13.2. Informative References . . . . . . . . . . . . . . . . . 98
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 102 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 102
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 102 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 102
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 102 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 102
skipping to change at page 29, line 47 skipping to change at page 29, line 47
} }
import ietf-voucher { import ietf-voucher {
prefix vch; prefix vch;
description "This module defines the format for a voucher, description "This module defines the format for a voucher,
which is produced by a pledge's manufacturer or which is produced by a pledge's manufacturer or
delegate (MASA) to securely assign a pledge to delegate (MASA) to securely assign a pledge to
an 'owner', so that the pledge may establish a secure an 'owner', so that the pledge may establish a secure
connection to the owner's network infrastructure"; connection to the owner's network infrastructure";
reference "RFC 8366: Voucher Artifact for Bootstrapping Protocols"; reference "RFC 8366: Voucher Artifact for
Bootstrapping Protocols";
} }
organization organization
"IETF ANIMA Working Group"; "IETF ANIMA Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/anima/> "WG Web: <https://datatracker.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org> WG List: <mailto:anima@ietf.org>
Author: Kent Watsen Author: Kent Watsen
<mailto:kent+ietf@watsen.net> <mailto:kent+ietf@watsen.net>
skipping to change at page 30, line 34 skipping to change at page 30, line 35
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or
modification, is permitted pursuant to, and subject to the license without modification, is permitted pursuant to, and subject
terms contained in, the Simplified BSD License set forth in Section to the license terms contained in, the Simplified BSD License
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision "2018-02-14" { revision "2018-02-14" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Bootstrapping Remote Secure Key Infrastructure"; "RFC XXXX: Bootstrapping Remote Secure Key Infrastructure";
skipping to change at page 31, line 49 skipping to change at page 31, line 51
requests SHOULD be ignored by the MASA."; requests SHOULD be ignored by the MASA.";
} }
augment "voucher" { augment "voucher" {
description description
"Adds leaf nodes appropriate for requesting vouchers."; "Adds leaf nodes appropriate for requesting vouchers.";
leaf prior-signed-voucher-request { leaf prior-signed-voucher-request {
type binary; type binary;
description description
"If it is necessary to change a voucher, or re-sign and "If it is necessary to change a voucher, or re-sign and
forward a voucher that was previously provided along a forward a voucher that was previously provided along a
protocol path, then the previously signed voucher SHOULD be protocol path, then the previously signed voucher SHOULD
included in this field. be included in this field.
For example, a pledge might sign a voucher request For example, a pledge might sign a voucher request
with a proximity-registrar-cert, and the registrar with a proximity-registrar-cert, and the registrar
then includes it as the prior-signed-voucher-request field. then includes it as the prior-signed-voucher-request
This is a simple mechanism for a chain of trusted field. This is a simple mechanism for a chain of
parties to change a voucher request, while trusted parties to change a voucher request, while
maintaining the prior signature information. maintaining the prior signature information.
The Registrar and MASA MAY examine the prior signed The Registrar and MASA MAY examine the prior signed
voucher information for the voucher information for the
purposes of policy decisions. For example this information purposes of policy decisions. For example this
could be useful to a MASA to determine that both pledge and information could be useful to a MASA to determine
registrar agree on proximity assertions. The MASA SHOULD that both pledge and registrar agree on proximity
remove all prior-signed-voucher-request information when assertions. The MASA SHOULD remove all
signing a voucher for imprinting so as to minimize the prior-signed-voucher-request information when
final voucher size."; signing a voucher for imprinting so as to minimize
the final voucher size.";
} }
leaf proximity-registrar-cert { leaf proximity-registrar-cert {
type binary; type binary;
description description
"An X.509 v3 certificate structure as specified by RFC 5280, "An X.509 v3 certificate structure as specified by
Section 4 encoded using the ASN.1 distinguished encoding RFC 5280, Section 4 encoded using the ASN.1
rules (DER), as specified in [ITU.X690.1994]. distinguished encoding rules (DER), as specified
in [ITU.X690.1994].
The first certificate in the Registrar TLS server The first certificate in the Registrar TLS server
certificate_list sequence (the end-entity TLS certificate, certificate_list sequence (the end-entity TLS
see [RFC8446]) presented by the Registrar to the Pledge. certificate, see [RFC8446]) presented by the Registrar
This MUST be populated in a Pledge's voucher request when a to the Pledge.
proximity assertion is requested."; This MUST be populated in a Pledge's voucher request
when a proximity assertion is requested.";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 9: YANG module for Voucher-Request Figure 9: YANG module for Voucher-Request
skipping to change at page 37, line 17 skipping to change at page 37, line 17
The use of CoAP to connect from pledge to registrar is out of scope The use of CoAP to connect from pledge to registrar is out of scope
for this document, and is described in future work. See for this document, and is described in future work. See
[I-D.ietf-anima-constrained-voucher]. [I-D.ietf-anima-constrained-voucher].
4.3. Proxy discovery and communication of Registrar 4.3. Proxy discovery and communication of Registrar
The registrar SHOULD announce itself so that proxies can find it and The registrar SHOULD announce itself so that proxies can find it and
determine what kind of connections can be terminated. determine what kind of connections can be terminated.
The registrar announces itself using ACP instance of GRASP using The registrar announces itself using ACP instance of GRASP using
M_FLOOD messages. A registrar may announce any convenient port M_FLOOD messages, with the "AN_join_registrar" objective. A
number, including using a stock port 443. ANI proxies MUST support registrar may announce any convenient port number, including using a
GRASP discovery of registrars. stock port 443. ANI proxies MUST support GRASP discovery of
registrars.
The M_FLOOD is formatted as follows: The M_FLOOD is formatted as follows:
[M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000, [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
[["AN_join_registrar", 4, 255, "EST-TLS"], [["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]] h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]]
Figure 12: An example of a Registrar announcement message Figure 12: An example of a Registrar announcement message
skipping to change at page 74, line 25 skipping to change at page 74, line 25
Reference: [This document] Reference: [This document]
Service Name: brski-registrar Service Name: brski-registrar
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>. Assignee: IESG <iesg@ietf.org>.
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: The Bootstrapping Remote Secure Key Description: The Bootstrapping Remote Secure Key
Infrastructures Registrar Infrastructures Registrar
Reference: [This document] Reference: [This document]
8.7. GRASP Objective Names
IANA is requested to register the following GRASP Objective Names:
The IANA is requested to register the value "AN_Proxy" (without
quotes) to the GRASP Objectives Names Table in the GRASP Parameter
Registry. The specification for this value is this document,
Section 4.1.1.
The IANA is requested to register the value "AN_join_registrar"
(without quotes) to the GRASP Objectives Names Table in the GRASP
Parameter Registry. The specification for this value is this
document, Section 4.3.
9. Applicability to the Autonomic Control Plane (ACP) 9. Applicability to the Autonomic Control Plane (ACP)
This document provides a solution to the requirements for secure This document provides a solution to the requirements for secure
bootstrap set out in Using an Autonomic Control Plane for Stable bootstrap set out in Using an Autonomic Control Plane for Stable
Connectivity of Network Operations, Administration, and Maintenance Connectivity of Network Operations, Administration, and Maintenance
[RFC8368], A Reference Model for Autonomic Networking [RFC8368], A Reference Model for Autonomic Networking
[I-D.ietf-anima-reference-model] and specifically the An Autonomic [I-D.ietf-anima-reference-model] and specifically the An Autonomic
Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section
3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and
Network). Network).
skipping to change at page 94, line 46 skipping to change at page 94, line 46
members, including Adam Roach, Alexey Melnikov, Alissa Cooper, members, including Adam Roach, Alexey Melnikov, Alissa Cooper,
Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund. Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", Work in Progress, Internet-Draft, Control Plane (ACP)", Work in Progress, Internet-Draft,
draft-ietf-anima-autonomic-control-plane-29, 11 September draft-ietf-anima-autonomic-control-plane-30, 30 October
2020, <http://www.ietf.org/internet-drafts/draft-ietf- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-
anima-autonomic-control-plane-29.txt>. anima-autonomic-control-plane-30.txt>.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", Work in Progress, Autonomic Signaling Protocol (GRASP)", Work in Progress,
Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017,
<http://www.ietf.org/internet-drafts/draft-ietf-anima- <http://www.ietf.org/internet-drafts/draft-ietf-anima-
grasp-15.txt>. grasp-15.txt>.
[IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009,
<http://standards.ieee.org/findstds/standard/802.1AR- <http://standards.ieee.org/findstds/standard/802.1AR-
skipping to change at page 99, line 27 skipping to change at page 99, line 27
Stok, P., Kampanakis, P., Richardson, M., and S. Raza, Stok, P., Kampanakis, P., Richardson, M., and S. Raza,
"EST over secure CoAP (EST-coaps)", Work in Progress, "EST over secure CoAP (EST-coaps)", Work in Progress,
Internet-Draft, draft-ietf-ace-coap-est-18, 6 January Internet-Draft, draft-ietf-ace-coap-est-18, 6 January
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
coap-est-18.txt>. coap-est-18.txt>.
[I-D.ietf-anima-constrained-voucher] [I-D.ietf-anima-constrained-voucher]
Richardson, M., Stok, P., and P. Kampanakis, "Constrained Richardson, M., Stok, P., and P. Kampanakis, "Constrained
Voucher Artifacts for Bootstrapping Protocols", Work in Voucher Artifacts for Bootstrapping Protocols", Work in
Progress, Internet-Draft, draft-ietf-anima-constrained- Progress, Internet-Draft, draft-ietf-anima-constrained-
voucher-08, 13 July 2020, <http://www.ietf.org/internet- voucher-09, 2 November 2020, <http://www.ietf.org/
drafts/draft-ietf-anima-constrained-voucher-08.txt>. internet-drafts/draft-ietf-anima-constrained-voucher-
09.txt>.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
Networking", Work in Progress, Internet-Draft, draft-ietf- Networking", Work in Progress, Internet-Draft, draft-ietf-
anima-reference-model-10, 22 November 2018, anima-reference-model-10, 22 November 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-anima- <http://www.ietf.org/internet-drafts/draft-ietf-anima-
reference-model-10.txt>. reference-model-10.txt>.
[I-D.ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "A YANG Data Model for a Keystore", Work in Watsen, K., "A YANG Data Model for a Keystore", Work in
Progress, Internet-Draft, draft-ietf-netconf-keystore-20, Progress, Internet-Draft, draft-ietf-netconf-keystore-20,
20 August 2020, <http://www.ietf.org/internet-drafts/ 20 August 2020, <http://www.ietf.org/internet-drafts/
draft-ietf-netconf-keystore-20.txt>. draft-ietf-netconf-keystore-20.txt>.
[I-D.richardson-anima-state-for-joinrouter] [I-D.richardson-anima-state-for-joinrouter]
Richardson, M., "Considerations for stateful vs stateless Richardson, M., "Considerations for stateful vs stateless
join router in ANIMA bootstrap", Work in Progress, join router in ANIMA bootstrap", Work in Progress,
Internet-Draft, draft-richardson-anima-state-for- Internet-Draft, draft-richardson-anima-state-for-
joinrouter-02, 25 January 2018, <http://www.ietf.org/ joinrouter-03, 22 September 2020, <http://www.ietf.org/
internet-drafts/draft-richardson-anima-state-for- internet-drafts/draft-richardson-anima-state-for-
joinrouter-02.txt>. joinrouter-03.txt>.
[imprinting] [imprinting]
"Wikipedia article: Imprinting", July 2015, "Wikipedia article: Imprinting", July 2015,
<https://en.wikipedia.org/wiki/Imprinting_(psychology)>. <https://en.wikipedia.org/wiki/Imprinting_(psychology)>.
[IoTstrangeThings] [IoTstrangeThings]
"IoT of toys stranger than fiction: Cybersecurity and data "IoT of toys stranger than fiction: Cybersecurity and data
privacy update (accessed 2018-12-02)", March 2017, privacy update (accessed 2018-12-02)", March 2017,
<https://www.welivesecurity.com/2017/03/03/internet-of- <https://www.welivesecurity.com/2017/03/03/internet-of-
things-security-privacy-iot-update/>. things-security-privacy-iot-update/>.
 End of changes. 26 change blocks. 
52 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/