draft-ietf-anima-bootstrapping-keyinfra-18.txt   draft-ietf-anima-bootstrapping-keyinfra-19.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: July 21, 2019 Sandelman Expires: September 8, 2019 Sandelman
M. Behringer M. Behringer
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
K. Watsen K. Watsen
Juniper Networks Juniper Networks
January 17, 2019 March 7, 2019
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-18 draft-ietf-anima-bootstrapping-keyinfra-19
Abstract Abstract
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a remote secure key infrastructure (BRSKI) Control Plane. To do this a remote secure key infrastructure (BRSKI)
is created using manufacturer installed X.509 certificate, in is created using manufacturer installed X.509 certificate, in
combination with a manufacturer's authorizing service, both online combination with a manufacturer's authorizing service, both online
and offline. Bootstrapping a new device can occur using a routable and offline. Bootstrapping a new device can occur using a routable
address and a cloud service, or using only link-local connectivity, address and a cloud service, or using only link-local connectivity,
or on limited/disconnected networks. Support for lower security or on limited/disconnected networks. Support for lower security
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 July 21, 2019. This Internet-Draft will expire on September 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17
2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 19 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 19
2.5. Architectural Components . . . . . . . . . . . . . . . . 21 2.5. Architectural Components . . . . . . . . . . . . . . . . 21
2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 21 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 21
2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 21 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 21
2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 21 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 21
2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 21 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 21
2.6. Certificate Time Validation . . . . . . . . . . . . . . . 22 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 22
2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 22 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 22
2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 22
2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 24 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 22
2.8. Determining the MASA to contact . . . . . . . . . . . . . 24 2.8. Determining the MASA to contact . . . . . . . . . . . . . 23
3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 25 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 23
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 26 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 24
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 24
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25
4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 31 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27
4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 32 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 30
4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 33 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 31
4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 34 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 32
4.3. Proxy discovery of Registrar . . . . . . . . . . . . . . 34 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 33
4.3. Proxy discovery and communication of Registrar . . . . . 33
5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 35 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 35
5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 37 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36
5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37
5.3. Registrar Authorization of 5.3. Registrar Authorization of
Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 39 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 39 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 39
5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 40 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 39
5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 41 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 41
5.5.2. MASA verification of voucher-request signature 5.5.2. MASA verification of voucher-request signature
consistency . . . . . . . . . . . . . . . . . . . . . 41 consistency . . . . . . . . . . . . . . . . . . . . . 41
5.5.3. MASA authentication of registrar (certificate) . . . 42 5.5.3. MASA authentication of registrar (certificate) . . . 41
5.5.4. MASA revocation checking of registrar (certificate) . 42 5.5.4. MASA revocation checking of registrar (certificate) . 42
5.5.5. MASA verification of pledge prior-signed-voucher- 5.5.5. MASA verification of pledge prior-signed-voucher-
request . . . . . . . . . . . . . . . . . . . . . . . 42 request . . . . . . . . . . . . . . . . . . . . . . . 42
5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 43 5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 42
5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 43 5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42
5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 43 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 43
5.6.1. Pledge voucher verification . . . . . . . . . . . . . 46 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 45
5.6.2. Pledge authentication of provisional TLS connection . 46 5.6.2. Pledge authentication of provisional TLS connection . 46
5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 47 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 47
5.8. Registrar audit log request . . . . . . . . . . . . . . . 48 5.8. Registrar audit log request . . . . . . . . . . . . . . . 47
5.8.1. MASA audit log response . . . . . . . . . . . . . . . 49 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 49
5.8.2. Registrar audit log verification . . . . . . . . . . 50 5.8.2. Registrar audit log verification . . . . . . . . . . 50
5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 51 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 51
5.9.1. EST Distribution of CA Certificates . . . . . . . . . 52 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 52
5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 52 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 52
5.9.3. EST Client Certificate Request . . . . . . . . . . . 53 5.9.3. EST Client Certificate Request . . . . . . . . . . . 53
5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 53 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 53
5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 54 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 54
5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 54 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 54
6. Reduced security operational modes . . . . . . . . . . . . . 55 6. Reduced security operational modes . . . . . . . . . . . . . 54
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 55 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 55
6.2. Pledge security reductions . . . . . . . . . . . . . . . 56 6.2. Pledge security reductions . . . . . . . . . . . . . . . 55
6.3. Registrar security reductions . . . . . . . . . . . . . . 56 6.3. Registrar security reductions . . . . . . . . . . . . . . 56
6.4. MASA security reductions . . . . . . . . . . . . . . . . 57 6.4. MASA security reductions . . . . . . . . . . . . . . . . 57
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
7.1. Well-known EST registration . . . . . . . . . . . . . . . 58 7.1. Well-known EST registration . . . . . . . . . . . . . . . 58
7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 58 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 58
7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58 7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58
7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 59 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 59
7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 59 7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 59
8. Applicability to the Autonomic 8. Applicability to the Autonomic
Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60
9.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60 9.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60
9.2. Used, Stolen or Grey Market equipment . . . . . . . . . . 61 9.2. What BRSKI-MASA reveals to the manufacturer . . . . . . . 61
9.2.1. What BRSKI-MASA reveals to the manufacturer . . . . . 61 9.3. Manufacturers and Used or Stolen Equipment . . . . . . . 63
9.2.2. Manufacturers and Used or Stolen Equipment . . . . . 63 9.4. Manufacturers and Grey market equipment . . . . . . . . . 64
9.2.3. Manufacturers and Grey market equipment . . . . . . . 64 9.5. Some mitigations for meddling by manufacturers . . . . . 64
9.2.4. Some mitigations for meddling by manufacturers . . . 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65
10. Security Considerations . . . . . . . . . . . . . . . . . . . 66 10.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 66
10.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 67
10.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 67 10.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 67
10.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 69 10.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 68
10.4. Manufacturer Maintainance of trust anchors . . . . . . . 69
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
12.1. Normative References . . . . . . . . . . . . . . . . . . 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 71
12.2. Informative References . . . . . . . . . . . . . . . . . 72 12.2. Informative References . . . . . . . . . . . . . . . . . 73
Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 75 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 76
A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 75 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 76
A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 76 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 77
Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 76 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 77
Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 77 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 78
Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 79 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 80
D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 79 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 80
D.1.1. MASA key pair for voucher signatures . . . . . . . . 79 D.1.1. MASA key pair for voucher signatures . . . . . . . . 80
D.1.2. Manufacturer key pair for IDevID signatures . . . . . 79 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 80
D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 80 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 81
D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 82 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 83
D.2. Example process . . . . . . . . . . . . . . . . . . . . . 84 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 85
D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 84 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 85
D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 90 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 91
D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 95 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 96
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101
1. Introduction 1. Introduction
BRSKI provides a solution for secure zero-touch (automated) bootstrap BRSKI provides a solution for secure zero-touch (automated) bootstrap
of virgin (untouched) devices that are called pledges in this of new (unconfigured) devices that are called pledges in this
document. document.
This document primarily provides for the needs of the ISP and This document primarily provides for the needs of the ISP and
Enterprise focused ANIMA Autonomic Control Plane (ACP) Enterprise focused ANIMA Autonomic Control Plane (ACP)
[I-D.ietf-anima-autonomic-control-plane]. Other users of the BRSKI [I-D.ietf-anima-autonomic-control-plane]. Other users of the BRSKI
protocol will need to provide separate applicability statements that protocol will need to provide separate applicability statements that
include privacy and security considerations appropriate to that include privacy and security considerations appropriate to that
deployment. Section Section 8 explains the details applicability for deployment. Section Section 8 explains the details applicability for
this the ACP usage. this the ACP usage.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
3. Pledge authenticating the registrar: "What is this registrar's 3. Pledge authenticating the registrar: "What is this registrar's
identity?" identity?"
4. Pledge authorizing the registrar: "Should I join it?" 4. Pledge authorizing the registrar: "Should I join it?"
This document details protocols and messages to answer the above This document details protocols and messages to answer the above
questions. It uses a TLS connection and an PKIX (X.509v3) questions. It uses a TLS connection and an PKIX (X.509v3)
certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
points 1 and 2. It uses a new artifact called a "voucher" that the points 1 and 2. It uses a new artifact called a "voucher" that the
registrar receives from a "Manufacturer Authorized Signing Authority" registrar receives from a "Manufacturer Authorized Signing Authority"
and passes to the pledge to answer points 3 and 2. and passes to the pledge to answer points 3 and 4.
A proxy provides very limited connectivity between the pledge and the A proxy provides very limited connectivity between the pledge and the
registrar. registrar.
The syntactic details of vouchers are described in detail in The syntactic details of vouchers are described in detail in
[RFC8366]. This document details automated protocol mechanisms to [RFC8366]. This document details automated protocol mechanisms to
obtain vouchers, including the definition of a 'voucher-request' obtain vouchers, including the definition of a 'voucher-request'
message that is a minor extension to the voucher format (see message that is a minor extension to the voucher format (see
Section 3) defined by [RFC8366]. Section 3) defined by [RFC8366].
skipping to change at page 6, line 24 skipping to change at page 6, line 24
manner. Existing automated mechanisms are known as non-secured manner. Existing automated mechanisms are known as non-secured
'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling'
[Stajano99theresurrecting] or 'pre-staging'. [Stajano99theresurrecting] or 'pre-staging'.
Another prior approach has been to try and minimize user actions Another prior approach has been to try and minimize user actions
during bootstrapping, but not eliminate all user-actions. The during bootstrapping, but not eliminate all user-actions. The
original EST protocol [RFC7030] does reduce user actions during original EST protocol [RFC7030] does reduce user actions during
bootstrap but does not provide solutions for how the following bootstrap but does not provide solutions for how the following
protocol steps can be made autonomic (not involving user actions): protocol steps can be made autonomic (not involving user actions):
o using the Implicit Trust Anchor database to authenticate an owner o using the Implicit Trust Anchor [RFC7030] database to authenticate
specific service (not an autonomic solution because the URL must an owner specific service (not an autonomic solution because the
be securely distributed), URL must be securely distributed),
o engaging a human user to authorize the CA certificate using out- o engaging a human user to authorize the CA certificate using out-
of-band data (not an autonomic solution because the human user is of-band data (not an autonomic solution because the human user is
involved), involved),
o using a configured Explicit TA database (not an autonomic solution o using a configured Explicit TA database (not an autonomic solution
because the distribution of an explicit TA database is not because the distribution of an explicit TA database is not
autonomic), autonomic),
o and using a Certificate-Less TLS mutual authentication method (not o and using a Certificate-Less TLS mutual authentication method (not
skipping to change at page 11, line 47 skipping to change at page 11, line 47
installed, is persisted on the device across system restarts installed, is persisted on the device across system restarts
("booting"). Bootstrapping occurs only infrequently such as when a ("booting"). Bootstrapping occurs only infrequently such as when a
device is transfered to a new owner or has been reset to factory device is transfered to a new owner or has been reset to factory
default settings. default settings.
1.4. Leveraging the new key infrastructure / next steps 1.4. Leveraging the new key infrastructure / next steps
As a result of the protocol described herein, the bootstrapped As a result of the protocol described herein, the bootstrapped
devices have the Domain CA trust anchor in common. An end entity devices have the Domain CA trust anchor in common. An end entity
certificate has optionally been issued from the Domain CA. This certificate has optionally been issued from the Domain CA. This
makes it possible to automatically deploy services across the domain makes it possible to securely deploy functionalities across the
in a secure manner. domain, e.g:
Services that benefit from this:
o Device management. o Device management.
o Routing authentication. o Routing authentication.
o Service discovery. o Service discovery.
The major beneficiary is that it possible to use the credentials The major beneficiary is that it possible to use the credentials
deployed by this protocol to secure the Autonomic Control Plane (ACP) deployed by this protocol to secure the Autonomic Control Plane (ACP)
([I-D.ietf-anima-autonomic-control-plane]). ([I-D.ietf-anima-autonomic-control-plane]).
1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices
The BRSKI protocol can be used in a number of environments. Some of The BRSKI protocol can be used in a number of environments. Some of
the flexibility in this document is the result of users out of the the options in this document is the result of requirements that are
ANI scope. This section defines the base requirements for ANI out of the ANI scope. This section defines the base requirements for
devices. ANI devices.
For devices that intend to become part of an Autonomic Network For devices that intend to become part of an Autonomic Network
Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes
an Autonomic Control Plane an Autonomic Control Plane
([I-D.ietf-anima-autonomic-control-plane]), the following actions are ([I-D.ietf-anima-autonomic-control-plane]), the BRSKI protocol MUST
required and MUST be performed by the pledge: be implemented.
o BRSKI: Request Voucher
o EST: CA Certificates Request
o EST: CSR Attributes The pledge must perform discovery of the proxy as described in
Section 4.1 using GRASP M_FLOOD announcements.
o EST: Client Certificate Request Upon successfully validating a voucher artiface, a status telemetry
MUST be returned. See Section 5.7.
o BRSKI: Enrollment status Telemetry An ANIMA ANI pledge MUST implement the EST automation extensions
described in Section 5.9. They supplement the [RFC7030] EST to
better support automated devices that do not have an end user.
The ANI Join Registrar ASA MUST support all the BRSKI and above The ANI Join Registrar ASA MUST support all the BRSKI and above
listed EST operations. listed EST operations.
All ANI devices SHOULD support the BRSKI proxy function, using All ANI devices SHOULD support the BRSKI proxy function, using
circuit proxies. Other proxy methods are optional, and MUST NOT circuit proxies over the ACP. (See Section 4.3)
enabled unless the Join Registrar ASA indicates support for them in
it's announcement. (See Section 4.3)
2. Architectural Overview 2. Architectural Overview
The logical elements of the bootstrapping framework are described in The logical elements of the bootstrapping framework are described in
this section. Figure 1 provides a simplified overview of the this section. Figure 1 provides a simplified overview of the
components. components.
+------------------------+ +------------------------+
+--------------Drop Ship--------------->| Vendor Service | +--------------Drop Ship--------------->| Vendor Service |
| +------------------------+ | +------------------------+
skipping to change at page 14, line 10 skipping to change at page 14, line 10
The domain registrar authenticates the pledge, makes authorization The domain registrar authenticates the pledge, makes authorization
decisions, and distributes vouchers obtained from the Manufacturer decisions, and distributes vouchers obtained from the Manufacturer
Service. Optionally the registrar also acts as a PKI Registration Service. Optionally the registrar also acts as a PKI Registration
Authority. Authority.
2.1. Behavior of a Pledge 2.1. Behavior of a Pledge
The pledge goes through a series of steps, which are outlined here at The pledge goes through a series of steps, which are outlined here at
a high level. a high level.
+--------------+ ------------
| Factory | / Factory \
| default | \ default /
+------+-------+ -----+------
| |
+------v-------+ +------v-------+
| (1) Discover | | (1) Discover |
+------------> | +------------> |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | (2) Identity | | | (2) Identity |
^------------+ | ^------------+ |
| rejected +------+-------+ | rejected +------+-------+
skipping to change at page 14, line 36 skipping to change at page 14, line 36
| | (3) Request | | | (3) Request |
| | Join | | | Join |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | (4) Imprint | | | (4) Imprint |
^------------+ | ^------------+ |
| Bad MASA +------+-------+ | Bad MASA +------+-------+
| response | send Voucher Status Telemetry | response | send Voucher Status Telemetry
| +------v-------+ | +------v-------+
| | (5) Enroll | | | (5) Enroll |<---+ (non-error HTTP codes )
^------------+ | ^------------+ |\___/ (e.g. 201 'Retry-After')
| Enroll +------+-------+ | Enroll +------+-------+
| Failure | | Failure |
| +------v-------+ | -----v------
| | (6) Enrolled | | / Enrolled \
^------------+ | ^------------+ |
Factory +--------------+ Factory \------------/
reset reset
Figure 2 Figure 2: pledge state diagram
State descriptions for the pledge are as follows: State descriptions for the pledge are as follows:
1. Discover a communication channel to a registrar. 1. Discover a communication channel to a registrar.
2. Identify itself. This is done by presenting an X.509 IDevID 2. Identify itself. This is done by presenting an X.509 IDevID
credential to the discovered registrar (via the proxy) in a TLS credential to the discovered registrar (via the proxy) in a TLS
handshake. (The registrar credentials are only provisionally handshake. (The registrar credentials are only provisionally
accepted at this time). accepted at this time).
3. Request to join the discovered registrar. A unique nonce can be 3. Request to join the discovered registrar. A unique nonce is
included ensuring that any responses can be associated with this included ensuring that any responses can be associated with this
particular bootstrapping attempt. particular bootstrapping attempt.
4. Imprint on the registrar. This requires verification of the 4. Imprint on the registrar. This requires verification of the
manufacturer service provided voucher. A voucher contains manufacturer service provided voucher. A voucher contains
sufficient information for the pledge to complete authentication sufficient information for the pledge to complete authentication
of a registrar. (The embedded 'pinned-domain-certificate' of a registrar. This document details this step in depth.
enables the pledge to finish authentication of the registrar TLS
server certificate).
5. Enroll. By accepting the domain specific information from a 5. Enroll. After imprint an authenticated TLS (HTTPS) connection
registrar, and by obtaining a domain certificate from a registrar exists between pledge and registrar. Enrollment over Secure
using a standard enrollment protocol, e.g. Enrollment over Transport (EST) [RFC7030] is then used to obtain a domain
Secure Transport (EST) [RFC7030]. certificate from a registrar.
6. The pledge is now a member of, and can be managed by, the domain The pledge is now a member of, and can be managed by, the domain and
and will only repeat the discovery aspects of bootstrapping if it will only repeat the discovery aspects of bootstrapping if it is
is returned to factory default settings. returned to factory default settings.
After imprint a secure transport exists between pledge and registrar.
This specification details integration with EST enrollment so that This specification details integration with EST enrollment so that
pledges can optionally obtain a locally issued certificate, although pledges can optionally obtain a locally issued certificate, although
any REST interface could be integrated in future work. any REST interface could be integrated in future work.
2.2. Secure Imprinting using Vouchers 2.2. Secure Imprinting using Vouchers
A voucher is a cryptographically protected artifact (a digital A voucher is a cryptographically protected artifact (a digital
signature) to the pledge device authorizing a zero-touch imprint on signature) to the pledge device authorizing a zero-touch imprint on
the registrar domain. the registrar domain.
skipping to change at page 16, line 22 skipping to change at page 16, line 20
the local security policy of the domain network to be enforced. the local security policy of the domain network to be enforced.
2.3. Initial Device Identifier 2.3. Initial Device Identifier
Pledge authentication and pledge voucher-request signing is via a Pledge authentication and pledge voucher-request signing is via a
PKIX certificate installed during the manufacturing process. This is PKIX certificate installed during the manufacturing process. This is
the 802.1AR Initial Device Identifier (IDevID), and it provides a the 802.1AR Initial Device Identifier (IDevID), and it provides a
basis for authenticating the pledge during the protocol exchanges basis for authenticating the pledge during the protocol exchanges
described here. There is no requirement for a common root PKI described here. There is no requirement for a common root PKI
hierarchy. Each device manufacturer can generate its own root hierarchy. Each device manufacturer can generate its own root
certificate. Specifically, the IDevID: certificate. Specifically, the IDevID enables:
1. Uniquely identifying the pledge by the Distinguished Name (DN) 1. Uniquely identifying the pledge by the Distinguished Name (DN)
and subjectAltName (SAN) parameters in the IDevID. The unique and subjectAltName (SAN) parameters in the IDevID. The unique
identification of a pledge in the voucher objects are derived identification of a pledge in the voucher objects are derived
from those parameters as described below. from those parameters as described below.
2. Securely authentating the pledges identity via TLS connection to 2. Provides a cryptographic authentication of the pledge to the
registrar. This provides protection against cloned/fake pledged. Registrar (see Section 5.3).
3. Secure auto-discovery of the pledges MASA by the registrar via 3. Secure auto-discovery of the pledge's MASA by the registrar (see
the MASA URI in IDevID as explained below. Section 2.8).
4. (Optionally) communicating the MUD URL (see Appendix C. 4. Signing of voucher-request by the pledge's IDevID (see
Section 3).
5. (Optional) Signing of voucher-request by the pledges IDevID to 5. Provides a cryptographic authentication of the pledge to the MASA
enable MASA to generate voucher only to a registrar that has a (see Section 5.5.5).
connection to the pledge.
6. Authorizing pledge (via registrar) to receive certificate from Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage
domain CA, by signing the Certificate Signing Request (CSR). extensions in the IDevID certificate. Any restrictions included
reduce the utility of the IDevID and so this specification RECOMMENDS
that no key usage restrictions be included. Additionally, [RFC5280]
section 4.2.1.3 does not require key usage restrictions for end
entity certificates.
2.3.1. Identification of the Pledge 2.3.1. Identification of the Pledge
In the context of BRSKI, pledges are uniquely identified by a In the context of BRSKI, pledges are uniquely identified by a
"serial-number". This serial-number is used both in the "serial- "serial-number". This serial-number is used both in the "serial-
number" field of voucher or voucher-requests (see Section 3) and in number" field of voucher or voucher-requests (see Section 3) and in
local policies on registrar or MASA (see Section 5). local policies on registrar or MASA (see Section 5).
The following fields are defined in [IDevID] and [RFC5280]: The following fields are defined in [IDevID] and [RFC5280]:
skipping to change at page 17, line 44 skipping to change at page 17, line 46
IDevID certificate. IDevID certificate.
As explained in Section 5.5 the Registrar MUST extract the serial- As explained in Section 5.5 the Registrar MUST extract the serial-
number again itself from the pledge's TLS certificate. It may number again itself from the pledge's TLS certificate. It may
consult the serial-number in the pledge-request if there are any consult the serial-number in the pledge-request if there are any
possible confusion about the source of the serial-number (hwSerialNum possible confusion about the source of the serial-number (hwSerialNum
vs serialNumber). vs serialNumber).
2.3.2. MASA URI extension 2.3.2. MASA URI extension
The following newly defined field SHOULD be in the PKIX IDevID This docucment defines a new PKIX non-critical certificate extension
certificate: A PKIX non-critical certificate extension that contains to carry the MASA URI. This extension is intended to be used in the
a single Uniform Resource Identifier (URI) that points to an on-line IDevID certificate. The URI is represented as described in
Manufacturer Authorized Signing Authority. The URI is represented as Section 7.4 of [RFC5280].
described in Section 7.4 of [RFC5280].
Any Internationalized Resource Identifiers (IRIs) MUST be mapped to Any Internationalized Resource Identifiers (IRIs) MUST be mapped to
URIs as specified in Section 3.1 of [RFC3987] before they are placed URIs as specified in Section 3.1 of [RFC3987] before they are placed
in the certificate extension. The URI provides the authority in the certificate extension. The IRI provides the authority
information. The BRSKI "/.well-known" tree ([RFC5785]) is described information. The BRSKI "/.well-known" tree ([RFC5785]) is described
in Section 5. in Section 5.
As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
this extension, including the scheme, iauthority, and ipath. As a
consideration to constrained systems, this MAY be reduced to only the
iauthority, in which case a scheme of "https://" and ipath of
"/.well-known/est" is to be assumed, as explained in section
Section 5.
The registrary can assume that only the iauthority is present in the
extension, if there are no slash ("/") characters in the extension.
Section 7.4 of [RFC5280] calls out various schemes that MUST be
supported, including ldap, http and ftp. However, the registrar MUST
use https for the BRSKI-MASA connection.
The new extension is identified as follows: The new extension is identified as follows:
<CODE BEGINS> <CODE BEGINS>
MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-MASAURLExtn2016(TBD) } id-mod(0) id-mod-MASAURLExtn2016(TBD) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
skipping to change at page 20, line 11 skipping to change at page 20, line 11
2.4. Protocol Flow 2.4. Protocol Flow
A representative flow is shown in Figure 3: A representative flow is shown in Figure 3:
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Circuit | | Domain | | Vendor | | Pledge | | Circuit | | Domain | | Vendor |
| | | Join | | Registrar | | Service | | | | Join | | Registrar | | Service |
| | | Proxy | | (JRC) | | (MASA) | | | | Proxy | | (JRC) | | (MASA) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| | | Internet | | | | Internet |
[discover] | | |
|<-RFC4862 IPv6 addr | | | |<-RFC4862 IPv6 addr | | |
|<-RFC3927 IPv4 addr | Appendix A | Legend | |<-RFC3927 IPv4 addr | Appendix A | Legend |
|-------------------->| | C - circuit | |-------------------->| | C - circuit |
| optional: mDNS query| Appendix B | join proxy | | optional: mDNS query| Appendix B | join proxy |
| RFC6763/RFC6762 | | P - provisional | | RFC6763/RFC6762 | | P - provisional |
|<--------------------| | TLS connection | |<--------------------| | TLS connection |
| GRASP M_FLOOD | | | | GRASP M_FLOOD | | |
| periodic broadcast| | | | periodic broadcast| | |
[identity] | | |
|<------------------->C<----------------->| | |<------------------->C<----------------->| |
| TLS via the Join Proxy | | | TLS via the Join Proxy | |
|<--Registrar TLS server authentication---| | |<--Registrar TLS server authentication---| |
[PROVISIONAL accept of server cert] | | [PROVISIONAL accept of server cert] | |
P---X.509 client authentication---------->| | P---X.509 client authentication---------->| |
P | | | [request join] | |
P---Voucher Request (include nonce)------>| | P---Voucher Request(w/nonce for voucher)->| |
P | /---> | | P /------------------- | |
P | | [accept device?] | P | [accept device?] |
P | | [contact Vendor] | P | [contact Vendor] |
P | | |--Pledge ID-------->| P | |--Pledge ID-------->|
P | | |--Domain ID-------->| P | |--Domain ID-------->|
P | | |--optional:nonce--->| P | |--optional:nonce--->|
P | | | [extract DomainID] P optional: | [extract DomainID]
P | optional: | [update audit log] P can occur in advance | [update audit log]
P | |can | | P if nonceleess | |
P | |occur | | P | |<- voucher ---------|
P | |in | | P \------------------- | w/nonce if provided|
P | |advance | |
P | |if | |
P | |nonceless | |
P | | |<- voucher ---------|
P | \----> | |
P<------voucher---------------------------| | P<------voucher---------------------------| |
[verify voucher , [verify provisional cert| | | [imprint] | |
|---------------------------------------->| | |-------voucher status telemetry--------->| |
| [voucher status telemetry] |<-device audit log--| | |<-device audit log--|
| | [verify audit log and voucher] | | [verify audit log and voucher] |
|<--------------------------------------->| | |<--------------------------------------->| |
[enroll] | |
| Continue with RFC7030 enrollment | | | Continue with RFC7030 enrollment | |
| using now bidirectionally authenticated | | | using now bidirectionally authenticated | |
| TLS session. | | | | TLS session. | |
[enrolled] | |
Figure 3 Figure 3
2.5. Architectural Components 2.5. Architectural Components
2.5.1. Pledge 2.5.1. Pledge
The pledge is the device that is attempting to join. Until the The pledge is the device that is attempting to join. Until the
pledge completes the enrollment process, it has link-local network pledge completes the enrollment process, it has link-local network
connectivity only to the proxy. connectivity only to the proxy.
skipping to change at page 22, line 19 skipping to change at page 22, line 19
document does not place any additional architectural requirements on document does not place any additional architectural requirements on
the Public Key Infrastructure. the Public Key Infrastructure.
2.6. Certificate Time Validation 2.6. Certificate Time Validation
2.6.1. Lack of realtime clock 2.6.1. Lack of realtime clock
Many devices when bootstrapping do not have knowledge of the current Many devices when bootstrapping do not have knowledge of the current
time. Mechanisms such as Network Time Protocols cannot be secured time. Mechanisms such as Network Time Protocols cannot be secured
until bootstrapping is complete. Therefore bootstrapping is defined until bootstrapping is complete. Therefore bootstrapping is defined
in a method that does not require knowledge of the current time. in a method that does not require knowledge of the current time. A
pledge MAY ignore all time stamps in the voucher and in the
Unfortunately there are moments during bootstrapping when certificate validity periods if it does not know the current time.
certificates are verified, such as during the TLS handshake, where
validity periods are confirmed. This paradoxical "catch-22" is
resolved by the pledge maintaining a concept of the current "window"
of presumed time validity that is continually refined throughout the
bootstrapping process as follows:
o Initially the pledge does not know the current time.
o Bootstrapping pledges that have a Realtime Clock (RTC), SHOULD use
it to verify certificate validity. However, they MUST be prepared
for the recognize that the RTC might be completely wrong when a
RTC battery fails and resets to an origin time (e.g., Jan. 1,
1970)
o If the pledge has any stable storage (such as from where firmware
is loaded) then it SHOULD assume that the clock CAN NOT be before
the date at which the firmware or the the storage was last time
stamped. The pledge SHOULD NOT update the timestamps in any file
systems until it has a secure time source. This provides an
earliest date which is reasonable. Call this the current
reasonable date (CRD). This value MUST NOT be used for any future
Registration attempt. The current reasonable date (CRD) may only
increase during a single attempt.
o The pledge is exposed to dates in the following five places
(registrar certificate, notBefore and notAfter. Voucher created-
on, and expires-on. Additionally, CMS signatures contain a
signingTime)
o During the initial connection with the registrar, the pledge sees
the registrar's Certificate. It has an inception date (notBefore)
and an expiry date (notAfter). It is reasonable that the
notBefore date be after the pledge's current working reasonable
date. It is however, suspicious for the notAfter date to be
before the pledge's current reasonable date. No action is
recommended, other than an internal audit entry for this.
o If the notBefore date of the registrar's certificate is newer than
the pledge's reasonable date, then it MAY update it's current
reasonable date to the notBefore value.
o After the voucher request process, the pledge will have a voucher.
It can validate the signature on the voucher, as it has been (by
literal construction) provided with the MASA's key as a trust
anchor. The time values (created-on, expires-on) in the voucher
can not in general be validated as the pledge has no certain real
time clock. There are some reasonable assumptions that can be
made: the voucher's expires-on time can not be prior to the
pledge's current reasonable date. For nonceless vouchers, the
voucher's created-on time COULD be earlier if the as well if a
long-lived voucher was obtained some time in the past, and the
pledge has since gone through a firmware update and factory reset.
o If the voucher contains a nonce then the pledge MUST confirm the
nonce matches the original pledge voucher-request. This ensures
the voucher is fresh. See Section 5.2. In that case, the
voucher's created-on date MUST NOT be prior to the pledge's
current reasonable date. In addition, when there is a valid
nonce, the current reasonable date MAY be incremented to that of
the CMS signingTime.
o Once the voucher is accepted the validity period of the pinned- The pledge is exposed to dates in the following five places:
domain-cert in the voucher now serves as a valid time window. As registrar certificate notBefore, registrar certificiate notAfter,
explained in Section 5.5.4, the MASA has checked the registrar's voucher created-on, and voucher expires-on. Additionally, CMS
certificate against real clocks , the endorsement of the MASA signatures contain a signingTime.
allows the pledge to treat the notBefore and notAfter dates as
being constraints on any subsequent certificate validity periods
that may need to be checked: for instance, validating peer
certificates during ANIMA ACP setup.
o When accepting an enrollment certificate the validity period If the voucher contains a nonce then the pledge MUST confirm the
within the new certificate is assumed to be valid by the pledge. nonce matches the original pledge voucher-request. This ensures the
The pledge is now willing to use this credential for client voucher is fresh. See Section 5.2.
authentication.
2.6.2. Infinite Lifetime of IDevID 2.6.2. Infinite Lifetime of IDevID
[RFC5280] explains that long lived pledge certificates "SHOULD be [RFC5280] explains that long lived pledge certificates "SHOULD be
assigned the GeneralizedTime value of 99991231235959Z". Registrars assigned the GeneralizedTime value of 99991231235959Z". Registrars
MUST support such lifetimes and SHOULD support ignoring pledge MUST support such lifetimes and SHOULD support ignoring pledge
lifetimes if they did not follow the RFC5280 recommendations. lifetimes if they did not follow the RFC5280 recommendations.
For example, IDevID may have incorrect lifetime of N <= 3 years, For example, IDevID may have incorrect lifetime of N <= 3 years,
rendering replacement pledges from storage useless after N years rendering replacement pledges from storage useless after N years
skipping to change at page 24, line 28 skipping to change at page 23, line 6
There exist operationally open network wherein devices gain There exist operationally open network wherein devices gain
unauthenticated access to the internet at large. In these use cases unauthenticated access to the internet at large. In these use cases
the management domain for the device needs to be discovered within the management domain for the device needs to be discovered within
the larger internet. These are less likely within the anima scope the larger internet. These are less likely within the anima scope
but may be more important in the future. but may be more important in the future.
There are additionally some greenfield situations involving an There are additionally some greenfield situations involving an
entirely new installation where a device may have some kind of entirely new installation where a device may have some kind of
management uplink that it can use (such as via 3G network for management uplink that it can use (such as via 3G network for
instance). In such a future situation, the device might use this instance). In such a future situation, the device might use this
management interface to learn that it should configure itself by to- management interface to learn that it should configure itself to
be-determined mechanism (such as an Intent) to become the local become the local registrar.
registrar.
In order to support these scenarios, the pledge MAY contact a well In order to support these scenarios, the pledge MAY contact a well
known URI of a cloud registrar if a local registrar cannot be known URI of a cloud registrar if a local registrar cannot be
discovered or if the pledge's target use cases do not include a local discovered or if the pledge's target use cases do not include a local
registrar. registrar.
If the pledge uses a well known URI for contacting a cloud registrar If the pledge uses a well known URI for contacting a cloud registrar
an Implicit Trust Anchor database (see [RFC7030]) MUST be used to an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
authenticate service as described in [RFC6125]. This is consistent authenticate service as described in [RFC6125]. This is consistent
with the human user configuration of an EST server URI in [RFC7030] with the human user configuration of an EST server URI in [RFC7030]
which also depends on RFC6125. which also depends on RFC6125.
2.8. Determining the MASA to contact 2.8. Determining the MASA to contact
The registrar needs to be able to contact a MASA that is trusted by The registrar needs to be able to contact a MASA that is trusted by
the pledge in order to obtain vouchers. There are three mechanisms the pledge in order to obtain vouchers. There are three mechanisms
described: described:
The device's Initial Device Identifier will normally contain the MASA The device's Initial Device Identifier (IDevID) will normally contain
URL as detailed in Section 2.3. This is the RECOMMENDED mechanism. the MASA URL as detailed in Section 2.3. This is the RECOMMENDED
mechanism.
If the registrar is integrated with [I-D.ietf-opsawg-mud] and the If the registrar is integrated with [I-D.ietf-opsawg-mud] and the
pledge IDevID contains the id-pe-mud-url then the registrar MAY pledge IDevID contains the id-pe-mud-url then the registrar MAY
attempt to obtain the MASA URL from the MUD file. The MUD file attempt to obtain the MASA URL from the MUD file. The MUD file
extension for the MASA URL is defined in Appendix C. extension for the MASA URL is defined in Appendix C.
It can be operationally difficult to ensure the necessary X.509 It can be operationally difficult to ensure the necessary X.509
extensions are in the pledge's IDevID due to the difficulty of extensions are in the pledge's IDevID due to the difficulty of
aligning current pledge manufacturing with software releases and aligning current pledge manufacturing with software releases and
development. As a final fallback the registrar MAY be manually development. As a final fallback the registrar MAY be manually
skipping to change at page 25, line 41 skipping to change at page 24, line 18
The "proximity-registrar-cert" leaf is used in the pledge voucher- The "proximity-registrar-cert" leaf is used in the pledge voucher-
requests. This provides a method for the pledge to assert the requests. This provides a method for the pledge to assert the
registrar's proximity. registrar's proximity.
The "prior-signed-voucher-request" leaf is used in registrar voucher- The "prior-signed-voucher-request" leaf is used in registrar voucher-
requests. If present, it is the encoded (signed form) of the pledge requests. If present, it is the encoded (signed form) of the pledge
voucher-request. This provides a method for the registrar to forward voucher-request. This provides a method for the registrar to forward
the pledge's signed request to the MASA. This completes transmission the pledge's signed request to the MASA. This completes transmission
of the signed "proximity-registrar-cert" leaf. of the signed "proximity-registrar-cert" leaf.
Unless otherwise signaled (outside the voucher-request artifact), the
signing structure is as defined for vouchers, see [RFC8366].
3.1. Nonceless Voucher Requests
A registrar MAY also retrieve nonceless vouchers by sending nonceless A registrar MAY also retrieve nonceless vouchers by sending nonceless
voucher-requests to the MASA in order to obtain vouchers for use when voucher-requests to the MASA in order to obtain vouchers for use when
the registrar does not have connectivity to the MASA. No "prior- the registrar does not have connectivity to the MASA. No "prior-
signed-voucher-request" leaf would be included. The registrar will signed-voucher-request" leaf would be included. The registrar will
also need to know the serial number of the pledge. This document also need to know the serial number of the pledge. This document
does not provide a mechanism for the registrar to learn that in an does not provide a mechanism for the registrar to learn that in an
automated fashion. Typically this will be done via scanning of bar- automated fashion. Typically this will be done via scanning of bar-
code or QR-code on packaging, or via some sales channel integration. code or QR-code on packaging, or via some sales channel integration.
Unless otherwise signaled (outside the voucher-request artifact), the 3.2. Tree Diagram
signing structure is as defined for vouchers, see [RFC8366].
3.1. Tree Diagram
The following tree diagram illustrates a high-level view of a The following tree diagram illustrates a high-level view of a
voucher-request document. The voucher-request builds upon the voucher-request document. The voucher-request builds upon the
voucher artifact described in [RFC8366]. The tree diagram is voucher artifact described in [RFC8366]. The tree diagram is
described in [RFC8340]. Each node in the diagram is fully described described in [RFC8340]. Each node in the diagram is fully described
by the YANG module in Section 3.3. Please review the YANG module for by the YANG module in Section 3.4. Please review the YANG module for
a detailed description of the voucher-request format. a detailed description of the voucher-request format.
module: ietf-voucher-request module: ietf-voucher-request
grouping voucher-request-grouping grouping voucher-request-grouping
+-- voucher +-- voucher
+-- created-on? yang:date-and-time +-- created-on? yang:date-and-time
+-- expires-on? yang:date-and-time +-- expires-on? yang:date-and-time
+-- assertion enumeration +-- assertion? enumeration
+-- serial-number string +-- serial-number string
+-- idevid-issuer? binary +-- idevid-issuer? binary
+-- pinned-domain-cert? binary +-- pinned-domain-cert? binary
+-- domain-cert-revocation-checks? boolean +-- domain-cert-revocation-checks? boolean
+-- nonce? binary +-- nonce? binary
+-- last-renewal-date? yang:date-and-time +-- last-renewal-date? yang:date-and-time
+-- prior-signed-voucher-request? binary +-- prior-signed-voucher-request? binary
+-- proximity-registrar-cert? binary +-- proximity-registrar-cert? binary
3.2. Examples 3.3. Examples
This section provides voucher-request examples for illustration This section provides voucher-request examples for illustration
purposes. These examples conform to the encoding rules defined in purposes. For detailed examples, see Appendix D.2. These examples
[RFC7951]. conform to the encoding rules defined in [RFC7951].
Example (1) The following example illustrates a pledge voucher- Example (1) The following example illustrates a pledge voucher-
request. The assertion leaf is indicated as 'proximity' request. The assertion leaf is indicated as 'proximity'
and the registrar's TLS server certificate is included and the registrar's TLS server certificate is included
in the 'proximity-registrar-cert' leaf. See in the 'proximity-registrar-cert' leaf. See
Section 5.2. Section 5.2.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:00.000Z", "created-on": "2017-01-01T00:00:00.000Z",
"assertion": "proximity",
"proximity-registrar-cert": "base64encodedvalue==" "proximity-registrar-cert": "base64encodedvalue=="
} }
} }
Example (2) The following example illustrates a registrar voucher- Example (2) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is request. The 'prior-signed-voucher-request' leaf is
populated with the pledge's voucher-request (such as the populated with the pledge's voucher-request (such as the
prior example). The pledge's voucher-request, if a prior example). The pledge's voucher-request, if a
signed artifact with a CMS format signature is a binary signed artifact with a CMS format signature is a binary
object. In the JSON encoding used here it must be object. In the JSON encoding used here it must be
base64 encoded. The nonce, created-on and assertion is base64 encoded. The nonce, created-on and assertion is
carried forward. The serial-number is extracted from carried forward. The serial-number is extracted from
the pledge's Client Certificate from the TLS connection. the pledge's Client Certificate from the TLS connection.
See Section 5.5. See Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "proximity",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
"prior-signed-voucher": "base64encodedvalue==" "prior-signed-voucher-request": "base64encodedvalue=="
} }
} }
Example (3) The following example illustrates a registrar voucher- Example (3) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is not request. The 'prior-signed-voucher-request' leaf is not
populated with the pledge's voucher-request nor is the populated with the pledge's voucher-request nor is the
nonce leaf. This form might be used by a registrar nonce leaf. This form might be used by a registrar
requesting a voucher when the pledge can not communicate requesting a voucher when the pledge can not communicate
with the registrar (such as when it is powered down, or with the registrar (such as when it is powered down, or
still in packaging), and therefore could not submit a still in packaging), and therefore could not submit a
nonce. This scenario is most useful when the registrar nonce. This scenario is most useful when the registrar
is aware that it will not be able to reach the MASA is aware that it will not be able to reach the MASA
during deployment. See Section 5.5. during deployment. See Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "TBD",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
Example (4) The following example illustrates a registrar voucher- Example (4) The following example illustrates a registrar voucher-
request. The 'prior-signed-voucher-request' leaf is not request. The 'prior-signed-voucher-request' leaf is not
populated with the pledge voucher-request because the populated with the pledge voucher-request because the
pledge did not sign its own request. This form might be pledge did not sign its own request. This form might be
used when more constrained pledges are being deployed. used when more constrained pledges are being deployed.
The nonce is populated from the pledge's request. See The nonce is populated from the pledge's request. See
Section 5.5. Section 5.5.
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"assertion": "proximity",
"idevid-issuer": "base64encodedvalue==" "idevid-issuer": "base64encodedvalue=="
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
3.3. YANG Module 3.4. YANG Module
Following is a YANG [RFC7950] module formally extending the [RFC8366] Following is a YANG [RFC7950] module formally extending the [RFC8366]
voucher into a voucher-request. voucher into a voucher-request.
<CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang" <CODE BEGINS> file "ietf-voucher-request@2018-02-14.yang"
module ietf-voucher-request { module ietf-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher-request"; "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
skipping to change at page 30, line 14 skipping to change at page 28, line 52
uses v:voucher-artifact-grouping { uses v:voucher-artifact-grouping {
refine "voucher/created-on" { refine "voucher/created-on" {
mandatory false; mandatory false;
} }
refine "voucher/pinned-domain-cert" { refine "voucher/pinned-domain-cert" {
mandatory false; mandatory false;
} }
refine "voucher/domain-cert-revocation-checks" {
description "The domain-cert-revocation-checks field
is not valid in a voucher request, and
any occurance MUST be ignored";
}
refine "voucher/assertion" {
mandatory false;
description "Any assertion included in voucher
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 be
included in this field. included in this field.
For example, a pledge might sign a proximity voucher, which For example, a pledge might sign a voucher request
an intermediate registrar then re-signs to make its own with a proximity-registrar-cert, and the registrar
proximity assertion. This is a simple mechanism for a then includes it in the prior-signed-voucher-request field.
chain of trusted parties to change a voucher, while This is a simple mechanism for a chain of trusted
parties to change a voucher request, while
maintaining the prior signature information. maintaining the prior signature information.
The pledge MUST ignore all prior voucher information when The Registrar and MASA MAY examine the prior signed
accepting a voucher for imprinting. Other parties MAY voucher information for the
examine the prior signed voucher information for the
purposes of policy decisions. For example this information purposes of policy decisions. For example this information
could be useful to a MASA to determine that both pledge and could be useful to a MASA to determine that both pledge and
registrar agree on proximity assertions. The MASA SHOULD registrar agree on proximity assertions. The MASA SHOULD
remove all prior-signed-voucher-request information when remove all prior-signed-voucher-request information when
signing a voucher for imprinting so as to minimize the signing a voucher for imprinting so as to minimize the
final voucher size."; 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 RFC 5280,
Section 4 encoded using the ASN.1 distinguished encoding Section 4 encoded using the ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690. rules (DER), as specified in ITU-T X.690.
The first certificate in the Registrar TLS server The first certificate in the Registrar TLS server
certificate_list sequence (see [RFC5246]) presented by certificate_list sequence (see [RFC5246]) presented by
the Registrar to the Pledge. This MUST be populated in a the Registrar to the Pledge. This MUST be populated in a
Pledge's voucher request if the proximity assertion is Pledge's voucher request if a proximity assertion is
populated."; requested.";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. Proxying details (Pledge - Proxy - Registrar) 4. Proxying details (Pledge - Proxy - Registrar)
The role of the proxy is to facilitate communications. The proxy The role of the proxy is to facilitate communications. The proxy
forwards packets between the pledge and a registrar that has been forwards packets between the pledge and a registrar that has been
provisioned to the proxy via GRASP discovery. provisioned to the proxy via GRASP discovery.
This section defines a stateful proxy mechanism which is refered to This section defines a stateful proxy mechanism which is refered to
as a "circuit" proxy. as a "circuit" proxy.
The proxy does not terminate the TLS handshake: it passes streams of The proxy does not terminate the TLS handshake: it passes streams of
bytes onward without examination. bytes onward without examination. A proxy MUST NOT assume any
specific TLS version.
A proxy MAY assume TLS framing for auditing purposes, but MUST NOT
assume any TLS version.
Registrars are assumed to have logically a locally integrated circuit A Registrar can directly provide the proxy announcements described
proxy to support directly (subnet) connected pledges - because below, in which case the announced port can point directly to the
registrars themself does not define any functions for pledges to Registrar itself. In this scenario the pledge is unaware that there
discover them. Such a logical local proxy does not need to provide is no proxing occuring. This is useful for Registrars servicing
actual TCP proxying (just discovery) as long as the registrar can pledges on directly connected networks.
operate with subnet (link) local addresses on the interfaces where
pledges may connect to.
As a result of the proxy Discovery process in Section 4.1.1, the port As a result of the proxy Discovery process in Section 4.1.1, the port
number exposed by the proxy does not need to be well known, or number exposed by the proxy does not need to be well known, or
require an IANA allocation. require an IANA allocation.
In the ANI, the Autonomic Control Plane (ACP) secured instance of
GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI
registrar ACP addresses and ports by ANI proxies. The TCP leg of the
proxy connection between ANI proxy and ANI registrar therefore also
runs across the ACP.
During the discovery of the Registrar by the Join Proxy, the Join During the discovery of the Registrar by the Join Proxy, the Join
Proxy will also learn which kinds of proxy mechanisms are available. Proxy will also learn which kinds of proxy mechanisms are available.
This will allow the Join Proxy to use the lowest impact mechanism This will allow the Join Proxy to use the lowest impact mechanism
which the Join Proxy and Registrar have in common. which the Join Proxy and Registrar have in common.
In order to permit the proxy functionality to be implemented on the In order to permit the proxy functionality to be implemented on the
maximum variety of devices the chosen mechanism SHOULD use the maximum variety of devices the chosen mechanism SHOULD use the
minimum amount of state on the proxy device. While many devices in minimum amount of state on the proxy device. While many devices in
the ANIMA target space will be rather large routers, the proxy the ANIMA target space will be rather large routers, the proxy
function is likely to be implemented in the control plane CPU of such function is likely to be implemented in the control plane CPU of such
a device, with available capabilities for the proxy function similar a device, with available capabilities for the proxy function similar
to many class 2 IoT devices. to many class 2 IoT devices.
The document [I-D.richardson-anima-state-for-joinrouter] provides a The document [I-D.richardson-anima-state-for-joinrouter] provides a
more extensive analysis and background of the alternative proxy more extensive analysis and background of the alternative proxy
methods. methods.
4.1. Pledge discovery of Proxy 4.1. Pledge discovery of Proxy
The result of discovery is a logical communication with a registrar, The result of discovery is a logical communication with a registrar,
through a proxy. The proxy is transparent to the pledge but is through a proxy. The proxy is transparent to the pledge. The
always assumed to exist. communication between the pledge is over IPv6 Link-Local addresses.
To discover the proxy the pledge performs the following actions: To discover the proxy the pledge performs the following actions:
1. MUST: Obtains a local address using IPv6 methods as described in 1. MUST: Obtains a local address using IPv6 methods as described in
[RFC4862] IPv6 Stateless Address AutoConfiguration. Use of [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of
[RFC4941] temporary addresses is encouraged. A new temporary [RFC4941] temporary addresses is encouraged. To limit pervasive
address SHOULD be allocated whenever the discovery process is monitoring ( [RFC7258]), a new temporary address MAY use a short
forced to restart due to failures. Pledges will generally prefer lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short).
use of IPv6 Link-Local addresses, and discovery of proxy will be Pledges will generally prefer use of IPv6 Link-Local addresses,
by Link-Local mechanisms. IPv4 methods are described in and discovery of proxy will be by Link-Local mechanisms. IPv4
Appendix A methods are described in Appendix A
2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp])
announcements of the objective: "AN_Proxy". See section announcements of the objective: "AN_Proxy". See section
Section 4.1.1 for the details of the objective. The pledge MAY Section 4.1.1 for the details of the objective. The pledge MAY
listen concurrently for other sources of information, see listen concurrently for other sources of information, see
Appendix B. Appendix B.
Once a proxy is discovered the pledge communicates with a registrar Once a proxy is discovered the pledge communicates with a registrar
through the proxy using the bootstrapping protocol defined in through the proxy using the bootstrapping protocol defined in
Section 5. Section 5.
skipping to change at page 34, line 5 skipping to change at page 33, line 5
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
["AN_Proxy", 4, 1, ""], ["AN_Proxy", 4, 1, ""],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]
Figure 6b: Proxy Discovery Figure 6b: Proxy Discovery
The formal CDDL [I-D.ietf-cbor-cddl] definition is: The formal CDDL [I-D.ietf-cbor-cddl] definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_Proxy", objective-flags, loop-count, objective = ["AN_Proxy", objective-flags, loop-count,
objective-value] objective-value]
ttl = 180000 ; 180,000 ms (3 minutes) ttl = 180000 ; 180,000 ms (3 minutes)
initiator = ACP address to contact Registrar initiator = ACP address to contact Registrar
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; one hop only loop-count = 1 ; one hop only
objective-value = any ; none objective-value = any ; none
locator-option = [ O_IPv6_LOCATOR, ipv6-address, locator-option = [ O_IPv6_LOCATOR, ipv6-address,
transport-proto, port-number ] transport-proto, port-number ]
ipv6-address = the v6 LL of the Proxy ipv6-address = the v6 LL of the Proxy
$transport-proto /= IPPROTO_TCP ; note this can be any value from the transport-proto /= IPPROTO_TCP ; note this can be any value from the
; IANA protocol registry, as per ; IANA protocol registry, as per
; [GRASP] section 2.9.5.1, note 3. ; [GRASP] section 2.9.5.1, note 3.
port-number = selected by Proxy port-number = selected by Proxy
Figure 6c: AN_Proxy CDDL Figure 6c: AN_Proxy CDDL
On a small network the Registrar MAY include the GRASP M_FLOOD
announcements to locally connected networks.
The $transport-proto above indicates the method that the pledge-
proxy-registrar will use. The TCP method described here is
mandatory, and other proxy methods, such as CoAP methods not defined
in this document are optional. Other methods MUST NOT be enabled
unless the Join Registrar ASA indicates support for them in it's own
announcement.
4.2. CoAP connection to Registrar 4.2. CoAP connection to Registrar
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 may be described in future work. for this document, and is described in future work. See
[I-D.ietf-anima-constrained-voucher].
4.3. Proxy discovery 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. They MUST support ANI TLS circuit proxy and M_FLOOD messages. ANI proxies MUST support GRASP discovery of
therefore BRSKI across HTTPS/TLS native across the ACP. ANI proxies registrars.
MUST support GRASP discovery of registrars.
The M_FLOOD is formatted as follows: The M_FLOOD is formatted as follows:
[M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, [M_FLOOD, 12340815, 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, 80]] h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 80]]
Figure 7a: Registrar Discovery Figure 7a: Registrar Discovery
skipping to change at page 35, line 41 skipping to change at page 35, line 5
locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
A protocol of 6 indicates that TCP proxying on the indicated port is A protocol of 6 indicates that TCP proxying on the indicated port is
desired. desired.
Registrars MUST announce the set of protocols that they support. Registrars MUST announce the set of protocols that they support.
They MUST support TCP traffic. They MUST support TCP traffic.
Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated.
Registrars MUST support ANI TLS circuit proxy and therefore BRSKI
across HTTPS/TLS native across the ACP.
In the ANI, the Autonomic Control Plane (ACP) secured instance of
GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI
registrar ACP addresses and ports by ANI proxies. The TCP leg of the
proxy connection between ANI proxy and ANI registrar therefore also
runs across the ACP.
5. Protocol Details (Pledge - Registrar - MASA) 5. Protocol Details (Pledge - Registrar - MASA)
The pledge MUST initiate BRSKI after boot if it is unconfigured. The The pledge MUST initiate BRSKI after boot if it is unconfigured. The
pledge MUST NOT automatically initiate BRSKI if it has been pledge MUST NOT automatically initiate BRSKI if it has been
configured or is in the process of being configured. configured or is in the process of being configured.
BRSKI is described as extensions to EST [RFC7030]. The goal of these BRSKI is described as extensions to EST [RFC7030]. The goal of these
extensions is to reduce the number of TLS connections and crypto extensions is to reduce the number of TLS connections and crypto
operations required on the pledge. The registrar implements the operations required on the pledge. The registrar implements the
BRSKI REST interface within the same "/.well-known" URI tree as the BRSKI REST interface within the same "/.well-known" URI tree as the
existing EST URIs as described in EST [RFC7030] section 3.2.2. The existing EST URIs as described in EST [RFC7030] section 3.2.2. The
communication channel between the pledge and the registrar is communication channel between the pledge and the registrar is
referred to as "BRSKI-EST" (see Figure 1). referred to as "BRSKI-EST" (see Figure 1).
The communication channel between the registrar and MASA is similarly The communication channel between the registrar and MASA is similarly
described as extensions to EST within the same "/.well-known" tree. described as extensions to EST within the same "/.well-known" tree.
For clarity this channel is referred to as "BRSKI-MASA". (See For clarity this channel is referred to as "BRSKI-MASA". (See
Figure 1). Figure 1).
MASA URI is "https://" authority "/.well-known/est". MASA URI is "https://" iauthority "/.well-known/est".
BRSKI uses existing CMS message formats for existing EST operations. BRSKI uses existing CMS message formats for existing EST operations.
BRSKI uses JSON [RFC7159] for all new operations defined here, and BRSKI uses JSON [RFC7159] for all new operations defined here, and
voucher formats. voucher formats.
While EST section 3.2 does not insist upon use of HTTP 1.1 persistent While EST section 3.2 does not insist upon use of HTTP 1.1 persistent
connections, BRSKI-EST connections SHOULD use persistent connections. connections, BRSKI-EST connections SHOULD use persistent connections.
The intention of this guidance is to ensure the provisional TLS state The intention of this guidance is to ensure the provisional TLS state
occurs only once, and that the subsequent resolution of the provision occurs only once, and that the subsequent resolution of the provision
state is not subject to a MITM attack during a critical phase. state is not subject to a MITM attack during a critical phase.
Summarized automation extensions for the BRSKI-EST flow are: Summarized automation extensions for the BRSKI-EST flow are:
o The pledge either attempts concurrent connections via each
discovered proxy, or it times out quickly and tries connections in
series, as explained at the end of Section 5.1.
o The pledge provisionally accepts the registrar certificate during o The pledge provisionally accepts the registrar certificate during
the TLS handshake as detailed in Section 5.1. the TLS handshake as detailed in Section 5.1.
o The pledge either attempts concurrent connections, or it times out
quickly and tries connections in series.
o The pledge requests and validates a voucher using the new REST o The pledge requests and validates a voucher using the new REST
calls described below. calls described below.
o The pledge completes authentication of the server certificate as o The pledge completes authentication of the server certificate as
detailed in Section 5.6.1. This moves the BRSKI-EST TLS detailed in Section 5.6.1. This moves the BRSKI-EST TLS
connection out of the provisional state. connection out of the provisional state.
o Mandatory boostrap steps conclude with voucher status telemetry o Mandatory boostrap steps conclude with voucher status telemetry
(see Section 5.7). (see Section 5.7).
skipping to change at page 37, line 38 skipping to change at page 37, line 9
Establishment of the BRSKI-EST TLS connection is as specified in EST Establishment of the BRSKI-EST TLS connection is as specified in EST
[RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
[RFC7030] wherein the client is authenticated with the IDevID [RFC7030] wherein the client is authenticated with the IDevID
certificate, and the EST server (the registrar) is provisionally certificate, and the EST server (the registrar) is provisionally
authenticated with an unverified server certificate. authenticated with an unverified server certificate.
The pledge maintains a security paranoia concerning the provisional The pledge maintains a security paranoia concerning the provisional
state, and all data received, until a voucher is received and state, and all data received, until a voucher is received and
verified as specified in Section 5.6.1 verified as specified in Section 5.6.1
To avoid blocking on a single erroneous registrar the pledge MUST A Pledge that can connect to multiple registries concurrently, SHOULD
drop the connection after 5 seconds in which there has been no do so. Some devices may be unable to do so for lack of threading, or
progress on the TCP connection. It should proceed to connect to any resource issues. Concurrent connections defeat atttempts by a
other registrar's via any other discovered proxies if there are any. malicious proxy from causing a TCP Slowloris-like attack (see
If there were no other proxies discovered, the pledge MAY continue to [slowloris]).
wait, as long as it is concurrently listening for new proxy
announcements. A pledge that can not maintain as many connections as there are
eligible proxies. If no connection is making process after 5 seconds
then the pledge SHOULD drop the oldest connection and go on to a
different proxy: the proxy that has been communicated with least
recently. If there were no other proxies discovered, the pledge MAY
continue to wait, as long as it is concurrently listening for new
proxy announcements.
5.2. Pledge Requests Voucher from the Registrar 5.2. Pledge Requests Voucher from the Registrar
When the pledge bootstraps it makes a request for a voucher from a When the pledge bootstraps it makes a request for a voucher from a
registrar. registrar.
This is done with an HTTPS POST using the operation path value of This is done with an HTTPS POST using the operation path value of
"/.well-known/est/requestvoucher". "/.well-known/est/requestvoucher".
The request media types are: The request media types are:
skipping to change at page 38, line 30 skipping to change at page 38, line 10
future media types but of course will simply fail the request if future media types but of course will simply fail the request if
those types are not yet known. those types are not yet known.
The pledge populates the voucher-request fields as follows: The pledge populates the voucher-request fields as follows:
created-on: Pledges that have a realtime clock are RECOMMENDED to created-on: Pledges that have a realtime clock are RECOMMENDED to
populate this field. This provides additional information to the populate this field. This provides additional information to the
MASA. MASA.
nonce: The pledge voucher-request MUST contain a cryptographically nonce: The pledge voucher-request MUST contain a cryptographically
strong random or pseudo-random number nonce. Doing so ensures strong random or pseudo-random number nonce. (see [RFC4086]) Doing
Section 2.6.1 functionality. The nonce MUST NOT be reused for so ensures Section 2.6.1 functionality. The nonce MUST NOT be
multiple bootstrapping attempts. reused for multiple bootstrapping attempts. (The registrar
voucher-request MAY omit the nonce as per Section 3.1)
assertion: The pledge voucher-request MAY contain an assertion of
"proximity".
proximity-registrar-cert: In a pledge voucher-request this is the proximity-registrar-cert: In a pledge voucher-request this is the
first certificate in the TLS server 'certificate_list' sequence first certificate in the TLS server 'certificate_list' sequence
(see [RFC5246]) presented by the registrar to the pledge. This (see [RFC5246]) presented by the registrar to the pledge. This
MUST be populated in a pledge voucher-request if the "proximity" MUST be populated in a pledge voucher-request if the "proximity"
assertion is populated. assertion is populated.
All other fields MAY be omitted in the pledge voucher-request. All other fields MAY be omitted in the pledge voucher-request.
An example JSON payload of a pledge voucher-request is in Section 3.2 An example JSON payload of a pledge voucher-request is in Section 3.3
Example 1. Example 1.
The registrar validates the client identity as described in EST The registrar validates the client identity as described in EST
[RFC7030] section 3.3.2. If the request is signed the registrar [RFC7030] section 3.3.2. If the request is signed the registrar
confirms that the 'proximity' asserion and associated 'proximity- confirms that the associated 'proximity-registrar-cert' is correct.
registrar-cert' are correct.
5.3. Registrar Authorization of Pledge 5.3. Registrar Authorization of Pledge
In a fully automated network all devices must be securely identified In a fully automated network all devices must be securely identified
and authorized to join the domain. and authorized to join the domain.
A Registrar accepts or declines a request to join the domain, based A Registrar accepts or declines a request to join the domain, based
on the authenticated identity presented. Automated acceptance on the authenticated identity presented. Automated acceptance
criteria include: criteria include:
skipping to change at page 40, line 35 skipping to change at page 40, line 13
the Domain CA, MUST be included in the CMS structure. the Domain CA, MUST be included in the CMS structure.
MASA impementations SHOULD anticipate future media types but of MASA impementations SHOULD anticipate future media types but of
course will simply fail the request if those types are not yet known. course will simply fail the request if those types are not yet known.
The registrar populates the voucher-request fields as follows: The registrar populates the voucher-request fields as follows:
created-on: Registrars are RECOMMENDED to populate this field. This created-on: Registrars are RECOMMENDED to populate this field. This
provides additional information to the MASA. provides additional information to the MASA.
nonce: The optional nonce value from the pledge request if desired nonce: This is the value from the pledge voucher-request. The
(see below). registrar voucher-request MAY omit the nonce as per Section 3.1)
serial-number: The serial number of the pledge the registrar would serial-number: The serial number of the pledge the registrar would
like a voucher for. The registrar determines this value by like a voucher for. The registrar determines this value by
parsing the authenticated pledge IDevID certificate. See parsing the authenticated pledge IDevID certificate. See
Section 2.3. The registrar SHOULD verify that the serial number Section 2.3. The registrar MUST verify that the serial number
field it parsed matches the serial number field the pledge field it parsed matches the serial number field the pledge
provided in its voucher-request. This provides a sanity check provided in its voucher-request. This provides a sanity check
useful for detecting error conditions and logging. The registrar useful for detecting error conditions and logging. The registrar
MUST NOT simply copy the serial number field from a pledge voucher MUST NOT simply copy the serial number field from a pledge voucher
request as that field is claimed but not certified. request as that field is claimed but not certified.
idevid-issuer: The idevid-issuer value from the pledge certificate idevid-issuer: The idevid-issuer value from the pledge certificate
is included to ensure a statistically unique identity. is included to ensure a statistically unique identity.
prior-signed-voucher-request: If a signed pledge voucher-request was prior-signed-voucher-request: If a signed pledge voucher-request was
skipping to change at page 41, line 21 skipping to change at page 40, line 48
Doing so allows the registrar to request a voucher when the pledge is Doing so allows the registrar to request a voucher when the pledge is
offline, or when the registrar anticipates not being able to connect offline, or when the registrar anticipates not being able to connect
to the MASA while the pledge is being deployed. Some use cases to the MASA while the pledge is being deployed. Some use cases
require the registrar to learn the appropriate IDevID SerialNumber require the registrar to learn the appropriate IDevID SerialNumber
field from the physical device labeling or from the sales channel field from the physical device labeling or from the sales channel
(out-of-scope for this document). (out-of-scope for this document).
All other fields MAY be omitted in the registrar voucher-request. All other fields MAY be omitted in the registrar voucher-request.
Example JSON payloads of registrar voucher-requests are in Example JSON payloads of registrar voucher-requests are in
Section 3.2 Examples 2 through 4. Section 3.3 Examples 2 through 4.
The MASA verifies that the registrar voucher-request is internally The MASA verifies that the registrar voucher-request is internally
consistent but does not necessarily authenticate the registrar consistent but does not necessarily authenticate the registrar
certificate since the registrar is not known to the MASA in advance. certificate since the registrar is not known to the MASA in advance.
The MASA performs the actions and validation checks described in the The MASA performs the actions and validation checks described in the
following sub-sections before issuing a voucher. following sub-sections before issuing a voucher.
5.5.1. MASA renewal of expired vouchers 5.5.1. MASA renewal of expired vouchers
As described in [RFC8366] vouchers are normally short lived to avoid As described in [RFC8366] vouchers are normally short lived to avoid
revocation issues. If the request is for a previous (expired) revocation issues. If the request is for a previous (expired)
voucher using the same registrar then the request for a renewed voucher using the same registrar then the request for a renewed
voucher SHOULD be automatically authorized. The MASA has sufficient voucher SHOULD be automatically authorized. The MASA has sufficient
information to determine this by examining the request, the registrar information to determine this by examining the request, the registrar
skipping to change at page 43, line 16 skipping to change at page 42, line 43
The registrar's certificate chain is extracted from the signature The registrar's certificate chain is extracted from the signature
method. The chain includes the domain CA certificate as specified in method. The chain includes the domain CA certificate as specified in
Section 5.5. This certificate is used to populate the "pinned- Section 5.5. This certificate is used to populate the "pinned-
domain-cert" of the voucher being issued. The domainID (e.g., hash domain-cert" of the voucher being issued. The domainID (e.g., hash
of the root public key) is determined from the pinned-domain-cert and of the root public key) is determined from the pinned-domain-cert and
is used to update the audit log. is used to update the audit log.
5.5.7. MASA nonce handling 5.5.7. MASA nonce handling
The MASA does not verify the nonce itself. It MAY perform a simple The MASA does not verify the nonce itself. If the registrar voucher-
consistency check: If the registrar voucher-request contains a nonce request contains a nonce, and the prior-signed-voucher-request is
and the prior-signed-voucher-request exists then the nonce in both exist, then the MASA MUST verify that the nonce is consistent.
MUST be consistent. (Recall from above that the voucher-request (Recall from above that the voucher-request might not contain a
might not contain a nonce, see Section 5.5 and Section 5.5.3). nonce, see Section 5.5 and Section 5.5.3).
The MASA MUST use the nonce from the registrar voucher-request for The MASA MUST use the nonce from the registrar voucher-request for
the resulting voucher and audit log. The prior-signed-voucher- the resulting voucher and audit log. The prior-signed-voucher-
request nonce is ignored during this operation. request nonce is ignored during this operation.
5.6. MASA and Registrar Voucher Response 5.6. MASA and Registrar Voucher Response
The MASA voucher response to the registrar is forwarded without The MASA voucher response to the registrar is forwarded without
changes to the pledge; therefore this section applies to both the changes to the pledge; therefore this section applies to both the
MASA and the registrar. The HTTP signaling described applies to both MASA and the registrar. The HTTP signaling described applies to both
skipping to change at page 44, line 6 skipping to change at page 43, line 34
as described in EST [RFC7030] section 4.2.3 wherein the client "MUST as described in EST [RFC7030] section 4.2.3 wherein the client "MUST
wait at least the specified 'Retry-After' time before repeating the wait at least the specified 'Retry-After' time before repeating the
same request". (see [RFC7231] section 6.6.4) The pledge is same request". (see [RFC7231] section 6.6.4) The pledge is
RECOMMENDED to provide local feedback (blinked LED etc) during this RECOMMENDED to provide local feedback (blinked LED etc) during this
wait cycle if mechanisms for this are available. To prevent an wait cycle if mechanisms for this are available. To prevent an
attacker registrar from significantly delaying bootstrapping the attacker registrar from significantly delaying bootstrapping the
pledge MUST limit the 'Retry-After' time to 60 seconds. Ideally the pledge MUST limit the 'Retry-After' time to 60 seconds. Ideally the
pledge would keep track of the appropriate Retry-After header values pledge would keep track of the appropriate Retry-After header values
for any number of outstanding registrars but this would involve a for any number of outstanding registrars but this would involve a
state table on the pledge. Instead the pledge MAY ignore the exact state table on the pledge. Instead the pledge MAY ignore the exact
Retry-After value in favor of a single hard coded value. A registrar Retry-After value in favor of a single hard coded value (a registrar
that is unable to complete the transaction the first time due to that is unable to complete the transaction after the first 60 seconds
timing reasons will have future chances. has another chance a minute later). A pledge SHOULD only maintain a
202 retry-state for up to 4 days, which is longer than a long
weekend, after which time the enrollment attempt fails and the pledge
returns to discovery state.
In order to avoid infinite redirect loops, which a malicious In order to avoid infinite redirect loops, which a malicious
registrar might do in order to keep the pledge from discovering the registrar might do in order to keep the pledge from discovering the
correct registrar, the pledge MUST NOT follow more than one correct registrar, the pledge MUST NOT follow more than one
redirection (3xx code) to another web origins. EST supports redirection (3xx code) to another web origins. EST supports
redirection but requires user input; this change allows the pledge to redirection but requires user input; this change allows the pledge to
follow a single redirection without a user interaction. follow a single redirection without a user interaction.
A 403 (Forbidden) response is appropriate if the voucher-request is A 403 (Forbidden) response is appropriate if the voucher-request is
not signed correctly, stale, or if the pledge has another outstanding not signed correctly, stale, or if the pledge has another outstanding
skipping to change at page 45, line 20 skipping to change at page 44, line 44
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
The MASA populates the voucher fields as follows: The MASA populates the voucher fields as follows:
nonce: The nonce from the pledge if available. See Section 5.5.7. nonce: The nonce from the pledge if available. See Section 5.5.7.
assertion: The method used to verify assertion. See Section 5.5.5. assertion: The method used to verify assertion. See Section 5.5.5.
pinned-domain-cert: The domain CA cert. See Section 5.5.6. pinned-domain-cert: The domain CA cert. See Section 5.5.6. This
figure is illustrative, for an example, see Appendix D.2
serial-number: The serial-number as provided in the voucher-request. serial-number: The serial-number as provided in the voucher-request.
Also see Section 5.5.5. Also see Section 5.5.5.
domain-cert-revocation-checks: Set as appropriate for the pledge's domain-cert-revocation-checks: Set as appropriate for the pledge's
capabilities and as documented in [RFC8366]. The MASA MAY set capabilities and as documented in [RFC8366]. The MASA MAY set
this field to 'false' since setting it to 'true' would require this field to 'false' since setting it to 'true' would require
that revocation information be available to the pledge and this that revocation information be available to the pledge and this
document does not make normative requirements for [RFC6961] or document does not make normative requirements for [RFC6961] or
equivalent integrations. equivalent integrations.
skipping to change at page 45, line 43 skipping to change at page 45, line 19
the voucher lifetime is consistent with any revocation or pinned- the voucher lifetime is consistent with any revocation or pinned-
domain-cert consistency checks the pledge might perform. See domain-cert consistency checks the pledge might perform. See
section Section 2.6.1. There are three times to consider: (a) a section Section 2.6.1. There are three times to consider: (a) a
configured voucher lifetime in the MASA, (b) the expiry time for configured voucher lifetime in the MASA, (b) the expiry time for
the registrar's certificate, (c) any certificate revocation the registrar's certificate, (c) any certificate revocation
information (CRL) lifetime. The expires-on field SHOULD be before information (CRL) lifetime. The expires-on field SHOULD be before
the earliest of these three values. Typically (b) will be some the earliest of these three values. Typically (b) will be some
significant time in the future, but (c) will typically be short significant time in the future, but (c) will typically be short
(on the order of a week or less). The RECOMMENDED period for (a) (on the order of a week or less). The RECOMMENDED period for (a)
is on the order of 20 minutes, so it will typically determine the is on the order of 20 minutes, so it will typically determine the
lifespan of the resulting voucher. lifespan of the resulting voucher. 20 minutes is sufficent time
to reach the post-provisional state in the pledge, at which point
there is an established trust relationship between pledge and
registrar. The subsequent operations can take as long as required
from that point onwards. The lifetime of the voucher has no
impact on the lifespan of the ownership relationship.
Whenever a voucher is issued the MASA MUST update the audit log Whenever a voucher is issued the MASA MUST update the audit log
appropriately. The internal state requirements to maintain the audit appropriately. The internal state requirements to maintain the audit
log are out-of-scope. See Section 5.8.1 for a discussion of log are out-of-scope. See Section 5.8.1 for a discussion of
reporting the log to a registrar. reporting the log to a registrar.
5.6.1. Pledge voucher verification 5.6.1. Pledge voucher verification
The pledge MUST verify the voucher signature using the manufacturer The pledge MUST verify the voucher signature using the manufacturer
installed trust anchor associated with the manufacturer's MASA (this installed trust anchor(s) associated with the manufacturer's MASA
is likely included in the pledge's firmware). (this is likely included in the pledge's firmware). Management of
the manufacter installed trust anchor(s) is out-of-scope of this
document; this protocol does not update these trust anchor(s).
The pledge MUST verify the serial-number field of the signed voucher The pledge MUST verify the serial-number field of the signed voucher
matches the pledge's own serial-number. matches the pledge's own serial-number.
The pledge MUST verify that the voucher nonce field is accurate and The pledge MUST verify that the voucher nonce field is accurate and
matches the nonce the pledge submitted to this registrar, or that the matches the nonce the pledge submitted to this registrar, or that the
voucher is nonceless (see Section 6.2). voucher is nonceless (see Section 6.2).
The pledge MUST be prepared to parse and fail gracefully from a The pledge MUST be prepared to parse and fail gracefully from a
voucher response that does not contain a 'pinned-domain-cert' field. voucher response that does not contain a 'pinned-domain-cert' field.
skipping to change at page 47, line 6 skipping to change at page 46, line 35
The registrar MUST use a certificate that chains to the pinned- The registrar MUST use a certificate that chains to the pinned-
domain-cert as its TLS server certificate. domain-cert as its TLS server certificate.
The pledge's PKIX path validation of a registrar certificate's The pledge's PKIX path validation of a registrar certificate's
validity period information is as described in Section 2.6.1. Once validity period information is as described in Section 2.6.1. Once
the PKIX path validation is successful the TLS connection is no the PKIX path validation is successful the TLS connection is no
longer provisional. longer provisional.
The pinned-domain-cert MAY be installed as an trust anchor for future The pinned-domain-cert MAY be installed as an trust anchor for future
operations. It can therefore can be used to authenticate any operations such as enrollment (e.g. [RFC7030] as recommended) or
dynamically discovered EST server that contain the id-kp-cmcRA trust anchor management or raw protocols that do not need full PKI
extended key usage extension as detailed in EST RFC7030 section based key management. It can be used to authenticate any dynamically
3.6.1; but to reduce system complexity the pledge SHOULD avoid discovered EST server that contain the id-kp-cmcRA extended key usage
additional discovery operations. Instead the pledge SHOULD extension as detailed in EST RFC7030 section 3.6.1; but to reduce
communicate directly with the registrar as the EST server. The system complexity the pledge SHOULD avoid additional discovery
'pinned-domain-cert' is not a complete distribution of the [RFC7030] operations. Instead the pledge SHOULD communicate directly with the
section 4.1.3 CA Certificate Response, which is an additional registrar as the EST server. The 'pinned-domain-cert' is not a
justification for the recommendation to proceed with EST key complete distribution of the [RFC7030] section 4.1.3 CA Certificate
management operations. Once a full CA Certificate Response is Response, which is an additional justification for the recommendation
obtained it is more authoritative for the domain than the limited to proceed with EST key management operations. Once a full CA
'pinned-domain-cert' response. Certificate Response is obtained it is more authoritative for the
domain than the limited 'pinned-domain-cert' response.
5.7. Pledge BRSKI Status Telemetry 5.7. Pledge BRSKI Status Telemetry
The domain is expected to provide indications to the system The domain is expected to provide indications to the system
administrators concerning device lifecycle status. To facilitate administrators concerning device lifecycle status. To facilitate
this it needs telemetry information concerning the device's status. this it needs telemetry information concerning the device's status.
To indicate pledge status regarding the voucher, the pledge MUST post To indicate pledge status regarding the voucher, the pledge MUST post
a status message. a status message.
skipping to change at page 51, line 24 skipping to change at page 51, line 12
any other device deployed"). Log entries can also be compared any other device deployed"). Log entries can also be compared
against local history logs in search of discrepancies (e.g. "this against local history logs in search of discrepancies (e.g. "this
device was re-deployed some number of times internally but the device was re-deployed some number of times internally but the
external audit log shows additional re-deployments our internal external audit log shows additional re-deployments our internal
logs are unaware of"). logs are unaware of").
nonce: Nonceless entries mean the logged domainID could nonce: Nonceless entries mean the logged domainID could
theoretically trigger a reset of the pledge and then take over theoretically trigger a reset of the pledge and then take over
management by using the existing nonceless voucher. management by using the existing nonceless voucher.
assertion: The assetion leaf in the voucher and audit log indicates assertion: The assertion leaf in the voucher and audit log indicates
why the MASA issued the voucher. A "verified" entry means that why the MASA issued the voucher. A "verified" entry means that
the MASA issued the associated voucher as a result of positive the MASA issued the associated voucher as a result of positive
verification of ownership but this can still be problematic for verification of ownership but this can still be problematic for
registrar's that expected only new (not pre-owned) pledges. A registrar's that expected only new (not pre-owned) pledges. A
"logged" assertion informs the registrar that the prior vouchers "logged" assertion informs the registrar that the prior vouchers
were issued with minimal verification. A "proximity" assertion were issued with minimal verification. A "proximity" assertion
assures the registrar that the pledge was truly communicating with assures the registrar that the pledge was truly communicating with
the prior domain and thus provides assurance that the prior domain the prior domain and thus provides assurance that the prior domain
really has deployed the pledge. really has deployed the pledge.
skipping to change at page 52, line 7 skipping to change at page 51, line 42
5.9. EST Integration for PKI bootstrapping 5.9. EST Integration for PKI bootstrapping
The pledge SHOULD follow the BRSKI operations with EST enrollment The pledge SHOULD follow the BRSKI operations with EST enrollment
operations including "CA Certificates Request", "CSR Attributes" and operations including "CA Certificates Request", "CSR Attributes" and
"Client Certificate Request" or "Server-Side Key Generation", etc. "Client Certificate Request" or "Server-Side Key Generation", etc.
This is a relatively seamless integration since BRSKI REST calls This is a relatively seamless integration since BRSKI REST calls
provide an automated alternative to the manual bootstrapping method provide an automated alternative to the manual bootstrapping method
described in [RFC7030]. As noted above, use of HTTP 1.1 persistent described in [RFC7030]. As noted above, use of HTTP 1.1 persistent
connections simplifies the pledge state machine. connections simplifies the pledge state machine.
An ANIMA ANI pledge MUST implement the EST automation extensions
described below. They supplement the [RFC7030] EST to better support
automated devices that do not have an end user.
Although EST allows clients to obtain multiple certificates by Although EST allows clients to obtain multiple certificates by
sending multiple CSR requests BRSKI mandates use of the CSR sending multiple CSR requests BRSKI mandates use of the CSR
Attributes request and mandates that the registrar validate the CSR Attributes request and mandates that the registrar validate the CSR
against the expected attributes. This implies that client requests against the expected attributes. This implies that client requests
will "look the same" and therefore result in a single logical will "look the same" and therefore result in a single logical
certificate being issued even if the client were to make multiple certificate being issued even if the client were to make multiple
requests. Registrars MAY contain more complex logic but doing so is requests. Registrars MAY contain more complex logic but doing so is
out-of-scope of this specification. BRSKI does not signal any out-of-scope of this specification. BRSKI does not signal any
enhancement or restriction to this capability. enhancement or restriction to this capability.
skipping to change at page 56, line 16 skipping to change at page 56, line 5
The pledge can choose to accept vouchers using less secure methods. The pledge can choose to accept vouchers using less secure methods.
These methods enable offline and emergency (touch based) deployment These methods enable offline and emergency (touch based) deployment
use cases: use cases:
1. The pledge MUST accept nonceless vouchers. This allows for a use 1. The pledge MUST accept nonceless vouchers. This allows for a use
case where the registrar can not connect to the MASA at the case where the registrar can not connect to the MASA at the
deployment time. Logging and validity periods address the deployment time. Logging and validity periods address the
security considerations of supporting these use cases. security considerations of supporting these use cases.
2. The pledge MAY support "trust on first use" for physical 2. Many devices already support "trust on first use" for physical
interfaces such as a local console port or physical user interfaces such as console ports. This document does not change
interface but MUST NOT support "trust on first use" on network that reality. Devices supporting this protocol MUST NOT support
interfaces. This is because "trust on first use" permanently "trust on first use" on network interfaces. This is because
degrades the security for all use cases. "trust on first use" over network interfaces would undermine the
logging based security protections provided by this
specification.
3. The pledge MAY have an operational mode where it skips voucher 3. The pledge MAY have an operational mode where it skips voucher
validation one time. For example if a physical button is validation one time. For example if a physical button is
depressed during the bootstrapping operation. This can be useful depressed during the bootstrapping operation. This can be useful
if the manufacturer service is unavailable. This behavior SHOULD if the manufacturer service is unavailable. This behavior SHOULD
be available via local configuration or physical presence methods be available via local configuration or physical presence methods
(such as use of a serial/craft console) to ensure new entities (such as use of a serial/craft console) to ensure new entities
can always be deployed even when autonomic methods fail. This can always be deployed even when autonomic methods fail. This
allows for unsecured imprint. allows for unsecured imprint.
skipping to change at page 58, line 42 skipping to change at page 58, line 33
o add /.well-known/est/requestauditlog (see Section 5.7) o add /.well-known/est/requestauditlog (see Section 5.7)
7.2. PKIX Registry 7.2. PKIX Registry
IANA is requested to register the following: IANA is requested to register the following:
This document requests a number for id-mod-MASAURLExtn2016(TBD) from This document requests a number for id-mod-MASAURLExtn2016(TBD) from
the pkix(7) id-mod(0) Registry. the pkix(7) id-mod(0) Registry.
This document requests a number from the id-pe registry (SMI Security This document has received an early allocation from the id-pe
for PKIX Certificate Extension) for id-pe-masa-url. registry (SMI Security for PKIX Certificate Extension) for id-pe-
masa-url with the value 32, resulting in an OID of
1.3.6.1.5.5.7.1.32.
7.3. Pledge BRSKI Status Telemetry 7.3. Pledge BRSKI Status Telemetry
IANA is requested to create a new Registry entitled: "BRSKI IANA is requested to create a new Registry entitled: "BRSKI
Parameters", and within that Registry to create a table called: Parameters", and within that Registry to create a table called:
"Pledge BRSKI Status Telemetry Attributes". New items can be added "Pledge BRSKI Status Telemetry Attributes". New items can be added
using the Specification Required. The following items are to be in using the Specification Required. The following items are to be in
the initial registration, with this document (Section 5.7) as the the initial registration, with this document (Section 5.7) as the
reference: reference:
skipping to change at page 61, line 18 skipping to change at page 61, line 9
Additionally the domainID captures only the unauthenticated subject Additionally the domainID captures only the unauthenticated subject
key identifier of the domain. A privacy sensitive domain could key identifier of the domain. A privacy sensitive domain could
theoretically generate a new domainID for each device being deployed. theoretically generate a new domainID for each device being deployed.
Similarly a privacy sensitive domain would likely purchase devices Similarly a privacy sensitive domain would likely purchase devices
that support proximity assertions from a manufacturer that does not that support proximity assertions from a manufacturer that does not
require sales channel integrations. This would result in a require sales channel integrations. This would result in a
significant level of privacy while maintaining the security significant level of privacy while maintaining the security
characteristics provided by Registrar based audit log inspection. characteristics provided by Registrar based audit log inspection.
9.2. Used, Stolen or Grey Market equipment 9.2. What BRSKI-MASA reveals to the manufacturer
9.2.1. What BRSKI-MASA reveals to the manufacturer
The so-called "call-home" mechanism that occurs as part of the BRSKI- The so-called "call-home" mechanism that occurs as part of the BRSKI-
MASA connection standardizes what has been deemed by some as a MASA connection standardizes what has been deemed by some as a
sinister mechanism for corporate oversight of individuals. sinister mechanism for corporate oversight of individuals.
([livingwithIoT] and [IoTstrangeThings] for a small sample). ([livingwithIoT] and [IoTstrangeThings] for a small sample).
As the Autonomic Control Plane (ACP) usage of BRSKI is not targetted As the Autonomic Control Plane (ACP) usage of BRSKI is not targetted
at individual usage of IoT devices, but rather at the Enterprise and at individual usage of IoT devices, but rather at the Enterprise and
ISP creation of networks in a zero-touch fashion, the "call-home" ISP creation of networks in a zero-touch fashion, the "call-home"
represents a different kind of concern. represents a different kind of concern.
First, it needs to be re-iterated that the BRSKI-MASA mechanism only It needs to be re-iterated that the BRSKI-MASA mechanism only occurs
occurs once during the comissioning of the device. It is well once during the comissioning of the device. It is well defined, and
defined, and although encrypted with TLS, it could in theory be made although encrypted with TLS, it could in theory be made auditable as
auditable as the contents are well defined. the contents are well defined. This connection does not occur when
the device powers on or is restarted for normal routines. It is
conceivable that a device could be forced to go through a full
factory reset during an exceptional firmware update situation, after
which enrollment would have be repeated.
This connection does not occur when the device powers on or is The BRSKI call-home mechanism is mediated via the owner's Registrar,
restarted for normal routines. It is possible with low-quality and the information that is transmitted is directly auditable by the
implementations that it might occur after certain firmware upgrades, device owner. This is in stark constrast to many "call-home"
for instance if the upgrade requires repartitoning of firmware space protocols where the device autonomously calls home and uses an
and this affects the credential storage. The usage of a Trusted undocumented protocol.
Platform Module (TPM) to store credentials should completely
eliminate this fault, however. Therefore this situation is clearly a
quality of implementation issue, and even in the worse case, it
results in additional enrollments being recorded when the significant
firmware update occurs.
(Some manufacturers might regard such an additional call-home a While the contents of the signed part of the pledge voucher request
significant feature as it might tell them how many of their customers can not be changed, they are not encrypted at the registrar. The
have performed this major upgrade, and therefore how many are still ability to audit the messages by the owner of the network prevents
vulnerable to some serious issue) exfiltration of data by a nefarious pledge. The contents of an
Second, the BRSKI call-home mechanism is mediated via the owner's unsigned voucher request are, however, completely changeable by the
Registrar, and the information that is transmitted is directly Registrar. Both are, to re-iterate, encrypted by TLS while in
auditable by the device owner. This is in stark constrast to many transit.
"call-home" protocols where the device autonomously calls home and
uses an undocumented protocol. While the contents of the signed part
of the pledge voucher request can not be changed, they are not
encrypted at the registrar. The contents of an unsigned voucher
request are, however, completely changeable by the Registrar. Both
are, to re-iterate, encrypted by TLS while in transit.
The BRSKI-MASA exchange reveals the following information to the The BRSKI-MASA exchange reveals the following information to the
manufacturer: manufacturer:
o the identity of the device being enrolled (down to the serial- o the identity of the device being enrolled (down to the serial-
number!). number!).
o an identity of the domain owner in the form of the domain trust o an identity of the domain owner in the form of the domain trust
anchor. However, this is not a global PKI anchored name within anchor. However, this is not a global PKI anchored name within
the WebPKI, so this identity could be pseudonymous. If there is the WebPKI, so this identity could be pseudonymous. If there is
skipping to change at page 63, line 19 skipping to change at page 63, line 5
point of view as the same set of services (and the same set of point of view as the same set of services (and the same set of
Distributed Denial of Service mitigations) may be used. Distributed Denial of Service mitigations) may be used.
Unfortunately, as the BRSKI-MASA connections include TLS Unfortunately, as the BRSKI-MASA connections include TLS
ClientCertificate exchanges, this may easily be observed in TLS 1.2, ClientCertificate exchanges, this may easily be observed in TLS 1.2,
and a traffic analysis may reveal it even in TLS 1.3. This does not and a traffic analysis may reveal it even in TLS 1.3. This does not
make such a plan irrelevant. There may be other organizational make such a plan irrelevant. There may be other organizational
reasons to keep the marketing site (which is often subject to reasons to keep the marketing site (which is often subject to
frequent redesigs, outsourcing, etc.) seperate from the MASA, which frequent redesigs, outsourcing, etc.) seperate from the MASA, which
may need to operate reliably for decades. may need to operate reliably for decades.
9.2.2. Manufacturers and Used or Stolen Equipment 9.3. Manufacturers and Used or Stolen Equipment
As explained above, the manufacturer receives information each time As explained above, the manufacturer receives information each time
that a device which is in factory-default mode does a zero-touch that a device which is in factory-default mode does a zero-touch
bootstrap, and attempts to enroll into a domain owner's registrar. bootstrap, and attempts to enroll into a domain owner's registrar.
The manufacturer is therefore in a position to decline to issue a The manufacturer is therefore in a position to decline to issue a
voucher if it detects that the new owner is not the same as the voucher if it detects that the new owner is not the same as the
previous owner. previous owner.
1. This can be seen as a feature if the equipment is believed to 1. This can be seen as a feature if the equipment is believed to
skipping to change at page 64, line 19 skipping to change at page 64, line 5
industry: many license systems are already deployed that have industry: many license systems are already deployed that have
significantly worse effect. significantly worse effect.
This section has outlined five situations in which a manufacturer This section has outlined five situations in which a manufacturer
could use the voucher system to enforce what are clearly license could use the voucher system to enforce what are clearly license
terms. A manufacturer that attempted to enforce license terms via terms. A manufacturer that attempted to enforce license terms via
vouchers would find it rather ineffective as the terms would only be vouchers would find it rather ineffective as the terms would only be
enforced when the device is enrolled, and this is not (to repeat), a enforced when the device is enrolled, and this is not (to repeat), a
daily or even monthly occurrance. daily or even monthly occurrance.
9.2.3. Manufacturers and Grey market equipment 9.4. Manufacturers and Grey market equipment
Manufacturers of devices often sell different products into different Manufacturers of devices often sell different products into different
regional markets. Which product is available in which market can be regional markets. Which product is available in which market can be
driven by price differentials, support issues (some markets may driven by price differentials, support issues (some markets may
require manuals and tech-support to be done in the local language), require manuals and tech-support to be done in the local language),
government export regulation (such as whether strong crypto is government export regulation (such as whether strong crypto is
permitted to be exported, or permitted to be used in a particular permitted to be exported, or permitted to be used in a particular
market). When an domain owner obtains a device from a different market). When an domain owner obtains a device from a different
market (they can be new) and transfers it to a different location, market (they can be new) and transfers it to a different location,
this is called a Grey Market. this is called a Grey Market.
skipping to change at page 65, line 10 skipping to change at page 64, line 45
differentiation by reducing the cost of doing it. differentiation by reducing the cost of doing it.
An issue that manufacturers will need to deal with in the above An issue that manufacturers will need to deal with in the above
automated process is when a device is shipped to one country with one automated process is when a device is shipped to one country with one
set of rules (or laws or entitlements), but the domain registry is in set of rules (or laws or entitlements), but the domain registry is in
another one. Which rules apply is something will have to be worked another one. Which rules apply is something will have to be worked
out: the manufacturer could come to believe they are dealing with out: the manufacturer could come to believe they are dealing with
Grey market equipment, when it is simply dealing with a global Grey market equipment, when it is simply dealing with a global
enterprise. enterprise.
9.2.4. Some mitigations for meddling by manufacturers 9.5. Some mitigations for meddling by manufacturers
The most obvious mitigation is not to buy the product. Pick The most obvious mitigation is not to buy the product. Pick
manufacturers that are up-front about their policies, who do not manufacturers that are up-front about their policies, who do not
change them gratutiously. change them gratutiously.
A manufacturer could provide a mechanism to manage the trust anchors A manufacturer could provide a mechanism to manage the trust anchors
and built-in certificates (IDevID) as an extension. This is a and built-in certificates (IDevID) as an extension. This is a
substantial amount of work, and may be an area for future substantial amount of work, and may be an area for future
standardization work. standardization work.
skipping to change at page 70, line 10 skipping to change at page 69, line 41
device category (e.g, a light bulb, or a cable-modem) are signed device category (e.g, a light bulb, or a cable-modem) are signed
by an certificate authority specifically for this. This is done by an certificate authority specifically for this. This is done
by CableLabs today. It is used for authentication and by CableLabs today. It is used for authentication and
authorization as part of TR-79: [docsisroot] and [TR069]. authorization as part of TR-79: [docsisroot] and [TR069].
The existing WebPKI provides a reasonable anchor between manufacturer The existing WebPKI provides a reasonable anchor between manufacturer
name and public key. It authenticates the key. It does not provide name and public key. It authenticates the key. It does not provide
a reasonable authorization for the manufacturer, so it is not a reasonable authorization for the manufacturer, so it is not
directly useable on it's own. directly useable on it's own.
10.4. Manufacturer Maintainance of trust anchors
BRSKI depends upon the manufacturer building in trust anchors to the
pledge device. The voucher artifact which is signed by the MASA will
be validated by the pledge using that anchor. This implies that the
manufacturer needs to maintain access to a signing key that the
pledge can validate.
The manufacturer will need to maintain the ability to make signatures
that can be validated for the lifetime that the device could be
onboarded. Whether this onboarding lifetime is less than the device
lifetime depends upon how the device is used. An inventory of
devices kept in a warehouse as spares might not be onboarded for many
decades.
There are good cryptographic hygiene reasons why a manufacturer would
not want to maintain access to a private key for many decades. A
manufacturer in that situation can leverage a long-term certificate
authority anchor, built-in to the pledge, and then a certificate
chain may be incorporated using the normal CMS certificate set. This
may increase the size of the voucher artifacts, but that is not a
significant issues in non-constrained environements.
There are a few other operational variations that manufacturers could
consider. For instance, there is no reason that every device need
have the same set of trust anchors pre-installed. Devices built in
different factories, or on different days, or any other consideration
could have different trust anchors built in, and the record of which
batch the device is in would be recorded in the asset database. The
manufacturer would then know which anchor to sign an artifact
against.
Aside from the concern about long-term access to private keys, a
major limiting factor for the shelf-life of many devices will be the
age of the cryptographic algorithms included. A device produced in
2019 will have hardware and software capable of validating algorithms
common in 2019, and will have no defense against attacks (both
quantum and von-neuman brute force attacks) which have not yet been
invented. This concern is orthogonal to the concern about access to
private keys, but this concern likely dominates and limits the
lifespan of a device in a warehouse. If any update to firmware to
support new cryptographic mechanism were possible (while the device
was in a warehouse), updates to trust anchors would also be done at
the same time.
11. Acknowledgements 11. Acknowledgements
We would like to thank the various reviewers for their input, in We would like to thank the various reviewers for their input, in
particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu
Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg,
and Peter van der Stok Peter van der Stok, and Thomas Werner
12. References Significant reviews were done by Jari Arko, Christian Huitema and
Russ Housley.
12. References
12.1. Normative References 12.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)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-18 (work in progress), August 2018. plane-18 (work in progress), August 2018.
[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)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009,
December 2009, <http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005, DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/info/rfc3927>. <https://www.rfc-editor.org/info/rfc3927>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, (LDAP): Schema for User Applications", RFC 4519,
DOI 10.17487/RFC4519, June 2006, DOI 10.17487/RFC4519, June 2006,
<https://www.rfc-editor.org/info/rfc4519>. <https://www.rfc-editor.org/info/rfc4519>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
skipping to change at page 73, line 11 skipping to change at page 73, line 41
<https://www.rfc-editor.org/info/rfc8368>. <https://www.rfc-editor.org/info/rfc8368>.
12.2. Informative References 12.2. Informative References
[Dingledine2004] [Dingledine2004]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the
second-generation onion router", 2004, second-generation onion router", 2004,
<https://spec.torproject.org/tor-spec>. <https://spec.torproject.org/tor-spec>.
[docsisroot] [docsisroot]
CableLabs, "CableLabs Digital Certificate Issuance "CableLabs Digital Certificate Issuance Service", February
Service", February 2018, 2018, <https://www.cablelabs.com/resources/
<https://www.cablelabs.com/resources/
digital-certificate-issuance-service/>. digital-certificate-issuance-service/>.
[I-D.ietf-ace-coap-est] [I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Richardson, M., and S. Raza, Stok, P., Kampanakis, P., Richardson, M., and S. Raza,
"EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-
est-07 (work in progress), January 2019. est-09 (work in progress), February 2019.
[I-D.ietf-anima-constrained-voucher]
Richardson, M., Stok, P., and P. Kampanakis, "Constrained
Voucher Artifacts for Bootstrapping Protocols", draft-
ietf-anima-constrained-voucher-02 (work in progress),
September 2018.
[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", draft-ietf-anima-reference-model-10 (work in Networking", draft-ietf-anima-reference-model-10 (work in
progress), November 2018. progress), November 2018.
[I-D.ietf-anima-stable-connectivity] [I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf- Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-10 (work in progress), February anima-stable-connectivity-10 (work in progress), February
2018. 2018.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-06 (work in progress), November 2018. cddl-07 (work in progress), February 2019.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero
Touch Provisioning (SZTP)", draft-ietf-netconf- Touch Provisioning (SZTP)", draft-ietf-netconf-
zerotouch-29 (work in progress), January 2019. zerotouch-29 (work in progress), January 2019.
[I-D.ietf-opsawg-mud] [I-D.ietf-opsawg-mud]
Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", draft-ietf-opsawg-mud-25 (work Description Specification", draft-ietf-opsawg-mud-25 (work
in progress), June 2018. in progress), June 2018.
[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", draft-richardson-anima- join router in ANIMA bootstrap", draft-richardson-anima-
state-for-joinrouter-02 (work in progress), January 2018. state-for-joinrouter-02 (work in progress), January 2018.
[imprinting] [imprinting]
Wikipedia, "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]
Internet, "IoT of toys stranger than fiction: "IoT of toys stranger than fiction: Cybersecurity and data
Cybersecurity and data privacy update (accessed privacy update (accessed 2018-12-02)", March 2017,
2018-12-02)", March 2017,
<https://www.welivesecurity.com/2017/03/03/ <https://www.welivesecurity.com/2017/03/03/
internet-of-things-security-privacy-iot-update/>. internet-of-things-security-privacy-iot-update/>.
[livingwithIoT] [livingwithIoT]
Internet, "What is it actually like to live in a house "What is it actually like to live in a house filled with
filled with IoT devices? (accessed 2018-12-02)", February IoT devices? (accessed 2018-12-02)", February 2018,
2018, <https://www.siliconrepublic.com/machines/ <https://www.siliconrepublic.com/machines/
iot-smart-devices-reality>. iot-smart-devices-reality>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999, RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>. <https://www.rfc-editor.org/info/rfc2663>.
skipping to change at page 75, line 15 skipping to change at page 76, line 5
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[slowloris]
"Slowloris (computer security)", February 2019,
<https://en.wikipedia.org/wiki/
Slowloris_(computer_security)/>.
[Stajano99theresurrecting] [Stajano99theresurrecting]
Stajano, F. and R. Anderson, "The resurrecting duckling: Stajano, F. and R. Anderson, "The resurrecting duckling:
security issues for ad-hoc wireless networks", 1999, security issues for ad-hoc wireless networks", 1999,
<https://www.cl.cam.ac.uk/~fms27/ <https://www.cl.cam.ac.uk/~fms27/
papers/1999-StajanoAnd-duckling.pdf>. papers/1999-StajanoAnd-duckling.pdf>.
[TR069] Broadband Forum, "TR-69: CPE WAN Management Protocol", [TR069] "TR-69: CPE WAN Management Protocol", February 2018,
February 2018, <https://www.broadband-forum.org/ <https://www.broadband-forum.org/standards-and-software/
standards-and-software/technical-specifications/ technical-specifications/tr-069-files-tools>.
tr-069-files-tools>.
Appendix A. IPv4 and non-ANI operations Appendix A. IPv4 and non-ANI operations
The secification of BRSKI in Section 4 intentionally only covers the The secification of BRSKI in Section 4 intentionally only covers the
mechanisms for an IPv6 pledge using Link-Local addresses. This mechanisms for an IPv6 pledge using Link-Local addresses. This
section describes non-normative extensions that can be used in other section describes non-normative extensions that can be used in other
environments. environments.
A.1. IPv4 Link Local addresses A.1. IPv4 Link Local addresses
 End of changes. 131 change blocks. 
406 lines changed or deleted 441 lines changed or added

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