draft-ietf-netconf-call-home-03.txt   draft-ietf-netconf-call-home-04.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 4253 (if approved) January 13, 2015 Updates: 4253 (if approved) February 2, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: July 17, 2015 Expires: August 6, 2015
NETCONF Call Home and RESTCONF Call Home NETCONF Call Home and RESTCONF Call Home
draft-ietf-netconf-call-home-03 draft-ietf-netconf-call-home-04
Abstract Abstract
This document presents NETCONF Call Home and RESTCONF Call Home, This document presents NETCONF Call Home and RESTCONF Call Home,
which respectively enable a NETCONF/RESTCONF server to initiate a which respectively enable a NETCONF/RESTCONF server to initiate a
secure connection to a NETCONF/RESTCONF client. secure connection to a NETCONF/RESTCONF client.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
This draft contains many placeholder values that need to be replaced This draft contains many placeholder values that need to be replaced
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 17, 2015. This Internet-Draft will expire on August 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 12
A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document presents NETCONF Call Home and RESTCONF Call Home, This document presents NETCONF Call Home and RESTCONF Call Home,
which respectively enable a NETCONF/RESTCONF server to initiate a which respectively enable a NETCONF/RESTCONF server to initiate a
secure connection to a NETCONF/RESTCONF client. The NETCONF protocol secure connection to a NETCONF/RESTCONF client. The NETCONF protocol
is described in [RFC6241] and the RESTCONF is described in is described in [RFC6241] and the RESTCONF is described in
[draft-ietf-netconf-restconf]. [draft-ietf-netconf-restconf].
skipping to change at page 7, line 24 skipping to change at page 7, line 24
However, when receiving a call home connection, the NETCONF/RESTCONF However, when receiving a call home connection, the NETCONF/RESTCONF
client does not have any context leading it to know the connection is client does not have any context leading it to know the connection is
from a particular NETCONF/RESTCONF server. Thus the NETCONF/RESTCONF from a particular NETCONF/RESTCONF server. Thus the NETCONF/RESTCONF
client must derive the NETCONF/RESTCONF server's identity using client must derive the NETCONF/RESTCONF server's identity using
information provided by the network and the NETCONF/RESTCONF server information provided by the network and the NETCONF/RESTCONF server
itself. This section describes strategies a NETCONF/RESTCONF client itself. This section describes strategies a NETCONF/RESTCONF client
can use to identify a NETCONF/RESTCONF server. can use to identify a NETCONF/RESTCONF server.
In addition to identifying a NETCONF/RESTCONF server, a NETCONF/ In addition to identifying a NETCONF/RESTCONF server, a NETCONF/
RESTCONF client must also be able to verify the NETCONF/RESTCONF RESTCONF client must also be able to verify the server's identity.
server's credentials. Verifying a NETCONF/RESTCONF server's Verifying a NETCONF/RESTCONF server's identity is necessary under
credentials is necessary under normal circumstances but, due to call normal circumstances but, due to call home being commonly used for
home being commonly used for newly deployed NETCONF/RESTCONF servers, newly deployed NETCONF/RESTCONF servers, how to verify its identity
how to verify its credentials the very first time becomes a prominent the very first time becomes a prominent concern. Therefore, this
concern. Therefore, this section also describes strategies a section also describes strategies a NETCONF/RESTCONF client can use
NETCONF/RESTCONF client can use to verify a NETCONF/RESTCONF server's to verify a NETCONF/RESTCONF server's identity.
credentials.
The first information a NETCONF/RESTCONF client learns from a call The first information a NETCONF/RESTCONF client learns from a call
home connection is the IP address of the NETCONF/RESTCONF server, as home connection is the IP address of the NETCONF/RESTCONF server, as
provided by the source address of the TCP connection. This IP provided by the source address of the TCP connection. This IP
address could be used as an identifier directly, but doing so would address could be used as an identifier directly, but doing so would
only work in networks that use known static addresses, in which case only work in networks that use known static addresses, in which case
a standard NETCONF/RESTCONF connection would have worked just as a standard NETCONF/RESTCONF connection would have worked just as
well. Due to this limited use, it is not recommended to identify a well. Due to this limited use, it is not recommended to identify a
NETCONF/RESTCONF server based on its source IP address. NETCONF/RESTCONF server based on its source IP address.
The next information a NETCONF/RESTCONF client learns is provided by The next information a NETCONF/RESTCONF client learns is provided by
the NETCONF/RESTCONF server in the form of a host-key or a the NETCONF/RESTCONF server in the form of a host-key or a
certificate, for the SSH and TLS protocols respectively. Without certificate, for the SSH and TLS protocols respectively. Without
examining the contents of the host-key or certificate, it is possible examining the contents of the host-key or certificate, it is possible
to form an identity for the NETCONF/RESTCONF server using it directly to form an identity for the NETCONF/RESTCONF server using it directly
(e.g., a fingerprint), since each NETCONF/RESTCONF server is assumed (e.g., a fingerprint). This works because each NETCONF/RESTCONF
to have a statistically unique public key, even in virtualized server is assumed to have a statistically unique public key, even in
environments. This strategy also provides a mechanism to verify the virtualized environments. This strategy also provides a mechanism to
NETCONF/RESTCONF server, in that a secure connection can only be verify the identity of the NETCONF/RESTCONF server, in that a secure
established with the NETCONF/RESTCONF server having the matching connection can only be established with the NETCONF/RESTCONF server
private key. This strategy is commonly implemented by SSH clients, having the matching private key. This strategy is commonly
and could be used equally well by TLS-based clients, such as may be implemented by SSH clients, and could be used equally well by TLS-
required when the NETCONF/RESTCONF servers have self-signed based clients, such as may be required when the NETCONF/RESTCONF
certificates. This strategy is viable and useful when the NETCONF/ servers have self-signed certificates. This strategy is viable and
RESTCONF servers call home using either SSH with standard RSA/DSA useful when the NETCONF/RESTCONF servers call home using either SSH
host-keys, or using TLS with self-signed certificates. with standard RSA/DSA host-keys, or using TLS with self-signed
certificates.
Yet another option for identifying a NETCONF/RESTCONF server is for Yet another option for identifying a NETCONF/RESTCONF server is for
its host key or certificate to encode its identity directly (e.g., its host key or certificate to encode its identity directly (e.g.,
within the "Subject" field). However, in order to trust the content within the "Subject" field). However, in order to trust the content
encoded within a host-key or certificate, it must be signed by a encoded within a host-key or certificate, it must be signed by a
certificate authority trusted by the NETCONF/RESTCONF client. This certificate authority trusted by the NETCONF/RESTCONF client. This
strategy's use of PKI enables a NETCONF/RESTCONF client to strategy's use of PKI enables a NETCONF/RESTCONF client to
transparently authenticate NETCONF/RESTCONF servers, thus eliminating transparently authenticate the NETCONF/RESTCONF server's certificate,
the need for manual authentication, as required by the previously thus eliminating the need for manual authentication, as required by
discussed strategies. Elimination of manual steps is needed to the previously discussed strategies. Elimination of manual steps is
achieve scalable solutions, however one can claim that this merely needed to achieve scalable solutions, however one can claim that this
pushes equivalent work to provisioning the NETCONF/RESTCONF servers merely pushes equivalent work to provisioning the NETCONF/RESTCONF
with signed credentials. This assessment is accurate in general, but servers with signed certificates. This assessment is accurate in
not in the case where the manufacturer itself provisions the general, but not in the case where the manufacturer itself provisions
credentials, such as is described by [Std-802.1AR-2009]. When the certificates, such as is described by [Std-802.1AR-2009]. When
NETCONF/RESTCONF servers are pre-provisioned this way, NETCONF/ NETCONF/RESTCONF servers are pre-provisioned this way, NETCONF/
RESTCONF clients can transparently authenticate NETCONF/RESTCONF RESTCONF clients can transparently authenticate NETCONF/RESTCONF
servers using just the manufacturer's trust anchor and a list of servers using just the manufacturer's trust anchor and a list of
expected NETCONF/RESTCONF server identifiers, which could be provided expected NETCONF/RESTCONF server identifiers, which could be provided
along with shipping information. This strategy is recommended for along with shipping information. This strategy is recommended for
all deployment scenarios. all deployment scenarios.
In discussing the use of certificates, it is worth noting that TLS In discussing the use of certificates, it is worth noting that TLS
uses X.509 certificates by default. However, to use X.509 uses X.509 certificates by default. However, to use X.509
certificates with SSH, both the NETCONF client and server must certificates with SSH, both the NETCONF client and server must
skipping to change at page 12, line 40 skipping to change at page 12, line 40
o Tried to improve readability (issue #6) o Tried to improve readability (issue #6)
o Removed "FIXME" in section 1.3 (issue #7) o Removed "FIXME" in section 1.3 (issue #7)
o Added RFC Editor notes (issue #8) o Added RFC Editor notes (issue #8)
o Removed "TCP session" term (issue #9) o Removed "TCP session" term (issue #9)
o Improved language for usage of IANA-assigned ports (issue #10) o Improved language for usage of IANA-assigned ports (issue #10)
A.4. 03 to 04
o Replaced "verify credentials" with "verify identity" (issue #11)
Appendix B. Open Issues Appendix B. Open Issues
All issues with this draft are tracked using GitHub issues. Please All issues with this draft are tracked using GitHub issues. Please
see: https://github.com/netconf-wg/call-home/issues to see currently see: https://github.com/netconf-wg/call-home/issues to see currently
opened issues. opened issues.
Author's Address Author's Address
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
 End of changes. 9 change blocks. 
31 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/