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>             |
                    |                                |
                    |    +----------------------+    |
                    |    |  <crypto processor>  |    |
                    |    |                      |    |
                    |    |  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 <sha1-hash-of-
   device-pub-key>.<vendor-zone>.  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

            +-------------------------------------------------+
            |             <vendor's DNS server>               |
            |                                                 |
            |  <sha1-of-device-public-key>.<vendor-zone>      |
            |    - 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 <sha1-of-device-pub-key>.<vendor-zone> |              |
     |             |                  |              |              |
     |             |                  |              |              |
     |------------------------------->|              |              |
     | 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

                 +----------------------------------------+
                 |                <NMS>                   |
                 |                                        |
                 |  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 <sha1-of-
   device-public-key>.<vendor-zone> 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]