RFC 7589 - Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7589
タイトル : RFC 7589 - NETCONF Protocol over Transport Layer Security（TLS）と相互X.509認証の使用
翻訳編集 : 自動生成

[要約] RFC 7589は、NETCONFプロトコルを相互X.509認証とTransport Layer Security（TLS）で使用するためのガイドラインです。このRFCの目的は、セキュアな通信を確保し、ネットワークデバイスの管理を強化することです。

Internet Engineering Task Force (IETF)                          M. Badra
Request for Comments: 7589                              Zayed University
Obsoletes: 5539                                                A. Luchuk
Category: Standards Track                            SNMP Research, Inc.
ISSN: 2070-1721                                         J. Schoenwaelder
                                                Jacobs University Bremen
                                                               June 2015

Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication

NETCONF Protocol over Transport Layer Security（TLS）と相互X.509認証の使用

Abstract

概要

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.

ネットワーク構成プロトコル（NETCONF）は、ネットワークデバイスの構成をインストール、操作、および削除するメカニズムを提供します。このドキュメントでは、相互X.509認証でトランスポート層セキュリティ（TLS）プロトコルを使用して、NETCONFメッセージの交換を保護する方法について説明します。 RFC 5539のこの改訂は、NETCONF 1.1で使用される新しいメッセージフレーミングを文書化し、RFC 5539を廃止します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7589.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7589で入手できます。

著作権表示

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Connection Initiation . . . . . . . . . . . . . . . . . . . .   3
   3.  Message Framing . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Connection Closure  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Certificate Validation  . . . . . . . . . . . . . . . . . . .   4
   6.  Server Identity . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Client Identity . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Appendix A.  Changes from RFC 5539  . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

The NETCONF protocol [RFC6241] defines a mechanism through which a network device can be managed. NETCONF is connection-oriented, requiring a persistent connection between peers. This connection must provide integrity, confidentiality, peer authentication, and reliable, sequenced data delivery.

NETCONFプロトコル[RFC6241]は、ネットワークデバイスを管理できるメカニズムを定義します。 NETCONFは接続指向であり、ピア間の永続的な接続を必要とします。この接続は、整合性、機密性、ピア認証、および信頼性の高い順序付けられたデータ配信を提供する必要があります。

This document defines how NETCONF messages can be exchanged over Transport Layer Security (TLS) [RFC5246]. Implementations MUST support mutual TLS certificate-based authentication [RFC5246]. This assures the NETCONF server of the identity of the principal who wishes to manipulate the management information. It also assures the NETCONF client of the identity of the server for which it wishes to manipulate the management information.

このドキュメントでは、NETCONFメッセージをトランスポート層セキュリティ（TLS）[RFC5246]で交換する方法を定義しています。実装は相互TLS証明書ベースの認証をサポートしなければなりません[RFC5246]。これにより、管理情報を操作するプリンシパルのIDがNETCONFサーバーに保証されます。また、管理情報を操作するサーバーのIDをNETCONFクライアントに保証します。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2. Connection Initiation

2. 接続開始

The peer acting as the NETCONF client MUST act as the TLS client. The TLS client actively opens the TLS connection and the TLS server passively listens for the incoming TLS connections. The well-known TCP port number 6513 is used by NETCONF servers to listen for TCP connections established by NETCONF over TLS clients. The TLS client MUST send the TLS ClientHello message to begin the TLS handshake. The TLS server MUST send a CertificateRequest in order to request a certificate from the TLS client. Once the TLS handshake has finished, the client and the server MAY begin to exchange NETCONF messages. Client and server identity verification is done before the NETCONF <hello> message is sent. This means that the identity verification is completed before the NETCONF session is started.

NETCONFクライアントとして機能するピアは、TLSクライアントとして機能する必要があります。 TLSクライアントはTLS接続をアクティブに開き、TLSサーバーは着信TLS接続をパッシブにリッスンします。既知のTCPポート番号6513は、NETCONFサーバーがTLSクライアント上のNETCONFによって確立されたTCP接続をリッスンするために使用されます。 TLSクライアントは、TLSハンドシェイクを開始するためにTLS ClientHelloメッセージを送信する必要があります。 TLSサーバーは、TLSクライアントから証明書を要求するために、CertificateRequestを送信する必要があります。 TLSハンドシェイクが完了すると、クライアントとサーバーはNETCONFメッセージの交換を開始する場合があります。クライアントとサーバーのID検証は、NETCONF <hello>メッセージが送信される前に行われます。これは、NETCONFセッションが開始される前にID検証が完了することを意味します。

