Internet DRAFT - draft-turner-netconf-over-tls13
draft-turner-netconf-over-tls13
Network Configuration S. Turner
Internet-Draft sn3rd
Intended status: Standards Track R. Housley
Expires: 19 December 2022 Vigil Security
17 June 2022
NETCONF over TLS 1.3
draft-turner-netconf-over-tls13-00
Abstract
RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This
document describes how to protect NETCONF messages with TLS 1.3.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Network Configuration
Working Group mailing list (netconf@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/netconf/.
Source for this draft and an issue tracker can be found at
https://github.com/seanturner/netconf-over-tls13.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://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 19 December 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Turner & Housley Expires 19 December 2022 [Page 1]
Internet-Draft NETCONF over TLS 1.3 June 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
3. Early Data . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
[RFC7589] defines how to protect NETCONF messages [RFC6241] with TLS
1.2 [RFC5246]. This document describes defines how to protect
NETCONF messages with TLS 1.3 [I-D.ietf-tls-rfc8446bis].
This document addresses cipher suites and the use of early data,
which is also known as 0-RTT data. It also updates the "netconf-tls"
IANA Registered Port Number entry to refer to this document. All
other provisions set forth in [RFC7589] are unchanged, including
connection initiation, message framing, connection closure,
certificate validation, server identity, and client identity.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Turner & Housley Expires 19 December 2022 [Page 2]
Internet-Draft NETCONF over TLS 1.3 June 2022
3. Early Data
Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3
[I-D.ietf-tls-rfc8446bis] that allows a client to send data ("early
data") as part of the first flight of messages to a server. Early
data is permitted by TLS 1.3 when the client and server share a PSK,
either obtained externally or via a previous handshake. The client
uses the PSK to authenticate the server and to encrypt the early
data.
As noted in Section 2.3 of [I-D.ietf-tls-rfc8446bis], the security
properties for early data are weaker than those for subsequent TLS-
protected data. In particular, early data is not forward secret, and
there are no protection against the replay of early data between
connections. Appendix E.5 of [I-D.ietf-tls-rfc8446bis] requires
applicaitons not use early data without a profile that defines its
use. This document specifies that implementations MUST NOT use early
data.
4. Cipher Suites
Implementations MUST support TLS 1.3 [I-D.ietf-tls-rfc8446bis], and
implementation are REQUIRED to support the mandatory-to-implement
cipher suites listed in Section 9.1 of [I-D.ietf-tls-rfc8446bis].
Implementations MAY implement additional TLS cipher suites that
provide mutual authentication and confidentiality, which are required
for NETCONF [RFC6241].
Implementations SHOULD follow the recommendations given in
[I-D.ietf-uta-rfc7525bis].
So, this is what {{Section 9.1 of I-D.ietf-tls-rfc8446bis}} says:
A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
[GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
[GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see
Appendix B.4).
A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A
TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
Is there any reason to narrow the algorithm choices?
My guess is not. These ought to be available in all TLS libraries.
Turner & Housley Expires 19 December 2022 [Page 3]
Internet-Draft NETCONF over TLS 1.3 June 2022
5. Security Considerations
Please review the Security Considerations in TLS 1.3
[I-D.ietf-tls-rfc8446bis].
Please review the recommendations regarding Diffie-Hellman exponent
reuse in Section 7.4 of [I-D.ietf-uta-rfc7525bis].
Please review the Security Considerations in NETCONF [RFC6241].
NETCONF is used to access configuration and state information and to
modify configuration information. TLS 1.3 mutual authentication is
used to ensure that only authorized users and systems are able to
view the NETCONF server's configuration and state or to modify the
NETCONF server's configuration. To this end, neither the client nor
the server should establish a NETCONF over TLS 1.3 connection with an
unknown, unexpected, or incorrect peer identity; see Section 7 of
[RFC7589]. If deployments make use of this list of Certification
Authority (CA) certificates [RFC5280], then the listed CAs should
only issue certificates to parties that are authorized to access the
NETCONF servers. Doing otherwise will allow certificates that were
issued for other purposes to be inappropriately accepted by a NETCONF
server.
Please review [RFC6125] for further details on generic host name
validation in the TLS context.
Please review the recommendations regarding certificate revocation
checking in Section 7.5 of [I-D.ietf-uta-rfc7525bis].
[RFC5539] assumes that the end-of-message (EOM) sequence, ]]>]]>,
cannot appear in any well-formed XML document, which turned out to be
mistaken. The EOM sequence can cause operational problems and open
space for attacks if sent deliberately in NETCONF messages. While it
is possible, the likelihood is believed to be very low. The EOM
sequence is used for the initial <hello> message to avoid
incompatibility with existing implementations. When the client and
server both implement the :base:1.1 capability, a proper framing
protocol (see Section 3 of [RFC7589]) is used for the rest of the
NETCONF session, to avoid injection attacks.
6. IANA Considerations
IANA is requested to add a reference to this document in the
"netconf-tls" entry in the "Registered Port Numbers". The updated
registry entry would appear as follows:
Turner & Housley Expires 19 December 2022 [Page 4]
Internet-Draft NETCONF over TLS 1.3 June 2022
Service Name: netconf-tls
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: NETCONF over TLS
Reference: RFC 7589, [THIS RFC]
Port Number: 6513
7. References
7.1. Normative References
[I-D.ietf-tls-rfc8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-04, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-04>.
[I-D.ietf-uta-rfc7525bis]
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", Work in Progress, Internet-Draft, draft-ietf-uta-
rfc7525bis-07, 26 May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-uta-
rfc7525bis-07>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
RFC 5539, DOI 10.17487/RFC5539, May 2009,
<https://www.rfc-editor.org/rfc/rfc5539>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
Turner & Housley Expires 19 December 2022 [Page 5]
Internet-Draft NETCONF over TLS 1.3 June 2022
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/rfc/rfc7589>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
7.2. Informative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/rfc/rfc6125>.
Acknowledgments
We would like to thank the following people TBD.
Authors' Addresses
Sean Turner
sn3rd
Email: sean@sn3rd.com
Russ Housley
Vigil Security, LLC
516 Dranesville Road
Herndon, VA, 20170
United States of America
Email: housley@vigilsec.com
Turner & Housley Expires 19 December 2022 [Page 6]
