One document matched: draft-kwatsen-netconf-zerotouch-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:01:31 |