| NETCONF Working Group | K. Watsen |
| Internet-Draft | Juniper Networks |
| Intended status: Standards Track | J. Clarke |
| Expires: January 7, 2016 | Cisco Systems |
| M. Abrahamsson | |
| T-Systems | |
| July 6, 2015 |
Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)
draft-ietf-netconf-zerotouch-03
This draft presents a technique for establishing a secure NETCONF connection between a newly deployed IP-based device, configured with just its factory default settings, and its rightful 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 January 7, 2016.
Copyright (c) 2015 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.
A fundamental business requirement is to reduce costs where possible. For network operators, deploying devices to many locations can be a significant cost, as sending trained specialists to each site to do installations is both cost prohibitive and does not scale.
The solution presented herein enables a device to securely obtain a bootstrapping configuration from the network without any operator input. Significantly, this configuration may configure the device to securely call home using NETCONF Call Home [draft-ietf-netconf-call-home].
Central to this solution is the device being able to process a set of files locally, without any need to reach out to the network again. As consequence, how the files are obtained is not critical to the security of the solution. The files can be read over any networking layer or medium. By example, the files could be loaded using a USB flash drive physically plugged into a device.
This draft defines a solution that differs from the solution presented in [draft-pritikin-anima-bootstrapping-keyinfra]. Yet it is this author's opinion that it should be possible for both solutions to co-exist simultaneously. How to integrate them is discussed in this section.
Already the ANIMA draft defines in Section #3 the progression of first searching link-local, then the local network (e.g., DHCP options or DNS service records), and finally trying Internet-based resources. This progression makes good sense and, in general, there may be other searching options before, after, or in between the ones listed here (e.g., USB flash drive). The important aspect to this list of options is that they're ordered so as to give priority to the "closest" option.
It seems right that a device try all comparably-secure bootstrapping options at each stage of the searching progression. For instance, an integrated solution might try all comparably-secure bootstrapping options when at the link-local stage, and again try all comparably-secure bootstrapping options when at the local network stage, and yet again try all the comparably-secure bootstrapping options when at the Internet stage.
By trying all comparably-secure options at each stage, it 1) minimizes the number of times a device needs to reconfigure its networking, 2) prevents a "further away" solution for one option snuffing out a closer solution for a closer solution for another option, and 3) avoids having devices reach out to remote options unnecessarily, and thereby reduce tracking.
Bootstrapping options that are not comparably-secure should not be integrated as described above. Specifically, all secure bootstrapping options should be attempted prior to attempting any unsecure option. For instance, a device should prefer a secure option with a remote server over an unsecure option available on the link-local network.
The solution presented below does not reflect the thoughts mentioned in this note. Specifically, it has no provision for using a link-local address or DNS service discovery. Instead, it only assumes the use of a DHCP server, potentially with DHCP options to direct the device to use resources on the local network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the sections below are to be interpreted as described in RFC 2119 [RFC2119].
A simplified graphical representation of the data models is used in this document. The meaning of the symbols in these diagrams is as follows:
The following diagram illustrates the overall solution presented in this draft. Note that some of the interactions illustrated below occur at different times, only the numbered interactions (1-3) occur at the time a device is bootstrapping itself.
manufactures
+----------------------------------+
| |
| 1.discover |
| bootstrap | 2.fetch bootstrap
| information v data and provide
| (optional) +------+ confirmation
| +---------------|Device|----------------+
| | +------+ |
| | | |
| v | v
+------+ +------+ | +---------+
|Vendor| | DHCP | |3.netconf |Bootstrap|
+------+ |Server| | callhome | Server |
| ^ +------+ | +---------+
| | ^ | ^
| | | stage | |
| | | bootstrap | stage |
| | | information v bootstrap |
| | | (optional) +-------+ data |
| | +---------------| NMS |---------------+
| | +-------+
| | imports trust anchor, | ^
| | signups for owner cert, | |
| | and orders devices | |
| +-------------------------------+ |
+------------------------------------+
ships devices, provides
serial-numbers and/or IDevID
certs, and ownership vouchers
The boxes in this diagram are described next. A sequence diagram explaining the various calls follows in Section 2.2.
The following diagram illustrates the interactions between the entities described in the previous section. Note that the interactions can be roughly categorized as those that occur before a device powers on and those that occur after a device powers on.
+------+ +------+ +---+ +---------+ +------+
|Vendor| |Device| |NMS| |Bootstrap| | DHCP |
+------+ +------+ +---+ | Server | |Server|
| | | +---------+ +------+
| | | | |
| 1. imports trust anchor | | |
|<------------------------------| | |
| | | | |
| 2. signs up for owner cert | | |
|<------------------------------| | |
| | | | |
| 3. orders devices | | |
|<------------------------------| | |
| | | | |
| 4. ships | | | |
|-------------->| | | |
| | | | |
| 5. provides serial-numbers | | |
| and/or IDevID cert(s), | | |
| and ownership vouchers | | |
|------------------------------>| | |
| | | 6.stage | |
x | | bootstrap | |
| | data | |
| |-------------->| |
| | | |
| | 7. stage bootstrap |
| | info (optional) |
| |------------------------------>|
8. power on | | | |
-------------->| | | |
| 9. get networking settings and| |
| staged bootstrap info (if any) |
|---------------------------------------------->|
| | | |
| | | x
| 10. update boot-image, if |
| needed, and install |
| config, if valid |
|------------------------------>|
| | |
| | x
| 11. netconf |
| call-home |
|+------------->|
| |
v v
These interactions are described below.
A Bootstrap Server MUST implement the southbound interface defined below. In order to support the southbound interface, the Bootstrap Server will also need to have a northbound interface, which is described in general terms below.
The Bootstrap Server will need to provide a northbound interface of some sort to enable configuration of the bootstrapping information for the devices. Defining this interface is out of scope for this document, but it northbound interface is generally expected to:
The Bootstrap Server's southbound interface is a REST API that is described by the YANG [RFC6020] module defined in this section and presented using RESTCONF [draft-ietf-netconf-restconf]. Example usage of this API is provided in Appendix A.2.
A tree digram describing the Bootstrap Server's southbound interface follows:
module: ietf-zerotouch-bootstrap-server
+--ro devices
+--ro device* [unique-id]
+--ro unique-id string
+--ro ownership-voucher
| +--ro voucher binary
| +--ro issuer-crl? string
+--ro owner-certificate
| +--ro certificate string
| +--ro issuer-crl? string
+--ro boot-image!
| +--ro name string
| +--ro md5 string
| +--ro sha1 string
| +--ro path string
| +--ro signature string
+--ro configuration
+--ro config
+--ro signature string
rpcs:
+---x notification
+---w input
+---w unique-id string
+---w type enumeration
+---w message? string
+---w ssh-host-keys!
+---w ssh-host-key*
+---w format enumeration
+---w key-data string
In the above diagram, notice that the entire data model is read-only, as devices can only pull data from the Bootstrap Server. The data model also defines a single RPC, which is used by the device to provide asynchronous notifications.
The Bootstrap Server's southbound interface is normatively defined by the following YANG module:
<CODE BEGINS> file "ietf-zerotouch-bootstrap-server@2015-07-06.yang"
module ietf-zerotouch-bootstrap-server {
namespace
"urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server";
prefix "ztbs";
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: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module defines the southbound interface for ZeroTouch
Bootstrap Servers.
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.";
revision "2015-07-06" {
description
"Initial version";
reference
"RFC XXXX: Zero Touch Provisioning for NETCONF Call Home";
}
// top-level container
container devices {
config false;
description
"A list of device entries";
list device {
key unique-id;
leaf unique-id {
type string;
}
container ownership-voucher {
// presence?
description
"This container contains the Ownership Voucher that the
device uses to ascertain the identity of its rightful
owner, as certified by its Vendor.";
leaf voucher {
type binary;
mandatory true;
description
"A Vendor-specific encoding binding unique device
identifiers to an owner identifier value matching the
value encoded in the owner-certificate below. An
example format for a voucher is presented in the
Appendix of RFC XXXX.";
}
leaf issuer-crl {
type string;
description
"An absolute path to a CRL for the issuer used by the
Vendor to sign Ownership Vouchers. The CRL should be
as up to date as possible. This leaf is optional as
it is primarily to support deployments where the device
is unable to download the CRL from the CRL distribution
point URLs listed in the Vendor's trust anchor
certificate.";
}
}
container owner-certificate {
// presense?
description
"It is intended that the device will fetch this container
as a whole, as it contains values that need to be
processed together.";
leaf certificate {
type string;
mandatory true;
description
"This is an X.509 certificate, signed by a Vendor, for
a business organization. This certificate must encode a
Vendor-assigned value identifying the organization. This
identifier must match the owner identifier encoded in
the Ownership Voucher.";
}
leaf issuer-crl {
type string;
description
"An absolute path to a CRL for the issuer used by the
Vendor to sign Owner Certificates. The CRL should be
as up to date as possible. This leaf is optional as
it is primarily to support deployments where the device
is unable to download the CRL from the CRL distribution
point URLs listed in the Vendor's trust anchor
certificate.";
}
}
container boot-image {
presence
"Only present when boot image information has been configured";
description
"It is intended that the device will fetch this container
as a whole, as it contains values that need to be
processed together.";
leaf name {
type string;
mandatory true;
description
"The name of the image of software the device is expected
to be running.";
}
leaf md5 {
type string;
mandatory true;
description
"The output of the MD5 hash algorithm over the image file.";
}
leaf sha1 {
type string;
mandatory true;
description
"The output of the SHA-1 hash algorithm over the image file.";
}
leaf path {
type string;
mandatory true;
description
"An absolute path to the boot-image file hosted on this
Bootstrap server.";
}
leaf signature {
type string;
mandatory true;
description
"The signature over the concatenation of the previous leafs
using the organization's private key. Specifically,
sign(name+md5+sha1+path), where simple string concatenation
to join values is used, resulting in a single null-terminated
string.";
}
}
container configuration {
description
"It is intended that the device will fetch this container
as a whole, as its contents need to be processed together.";
anyxml config {
mandatory true;
description
"Any configuration data model known to the device. It may
contain Vendor-specific and/or standards-based data models.
An example configuration using a couple IETF-defined data
models is presented the Appendix of RFC XXXX.";
}
leaf signature {
type string;
mandatory true;
description
"The signature over the concatenation of the previous leaf
using the organization's private key. Specifically,
sign(config), where 'config' is treated as a single null-
terminated string.";
}
}
/*
action notification {
input {
leaf type {
type enumeration {
enum boot-image-missing {
description
"Indicates that the device got an error when trying to
access the provided URL";
}
enum boot-image-invalid {
description
"Indicates that the device had a problem processing the
boot-image file (corruption)";
}
enum image-name-mismatch {
description
"Indicates that the processed boot-image contains a name
other than provided";
}
enum voucher-invalid {
description
"Indicates that the device had a problem processing the
voucher (chain verification failed, revoked crl)";
}
enum owner-cert-invalid {
description
"Indicates that the device had a problem processing the
voucher (chain verification failed, revoked crl)";
}
enum owner-id-mismatch {
description
"Indicates that the owner-id in the voucher does not
match the one inside the owner-cert";
}
enum signature-invalid {
description
"Indicates that the signature could not be verified
using the owner-cert";
}
enum bootstrap-complete {
description
"Indicates that the device successfully processed the
bootstrap data. At this point, the device is running
the required boot-image and configuration. A device
is expected to only send this notification once,
assuming it does not receive an error in the HTTP
response from the Bootstrap Server.";
}
}
mandatory true;
}
leaf message {
type string;
description
"A human-readable value.";
}
container ssh-host-keys {
presence "Only present for bootstrap-complete messages.";
list ssh-host-key {
leaf format {
type enumeration {
enum ssh-dss;
enum ssh-rsa;
}
mandatory true;
}
leaf key-data {
type string;
mandatory true;
}
}
}
}
} // end action
*/
}
}
rpc notification {
input {
leaf unique-id {
type string;
mandatory true;
}
leaf type {
type enumeration {
enum boot-image-missing {
description
"Indicates that the device got an error when trying to
access the provided URL";
}
enum boot-image-invalid {
description
"Indicates that the device had a problem processing the
boot-image file (corruption)";
}
enum image-name-mismatch {
description
"Indicates that the processed boot-image contains a name
other than provided";
}
enum voucher-invalid {
description
"Indicates that the device had a problem processing the
voucher (chain verification failed, revoked crl)";
}
enum owner-cert-invalid {
description
"Indicates that the device had a problem processing the
voucher (chain verification failed, revoked crl)";
}
enum owner-id-mismatch {
description
"Indicates that the owner-id in the voucher does not
match the one inside the owner-cert";
}
enum signature-invalid {
description
"Indicates that the signature could not be verified
using the owner-cert";
}
enum bootstrap-complete {
description
"Indicates that the device successfully processed the
bootstrap data. At this point, the device is running
the required boot-image and configuration. A device
is expected to only send this notification once,
assuming it does not receive an error in the HTTP
response from the Bootstrap Server.";
}
}
mandatory true;
}
leaf message {
type string;
description
"A human-readable value that might provide useful information";
}
container ssh-host-keys {
presence "Only present for bootstrap-complete messages.";
list ssh-host-key {
leaf format {
type enumeration {
enum ssh-dss;
enum ssh-rsa;
}
mandatory true;
}
leaf key-data {
type string;
mandatory true;
}
}
}
}
} // end rpc notification
}
<CODE ENDS>
Devices supporting ZeroTouch MUST have the preconfigured factory default state and bootstrapping logic described in the following sections.
+------------------------------------------------------------------+ | <device> | | | | +----------------------------------------------------------+ | | | <read-only storage> | | | | | | | | 1. list of public Internet Bootstrap Servers | | | | 2. list of trust anchor certs for Bootstrap Servers | | | | 3. trust anchor cert for owner certificates | | | | 4. trust anchor cert for device ownership vouchers | | | | 5. IDevID cert & associated intermediate certificate(s) | | | +----------------------------------------------------------+ | | | | +----------------------+ | | | <secure storage> | | | | | | | | 6. private key | | | +----------------------+ | | | +------------------------------------------------------------------+
Power On
|
v No
1. Running default config? --------> Boot normally
|
| Yes
v No
2. Able to reach DHCP server? --------> Boot normally
|
| Yes
v
3. Prepend any additional Bootstrap Servers discovered
|
v No
4. Able to bootstrap off any Bootstrap Server? -------> Boot normally
(see next diagram for drill-down details)
|
| Yes
v
5. Run with new configuration
These interactions are described next.
Following are the actions performed by the device when bootstrap off a Bootstrap Server (step #4 the in previous diagram).
Connect to port 443
|
v No
1. Able to validate server certificate? ------> Exit
|
| Yes
v No
2. Able to validate ownership voucher? ------> Post notification and exit
|
| Yes
v No
3. Able to validate owner certificate? ------> Post notification and exit
|
| Yes
v No
4. Able to validate boot image info? ------> Post notification and exit
|
| Yes
v No
5. Need to install boot image? ------> Install and reboot
|
| Yes
v No
6. Able to validate configuration? ------> Post notification and exit
|
| Yes
v
7. Merge configuration into running datastore
|
v
8. Post bootstrap complete notification and exit
These interactions are described next.
It is expected that the bootstrapping configuration will guide the device to initiate a secure NETCONF connection to the NMS using NETCONF Call Home [draft-ietf-netconf-call-home]. This section describes what the NMS needs to do to ensure security for the device's connection.
+-----------------------------------------------------------------+ | <nms> | | | | +-----------------------------------------------------+ | | | <read-only storage> | | | | | | | | 1. list of IDevID trust anchor certificates | | | +-----------------------------------------------------+ | | | | +-----------------------------------------------------+ | | | <configuration> | | | | | | | | 2. list of expected device unique identifiers | | | +-----------------------------------------------------+ | | | | +-----------------------------------------------------+ | | | <secure storage> | | | | | | | | 3. map of device identifiers to login credentials | | | +-----------------------------------------------------+ | | | +-----------------------------------------------------------------+
When receiving a NETCONF call home connection from a device, the NSM completes the connection as specified NETCONF Call Home [draft-ietf-netconf-call-home].
Section 7.2.7.2 of the IEEE Std 802.1AR-2009 standard says that IDevID certificate should never expire (i.e. having a notAfter 99991231235959Z). Given the long-lived nature of these certificates, it is paramount to use a strong key length (e.g., 512-bit ECC). Vendors SHOULD deploy Online Certificate State Protocol (OCSP) responders or CRL Distribution Points (CDP) to revoke certificates in case necessary.
This draft suggests using the device's serial number as the unique identifier in its IDevID 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.
The following registrations are in accordance to RFC 2939 for "BOOTP Vendor Extensions and DHCP Options" registry maintained at http://www.iana.org/assignments/bootp-dhcp-parameters.
Tag: XXX
Name: Zero Touch Information
Description: Returns a list of null-terminated Configuration
Server hostnames and/or IP addresses.
Code Len
+-----+-----+------+------+----
| XXX | n | svr1 | svr2 | ...
+-----+-----+------+------+----
Reference: RFC XXXX
Tag: YYY
Name: Zero Touch Information
Description: Returns a list of null-terminated Configuration
Server hostnames and/or IP addresses.
Code Len
+-----+-----+------+------+----
| YYY | n | svr1 | svr2 | ...
+-----+-----+------+------+----
Reference: RFC XXXX
The authors would like to thank for following for lively discussions on list and in the halls (ordered by last name): David Harrington, Dean Bogdanovic, Martin Bjorklund, Stephen Hanna, Wes Hardaker, Russ Mundy, Reinaldo Penno, Randy Presuhn, Juergen Schoenwaelder.
Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for brainstorming the original I-D's solution during the IETF 87 meeting in Berlin.
| [draft-ietf-netconf-call-home] | Watsen, K., "NETCONF Call Home (work in progress)", October 2014. |
| [draft-ietf-netconf-restconf] | Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", Internet-Draft draft-ieft-netconf-restconf-04, 2014. |
| [draft-ietf-netconf-server-model] | Watsen, K., "NETCONF Server Model (work in progress)", September 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. |
| [RFC6187] | Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, March 2011. |
| [Std-802.1AR-2009] | IEEE SA-Standards Board, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009. |
| [draft-pritikin-anima-bootstrapping-keyinfra] | Pritikin, M., Behringer, M. and S. Bjarnason, "Bootstrapping Key Infrastructures", Internet-Draft draft-pritikin-anima-bootstrapping-keyinfra-01, 2015. |
Following describes an example data-model for an Ownership Voucher. Real vouchers are expected to be encoded in a Vendor-specific format outside the of scope for this draft.
A tree digram describing an Ownership Voucher:
module: ietf-zerotouch-ownership-voucher
+--rw voucher
+--rw unique-id* string
+--rw owner-id string
+--rw created-on yang:date-and-time
+--rw expires-on? yang:date-and-time
+--rw signature string
The YANG module for this example voucher:
<CODE BEGINS> file "ietf-zerotouch-ownership-voucher@2015-07-06.yang"
module ietf-zerotouch-ownership-voucher {
namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-ownership-voucher";
prefix "ztov";
import ietf-yang-types { prefix yang; }
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: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module defines the format for a ZeroTouch ownership voucher,
which is produced by Vendors, relayed by Bootstrap Servers, and
consumed by devices. The purpose of the voucher is to enable a
device to ascertain the identity of its rightful owner, as
certified by its Vendor.
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.";
revision "2015-07-06" {
description
"Initial version";
reference
"RFC XXXX: Zero Touch Provisioning for NETCONF Call Home";
}
// top-level container
container voucher {
leaf-list unique-id {
type string;
min-elements 1;
description
"The unique identifier (e.g., serial-number) for a device.
The value must match the value in the device's IDevID
certificate. A device uses this value to determine if
the voucher applies to it.";
}
leaf owner-id {
type string;
mandatory true;
description
"A Vendor-assigned value for the rightful owner of the
devices enumerated by this voucher. The owner-id value
must match the value in the owner-certificate below";
}
leaf created-on {
type yang:date-and-time;
mandatory true;
description
"The date this voucher was created";
}
leaf expires-on {
type yang:date-and-time;
description
"The date this voucher expires, if any";
}
leaf signature {
type string;
mandatory true;
description
"The signature over the concatenation of all the previous
values";
}
}
}
<CODE ENDS>
['\' line wrapping added for formatting only] GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ devices/device=123456/ownership-voucher GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ devices/device=123456/owner-certificate GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ devices/device=123456/boot-image GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\ devices/device=123456/configuration POST https://example.com/restconf/operations/ietf-zerotouch-bootstrap-\ server:notification
This example illustrates a configuration enabling secure NETCONF call-home using standards-based YANG modules.
<?xml version="1.0"?>
<configuration>
<!-- from ietf-system.yang -->
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-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 xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<call-home>
<application>
<name>config-mgr</name>
<ssh>
<endpoints>
<endpoint>
<name>east-data-center</name>
<address>11.22.33.44</address>
</endpoint>
<endpoint>
<name>west-data-center</name>
<address>55.66.77.88</address>
</endpoint>
</endpoints>
<host-keys>
<host-key>my-call-home-x509-key</host-key>
</host-keys>
</ssh>
</application>
</call-home>
</netconf-server>
</configuration>