draft-ietf-netconf-rfc5539bis-08.txt   draft-ietf-netconf-rfc5539bis-09.txt 
NETCONF Working Group M. Badra NETCONF Working Group M. Badra
Internet-Draft Zayed University Internet-Draft Zayed University
Obsoletes: 5539 (if approved) A. Luchuk Obsoletes: 5539 (if approved) A. Luchuk
Intended status: Standards Track SNMP Research, Inc. Intended status: Standards Track SNMP Research, Inc.
Expires: July 31, 2015 J. Schoenwaelder Expires: August 16, 2015 J. Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
January 27, 2015 February 12, 2015
Using the NETCONF Protocol over Transport Layer Security (TLS) with Using the NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication Mutual X.509 Authentication
draft-ietf-netconf-rfc5539bis-08 draft-ietf-netconf-rfc5539bis-09
Abstract Abstract
The Network Configuration Protocol (NETCONF) provides mechanisms to The Network Configuration Protocol (NETCONF) provides mechanisms to
install, manipulate, and delete the configuration of network devices. install, manipulate, and delete the configuration of network devices.
This document describes how to use the Transport Layer Security (TLS) This document describes how to use the Transport Layer Security (TLS)
protocol with mutual X.509 authentication to secure the exchange of protocol with mutual X.509 authentication to secure the exchange of
NETCONF messages. This revision of RFC 5539 documents the new NETCONF messages. This revision of RFC 5539 documents the new
message framing used by NETCONF 1.1 and it obsoletes RFC 5539. message framing used by NETCONF 1.1 and it obsoletes RFC 5539.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 31, 2015. This Internet-Draft will expire on August 16, 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 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Connection Initiation . . . . . . . . . . . . . . . . . . . . 3 2. Connection Initiation . . . . . . . . . . . . . . . . . . . . 3
3. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 3 3. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 3
4. Connection Closure . . . . . . . . . . . . . . . . . . . . . 3 4. Connection Closure . . . . . . . . . . . . . . . . . . . . . 3
5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4 5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4
6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4 6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4
7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4 7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4
8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 8 Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 9
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9
B.1. draft-ietf-netconf-rfc5539bis-07 . . . . . . . . . . . . 8 B.1. draft-ietf-netconf-rfc5539bis-07 . . . . . . . . . . . . 9
B.2. draft-ietf-netconf-rfc5539bis-06 . . . . . . . . . . . . 9 B.2. draft-ietf-netconf-rfc5539bis-06 . . . . . . . . . . . . 9
B.3. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . 9 B.3. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . 10
B.4. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . 9 B.4. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . 10
B.5. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . 9 B.5. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . 10
B.6. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . 9 B.6. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . 10
B.7. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . 10 B.7. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The NETCONF protocol [RFC6241] defines a mechanism through which a The NETCONF protocol [RFC6241] defines a mechanism through which a
network device can be managed. NETCONF is connection-oriented, network device can be managed. NETCONF is connection-oriented,
requiring a persistent connection between peers. This connection requiring a persistent connection between peers. This connection
must provide integrity, confidentiality, peer authentication, and must provide integrity, confidentiality, peer authentication, and
reliable, sequenced data delivery. reliable, sequenced data delivery.
This document defines how NETCONF messages can be exchanged over This document defines how NETCONF messages can be exchanged over
skipping to change at page 4, line 31 skipping to change at page 4, line 31
The NETCONF server MUST verify the identity of the NETCONF client to The NETCONF server MUST verify the identity of the NETCONF client to
ensure that the incoming request to establish a NETCONF session is ensure that the incoming request to establish a NETCONF session is
legitimate before the NETCONF session is started. legitimate before the NETCONF session is started.
The NETCONF protocol [RFC6241] requires that the transport protocol's The NETCONF protocol [RFC6241] requires that the transport protocol's
authentication process results in an authenticated NETCONF client authentication process results in an authenticated NETCONF client
identity whose permissions are known to the server. The identity whose permissions are known to the server. The
authenticated identity of a client is commonly referred to as the authenticated identity of a client is commonly referred to as the
NETCONF username. The following algorithm is used by the NETCONF NETCONF username. The following algorithm is used by the NETCONF
server to derive a NETCONF username from a certificate: server to derive a NETCONF username from a certificate. (Note that
the algorithm below is the same as the one described in the SNMP-TLS-
TM-MIB MIB module defined in [RFC6353] and in the ietf-x509-cert-to-
name YANG module defined in [RFC7407].)
o The server maintains an ordered list of mappings of certificates (a) The server maintains an ordered list of mappings of certificates
to NETCONF usernames. The username is derived by considering each to NETCONF usernames. Each list entry contains
list entry in order. The fingerprint member of a list entry
determines whether the list entry is a match:
1. If the list entry's fingerprint value matches that of the * a certificate fingerprint (used for matching the presented
presented certificate, then consider the list entry as a certificate),
successful match.
2. If the list entry's fingerprint value matches that of a * a map type (indicates how the NETCONF username is derived
locally held copy of a trusted CA certificate, and that CA from the certificate), and
certificate was part of the CA certificate chain to the
presented certificate, then consider the list entry as a
successful match.
o Once a matching list entry has been found, the mapping type * optional auxiliary data (used to carry a NETCONF username if
property of the list entry is used to determine how the username the map type indicates the user name is explicitly
associated with the certificate should be determined. Possible configured).
mapping options are:
A. The username is explicitly configured. (b) The NETCONF username is derived by considering each list entry
in order. The fingerprint member of the current list entry
determines whether the current list entry is a match:
B. The subjectAltName's rfc822Name is mapped to a username. 1. If the list entry's fingerprint value matches the
fingerprint of the presented certificate, then consider the
list entry as a successful match.
C. The subjectAltName's dNSName is mapped to a username. 2. If the list entry's fingerprint value matches that of a
locally held copy of a trusted CA certificate, and that CA
certificate was part of the CA certificate chain to the
presented certificate, then consider the list entry as a
successful match.
D. The subjectAltName's iPAddress is mapped to a username. (c) Once a matching list entry has been found, the map type of the
current list entry is used to determine how the username
associated with the certificate should be determined. Possible
mapping options are:
E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress is A. The username is taken from the auxiliary data of the current
mapped to a username. list entry. This means the username is explicitely
configured (map type 'specified').
F. The certificate's CommonName is mapped to a username. B. The subjectAltName's rfc822Name field is mapped to the
username (map type 'san-rfc822-name'). The local part of
the rfc822Name is used unaltered but the host-part of the
name must be converted to lowercase.
o If it is impossible to determine a username from the list entry's C. The subjectAltName's dNSName is mapped to the username (map
data combined with the data presented in the certificate, then type 'san-dns-name'). The characters of the dNSName are
additional list entries MUST be searched looking for another converted to lowercase.
potential match. Similarily, if the username does not comply to
the NETCONF requirements on usernames [RFC6241] (i.e., the D. The subjectAltName's iPAddress is mapped to the username
username is not representable in XML), then additional list (map type 'san-ip-address'). IPv4 addresses are converted
entries MUST be searched looking for another potential match. If into decimal-dotted quad notation (e.g., '192.0.2.1'). IPv6
there are no further list entries, the TLS session MUST be addresses are converted into a 32-character all lowercase
terminated. hexadecimal string without any colon separators.
E. Any of the subjectAltName's rfc822Name, dNSName, iPAddress
is mapped to the username (map type 'san-any'). The first
matching subjectAltName value found in the certificate of
the above types MUST be used when deriving the name.
F. The certificate's CommonName is mapped to the username (map
type 'common-name'). The CommonName is converted to UTF-8
encoding. The usage of CommonNames is deprecated and users
are encouraged to use subjectAltName mapping methods
instead.
(d) If it is impossible to determine a username from the list
entry's data combined with the data presented in the
certificate, then additional list entries MUST be searched
looking for another potential match. Similarily, if the
username does not comply to the NETCONF requirements on
usernames [RFC6241] (i.e., the username is not representable in
XML), then additional list entries MUST be searched looking for
another potential match. If there are no further list entries,
the TLS session MUST be terminated.
The username provided by the NETCONF over TLS implementation will be The username provided by the NETCONF over TLS implementation will be
made available to the NETCONF message layer as the NETCONF username made available to the NETCONF message layer as the NETCONF username
without modification. without modification.
8. Cipher Suites 8. Cipher Suites
Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
support the mandatory-to-implement cipher suite. Implementations MAY support the mandatory-to-implement cipher suite. Implementations MAY
implement additional TLS cipher suites that provide mutual implement additional TLS cipher suites that provide mutual
skipping to change at page 7, line 20 skipping to change at page 8, line 4
Kent Watsen, Bert Wijnen and the NETCONF mailing list members for Kent Watsen, Bert Wijnen and the NETCONF mailing list members for
their comments on this document. Charlie Kaufman, Pasi Eronen, and their comments on this document. Charlie Kaufman, Pasi Eronen, and
Tim Polk provided a thorough review of previous versions of this Tim Polk provided a thorough review of previous versions of this
document. document.
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Juergen Schoenwaelder was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission Excellence project (ICT-318488) supported by the European Commission
under its Seventh Framework Programme. under its Seventh Framework Programme.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-uta-tls-bcp] [I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre, Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft- "Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-08 (work in progress), December 2014. ietf-uta-tls-bcp-09 (work in progress), February 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
skipping to change at page 8, line 20 skipping to change at page 9, line 5
12.2. Informative References 12.2. Informative References
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure SHell (SSH)", RFC 4742, Configuration Protocol over Secure SHell (SSH)", RFC 4742,
December 2006. December 2006.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
RFC 5539, May 2009. RFC 5539, May 2009.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 6353, July 2011.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, December 2014.
Appendix A. Changes from RFC 5539 Appendix A. Changes from RFC 5539
This section summarizes major changes between this document and RFC This section summarizes major changes between this document and RFC
5539. 5539.
o Documented that NETCONF over TLS uses the new message framing if o Documented that NETCONF over TLS uses the new message framing if
both peers support the :base:1.1 capability. both peers support the :base:1.1 capability.
o Removed redundant text that can be found in the TLS and NETCONF o Removed redundant text that can be found in the TLS and NETCONF
specifications and restructured the text. Alignment with specifications and restructured the text. Alignment with
 End of changes. 23 change blocks. 
52 lines changed or deleted 90 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/