Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 9918 sn3rd
Updates: 7589 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 July 2026
RFC 7589 defines how to protect Network Configuration Protocol (NETCONF) messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data.
RFC 7589 では、TLS 1.2 を使用してネットワーク構成プロトコル (NETCONF) メッセージを保護する方法を定義しています。この文書は RFC 7589 を更新して、TLS 1.2 のサポート要件を更新し、TLS 1.3 の初期データの使用に関する制限を含む TLS 1.3 のサポート要件を追加します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9918.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9918 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions
3. Early Data
4. Cipher Suites
5. Security Considerations
6. IANA Considerations
7. Normative References
Acknowledgments
Authors' Addresses
[RFC7589] defines how to protect NETCONF messages [RFC6241] with TLS 1.2 [RFC5246]. This document updates [RFC7589] to update support requirements for TLS 1.2 [RFC5246] and add TLS 1.3 [RFC9846] support requirements, including restrictions on the use of TLS 1.3's early data, which is also known as 0-RTT data. It also updates "netconf-tls", the 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.
[RFC7589] は、TLS 1.2 [RFC5246] を使用して NETCONF メッセージ [RFC6241] を保護する方法を定義しています。この文書は、[RFC7589] を更新して、TLS 1.2 [RFC5246] のサポート要件を更新し、TLS 1.3 の初期データ (0-RTT データとも呼ばれる) の使用制限を含む TLS 1.3 [RFC9846] のサポート要件を追加します。また、このドキュメントを参照するために、IANA 登録ポート番号エントリである「netconf-tls」も更新されます。[RFC7589] に規定されている他のすべての規定 (接続の開始、メッセージ フレーミング、接続の終了、証明書の検証、サーバー ID、クライアント ID など) は変更されていません。
NOTE: Implementations that support TLS 1.3 [RFC9846] SHOULD also follow Sections 4 and 5 of [RFC7589].
注: TLS 1.3 [RFC9846] をサポートする実装は、[RFC7589] のセクション 4 および 5 にも従うべきです(SHOULD)。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3 [RFC9846] that allows a client to send data ("early data") as part of the first flight of messages to a server. Note that TLS 1.3 can be used without early data as per Appendix F.5 of [RFC9846]. In fact, early data is permitted by TLS 1.3 only when the client and server share a Pre-Shared Key (PSK), either obtained externally or via a previous handshake. The client uses the PSK to authenticate the server and to encrypt the early data.
初期データ (別名 0-RTT データ) は、TLS 1.3 [RFC9846] で定義されているメカニズムで、クライアントがサーバーへのメッセージの最初のフライトの一部としてデータ (「初期データ」) を送信できるようにします。[RFC9846] の付録 F.5 に従って、TLS 1.3 は初期データなしで使用できることに注意してください。実際、TLS 1.3 によって初期データが許可されるのは、クライアントとサーバーが、外部または以前のハンドシェイクによって取得された事前共有キー (PSK) を共有する場合に限られます。クライアントは PSK を使用してサーバーを認証し、初期データを暗号化します。
As noted in Section 2.3 of [RFC9846], 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 is no protection against the replay of early data between connections. Appendix F.5 of [RFC9846] requires applications not use early data without a profile that defines its use. This document specifies that NETCONF implementations that support TLS 1.3 or later MUST NOT use early data.
[RFC9846] のセクション 2.3 に記載されているように、初期のデータのセキュリティ特性は、その後の TLS で保護されたデータのセキュリティ特性よりも弱いです。特に、初期データは前方秘密ではないため、接続間での初期データの再生に対する保護はありません。[RFC9846] の付録 F.5 では、アプリケーションが初期データの用途を定義するプロファイルなしで初期データを使用しないよう要求しています。この文書では、TLS 1.3 以降をサポートする NETCONF 実装では初期データを使用してはならないと規定しています。
Implementations MUST support mutually authenticated TLS 1.2 [RFC5246], and they are, as specified in [RFC9325], recommended to support the cipher suites found in Section 4.2 of [RFC9325].
実装は相互認証された TLS 1.2 [RFC5246] をサポートしなければならず (MUST)、[RFC9325] で規定されているように、[RFC9325] のセクション 4.2 にある暗号スイートをサポートすることが推奨されています。
Implementations MAY implement additional TLS 1.2 cipher suites that provide mutual authentication [RFC5246] and confidentiality, as required by NETCONF [RFC6241].
実装では、NETCONF [RFC6241] で要求されているように、相互認証 [RFC5246] と機密性を提供する追加の TLS 1.2 暗号スイートを実装してもよい (MAY)。
Implementations SHOULD support mutually authenticated TLS 1.3 [RFC9846] and, if implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS.
実装は相互認証された TLS 1.3 [RFC9846] をサポートする必要があり (SHOULD)、実装されている場合は、以前のバージョンの TLS よりも TLS 1.3 のネゴシエーションを優先しなければなりません (MUST)。
Implementations that support TLS 1.3 [RFC9846] are REQUIRED to support the mandatory-to-implement cipher suites listed in Section 9.1 of [RFC9846].
TLS 1.3 [RFC9846] をサポートする実装は、[RFC9846] のセクション 9.1 にリストされている実装必須の暗号スイートをサポートする必要があります。
Implementations that support TLS 1.3 MAY implement additional TLS cipher suites that provide mutual authentication and confidentiality, which are required for NETCONF [RFC6241].
TLS 1.3 をサポートする実装では、NETCONF [RFC6241] に必要な相互認証と機密性を提供する追加の TLS 暗号スイートを実装してもよい(MAY)。
The security considerations of [RFC6241], [RFC7589], and [RFC9325] apply here as well.
[RFC6241]、[RFC7589]、および [RFC9325] のセキュリティに関する考慮事項がここにも適用されます。
NETCONF implementations SHOULD follow the TLS recommendations given in [RFC9325].
NETCONF 実装は、[RFC9325] で与えられている TLS 推奨事項に従う必要があります (SHOULD)。
For implementations that support TLS 1.3, the security considerations of TLS 1.3 [RFC9846] apply.
TLS 1.3 をサポートする実装には、TLS 1.3 [RFC9846] のセキュリティに関する考慮事項が適用されます。
As specified in [RFC7589], NETCONF over TLS requires mutual authentication.
[RFC7589] で規定されているように、TLS 上の NETCONF には相互認証が必要です。
For implementations that support TLS 1.3 [RFC9846]:
TLS 1.3 [RFC9846] をサポートする実装の場合:
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 incorrectly identified peer; see Section 7 of [RFC7589]. If deployments make use of a trusted 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.
TLS 1.3 相互認証は、許可されたユーザーおよびシステムのみが NETCONF サーバーの構成と状態を表示したり、NETCONF サーバーの構成を変更したりできるようにするために使用されます。このため、クライアントもサーバーも、未知のピア、予期しないピア、または誤って識別されたピアとの TLS 1.3 接続を介した NETCONF 接続を確立してはなりません。[RFC7589] のセクション 7 を参照してください。展開で認証局 (CA) 証明書の信頼できるリスト [RFC5280] を使用する場合、リストされた CA は、NETCONF サーバーへのアクセスを許可された当事者にのみ証明書を発行する必要があります。そうしないと、他の目的で発行された証明書が NETCONF サーバーによって不適切に受け入れられる可能性があります。
The security considerations of [RFC9525] apply to all implementations when the client checks the identity of the server, as is required in Section 6 of [RFC7589].
[RFC9525] のセキュリティに関する考慮事項は、[RFC7589] のセクション 6 で要求されているように、クライアントがサーバーの ID をチェックするときにすべての実装に適用されます。
IANA has added a reference to this document in the "netconf-tls" entry in the "Service Name and Transport Protocol Port Number Registry". The updated registry entry appears as follows:
IANA は、「サービス名およびトランスポート プロトコル ポート番号レジストリ」の「netconf-tls」エントリにこの文書への参照を追加しました。更新されたレジストリ エントリは次のように表示されます。
Service Name:
サービス名：
netconf-tls
netconf-tls
Port Number:
ポート番号:
6513
6513
Transport Protocol:
トランスポートプロトコル:
tcp
tcp
Description:
説明：
NETCONF over TLS
TLS 経由の NETCONF
Assignee:
譲受人:
IESG <iesg@ietf.org>
IESG <iesg@ietf.org>
Contact:
接触：
IETF Chair <chair@ietf.org>
IETF 議長 <chair@ietf.org>
Reference:
参照：
RFC 7589, RFC 9918
RFC 7589、RFC 9918
[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/info/rfc2119>.
[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/info/rfc5246>.
[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/info/rfc5280>.
[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/info/rfc6241>.
[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/info/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/info/rfc8174>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
We would like to thank Per Andersson, Jürgen Schönwälder, Jeff Hartley, Rob Wilton, and Qin Wu for their reviews.
レビューを寄せてくださった Per Andersson、Jürgen Schönwälder、Jeff Hartley、Rob Wilton、Qin Wu に感謝いたします。
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