NETCONF Working Group K. Watsen Internet-Draft S. Hanna Intended status: Standards Track Juniper Networks Expires: May 05, 2014 November 2013 Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) draft-kwatsen-netconf-zerotouch-00 Abstract This memo presents a technique for how to establish a secure network management relationship between a newly delivered network device, configured with just its factory default settings, and the new owner's Network Management System (NMS). The solution has been designed with the following prioritized goals in mind: security, deployment flexibility, ease of use, and device cost. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 05, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Watsen & Hanna Expires May 05, 2014 [Page 1] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 4 4. Supporting Private Networks . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 9 A.1. DNSSEC doesn't currently allow client certificates . . . 9 A.2. Should DNS record provide SSH-specific information? . . . 10 A.3. Standardize REST API used to set DNS record info? . . . . 10 1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction A fundamental business requirement is to reduce operational costs where possible. In the deployment of a network management solution, a significant consideration is how the devices are installed in the network, as sending trained specialists to each site is both cost prohibitive and doesn't scale. Both networking vendors and standard bodies have tried to address this issue, with varying levels of success. For instance, the Broadband Forum TR-069 specification [TR069] relies on DHCP for NMS discovery, but this only works in environments where the DHCP server can be configured, which isn't the case when the device is connected to an ISP's network. In another example, some network vendors have enabled their devices to load an initial configuration from removable Watsen & Hanna Expires May 05, 2014 [Page 2] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 storage media (e.g. a USB flash drive), but not all devices have such ports and there are a number of logistical issues that make it undesirable to use except for the special case of a private network (see Supporting Private Networks (Section 4)). The solution presented herein attempts to addresses all the primary evaluation criteria outlined by the draft "Configuring Security Parameters in Small Devices" [draft-hanna-zeroconf-seccfg-00]: security, flexibility, ease of use, and device cost. More specifically: o Security Security is fundamental to any automated discovery solution, especially one that bootstraps the parameters used to secure a device's connection to its NMS. Consistent with [RFC3365], security is a required aspect of ZeroTouch. Every ZeroTouch implementation is sure to be secure. o Flexibility ZeroTouch is designed to support a wide variety of deployments, including cases where the device is connected to a network without administrative control of the local DHCP and DNS servers, where the device is connected to an untrusted network, or deployed behind a gateway that dynamically translates its network address (e.g. NAT). Special consideration is also provided for devices that are on a network with no public Internet access. o Ease of Use Ultimately, the success of the solution depends on the ability for presumably non-technical personnel to be able to complete the installation by themselves. To this end, it is envisioned that installers only need to connect the device to a wired or wireless network and a power source and wait for an LED to indicate success. ZeroTouch also attempts to not be overly complicated for NMS administrators. Indeed, the only stakeholder that shoulders any significant complexity is the vendor, which seems reasonable since their effort is amortizable across many device installations. o Device Cost For vendors of devices with already slim margins, such as consumer-oriented devices, a significant concern is the cost of goods. Fortunately, the solution presented in this draft Watsen & Hanna Expires May 05, 2014 [Page 3] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 requires minimal additional components. Other costs that should be considered are the development and support costs, but even these are not believed to be exorbitant, though that may vary by vendor given their circumstances. The solution presented in this draft is designed to support the NETCONF configuration protocol [RFC6241]. This is achieved by leveraging the recently standardized call home mechanisms for SSH [REVERSE-SSH] and TLS [RFC5539bis]. 3. Solution Proposal Devices supporting ZeroTouch must have a unique private key that is created during its manufacturing process and a matching X.509 certificate having its serial number set in the "Common Name" field. The private key should be generated and protected by a tamper- resistant cryptographic processor, as this would negate the possibility that even the vendor knows the private key. The certificate must be signed by a certificate authority (CA) having a chain of trust leading to the vendor's well-known certificate authority. Devices must additionally know the FQDN for their vendor's DNS server and be able to validate DNSSEC [RFC4033] signed records. Device State Precondition +--------------------------------+ | | | | | +----------------------+ | | | | | | | | | | | device private key | | | | device certificate | | | +----------------------+ | | | | FQDN of vendor's DNS server | +--------------------------------+ When the device boots up with its default factory settings, it first configures its networking using DHCP and then it does a DNSSEC lookup in its vendor's DNS server for its unique DNS record .. By naming DNS records this way and configuring the DNS server to use NSEC3 [RFC5155], it reduces the ability for attackers to do random DNS lookups. By having the device use the vendor's DNS server directly, no other DNS servers in the network need to be configured to use DNSSEC. In Watsen & Hanna Expires May 05, 2014 [Page 4] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 deployments on networks without Internet access, this lookup will fail (see Section 4). The DNS record returned to the device must contain the FQDN of the NMS it is to connect to and a flag indicating if the device should use reverse SSH [REVERSE-SSH] or reverse TLS [RFC5539bis] to connect to the NMS. The DNS record must also contain information used to configure a user account on the device (see Appendix A). Vendor's DNS Server State +-------------------------------------------------+ | | | | | . | | - FQDN of NMS to connect to | | - flag indicating if SSH or TLS | | - username NMS will login using | | - NMS's auth credentials | | | +-------------------------------------------------+ After validating the DNS record is authentic, the device persists the provided informaiton, configuring how it initiates a connection and also a local user account. Once this configuration is persisted, the device immediately starts trying to connect to the NMS using the specied protocol. The device may use a local DNS lookup to obtain the NMS's IP address. For either reverse TLS or reverse SSH, the device simultaneously identifies and authenticates itself to the NMS using its certificate signed by the vendor's well-known CA and containing its serial number in the "Common Name" field. If using SSH, the device must use the X.509 certificate as its hostkey per RFC 6187 [RFC6187]. Watsen & Hanna Expires May 05, 2014 [Page 5] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 ZeroTouch Sequence Diagram DEVICE LOCAL DHCP LOCAL DNS VENDOR'S DNS NMS | SERVER SERVER SERVER (DNSSEC) | | | | | | |------------>| | | | | Lease IP | | | | | | | | | |------------------------------->| | | | Lookup vendor's DNS server | | | | | | | | | | | | | |---------------------------------------------->| | | Lookup . | | | | | | | | | | | | |------------------------------->| | | | Lookup NMS IP address | | | | | | | | | | | | | |------------------------------------------------------------->| | Reverse SSH or Reverse TLS | | | | | | | | | | | | | Since the device is expected to persist its configuration for calling home, it will no longer having its factory default configuration, and thus its ZeroTouch logic would be disabled the next time it boots. In order for the NMS to authenticate the device, it must have the certificate for the vendor's well-known certificate authority, which is the trust anchor for the device's certificate. When authenticating the certificate provided by the device, it is important the NMS verifies both that it was signed by the trust anchor and that the serial number listed in the "Common Name" field is expected, and not just some random device from that vendor. How the NMS authenticates itself to the device is protocol specific. For TLS, RFC5539bis requires the NMS present a client-certificate. For SSH, a username must be explicitly passed, as well as some authentication credentials (see Appendix A). In either case, the NMS must be preconfigured to know what username and authentication credentials to use. Watsen & Hanna Expires May 05, 2014 [Page 6] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 NMS State Precondition +----------------------------------------+ | | | | | vendor's trusted CA certificate | | serial numbers for expected devices | | username to log into devices with | | auth credentials to log into devices | | | +----------------------------------------+ In order for the device's DNS record to be configured with the NMS specific information, it is anticipated that vendors will provide a mechanism (e.g. a web page) for their customers to supply the information for a given serial number. In order for customers to know the serial number for devices that drop-shipped directly from the vendor or channel, vendors should ensure the serial number is included along with other customary shipping information. 4. Supporting Private Networks This section is TBD, pending more analysis. One option might be for the private network to impersonate the vendor's DNS server and define all the DNS records to satisfy the DNSSEC lookup. This might be possible if the private network's DNS server can impersonate the TLD records, signing them with its own private key. Another option would be for the device to pull information from a local DHCP server that, on a private network, is ensured to be administered locally. This option may be undesirable, though, due to introducing extra logic to code and, perhaps, a path to bypass the security offered by the primary solution. Yet another option is to have the device read the equivalent information from a removable media device (e.g. USB flash drive). This solution is relatively easy to implement and doesn't introduce a remote exploit, but it requires the device to have a USB port, which isn't always the case. 5. Security Considerations This draft entails the device having an X.509 certificate that is used by the NMS to authenticate the device. This certificate and every certificate in the chain leading to the vendor's well known CA, must have a expiration date greater than the device's useful life Watsen & Hanna Expires May 05, 2014 [Page 7] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 expectancy. Given the long-lived nature of the device certificates, it is paramount to use a strong key length (e.g. a 512-bit ECC key). Similarly, vendors should deploy Online Certificate State Protocol (OCSP) responders to invalidate certificates in case one is thought to be compromised. One privacy concern stems from the database of DNS records maintained by the vendor. Even though the record names are not easily guessed, and NSEC3 can be used to prevent enumeration, it remains possible for the information to be revealed. In this case, adversaries would learn the NMS's FQDN from which they would know that the NMS manages devices from that vendor and try to launch an attack against the NMS. This draft recommends the device's certificate contain its Serial Number. It is understood that serial numbers many times encode revealing information, such as the device's model number, manufacture date, and/or sequence number. Knowledge of this information may provide an adversary with additional information to launch an attack. To address this concern, the certificate could contain the hash of the serial number instead, which the NMS could also compute, but doing so is much less intuitive and raises questions if it's just security through obscurity. 6. IANA Considerations None 7. Acknowledgements The authors would like to thank Russ Mundy and Wes Hardaker for brainstorming the solution presented in this draft with us during the IETF 87 meeting in Berlin. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels ", BCP 14, RFC 2119, March 1997. [RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols ", RFC 3365, August 2002. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements ", RFC 4033, March 2005. Watsen & Hanna Expires May 05, 2014 [Page 8] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol ", RFC 4252, January 2006. [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints ", RFC 4255, January 2006. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence ", RFC 5155, January 2006. [RFC5539bis] Badra, M. and A. Luchuk, "Using the NETCONF Protocol over Transport Layer Security (TLS) ", RFC 6187, March 2011. [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication ", RFC 6187, March 2011. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "NETCONF Configuration Protocol", RFC 6241, June 2011. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012. [REVERSE-SSH] Watsen, K., "Reverse SSH", June 2013. 8.2. Informative References [TR069] The Broadband Forum, ., "TR-069 Amendemnt 3, CPE WAN Management Protocol ", November 2010. [draft-hanna-zeroconf-seccfg-00] Hanna, ., "Configuring Security Parameters in Small Devices ", January 2002. Appendix A. Open Issues A.1. DNSSEC doesn't currently allow client certificates The TLSA record in DNSSEC [RFC6698] is currently specified to provide information to authenticate the server's certificate. It does not specifically allow information to authenticate client certificates. Should [RFC6698] be updated to define support for client certificates? Watsen & Hanna Expires May 05, 2014 [Page 9] Internet-DraftZero Touch Provisioning for NETCONF Call HomeNovember 2013 Even if the TLSA record is updated, there may sill be a need to provide additional information for the device to map the client certificate to a username - or can this be hardcoded? A.2. Should DNS record provide SSH-specific information? This proposal currently specifies that the DNS record . contain "authentication credentials". This is fine for NETCONF-over-TLS [RFC5539bis], as it requires the NMS present a client-certificate, for which there is the TLSA record. However, for NETCONF over SSH, the SSHFP resource record [RFC4255], like the current TLSA record, is meant to only convey information about the server's key. Does that RFC need to be updated to support SSH client information such as username and a few different kinds of public keys, such as RSA, DSA, and X.509? Maybe it could also encode a pre-hashed password (not cleartext)? A.3. Standardize REST API used to set DNS record info? One aspect of this proposal is an ability vendors would provide enabling device owners to update the DNS record for their devices they own. There opens the opportunity for IETF to define an programmatic interface (e.g. REST) to accomplish this step. Is it worth pursuing? Authors' Addresses Kent Watsen Juniper Networks EMail: kwatsen@juniper.net Stephen Hanna Juniper Networks EMail: shanna@juniper.net Watsen & Hanna Expires May 05, 2014 [Page 10]