3. Message Framing

3. メッセージのフレーミング

All NETCONF messages MUST be sent as TLS "application data". It is possible for multiple NETCONF messages to be contained in one TLS record, or for a NETCONF message to be transferred in multiple TLS records.

すべてのNETCONFメッセージは、TLS「アプリケーションデータ」として送信する必要があります。複数のNETCONFメッセージが1つのTLSレコードに含まれるか、NETCONFメッセージが複数のTLSレコードで転送される可能性があります。

The previous version of this specification [RFC5539] used the framing sequence defined in [RFC4742]. This version aligns with [RFC6242] and adopts the framing protocol defined in [RFC6242] as follows:

この仕様の以前のバージョン[RFC5539]は、[RFC4742]で定義されたフレーミングシーケンスを使用していました。このバージョンは[RFC6242]に対応し、[RFC6242]で定義されているフレーミングプロトコルを次のように採用しています。

The NETCONF <hello> message MUST be followed by the character sequence ]]>]]>. Upon reception of the <hello> message, the peers inspect the announced capabilities. If the :base:1.1 capability is advertised by both peers, the chunked framing mechanism defined in Section 4.2 of [RFC6242] is used for the remainder of the NETCONF session. Otherwise, the old end-of-message-based mechanism (see Section 4.3 of [RFC6242]) is used.

NETCONF <hello>メッセージの後には、文字シーケンス]]>]]>が続く必要があります。 <hello>メッセージを受信すると、ピアはアナウンスされた機能を検査します。：base：1.1機能が両方のピアによってアドバタイズされる場合、[RFC6242]のセクション4.2で定義されたチャンクフレーミングメカニズムが、NETCONFセッションの残りの部分で使用されます。それ以外の場合は、古いメッセージ終了ベースのメカニズム（[RFC6242]のセクション4.3を参照）が使用されます。

4. Connection Closure

4. 接続の閉鎖

A NETCONF server will process NETCONF messages from the NETCONF client in the order in which they are received. A NETCONF session is closed using the <close-session> operation. When the NETCONF server processes a <close-session> operation, the NETCONF server SHALL respond and close the TLS session as described in Section 7.2.1 of [RFC5246].

NETCONFサーバーは、NETCONFクライアントからのNETCONFメッセージを受信順に処理します。 NETCONFセッションは、<close-session>操作を使用して閉じられます。 [RFC5246]のセクション7.2.1で説明されているように、NETCONFサーバーが<close-session>操作を処理すると、NETCONFサーバーは応答し、TLSセッションを閉じる必要があります。

5. Certificate Validation

5. 証明書の検証

Both peers MUST use X.509 certificate path validation [RFC5280] to verify the integrity of the certificate presented by the peer. The presented X.509 certificate may also be considered valid if it matches one obtained by another trusted mechanism, such as using a locally configured certificate fingerprint. If X.509 certificate path validation fails and the presented X.509 certificate does not match a certificate obtained by a trusted mechanism, the connection MUST be terminated as defined in [RFC5246].

両方のピアは、X.509証明書パス検証[RFC5280]を使用して、ピアによって提示された証明書の整合性を検証する必要があります。提示されたX.509証明書は、ローカルに構成された証明書のフィンガープリントを使用するなど、別の信頼できるメカニズムによって取得されたものと一致する場合にも有効と見なされます。 X.509証明書パスの検証が失敗し、提示されたX.509証明書が信頼できるメカニズムによって取得された証明書と一致しない場合、[RFC5246]の定義に従って接続を終了する必要があります。

6. Server Identity

6. サーバーID

The NETCONF client MUST check the identity of the server according to Section 6 of [RFC6125].

NETCONFクライアントは、[RFC6125]のセクション6に従ってサーバーのIDを確認する必要があります。

7. Client Identity

7. クライアントID

The NETCONF server MUST verify the identity of the NETCONF client to ensure that the incoming request to establish a NETCONF session is legitimate before the NETCONF session is started.

NETCONFサーバーは、NETCONFセッションが開始される前に、NETCONFセッションを確立するための着信要求が正当であることを確認するために、NETCONFクライアントのIDを検証する必要があります。

