Appendix D. To be deprecated: Consolidation remnants [[EDNOTE: As per working group feedback there were multiple instances where this document repeated itself. To address this we have moved all text to this appendix and restored only one copy of each normative discussion. The next pass will reduce and delete this appendix to '0'; although some may be maintained in a design considerations appendix.]] D.1. Functional Overview Entities behave in an autonomic fashion. They discover each other and autonomically bootstrap into a key infrastructure delineating the autonomic domain. See [RFC7575] for more information. This section details the state machine and operational flow for each of the main three entities. The pledge, the domain (primarily a Registrar) and the MASA service. A representative flow is shown in Figure 3: Pritikin, et al. Expires April 6, 2018 [Page 55] Internet-Draft BRSKI October 2017 +--------+ +---------+ +------------+ +------------+ | Pledge | | Circuit | | Domain | | Vendor | | | | Proxy | | Registrar | | Service | | | | | | | | (Internet | +--------+ +---------+ +------------+ +------------+ | | | | |<-RFC3927 IPv4 adr | Appendix A | | or|<-RFC4862 IPv6 adr | | | | | | | |-------------------->| | | | optional: mDNS query| Appendix B | | | RFC6763/RFC6762 | | | | | | | |<--------------------| | | | GRASP M_FLOOD | | | | periodic broadcast| | | | | | | |<------------------->C<----------------->| | | TLS via the Circuit Proxy | | |<--Registrar TLS server authentication---| | [PROVISIONAL accept of server cert] | | P---X.509 client authentication---------->| | P | | | P---Request Voucher (include nonce)------>| | P | | | P | /---> | | P | | [accept device?] | P | | [contact Vendor] | P | | |--Pledge ID-------->| P | | |--Domain ID-------->| P | | |--optional:nonce--->| P | | | [extract DomainID] P | | | | P | optional: | [update audit log] P | |can | | P | |occur | | P | |in | | P | |advance | | P | | | | P | | |<-device audit log--| P | | |<- voucher ---------| P | \----> | | P | | | P | [verify audit log and voucher] | P | | | P<------voucher---------------------------| | [verify voucher ] | | | [verify provisional cert| | | Pritikin, et al. Expires April 6, 2018 [Page 56] Internet-Draft BRSKI October 2017 | | | | |<--------------------------------------->| | | Continue with RFC7030 enrollment | | | using now bidirectionally authenticated | | | TLS session. | | | | | | | | | | | | | | | Figure 3 [[UNRESOLVED:need to restore some functional overview section for all these diagrams]]In order to obtain a Voucher and associated logs a Registrar contacts the MASA service Service using REST calls: +-----------+ +----------+ +-----------+ +----------+ | New | | Circuit | | | | | | Entity | | Proxy | | Registrar | | Vendor | | | | | | | | | ++----------+ +--+-------+ +-----+-----+ +--------+-+ | | | | | | | | | TLS hello | TLS hello | | Establish +---------------C---------------> | TLS | | | | connection | | Server Cert | | <---------------C---------------+ | | Client Cert | | | +---------------C---------------> | | | | | HTTP REST | POST /requestvoucher | | Data +--------------------nonce------> | | . | /requestvoucher| | . +----------------> | <----------------+ | | /requestlog | | +----------------> | voucher <----------------+ <-------------------------------+ | | (optional config information) | | | . | | | . | | Figure 8 In some use cases the Registrar may need to contact the Vendor in advanced, for example when the target network is air-gapped. The nonceless request format is provided for this and the resulting flow Pritikin, et al. Expires April 6, 2018 [Page 57] Internet-Draft BRSKI October 2017 is slightly different. The security differences associated with not knowing the nonce are discussed below: +-----------+ +----------+ +-----------+ +----------+ | New | | Circuit | | | | | | Entity | | Proxy | | Registrar | | Vendor | | | | | | | | | ++----------+ +--+-------+ +-----+-----+ +--------+-+ | | | | | | | | | | | /requestvoucher| | | (nonce +----------------> | | unknown) <----------------+ | | | /requestlog | | | +----------------> | | <----------------+ | TLS hello | TLS hello | | Establish +---------------C---------------> | TLS | | | | connection | | Server Cert | | <---------------C---------------+ | | Client Cert | | | | | | | HTTP REST | POST /requestvoucher | | Data +----------------------nonce----> (discard | | voucher | nonce) | <-------------------------------+ | | (optional config information) | | | . | | | . | | Figure 9 D.1.1. Behavior of a Join Proxy D.1.2. Behavior of the Registrar A Registrar listens for Pledges and determines if they can join the domain. A Registrar obtains a Voucher from the MASA service and delivers them to the Pledge as well as facilitating enrollment with the domain PKI. [[RESOLVED: moved to discovery discussion]] A Registrar is typically configured manually. When the Registrar joins an Autonomic Control Plane ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP ([I-D.ietf-anima-grasp]) M_DISCOVERY message. See Section 4.1 Registrar behavior is as follows: Pritikin, et al. Expires April 6, 2018 [Page 58] Internet-Draft BRSKI October 2017 Contacted by Pledge + | +-------v----------+ | Entity | fail? | Authentication +---------+ +-------+----------+ | | | +-------v----------+ | | Entity | fail? | | Authorization +---------> +-------+----------+ | | | +-------v----------+ | | Claiming the | fail? | | Entity +---------> +-------+----------+ | | | +-------v----------+ | | Log Verification | fail? | | +---------> +-------+----------+ | | | +-------v----------+ +----v-------+ | Forward | | | | Voucher | | Reject | | to the Pledge | | Device | | | | | +------------------+ +------------+ Figure 4 D.1.2.1. Pledge Authentication The applicable authentication methods detailed in EST [RFC7030] are: o [[RESOLVED:pointed out in protocol details]]the use of an X.509 IDevID credential during the TLS client authentication, o or the use of a secret that is transmitted out of band between the Pledge and a Registrar (this use case is not autonomic). In order to validate the X.509 IDevID credential a Registrar maintains a database of vendor trust anchors (e.g. vendor root certificates or keyIdentifiers for vendor root public keys). For user interface purposes this database can be mapped to colloquial vendor names. Registrars can be shipped with the trust anchors of a significant number of third-party vendors within the target market. Pritikin, et al. Expires April 6, 2018 [Page 59] Internet-Draft BRSKI October 2017 D.1.2.2. Pledge Authorization [[UNRESOLVED: this is referenced above as how the MASA does authorization. That is incorrect]] In a fully automated network all devices must be securely identified and authorized to join the domain. A Registrar accepts or declines a request to join the domain, based on the authenticated identity presented. Automated acceptance criteria include: o allow any device of a specific type (as determined by the X.509 IDevID), o allow any device from a specific vendor (as determined by the X.509 IDevID), o allow a specific device from a vendor (as determined by the X.509 IDevID) against a domain white list. (The mechanism for checking a shared white list potentially used by multiple Registrars is out of scope). [[RESOLVED: this looks like good text to include in above]]To look the Pledge up in a domain white list a consistent method for extracting device identity from the X.509 certificate is required. RFC6125 describes Domain-Based Application Service identity but here we require Vendor Device-Based identity. The subject field's DN encoding MUST include the "serialNumber" attribute with the device's unique serial number. In the language of RFC6125 this provides for a SERIALNUM-ID category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. The SERIALNUM-ID whitelist is collated according to vendor trust anchor since serial numbers are not globally unique. [[RESOLVED: into log request]]The Registrar MUST use the vendor provided MASA service to verify that the device's history log does not include unexpected Registrars. If a device had previously registered with another domain, a Registrar of that domain would show in the log. [[RESOLVED: est integration section used 'SHOULD']]The authorization performed during BRSKI MAY be used for EST enrollment requests by proceeding with EST enrollment using the authenticated and authorized TLS connection. This minimizes the number of cryptographic and protocol operations necessary to complete bootstrapping of the local key infrastructure. Pritikin, et al. Expires April 6, 2018 [Page 60] Internet-Draft BRSKI October 2017 D.1.2.3. Claiming the Pledge Claiming an pledge establishes an audit log at the MASA server and provides a Registrar with proof, in the form of the Voucher, that the log entry has been inserted. As indicated in [[AcceptDomain]] a Pledge will only proceed with bootstrapping if a Voucher has been received. The Pledge therefore enforces that bootstrapping only occurs if the claim has been logged. There is no requirement for the vendor to definitively know that the device is owned by the Registrar. The Registrar obtains the MASA URI via static configuration or by extracting it from the X.509 IDevID credential. See Section 2.3. During initial bootstrapping the Pledge provides a nonce specific to the particular bootstrapping attempt. [[RESOLVED: to resolve this I updated many points where vouchers are referenced]]The Registrar SHOULD include this nonce when claiming the Pledge from the MASA service. Claims from an unauthenticated Registrar are only serviced by the MASA resource if a nonce is provided. The Registrar can claim a Pledge that is offline by forming the request using the entities unique identifier and not including a nonce in the claim request. Vouchers obtained in this way do not have a lifetime and they provide a permanent method for the domain to claim the device. Evidence of such a claim is provided in the audit log entries available to any future Registrar. Such claims reduce the ability for future domains to secure bootstrapping and therefore the Registrar MUST be authenticated by the MASA service although no requirement is implied that the MASA associates this authentication with ownership. An Ownership Voucher requires the vendor to definitively know that a device is owned by a specific domain. The method used to "claim" this are out-of-scope. A MASA ignores or reports failures when an attempt is made to claim a device that has a an Ownership Voucher. D.1.2.4. Log Verification A Registrar requests the log information for the Pledge from the MASA service. The log is verified to confirm that the following is true to the satisfaction of a Registrar's configured policy: o Any nonceless entries in the log are associated with domainIDs recognized by the registrar. Pritikin, et al. Expires April 6, 2018 [Page 61] Internet-Draft BRSKI October 2017 o Any nonce'd entries are older than when the domain is known to have physical possession of the Pledge or that the domainIDs are recognized by the registrar. If any of these criteria are unacceptable to a Registrar the entity is rejected. [[RESOLVED: moved to main body]] A Registrar MAY be configured to ignore the history of the device but it is RECOMMENDED that this only be configured if hardware assisted NEA [RFC5209] is supported. [[RESOLVED: added to main text]]This document specifies a simple log format as provided by the MASA service to the registar. This format could be improved by distributed consensus technologies that integrate vouchers with a technologies such as block-chain or hash trees or the like. Doing so is out of the scope of this document but are anticipated improvements for future work. D.1.3. Behavior of the MASA Service [[UNRESOLVED: primary value of keeping this discussion is to distinguish between registrar and masa particularly wrt to the protocol functions provided. perhaps add statements in each protocol entry "provided by masa" etc?]] The Manufacturer Authorized Signing Authority service is directly provided by the manufacturer, or can be provided by a third party the manufacturer authorizes. It is a cloud resource. The MASA service provides the following functionalities to Registrars: Issue Vouchers: In response to Registrar requests the MASA service issues vouchers. Depending on the MASA policy the Registrar claim of device ownership is either accepted or verified using out-of- scope methods (that are expected to improve over time). Log Vouchers Issued: When a voucher is issued the act of issuing it includes updating the certifiable logs. Future work to enhance and distribute these logs is out-of-scope but expected over time. Provide Logs: As a baseline implementation of the certified logging mechanism the MASA is repsonsible for reporting logged information. The current method involves trusting the MASA. Other logging methods where the MASA is less trusted are expected to be developed over time. Pritikin, et al. Expires April 6, 2018 [Page 62] Internet-Draft BRSKI October 2017 D.2. Domain Operator Activities This section describes how an operator interacts with a domain that supports the bootstrapping as described in this document. D.2.1. Instantiating the Domain Certification Authority This is a one time step by the domain administrator. This is an "off the shelf" CA with the exception that it is designed to work as an integrated part of the security solution. This precludes the use of 3rd party certification authority services that do not provide support for delegation of certificate issuance decisions to a domain managed Registration Authority. D.2.2. Instantiating the Registrar This is a one time step by the domain administrator. One or more devices in the domain are configured take on a Registrar function. A device can be configured to act as a Registrar or a device can auto-select itself to take on this function, using a detection mechanism to resolve potential conflicts and setup communication with the Domain Certification Authority. Automated Registrar selection is outside scope for this document. D.2.3. Accepting New Entities For each Pledge the Registrar is informed of the unique identifier (e.g. serial number) along with the manufacturer's identifying information (e.g. manufacturer root certificate). This can happen in different ways: 1. Default acceptance: In the simplest case, the new device asserts its unique identity to a Registrar. The registrar accepts all devices without authorization checks. This mode does not provide security against intruders and is not recommended. 2. Per device acceptance: The new device asserts its unique identity to a Registrar. A non-technical human validates the identity, for example by comparing the identity displayed by the registrar (for example using a smartphone app) with the identity shown on the packaging of the device. Acceptance may be triggered by a click on a smartphone app "accept this device", or by other forms of pairing. See also [I-D.behringer-homenet-trust-bootstrap] for how the approach could work in a homenet. 3. Whitelist acceptance: In larger networks, neither of the previous approaches is acceptable. Default acceptance is not secure, and Pritikin, et al. Expires April 6, 2018 [Page 63] Internet-Draft BRSKI October 2017 a manual per device methods do not scale. Here, the registrar is provided a priori with a list of identifiers of devices that belong to the network. This list can be extracted from an inventory database, or sales records. If a device is detected that is not on the list of known devices, it can still be manually accepted using the per device acceptance methods. 4. Automated Whitelist: an automated process that builds the necessary whitelists and inserts them into the larger network domain infrastructure is plausible. Once set up, no human intervention is required in this process. Defining the exact mechanisms for this is out of scope although the registrar authorization checks is identified as the logical integration point of any future work in this area. None of these approaches require the network to have permanent Internet connectivity. Even when the Internet based MASA service is used, it is possible to pre-fetch the required information from the MASA a priori, for example at time of purchase such that devices can enroll later. This supports use cases where the domain network may be entirely isolated during device deployment. Additional policy can be stored for future authorization decisions. For example an expected deployment time window or that a certain Proxy must be used. D.2.4. Automatic Enrollment of Devices The approach outlined in this document provides a secure zero-touch method to enroll new devices without any pre-staged configuration. New devices communicate with already enrolled devices of the domain, which proxy between the new device and a Registrar. As a result of this completely automatic operation, all devices obtain a domain based certificate. D.2.5. Secure Network Operations The certificate installed in the previous step can be used for all subsequent operations. For example, to determine the boundaries of the domain: If a neighbor has a certificate from the same trust anchor it can be assumed "inside" the same organization; if not, as outside. See also [[boundary]]. The certificate can also be used to securely establish a connection between devices and central control functions. Also autonomic transactions can use the domain certificates to authenticate and/or encrypt direct interactions between devices. The usage of the domain certificates is outside scope for this document. Pritikin, et al. Expires April 6, 2018 [Page 64] Internet-Draft BRSKI October 2017 Authors' Addresses Max Pritikin Cisco Email: pritikin@cisco.com Michael C. Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca URI: http://www.sandelman.ca/ Michael H. Behringer Cisco Email: mbehring@cisco.com Steinthor Bjarnason Arbor Networks Email: sbjarnason@arbor.net Kent Watsen Juniper Networks Email: kwatsen@juniper.net Pritikin, et al. Expires April 6, 2018 [Page 65]