| NETCONF Working Group | K.W. Watsen |
| Internet-Draft | S.H. Hanna |
| Intended status: Standards Track | Juniper Networks |
| Expires: August 17, 2014 | J.M.C. Clarke |
| Cisco Systems | |
| M.A. Abrahamsson | |
| T-Systems | |
| February 13, 2014 |
Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)
draft-kwatsen-netconf-zerotouch-01
This draft presents a technique for how to establish a secure NETCONF connection between a newly deployed networking device, configured with just its factory default settings, and the new owner's Network Management System (NMS).
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 August 17, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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].
The solution presented herein 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].
A fundamental business requirement is to reduce operational costs where possible. Deploying new devices is typically one of the largest costs in running 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 storage media (e.g., a USB flash drive), but not all devices have such ports.
The solution presented herein attempts to addresses the 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:
The device is the networking entity that initiates Zero Touch. Whenever a device boots with its factory default settings, it initiates ZeroTouch with the goal of finding a Configlet with which it can use to configure itself. Once a Configlet is found, the device initializes its configuration using that Configlet and then exits ZeroTouch. Since the Configlet configures the device to "call home" upon entering its normal operating mode, the device immediately begins trying to establish a reverse-SSH or reverse-TLS connection, as specified by the Configlet.
A Configlet is an XML file, containing specific YANG-defined configuration, that has been signed by a trusted signer known to the device (e.g., the device's manufacturer).
The Configlet data-model, defined by the YANG module in this document (see Section 3.2), is just enough to configure a local user account and either reverse-SSH or reverse-TLS. More specifically, this data-model is a subset of what's defined in ietf-system and ietf-netconf-server YANG models. This focused data-model is consistent with the common use-case of having the NMS push a full configuration to a device when it calls home.
The signature on the Configlet is enveloped, meaning that the signature is contained inside the XML file itself. The signature block also contains the X.509 certificate of the Configlet Signer and its chain of trust.
Once a device authenticates the signature on a Configlet and matches the unique identifier (e.g., serial number) within the Configlet, it merges the configuration contained in the Configlet into its running datastore.
A Configlet Signer is the entity authorized by the device manufacturer to sign Configlets for its devices (note: this may be the device vendor itself).
A Configlet Signer MUST provide a user-facing service enabling the creation of a Configlet with user-specific deployment values, using the YANG schema defined in Section 3.2. This document does not specify what form this interface must take, so it is the Configlet Signer's discretion if it is a web page, a REST API, or something else.
A Configlet Signer MUST ensure that the end-user is the rightful owner of the device containing the unique identifier value to be put into the Configlet. How a Configlet Signer ensures this is outside the scope of this document, but it is envisioned that the vendor would provide a secured interface for its trusted Configlet Signers to use.
A Configlet Signer MUST have an X.509 certificate with Key Usage capable of signing data (digitalSignature) and be signed by a certificate authority having a chain of trust leading to a trust anchor known to the devices loading its Configlets. The Configlet Signer MUST possess all intermediate certificates leading to its trust anchor.
When a Configlet Signer signs a Configlet, it attaches both the signature and the chain of X.509 certificates, including its own, but not necessarily including the trust anchor's certificate. This chain of certificates is needed so a device can validate a Configlet using only the Configlet Signer trust anchors known to it.
A Configlet Signer does not need to retain the Configlet after signing it; it is expected that either the end-user or the Configlet Signer will convey the signer Configlet to a Configuration Server where it will be hosted.
https://example.com?id=
scp://user@zerotouch.example.com/configlets/
ftp://example.com/zerotouch/configlets/
https://example.com?id=<fingerprint>
scp://user@zerotouch.example.com/configlets/<fingerprint>
ftp://example.com/zerotouch/configlets/<fingerprint>
A Configuration Server is the entity hosting configurations that can be downloaded over a network. Configuration Servers are known to devices in the form of a URI, to which a device appends the fingerprint of its entity certificate (see Section 4.1 for details). For instance, if the URI were: Section 4.1).
The Configuration Server is expected to be able to map the fingerprint to a device-specific unique identifier (e.g., serial number), which is the value contained in the Configlet it is hosting. How the Configuration Server does this mapping is outside the scope of this document, but it is envisioned that the vendor would provide a secured interface for its trusted Configuration Servers to use.
Configuration Servers do not need to use encryption, since the Configlets themselves are immutable to tampering, due to being signed. However, for confidentiality reasons, it is RECOMMENDED to use encryption, so adversaries cannot see the Configlet's otherwise clear-text content, from which they can learn some details about the device's internal deployment.
If a Configuration Server uses X.509-based encryption, then its X.509 certificate MUST have a chain of trust to a trust anchor known to devices. The Configuration Server MUST possess all the intermediate certificates leading to a trust anchor.
When a Configuration Server negotiates encryption with the device, it provides the chain of X.509 certificates, including its own, but not necessarily including the trust anchor's certificate. Devices need the chain of certificates to be passed so they can validate the server using only a minimal list of Configuration Server trust anchors.
Configuration Server's SHOULD automatically expire Configlets after some user-specified amount of time.
In order to facilitate troubleshooting and auditing, the Configuration Server SHOULD record into a log a record of the various Configlet download requests. This draft does not define what information should be kept or for how long.
The NMS is the ultimate destination of ZeroTouch for a device. It is the NMS's network address configured in the Configlet. The device will connect to the NMS using either a reverse-SSH or reverse-TLS, as configured by the Configlet loaded.
In order to authenticate the device, the NMS MUST possess the X.509 certificate for the trust anchor leading to the device's entity certificate. The NMS uses this certificate to validate the server-certificate the device presents during SSH or TLS transport negotiation.
The NMS SHOULD also validate that the unique identifier (e.g., serial number), within the "Common Name" field of the device's X.509 certificate, is an identity that the NMS is expecting, and not another device having the same device type. In order for the NMS to know the unique identifiers for devices shipped directly to their destinations, it may be necessary for the device manufacturer to provide the unique identifiers along with other shipping or billing information. This draft not specify a format for this information exchange.
In addition to authenticating the device, the NMS must also authenticate itself to the device. How this is done is protocol specific. For reverse-SSH, the NMS needs to know the information configured on the device by the Configlet it loaded, specifically the name of a local user account and the necessary credentials configured for the account (i.e., password or the private-half of a SSH host key). For reverse-TLS, the NMS must present a client certificate. Presumably the NMS has been configured with the information used when the Configlet was created.
Devices supporting ZeroTouch MUST support either reverse-SSH or reverse-TLS, and MAY support both. In either case, the device MUST present an X.509-based certificate encoding a unique device identifier (e.g. serial number) and a public key, both signed by a trusted certificate authority. This certificate is the "entity certificate" in the diagram below. This certificate is needed in order for the NMS to positively authenticate a device. For reverse-SSH, this certificate requirement constrains the SSH host key algorithms the device is allowed to to use to those defined in [RFC6187].
The unique identifier MUST be something that is both known to the device and easily tracked through labels affixed to the device as well as the box it is packaged in. A device's serial number is commonly treated this way and would be suitable for this purpose.
The device MUST possess the private key matching the public key encoded in the entity certificate. Ideally, the private key SHOULD be generated and protected by a tamper-resistant cryptographic processor, as this provides the greatest assurance that the private key is known to no one, including the device's manufacturer.
The entity certificate MUST be signed by a certificate authority having a chain of trust to a well-known trust anchor. The device MUST also possess the X.509 certificates for any intermediate CAs leading to the trust anchor. During SSH or TLS transport setup, the device will send both its entity and any intermediate certificates so the NMS can verify the certificate path using only the well-known trust anchor.
Since the entity certificate is to be used for SSH and TLS connections, its Key Usage, if set, SHOULD have the digitalSignature, keyEncipherment, and keyAgreement bits set.
In order for a device to know where it can obtain a Configlet, it MUST have two sets of URIs, identifying resources where it can obtain Configlets. One set contains secure schemes (e.g. https://, scp://) and the other contains insecure schemes (e.g., http://, ftp://). These URIs point to the "Configuration Servers" in the diagram below.
In order for a device to use a URI with a secure scheme, devices MUST possess a trust anchor certificate that it can use to authenticate the Configuration Server with. As each Configuration Server may use a different trust anchor, this generalizes to a list of Configuration Server trust anchor certificates. These trust anchors MAY include broadly recognized certificate authorities, such as the certificates packaged with web browsers.
In order for a device to authenticate Configlets, it MUST have a trust anchor for the CA that signed the Configlet. The CA used to sign Configlets is called a "Configlet Signer" in the diagram below. In order to enable Configlets to be signed by different CAs, the device MAY have either a list of trust anchors, or a single trust anchor that delegates Configlet signing trust to other CAs. The diagram below shows a list of Configlet Signer trust anchors only because it is the more flexible option.
Devices SHOULD ensure that all its trust anchor certificates, including those for the Configlet Signer and Configuration Server, are protected from external modification. It is for this reason that the diagram below shows them in immutable storage. However, it may be necessary to update these certificates over time (e.g., the vendor wants to delegate trust to a new CA). Therefore, devices MAY update these trust anchors when needed through a verifiable process, such as a software upgrade using signed software images.
Devices SHOULD ensure that the certificates for its trust anchors are protected from external modification, specifically the Configlet Signer and Configuration Server X.509 certificates. It is for this reason that the diagram below shows them in immutable storage. The certificates for the device's trust anchors MAY be updated along with a standard software image upgrade.
Device State Precondition
+------------------------------------------------------------------+ | <device> | | | | +------------------------------------------------------+ | | | <immutable storage> | | | | | | | | list of Configlet Signer trust anchor certificates | | | | list of Configuration Server trust anchor certs | | | +------------------------------------------------------+ | | | | +----------------------------------------------------------+ | | | <other storage> | | | | | | | | two sets of Configuration Server URIs | | | | device entity & associated intermediate certificate(s) | | | +----------------------------------------------------------+ | | | | +----------------------+ | | | <crypto processor> | | | | | | | | device private key | | | +----------------------+ | | | +------------------------------------------------------------------+
Whenever a device boots with its factory default settings, it initiates ZeroTouch with the goal of finding a configuration with which it can use to configure itself.
The device MUST first initialize its networking as per its default factory configuration. This SHOULD result in the dynamic assignment of an IP address, subnet or prefix, gateway, and a DNS server.
While initializing its networking, the device MAY receive some additional URIs for where a software image or configuration can be downloaded. This draft does not define how such URIs MAY be exchanged, for instance, using DHCP options.
If, while initializing its networking, the device receives software image URIs, it MAY download and install the software image only if the image is protected from modification (e.g., the image is signed) and the device is able to verify its integrity. The device SHOULD try URIs with secure schemes before URIs with insecure schemes (e.g., scp:// before ftp://). If the device needs to reboot to activate the new software image, it MUST do so with its default factory configuration set so that ZeroTouch will run again when the device comes back up.
If, while initializing its networking, the device receives configuration URIs, each URI SHOULD be appended to one of the device's two sets of Configuration Server URIs, depending on if the URI's scheme is secure or not. URIs added this way MUST remain distinguishable from those URIs the device was shipped with, for reasons discussed in Section 4.2.
Before trying any of the Configuration Server URIs, the device SHOULD first try to load a configuration through local means that assert physical presence. For instance, a removable USB flash drive or near-field communication mechanism. Configurations obtained through an assertion of physical presence do not have to be signed or contain the device's unique identifier (e.g., serial number). If a Configlet is found, the device MUST use it without trying any of the Configuration Server URIs.
If a configuration was not found via physical presence, the device then iterates over its two sets of Configuration Server URIs. The device MUST first try all the URIs from the set having secure schemes before trying any of the URIs from the set having insecure schemes. For each URI, until a usable configuration is found and successfully loaded, the device attempts to download a configuration from the URI. If the URI uses a secure scheme (e.g., https), the device MUST validate the Configuration Server's certificate using one of its Configuration Server trust anchors. If the device is unable to verify the server's certificate, the device MUST skip that URI. If the device reaches the end of all its URIs without finding a configuration, it MAY continue its normal boot sequence using its factory default configuration.
When the device is accessing a Configuration Server URI that it was shipped with (i.e., not discovered while initializing its networking, it MUST do so by appending the fingerprint of its entity certificate to the URI's string, as described in the Section 3.4. For URIs discovered while initializing its networking, the device MAY try both the raw URI as well as the permutation of it using its fingerprint.
The Configuration Server's response MAY be anything allowed by the given URI's scheme. For instance, if the scheme is HTTP-based, the Configuration Server MAY return an HTTP redirect. In this way, a vendor's Configuration Server service may allow the device owner to redirect the device to a Configuration Server running in their network.
If the Configuration Server returns a Configlet, the device MUST first verify it before use. Configlet verification entails both verifying the Configlet's signature using the device's list of Configlet Signer trust anchors, and also verifying that the unique identifier (e.g., serial number) within the Configlet matches the device's unique identifier.
Once a Configlet is authenticated, the device merges the Configlet's contents into its running configuration and then exits ZeroTouch. Since the Configlet configures the device to "call home," upon entering its normal operating mode, the device immediately begins trying to establish a reverse-SSH or reverse-TLS connection, as specified by the Configlet.
If configured to establish a reverse-SSH connection, the the device MUST use its entity and associated intermediate X.509 certificates as its host key per RFC 6187 [RFC6187]. If configured to use reverse-TLS, the device MUST use its entity and associated intermediate X.509 certificates as its server-side certificate for the TLS connection.
In order to facilitate troubleshooting, the device SHOULD record into a log information relating to its stepping through the ZeroTouch sequence of steps. This draft does not define any specific log messages, for instance, for Syslog or SNMP.
ZeroTouch Sequence Diagram
DEVICE LOCAL DHCP CONFIGLET NMS
| SERVER SERVERS |
| | | |
|------------>| | |
| Lease IP | | |
| | | |
|------------------------------->| |
| Iterate until Configlet found | |
| | | |
| | | |
|---------------------+ | |
| Validate Configlet | | |
|<--------------------+ | |
| | | |
| | | |
|---------------------------------------------->|
| reverse-SSH or reverse-TLS | |
| | | |
| | | |
The Configlet's data is modeled after the data models provided by draft-ietf-netmod-system-mgmt and draft-kwatsen-netconf-server. These data models are used to configure a local user account and either reverse-SSH or reverse-TLS. Networking is not included in the Configlet data model as it is expected that the device will by assigned a dynamic address by the network and that it will use this address both when connecting to a Configuration Server and later the NMS.
From draft-ietf-netmod-system-mgmt, the data model for user authentication has the following structure:
+--rw system
+--rw authentication
+--rw user-authentication-order* identityref
+--rw user* [name]
+--rw name string
+--rw password? crypt-hash
+--rw ssh-key* [name]
+--rw name string
+--rw algorithm string
+--rw key-data binary
From draft-kwatsen-netconf-server, the data model for reverse-SSH has the following structure:
+--rw netconf
+--rw ssh {ssh}?
+--rw listen {inbound-ssh}?
| +--rw (one-or-many)?
| +--:(one-port)
| | +--rw port? inet:port-number
| +--:(many-ports)
| +--rw interface* [address]
| +--rw address inet:ip-address
| +--rw port? inet:port-number
+--rw call-home {outbound-ssh}?
+--rw applications
+--rw application* [name]
+--rw name string
+--rw description? string
+--rw servers
| +--rw server* [address]
| +--rw address inet:host
| +--rw port? inet:port-number
+--rw connection-type
| +--rw (connection-type)?
| +--:(persistent-connection)
| | +--rw persistent
| | +--rw keep-alives
| | +--rw interval-secs? uint8
| | +--rw count-max? uint8
| +--:(periodic-connection)
| +--rw periodic
| +--rw timeout-mins? uint8
| +--rw linger-secs? uint8
+--rw reconnect-strategy
| +--rw start-with? enumeration
| +--rw interval-secs? uint8
| +--rw count-max? uint8
+--rw host-keys
+--rw host-key* [name]
+--rw name string
Also from draft-kwatsen-netconf-server, the data model for reverse-TLS has the following structure:
+--rw netconf
+--rw tls {tls}?
+--rw listen {inbound-tls}?
| +--rw (one-or-many)?
| +--:(one-port)
| | +--rw port? inet:port-number
| +--:(many-ports)
| +--rw interface* [address]
| +--rw address inet:ip-address
| +--rw port? inet:port-number
+--rw call-home {outbound-tls}?
| +--rw applications
| +--rw application* [name]
| +--rw name string
| +--rw description? string
| +--rw servers
| | +--rw server* [address]
| | +--rw address inet:host
| | +--rw port? inet:port-number
| +--rw connection-type
| | +--rw (connection-type)?
| | +--:(persistent-connection)
| | | +--rw persistent
| | | +--rw keep-alives
| | | +--rw interval-secs? uint8
| | | +--rw count-max? uint8
| | +--:(periodic-connection)
| | +--rw periodic
| | +--rw timeout-mins? uint8
| | +--rw linger-secs? uint8
| +--rw reconnect-strategy
| +--rw start-with? enumeration
| +--rw interval-secs? uint8
| +--rw count-max? uint8
+--rw cert-maps {tls-map-certificates}?
| +--rw cert-to-name* [id]
| +--rw id uint32
| +--rw fingerprint x509c2n:tls-fingerprint
| +--rw map-type identityref
| +--rw name string
+--rw psk-maps {tls-map-pre-shared-keys}?
+--rw psk-map* [psk-identity]
+--rw psk-identity string
+--rw user-name nacm:user-name-type
+--rw not-valid-before? yang:date-and-time
+--rw not-valid-after? yang:date-and-time
+--rw key yang:hex-string
Configlets obtained over the network MUST be signed using the W3C standard "XML Signature Syntax and Processing" [XMLSIG]. The entire contents of the Configlet MUST be signed. The signature block must also include the Configlet Signer's certificate and any intermediate certificates leading to a Configlet Signer trust anchor.
A signed Configlet example is in the Appendix.
Following is the YANG module for the Configlet:
module ietf-netconf-zerotouch {
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-zerotouch";
prefix "nczerotouch";
//import ietf-system {
// prefix ncsystem;
//}
import ietf-netconf-server {
prefix ncserver;
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Bert Wijnen
<mailto:bertietf@bwijnen.net>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module contains a collection of YANG definitions for
configuring NETCONF zerotouch.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note
// RFC Ed.: please update the date to the date of publication
revision "2014-01-24" {
description
"Initial version";
reference
"RFC XXXX: A YANG Data Model for NETCONF ZeroTouch Configlet";
}
typedef crypt-hash {
type string {
pattern
'$0$.*'
+ '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
+ '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
+ '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
}
description
"The crypt-hash type is used to store passwords using
a hash function. The algorithms for applying the hash
function and encoding the result are implemented in
various UNIX systems as the function crypt(3).
A value of this type matches one of the forms:
$0$<clear text password>
$<id>$<salt>$<password hash>
$<id>$<parameter>$<salt>$<password hash>
The '$0$' prefix signals that the value is clear text. When
such a value is received by the server, a hash value is
calculated, and the string '$<id>$<salt>$' or
$<id>$<parameter>$<salt>$ is prepended to the result. This
value is stored in the configuration data store.
If a value starting with '$<id>$', where <id> is not '0', is
received, the server knows that the value already represents a
hashed value, and stores it as is in the data store.
When a server needs to verify a password given by a user, it
finds the stored password hash string for that user, extracts
the salt, and calculates the hash with the salt and given
password as input. If the calculated hash value is the same
as the stored value, the password given by the client is
accepted.
This type defines the following hash functions:
id | hash function | feature
---+---------------+-------------------
1 | MD5 | crypt-hash-md5
5 | SHA-256 | crypt-hash-sha-256
6 | SHA-512 | crypt-hash-sha-512
The server indicates support for the different hash functions
by advertising the corresponding feature.";
reference
"IEEE Std 1003.1-2008 - crypt() function
Wikipedia: http://en.wikipedia.org/wiki/Crypt_(C)
RFC 1321: The MD5 Message-Digest Algorithm
FIPS.180-3.2008: Secure Hash Standard";
}
container configlet {
description
"Top-level container for ZeroTouch configuration objects.";
container system {
// no way to use top-level "netconf" container?
container authentication {
list user {
key name;
description
"The list of local users configured on this device.";
leaf name {
type string;
description
"The user name string identifying this entry.";
}
leaf password {
type crypt-hash;
description
"The password for this entry.";
}
list ssh-key {
key name;
description
"A list of public SSH keys for this user.";
reference
"RFC 4253: The Secure Shell (SSH) Transport Layer
Protocol";
leaf name {
type string;
description
"An arbitrary name for the ssh key.";
}
leaf algorithm {
type string;
mandatory true;
description
"The public key algorithm name for this ssh key.
Valid values are the values in the IANA Secure Shell
(SSH) Protocol Parameters registry, Public Key
Algorithm Names";
reference
"IANA Secure Shell (SSH) Protocol Parameters
registry, Public Key Algorithm Names";
}
leaf key-data {
type binary;
mandatory true;
description
"The binary key data for this ssh key.";
}
}
}
}
}
container netconf-server {
// no way to use top-level "netconf" container?
container ssh {
uses ncserver:ssh-config;
// no way to disable "listen" container?
}
container tls {
uses ncserver:tls-config;
// no way to disable "listen" container?
}
}
}
}
It is not possible to substitute a Configlet created for a different device, since devices assert that the Configlet contains their unique identifier (e.g., serial number).
It is possible to substitute a Configlet created for a device with a different Configlet created for the same device. Generally, unless imposed by the Configlet Signers, there is no limit to the number of Configlets that may be generated for a given device. This could be resolved, in part, by placing a timestamp into the Configlet and ensuring devices do not load Configlets older than some amount, but this requires the devices have an accurate clock when validating a Configlet and for Configlet Signers to not sign a Configlet when another Configlet is still active.
Confidentiality of Configlets loaded over a network is only assured when the device uses a secure networking scheme and validates the Configuration Server's certificate.
Confidentiality is further provided by using the fingerprint of the device's entity certificate when doing a Configuration Server lookup, as it is not guessable and thus makes it nearly impossible for an adversary to lookup.
This draft allows devices to try alternate means to load a Configlet before trying the network, so long as they assert physical presence. For instance, a removable USB drive or a near-field communication mechanism. Further, this draft does not require Configlets to be signed, if loaded via a mechanism that asserts physical presence. or require those Configlets to have the device's unique identifier value set. All of these relaxations in Security are deemed acceptable because physical presence should only be accessible to trusted parties.
This draft allows devices to use insecure schemes when doing a Configuration Server lookup. This is deemed acceptable because the Configlet is tamper-proof, due to being signed, only confidentiality is lost.
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 well known trust anchor, should have a expiration date greater than the device's useful life expectancy. Given the long-lived nature of these device certificates, it is paramount to use a strong key length (e.g., 512-bit ECC). Configlet Signers should deploy Online Certificate State Protocol (OCSP) responders or CRL Distribution Points (CDP) to revoke certificates in case necessary.
This draft mentions using the device's serial number as its unique identifier in its entity certificate. This is because serial numbers are ubiquitous and prominently contained in invoices and on labels affixed to devices and their packaging. That said, 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 details needed 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 is just security through obscurity.
It is paramount the device manufacturer ensures the integrity of the device's list of trust anchors. It should not be possible for anyone other than the manufacturer be able to modify the list of trust anchors. One way to achieve this to sign the list of trust anchors with a private key known only to the manufacturer, and for the matching public key to be stored on tamper-resistant read-only media.
None
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.
| [RFC2119] | Bradner, S.B., "Key words for use in RFCs to Indicate Requirement Levels ", BCP 14, RFC 2119, March 1997. |
| [RFC3365] | Schiller, J.S., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols ", RFC 3365, August 2002. |
| [RFC4252] | Ylonen, T.Y. and C.L. Lonvick, "The Secure Shell (SSH) Authentication Protocol ", RFC 4252, January 2006. |
| [RFC5539bis] | Badra, M.B. and A.L. Luchuk, "Using the NETCONF Protocol over Transport Layer Security (TLS) ", RFC 5539, March 2011. |
| [RFC6187] | Igoe, K.I. and D.S. Stebila, "X.509v3 Certificates for Secure Shell Authentication ", RFC 6187, March 2011. |
| [RFC6241] | Enns, R.E., Bjorklund, M.B., Schoenwaelder, J.S. and A.B. Bierman, "NETCONF Configuration Protocol", RFC 6241, June 2011. |
| [REVERSE-SSH] | Watsen, K.W., "Reverse SSH", June 2013. |
| [XMLSIG] | XML Signature Syntax and Processing", June 2008. | , "
| [TR069] | The Broadband Forum, , "TR-069 Amendment 3, CPE WAN Management Protocol ", November 2010. |
| [draft-hanna-zeroconf-seccfg-00] | Hanna, , "Configuring Security Parameters in Small Devices ", January 2002. |
This example illustrates a Configlet configuring both a local user account and reverse-SSH. This Configlet includes both the Configlet Signer's certificate as well as an Intermediate certificate. Note that '\' characters have been added for formatting reasons.
<?xml version="1.0"?>
<configlet xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-zerotouch">
<!-- from ietf-system.yang -->
<system>
<authentication>
<user>
<name>admin</name>
<ssh-key>
<name>admin's rsa ssh host-key</name>
<algorithm>ssh-rsa</algorithm>
<key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsRC
jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mwj
E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVcC
WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA5
vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jWq
EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf6
gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
</ssh-key>
</user>
</authentication>
</system>
<!-- from ietf-netconf-server.yang -->
<netconf-server>
<ssh>
<call-home>
<applications>
<application>
<name>config-mgr</name>
<description>
This entry requests the device to periodically
connect to the Configuration Manager application
</description>
<servers>
<server>
<address>config-mgr1.example.com</address>
</server>
<server>
<address>config-mgr2.example.com</address>
</server>
</servers>
<connection-type>
<periodic>
<timeout-mins>5</timeout-mins>
<linger-secs>10</linger-secs>
</periodic>
</connection-type>
<reconnect-strategy>
<start-with>last-connected</start-with>
<interval-secs>10</interval-secs>
<count-max>3</count-max>
</reconnect-strategy>
<host-keys>
<host-key>
<name>ssh_host_key_cert</name>
</host-key>
<host-key>
<name>ssh_host_key_cert2</name>
</host-key>
</host-keys>
</application>
</applications>
</call-home>
</ssh>
</netconf-server>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference>
<Transforms>
<Transform
Algorithm=\
"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>2xlFdlVifb1snGBLJuEZYrLjSUQ=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>\
HUx3S7TZXGJGUhazWGRSB9CBMZ0T+tTrB1fOnTcKi9wU4UOnSw5KMWDvOVwc6ldM
UIOJIuJigWhSkn+VvWSWz6qy7LTYIywNcxDyghMvmMXfoRXETpL+qCDxribMi4VW
mVhEw1oe83kJt7W/0DJUE7FFKRUhPjy9EgxpQX/7WdKSK+4f2uYkSpq2UumW3DIU
LeK9vNRVQBbhmcF3zZWANmwKH5V4WeQimwWE497AeSYWgSImSetADI0NvvXfBZjx
JqzFEaYLNz8IB0ZVY+w14s1RZbN7YmxhN1R3q52wWvHjR2SylR/Z5BpIhYoDeKoD
HMQMf3HZL06Hm5S8r8rgGg==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>\
MIIFKjCCBBKgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAwMRMwEQYDVQQKFApUUE1f
VmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMB4XDTEzMTAyMDE2MjIx
MFoXDTE0MTAyMDE2MjIxMFowKzETMBEGA1UEChQKVFBNX1ZlbmRvcjEUMBIGA1UE
AxQLY2hpcF8wMDAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDf
4hyWqFsf801sZYJQBJ0PB4cHmlnPNOs9pv3QCCB1PzlYhfcDOygVmqhzZjPY+t7q
ZTjPs/E8n5X4dd0DkR80uc4MWmzc40Pz2HAW6GQ2mo+eUYzXUqQFbi3EkqrzddZk
gRi6vuadMkAcJH8ugYR+cbw/LlpXhIy2A5fUh4JP7Y9l1wABTbK8eGhF9cvGxBYR
+KqZJycoV6aaIvD/0NO1CNSaGeAJXXxXWoRF5E6HVKsolTHPPdi+40BmYrCuuWy6
1ybCIP5uZZ7Oza4j0n/fPb6SEqEa0I1zUEWlFQMZYsBClNY5TzWHNgQ5dPJO2qgx
PONwnLIsx46DlAzlpFpXAgMBAAGjggJSMIICTjAMBgNVHRMBAf8EAjAAMIGTBgNV
HSABAf8EgYgwgYUwgYIGC2CGSAGG+EUBBy8BMHMwOQYIKwYBBQUHAgEWLWh0dHA6
Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDA2BggrBgEF
BQcCAjAqGihUQ1BBIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlIEVuZG9yc2VtZW50
MIHXBgNVHSMEgc8wgcyAFCHd7bYICEQX3QxR30ixhppG7bjmoYGwpIGtMIGqMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2
YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0wGwYDVQQLFBRDZXJ0aWZp
Y2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0X0FuY2hvcjEdMBsGCSqG
SIb3DQEJARYOY2FAanVuaXBlci5jb22CAQEwcQYDVR0fBGowaDBmoC6gLIYqaHR0
cDovL2NybC5qdW5pcGVyLm5ldD9jYT1KdW5pcGVyX1hYWFhYX0NBojSkMjAwMRMw
EQYDVQQKFApUUE1fVmVuZG9yMRkwFwYDVQQDFBBKdW5pcGVyX1hYWFhYX0NBMFsG
A1UdEQEB/wRRME+kTTBLMQswCQYDVQQGEwJVSzEYMBYGA1UEChMPTXkgT3JnYW5p
emF0aW9uMRAwDgYDVQQLEwdNeSBVbml0MRAwDgYDVQQDEwdNeSBOYW1lMA0GCSqG
SIb3DQEBCwUAA4IBAQCsVFVA90O8E4p/8ohBYQRezVaWidTHCTM1sdAoeljlrsFX
xqwcQEGVT3BpzwN8w2r+iKOKLQkWv64os0KKL0RIIjmCmJ2RukqH/R0M8Air4+Im
iWI3xV+HzVRsJIrCRT2tzxbchU/i/LQiwhteUEZ9sZbHKyLQe9x9HgByM05ifOGh
z2dcb7AWNlo7nJtRBmx0v9iim2kktqGMuXgBzlnMMabqHMb4L+vjww2Wn5nNYbr/
oXq4fa01MGQyvRPAEOwL3ZxcaqKHvmTn9coBLhpP3nQIEV+V+PngQjtBmwdkjIj5
feDp86jGN6348H+z9CzXUSbyOn6utIxN0SvVESxx</X509Certificate>
<X509Certificate>\
MIIExTCCA62gAwIBAgIBATANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVN1bm55dmFsZTEZMBcGA1UE
ChQQSnVuaXBlcl9OZXR3b3JrczEdMBsGA1UECxQUQ2VydGlmaWNhdGVfSXNzdWFu
Y2UxGTAXBgNVBAMUEFRQTV9UcnVzdF9BbmNob3IxHTAbBgkqhkiG9w0BCQEWDmNh
QGp1bmlwZXIuY29tMB4XDTEzMTAyMDE2MjIwOVoXDTE0MTAyMDE2MjIwOVowMDET
MBEGA1UEChQKVFBNX1ZlbmRvcjEZMBcGA1UEAxQQSnVuaXBlcl9YWFhYWF9DQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK+D34JQ/tsWv5SZ5L2TF7u7
xo7eZEpz/BmnXhxa6keBx5gmjkBXgfSMov7ZJaZfzXkCL01YDDCDQyXBLkh/n2bL
3K0AkEUJPTJgSTTQbPtLkVJgWWAwYASu3/L88c9JH33tvPNQusL0qW683Pd3iVV5
VFOe7c2ZZ0aUtw/FBexjOwPmkQdivb78mfNwyJYkgy0dq0z5GaIIZNna2de1N/Jk
mStZEB6+QJfn0qRsaJbA3TS5JQ13ZBSOqcvtjOIDingjHCXGWEULTeF1UVExNXEG
fsHY2CtQaP/r8hT/8TjPB4mJpbuG1P/BpIAXtBC+hqggwAnNpVfcAxReozzoFCcC
AwEAAaOCAW0wggFpMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFCHd7bYI
CEQX3QxR30ixhppG7bjmMIHfBgNVHSMEgdcwgdSAFH+nvIT5PZV62rnjGbqzwT2R
K1FOoYGwpIGtMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTES
MBAGA1UEBxMJU3Vubnl2YWxlMRkwFwYDVQQKFBBKdW5pcGVyX05ldHdvcmtzMR0w
GwYDVQQLFBRDZXJ0aWZpY2F0ZV9Jc3N1YW5jZTEZMBcGA1UEAxQQVFBNX1RydXN0
X0FuY2hvcjEdMBsGCSqGSIb3DQEJARYOY2FAanVuaXBlci5jb22CCQCVivZlfsyT
TzAOBgNVHQ8BAf8EBAMCAgQwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybC5q
dW5pcGVyLm5ldD9jYT1KdW5pcGVyX1RydXN0X0FuY2hvcl9DQTANBgkqhkiG9w0B
AQsFAAOCAQEAXw4/3c9yC4TiYTxHmEXoqYgw2+xyEtJIEs3Kv7MSbF/cJwXz4lci
8Fy3ZiKgq9gj9vloWLT5V9ri1HCgalD8D56iKtQCOvY7TJ64qChAA8q7/WNC3dbJ
s9Op6+nSpolfG8YNHfBroCSfNOVCteJ+pU26p3cC1150Pr+/yZZHnsMhNLYuLCvq
29uvnPDBC4MMVfcMbasPpsxL7Ue4PJsjnLquGLZ33MgNGP1TdefvYCFLF2ZEIbvi
KEGLOTXMrXsbUbQLZAdlq6kLCm7A3u6gwTMg+NydCziVsARq+ZKJS0n3vDoAIJxl
BfXhJE4VOjAEQ8w+Sftu1lu6rJZr3ctSLg==</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</configlet>
The current YANG module must redefine parts of the "ietf-system" and "ietf-netconf-server" modules. Also, when referencing parts that it can, the YANG module unnecessarily includes parts it doesn't need, such as configuring the device to listen for inbound connections. Ideally "deviation" statements could be used to delete the unwanted sub-trees.
This drafts states that Configlets don't have to be signed when loaded through a mechanism that asserts physical presence. However, some have voiced concern, saying that no possible backdoor should be allowed.