The NETCONF protocol [RFC6241] requires that the transport protocol's authentication process results in an authenticated NETCONF client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The following algorithm is used by the NETCONF 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].)

NETCONFプロトコル[RFC6241]では、トランスポートプロトコルの認証プロセスの結果、認証されたNETCONFクライアントIDが得られ、そのアクセス許可がサーバーに認識されます。クライアントの認証済みIDは、一般にNETCONFユーザー名と呼ばれます。次のアルゴリズムは、NETCONFサーバーが証明書からNETCONFユーザー名を取得するために使用します。（以下のアルゴリズムは、[RFC6353]で定義されたSNMP-TLS-TM-MIB MIBモジュールおよび[RFC7407]で定義されたietf-x509-cert-to-name YANGモジュールで説明されているアルゴリズムと同じであることに注意してください。）

(a) The server maintains an ordered list of mappings of certificates to NETCONF usernames. Each list entry contains

（a）サーバーは、証明書からNETCONFユーザー名へのマッピングの順序付きリストを維持します。各リストエントリには

* a certificate fingerprint (used for matching the presented certificate),

* 証明書のフィンガープリント（提示された証明書の照合に使用）、

* a map type (indicates how the NETCONF username is derived from the certificate), and

* マップタイプ（NETCONFユーザー名が証明書からどのように導出されるかを示します）、および

* optional auxiliary data (used to carry a NETCONF username if the map type indicates the username is explicitly configured).

* オプションの補助データ（マップタイプがユーザー名が明示的に構成されていることを示す場合、NETCONFユーザー名を運ぶために使用されます）。

(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）NETCONFユーザー名は、各リストエントリを順番に検討することによって得られます。現在のリストエントリのフィンガープリントメンバーは、現在のリストエントリが一致するかどうかを決定します。

1. If the list entry's fingerprint value matches the fingerprint of the presented certificate, then consider the list entry as a successful match.

1. リストエントリのフィンガープリント値が提示された証明書のフィンガープリントと一致する場合、リストエントリは一致したと見なします。

2. If the list entry's fingerprint value matches that of a locally held copy of a trusted certification authority (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.

2. リストエントリのフィンガープリント値が信頼できる認証局（CA）証明書のローカルに保持されたコピーの値と一致し、そのCA証明書が提示された証明書へのCA証明書チェーンの一部であった場合、リストエントリは正常に一致したと見なします。

(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:

（c）一致するリストエントリが見つかったら、現在のリストエントリのマップタイプを使用して、証明書に関連付けられているユーザー名を決定する方法を決定します。可能なマッピングオプションは次のとおりです。

A. The username is taken from the auxiliary data of the current list entry. This means the username is explicitly configured (map type 'specified').

A.ユーザー名は、現在のリストエントリの補助データから取得されます。これは、ユーザー名が明示的に構成されていることを意味します（マップタイプ '指定'）。

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.

B. subjectAltNameのrfc822Nameフィールドはユーザー名にマップされます（マップタイプ 'san-rfc822-name'）。 rfc822Nameのローカル部分は変更されずに使用されますが、名前のホスト部分は小文字に変換する必要があります。

C. The subjectAltName's dNSName is mapped to the username (map type 'san-dns-name'). The characters of the dNSName are converted to lowercase.

C. subjectAltNameのdNSNameはユーザー名にマップされます（マップタイプ 'san-dns-name'）。 dNSNameの文字は小文字に変換されます。

D. The subjectAltName's iPAddress is mapped to the username (map type 'san-ip-address'). IPv4 addresses are converted into decimal-dotted quad notation (e.g., '192.0.2.1'). IPv6 addresses are converted into a 32-character all lowercase hexadecimal string without any colon separators.

D. subjectAltNameのiPAddressがユーザー名にマップされます（マップタイプ 'san-ip-address'）。 IPv4アドレスは、10進ドットのクワッド表記に変換されます（例： '192.0.2.1'）。 IPv6アドレスは、コロン区切り文字なしの32文字のすべて小文字の16進文字列に変換されます。

E. The rfc822Name, dNSName, or iPAddress of the subjectAltName 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.

E. subjectAltNameのrfc822Name、dNSName、またはiPAddressがユーザー名にマップされます（マップタイプ 'san-any'）。上記のタイプの証明書で見つかった最初に一致するsubjectAltName値は、名前を導出するときに使用する必要があります。

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.

F.証明書のCommonNameはユーザー名にマップされます（マップタイプ 'common-name'）。 CommonNameはUTF-8エンコーディングに変換されます。 CommonNamesの使用は推奨されておらず、代わりにsubjectAltNameマッピングメソッドを使用することをお勧めします。

(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 to look for another potential match. Similarly, if the username does not comply to the NETCONF requirements on usernames [RFC6241], then additional list entries MUST be searched to look for another potential match. If there are no further list entries, the TLS session MUST be terminated.

（d）証明書で提示されたデータと組み合わせたリストエントリのデータからユーザー名を特定することが不可能な場合は、別の潜在的な一致を探すために、追加のリストエントリを検索する必要があります。同様に、ユーザー名がユーザー名[RFC6241]のNETCONF要件に準拠していない場合は、別の潜在的な一致を探すために、追加のリストエントリを検索する必要があります。これ以上リストエントリがない場合は、TLSセッションを終了する必要があります。

The username provided by the NETCONF over TLS implementation will be made available to the NETCONF message layer as the NETCONF username without modification.

TLS実装のNETCONFによって提供されるユーザー名は、NETCONFメッセージレイヤーで変更なしのNETCONFユーザー名として使用できるようになります。

The NETCONF server configuration data model [NETCONF-RESTCONF] covers NETCONF over TLS and provides further details such as certificate fingerprint formats exposed to network configuration systems.

NETCONFサーバー構成データモデル[NETCONF-RESTCONF]は、TLSを介したNETCONFをカバーし、ネットワーク構成システムに公開される証明書フィンガープリント形式などの詳細を提供します。

8. Cipher Suites

8. 暗号スイート

Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the mandatory-to-implement cipher suite. Implementations MAY implement additional TLS cipher suites that provide mutual authentication [RFC5246] and confidentiality as required by NETCONF [RFC6241]. Implementations SHOULD follow the recommendations given in [RFC7525].

実装はTLS 1.2 [RFC5246]をサポートしなければならず（MUST）、実装に必須の暗号スイートをサポートする必要があります。実装は、相互認証[RFC5246]およびNETCONF [RFC6241]で要求される機密性を提供する追加のTLS暗号スイートを実装してもよい（MAY）。実装は[RFC7525]で与えられた推奨に従うべきです。

9. Security Considerations

9. セキュリティに関する考慮事項

NETCONF is used to access configuration and state information and to modify configuration information, so the ability to access this protocol should be limited to users and systems that are authorized to view the NETCONF server's configuration and state or to modify the NETCONF server's configuration.

NETCONFは、構成と状態の情報へのアクセスと構成情報の変更に使用されるため、このプロトコルにアクセスする機能は、NETCONFサーバーの構成と状態の表示、またはNETCONFサーバーの構成の変更を許可されているユーザーとシステムに限定する必要があります。

Configuration or state data may include sensitive information, such as usernames or security keys. So, NETCONF requires communications channels that provide strong encryption for data privacy. This document defines a NETCONF over TLS mapping that provides for support of strong encryption and authentication. The security considerations for TLS [RFC5246] and NETCONF [RFC6241] apply here as well.

構成または状態データには、ユーザー名やセキュリティキーなどの機密情報が含まれる場合があります。したがって、NETCONFには、データプライバシーのための強力な暗号化を提供する通信チャネルが必要です。このドキュメントでは、強力な暗号化と認証をサポートするNETCONF over TLSマッピングを定義しています。 TLS [RFC5246]およびNETCONF [RFC6241]のセキュリティに関する考慮事項は、ここでも適用されます。

NETCONF over TLS requires mutual authentication. Neither side should establish a NETCONF over TLS connection with an unknown, unexpected, or incorrect identity on the opposite side. Note that the decision whether a certificate presented by the client is accepted can depend on whether a trusted CA certificate is white listed (see Section 7). If deployments make use of this option, it is recommended that the white-listed CA certificate is used only to issue certificates that are used for accessing NETCONF servers. Should the CA certificate be used to issue certificates for other purposes, then all certificates created for other purposes will be accepted by a NETCONF server as well, which is likely not suitable.

NETCONF over TLSでは相互認証が必要です。どちらの側も、反対側で不明、予期しない、または正しくないIDを使用してNETCONF over TLS接続を確立しないでください。クライアントによって提示された証明書が受け入れられるかどうかの決定は、信頼できるCA証明書がホワイトリストに記載されているかどうかに依存する可能性があることに注意してください（セクション7を参照）。展開でこのオプションを使用する場合、ホワイトリストに記載されたCA証明書は、NETCONFサーバーへのアクセスに使用される証明書の発行にのみ使用することをお勧めします。 CA証明書を使用して他の目的で証明書を発行する場合、他の目的で作成されたすべての証明書はNETCONFサーバーでも受け入れられるため、適切ではない可能性があります。

This document does not support third-party authentication (e.g., backend Authentication, Authorization, and Accounting (AAA) servers) due to the fact that TLS does not specify this way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third-party authentication is needed, the Secure Shell (SSH) transport [RFC6242] can be used.

このドキュメントでは、TLSがこの認証方法を指定しておらず、NETCONFが認証サービスのトランスポートプロトコルに依存しているため、サードパーティ認証（バックエンドの認証、承認、アカウンティング（AAA）サーバーなど）はサポートされていません。サードパーティ認証が必要な場合は、Secure Shell（SSH）トランスポート[RFC6242]を使用できます。

RFC 5539 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. It is however believed that the associated threat is not very high. This document still uses the EOM sequence for the initial <hello> message to avoid incompatibility with existing implementations. When both peers implement the :base:1.1 capability, a proper framing protocol (chunked framing mechanism; see Section 3) is used for the rest of the NETCONF session, to avoid injection attacks.

RFC 5539は、メッセージの終わり（EOM）シーケンス]]>]]>が、整形式のXMLドキュメントに表示されないことを前提としています。 EOMシーケンスは、意図的にNETCONFメッセージで送信された場合、操作上の問題と攻撃用の空き領域を引き起こす可能性があります。ただし、関連する脅威はそれほど高くないと考えられています。このドキュメントでは、既存の実装との非互換性を回避するために、最初の<hello>メッセージにEOMシーケンスを引き続き使用しています。両方のピアが：base：1.1機能を実装している場合、インジェクション攻撃を回避するために、適切なフレーミングプロトコル（チャンクフレーミングメカニズム。セクション3を参照）が残りのNETCONFセッションに使用されます。

10. IANA Considerations

10. IANAに関する考慮事項

Per RFC 5539, IANA assigned TCP port number (6513) in the "Registered Port Numbers" range with the service name "netconf-tls". This port is the default port for NETCONF over TLS, as defined in Section 2. Below is the registration template following the rules in [RFC6335].

RFC 5539に従い、IANAは、サービス名が「netconf-tls」の「登録済みポート番号」の範囲でTCPポート番号（6513）を割り当てました。このポートは、セクション2で定義されているNETCONF over TLSのデフォルトポートです。以下は、[RFC6335]のルールに従う登録テンプレートです。

      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
      Port Number:            6513

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://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, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://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, <http://www.rfc-editor.org/info/rfc5280>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。

[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, <http://www.rfc-editor.org/info/rfc6125>.

[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。

[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, <http://www.rfc-editor.org/info/rfc6241>.

[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。

[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <http://www.rfc-editor.org/info/rfc6242>.

[RFC6242] Wasserman、M。、「Secure Shell（SSH）を介したNETCONFプロトコルの使用」、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<http://www.rfc-editor.org/info/rfc6242>。

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.

[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.

[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。

11.2. Informative References

11.2. 参考引用

[NETCONF-RESTCONF] Watsen, K. and J. Schoenwaelder, "NETCONF Server and RESTCONF Server Configuration Models", Work in Progress, draft-ietf-netconf-server-model-06, February 2015.

[NETCONF-RESTCONF] Watsen、K。およびJ. Schoenwaelder、「NETCONFサーバーおよびRESTCONFサーバー構成モデル」、作業中、draft-ietf-netconf-server-model-06、2015年2月。

[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, DOI 10.17487/RFC4742, December 2006, <http://www.rfc-editor.org/info/rfc4742>.

[RFC4742] Wasserman、M。、およびT. Goddard、「Secure Shell（SSH）でのNETCONF構成プロトコルの使用」、RFC 4742、DOI 10.17487 / RFC4742、2006年12月、<http://www.rfc-editor.org/ info / rfc4742>。

[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, DOI 10.17487/RFC5539, May 2009, <http://www.rfc-editor.org/info/rfc5539>.

[RFC5539] Badra、M。、「NETCONF over Transport Layer Security（TLS）」、RFC 5539、DOI 10.17487 / RFC5539、2009年5月、<http://www.rfc-editor.org/info/rfc5539>。

[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, <http://www.rfc-editor.org/info/rfc6353>.

[RFC6353] Hardaker、W。、「簡易ネットワーク管理プロトコル（SNMP）のトランスポート層セキュリティ（TLS）トランスポートモデル」、STD 78、RFC 6353、DOI 10.17487 / RFC6353、2011年7月、<http：//www.rfc -editor.org/info/rfc6353>。

[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, December 2014, <http://www.rfc-editor.org/info/rfc7407>.

[RFC7407] Bjorklund、M。、およびJ. Schoenwaelder、「SNMP構成用のYANGデータモデル」、RFC 7407、DOI 10.17487 / RFC7407、2014年12月、<http://www.rfc-editor.org/info/rfc7407> 。

Appendix A. Changes from RFC 5539

付録A. RFC 5539からの変更点

This section summarizes major changes between this document and RFC 5539.

このセクションでは、このドキュメントとRFC 5539の間の主な変更点をまとめています。

o Documented that NETCONF over TLS uses the new message framing if both peers support the :base:1.1 capability.

o 両方のピアが：base：1.1機能をサポートする場合、NETCONF over TLSが新しいメッセージフレーミングを使用することを文書化しました。

o Removed redundant text that can be found in the TLS and NETCONF specifications and restructured the text. Alignment with [RFC6125].

o TLSおよびNETCONF仕様にある冗長なテキストを削除し、テキストを再構成しました。 [RFC6125]との整合。

o Added a high-level description on how NETCONF usernames are derived from certificates.

o NETCONFユーザー名が証明書からどのように導出されるかについての高レベルの説明を追加しました。

o Removed the reference to BEEP.

o BEEPへの参照を削除しました。

Acknowledgements

謝辞

The authors like to acknowledge Martin Bjorklund, Olivier Coupelon, Pasi Eronen, Mehmet Ersue, Stephen Farrell, Miao Fuyou, Ibrahim Hajjeh, David Harrington, Sam Hartman, Alfred Hoenes, Simon Josefsson, Charlie Kaufman, Barry Leiba, Tom Petch, Tim Polk, Eric Rescorla, Dan Romascanu, Kent Watsen, Bert Wijnen, Stefan Winter, and the NETCONF mailing list members for their comments on this document.

著者は、マーティン・ビョークランド、オリビエ・クーペロン、パシ・エロネン、メフメット・エルスエ、スティーブン・ファレル、ミャオ・フヨウ、イブラヒム・ハジェ、デビッド・ハリントン、サム・ハートマン、アルフレッド・ホーネス、サイモン・ジョセフソン、チャーリー・カウフマン、バリー・レイバ、トム・ペッチ、ティム・ポルクを認めたいこのドキュメントに関するコメントについては、Eric Rescorla、Dan Romascanu、Kent Watsen、Bert Wijnen、Stefan Winter、およびNETCONFメーリングリストメンバー。

Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme.

Juergen Schoenwaelderは、その第7フレームワークプログラムの下で欧州委員会が支援するネットワークオブエクセレンスプロジェクト（ICT-318488）であるフラミンゴから資金提供を受けました。

Authors' Addresses

著者のアドレス

Mohamad Badra Zayed University P.O. Box 19282 Dubai, United Arab Emirates

Mohammad Bandra Zayed University P.O. Box 19272ドバイ、アラブ首長国連邦

   Phone: +971 4 4021879
   EMail: mohamad.badra@zu.ac.ae
   URI:   http://www.zu.ac.ae

Alan Luchuk SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920 United States

Alan Luchuk SNMP Research、Inc. 3001 Kimberlin Heights Road Knoxville、TN 37920 United States

   Phone: +1 865 573 1434
   EMail: luchuk@snmp.com
   URI:   http://www.snmp.com/

Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28759 Bremen Germany

Juergen Schoenwaelder Jacobs Universityブレーメンキャンパスリング1 28759ブレーメンドイツ

   Phone: +49 421 200 3587
   EMail: j.schoenwaelder@jacobs-university.de
   URI:   http://www.jacobs-university.de/