[要約] RFC 7869は、VNC URIスキームの仕様を定義しており、VNCクライアントへの統一的なアクセス方法を提供します。このRFCの目的は、VNCセッションの開始や制御を簡素化し、ユーザーエクスペリエンスを向上させることです。
Independent Submission D. Warden
Request for Comments: 7869 Dell Products LP
Category: Informational I. Iordanov
ISSN: 2070-1721 Undatech
May 2016
The "vnc" URI Scheme
「vnc」URIスキーム
Abstract
概要
Virtual Network Computing (VNC) software provides remote desktop functionality. This document describes a Uniform Resource Identifier (URI) scheme enabling the launch of VNC clients from other applications. The scheme specifies parameters useful in securely connecting clients with remote hosts.
Virtual Network Computing（VNC）ソフトウェアは、リモートデスクトップ機能を提供します。このドキュメントでは、他のアプリケーションからVNCクライアントを起動できるようにするURI（Uniform Resource Identifier）スキームについて説明します。このスキームは、クライアントをリモートホストに安全に接続するのに役立つパラメータを指定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7869.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7869で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. The "vnc" URI Scheme ............................................3
2.1. URI Scheme Syntax ..........................................3
2.1.1. URI Parameters ......................................4
2.1.2. Data Types ..........................................9
2.2. Processing URIs ...........................................11
2.2.1. Error Handling .....................................12
2.2.2. Connection Profile Matching ........................12
2.3. Connection Channel Types ..................................12
2.3.1. The "Integrated SSH" Channel Type ..................12
2.3.2. The "Secure Tunnel" Channel Type ...................14
3. Security Considerations ........................................15
3.1. Application Trust .........................................16
3.2. URI Handling ..............................................16
3.3. Host Identification .......................................17
3.4. Connection Database Integrity .............................18
4. IANA Considerations ............................................18
4.1. "vnc" Scheme ..............................................18
4.2. Remote Framebuffer Security Types .........................18
4.3. VNC URI Group .............................................19
4.4. VNC URI Connection Channel Types ..........................19
4.5. VNC URI ID Hash Algorithms ................................19
4.6. VNC URI Parameters ........................................21
5. References .....................................................22
5.1. Normative References ......................................22
5.2. Informative References ....................................23
Appendix A. "vnc" URI Template ....................................24
Acknowledgments ...................................................25
Authors' Addresses ................................................25
Virtual Network Computing (VNC) clients are used to support remote desktop connectivity based on the Remote Framebuffer (RFB) Protocol [RFC6143]. It is often desirable to integrate such functionality with other software. However, the lack of a standard method for specifying VNC client parameters has limited such integration.
仮想ネットワークコンピューティング（VNC）クライアントは、リモートフレームバッファ（RFB）プロトコル[RFC6143]に基づくリモートデスクトップ接続をサポートするために使用されます。そのような機能を他のソフトウェアと統合することがしばしば望ましい。ただし、VNCクライアントパラメータを指定する標準的な方法がないため、このような統合は制限されています。
The "vnc" Uniform Resource Identifier (URI) scheme specified in this document facilitates the launch of VNC clients from applications in browser-based, desktop, and mobile environments. Using this scheme, users and application vendors will be able to integrate remote desktop capabilities without being tied to a particular client.
このドキュメントで指定されている "vnc" URI（Uniform Resource Identifier）スキームは、ブラウザベース、デスクトップ、およびモバイル環境のアプリケーションからVNCクライアントを起動しやすくします。このスキームを使用すると、ユーザーとアプリケーションベンダーは、特定のクライアントに縛られることなく、リモートデスクトップ機能を統合できます。
Remote desktop clients often store connection profiles in a local connection database. By associating connections specified in a URI with those stored in a database, client-specific options can be automatically applied to a connection launched from another application, even when that application is unaware of those options.
リモートデスクトップクライアントは、多くの場合、接続プロファイルをローカル接続データベースに格納します。 URIで指定された接続をデータベースに保存された接続に関連付けることにより、クライアント固有のオプションは、そのアプリケーションがそれらのオプションを認識していない場合でも、別のアプリケーションから起動された接続に自動的に適用できます。
Connections to VNC servers are often secured using mechanisms including Transport Layer Security / Secure Sockets Layer (TLS/SSL) tunneling [RFC5246] and Secure Shell (SSH) [RFC4251] tunneling, which are outside the scope of the RFB protocol. Defining the behavior of these client-integrated security options enables their use with "vnc" URIs.
VNCサーバーへの接続は、RFBプロトコルの範囲外であるトランスポート層セキュリティ/ Secure Sockets Layer（TLS / SSL）トンネリング[RFC5246]およびセキュアシェル（SSH）[RFC4251]トンネリングなどのメカニズムを使用して保護されることがよくあります。これらのクライアント統合セキュリティオプションの動作を定義すると、「vnc」URIでの使用が可能になります。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying the significance described in RFC 2119.
このドキュメントでは、これらの単語はすべて大文字の場合にのみその解釈で表示されます。これらの単語の小文字の使用は、RFC 2119に記載されている重要性を持つと解釈されるべきではありません。
The normative syntax of the "vnc" URI is defined in the <vnc-uri> rule in the following syntax specification. This specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. The "vnc" URI conforms to the generic URI syntax specified in [RFC3986]. The <userinfo>, <host>, <port>, <unreserved>, and <pct-encoded> rules are defined in [RFC3986].
"vnc" URIの標準構文は、次の構文仕様の<vnc-uri>ルールで定義されています。この仕様では、[RFC5234]で説明されているようにAugmented Backus-Naur Form（ABNF）を使用します。 「vnc」URIは、[RFC3986]で指定されている一般的なURI構文に準拠しています。 <userinfo>、<host>、<port>、<unreserved>、および<pct-encoded>ルールは、[RFC3986]で定義されています。
vnc-uri = "vnc://" [ userinfo "@" ] [ host [ ":" port ] ]
[ "?" [ vnc-params ] ]
vnc-params = param "=" value *("&" param "=" value) ["&"]
param = 1*( param-char )
value = *( param-char )
param-char = unreserved / pct-encoded / unreserved-symbols
unreserved-symbols = ":" / "/" / "@" / "!" / "$" / "'"
/ "(" / ")" / "*" / "," / ";"
The "?", "=", and "&" characters are used to delimit VNC parameters and must be percent-encoded when representing a data octet as specified in [RFC3986]. Within the <vnc-params> portion of a "vnc" URI, the <unreserved-symbols> do not have special meaning and need not be percent-encoded when representing a data octet.
「？」、「=」、「＆」の文字はVNCパラメータを区切るために使用され、[RFC3986]で指定されているようにデータオクテットを表す場合はパーセントエンコードする必要があります。 「vnc」URIの<vnc-params>部分内では、<unreserved-symbols>に特別な意味はなく、データオクテットを表すときにパーセントエンコードする必要はありません。
A "vnc" URI has the general form:
「vnc」URIの一般的な形式は次のとおりです。
vnc://host:port?param1=value1¶m2=value2...
vnc：// host：port？param1 = value1＆param2 = value2 ...
The host information and each parameter value specify information used in establishing or operating the remote desktop session as specified in Section 2.1.1.
ホスト情報と各パラメータ値は、セクション2.1.1で指定されているリモートデスクトップセッションの確立または操作で使用される情報を指定します。
For example:
例えば：
vnc://10.0.0.1:5901?VncPassword=secret&SecurityType=2
This example indicates a VNC connection to the host at IP "10.0.0.1" on port "5901" with VNC password "secret" using the VNC Authentication security type.
この例は、VNC認証セキュリティタイプを使用して、VNCパスワード「シークレット」でポート「5901」上のIP「10.0.0.1」にあるホストへのVNC接続を示しています。
A description of host information and URI parameters is provided in this section. Information on the constraints of various data types is provided in Section 2.1.2. All parameters are considered optional; however, a client will not be able to connect without sufficient information.
このセクションでは、ホスト情報とURIパラメーターについて説明します。さまざまなデータ型の制約に関する情報は、セクション2.1.2に記載されています。すべてのパラメーターはオプションと見なされます。ただし、クライアントは十分な情報がないと接続できません。
A parameter without a specified default value indicates that no default value is implied by this URI scheme; however, VNC clients can apply implementation-dependent default behaviors otherwise consistent with this document.
デフォルト値が指定されていないパラメータは、デフォルト値がこのURIスキームによって暗示されていないことを示します。ただし、VNCクライアントは実装に依存するデフォルトの動作を適用できますが、それ以外の場合はこのドキュメントと一致します。
The <userinfo> value is deprecated and processed only in an implementation-specific manner. The <userinfo> component MUST NOT be generated in an environment where a client supporting an updated URI format is expected to be available. When processing a URI value from an untrusted source, VNC clients SHOULD alert the user in order to mitigate the risk that the URI is constructed to obscure the identity of the remote host unless the URI can be validated or backwards-compatibility considerations make an alert impractical.
<userinfo>値は非推奨になり、実装固有の方法でのみ処理されます。 <userinfo>コンポーネントは、更新されたURI形式をサポートするクライアントが利用可能であることが期待される環境で生成してはなりません（MUST NOT）。信頼できないソースからのURI値を処理する場合、VNCクライアントは、URIを検証できないか、下位互換性の考慮によりアラートを非実用的にできない限り、リモートホストのIDを隠すためにURIが構築されるリスクを軽減するために、ユーザーに警告する必要があります（SHOULD）。 。
The <host> and <port> values in the "vnc" URI specify the address of the VNC server on the remote host:
"vnc" URIの<host>および<port>値は、リモートホスト上のVNCサーバーのアドレスを指定します。
+------------+------------+-----------------------------+----------+
| Name | Type | Description | Default |
+------------+------------+-----------------------------+----------+
| host | string | VNC server hostname or IP | none |
+------------+------------+-----------------------------+----------+
| port | ushort | VNC server port | 5900 |
+------------+------------+-----------------------------+----------+
The "vnc" URI parameter values specify remote desktop connection or
session properties, including aspects of client operation, usability,
and security as specified in the table below:
+---------------+---------+-----------------------------+----------+
| Name | Type | Description | Default |
+---------------+---------+-----------------------------+----------+
|ConnectionName | string | Name of connection profile | none |
+---------------+---------+-----------------------------+----------+
|VncUsername | string | VNC server username | none |
+---------------+---------+-----------------------------+----------+
|VncPassword | string | VNC server password | none |
+---------------+---------+-----------------------------+----------+
|SecurityType | enum | RFB security type used | none |
| | <rfbsec>| | |
+---------------+---------+-----------------------------+----------+
|ChannelType | enum | Connection channel type | none |
| | <chan> | | |
+---------------+---------+-----------------------------+----------+
|SshHost | string | SSH server hostname or IP | <host> |
+---------------+---------+-----------------------------+----------+
|SshPort | ushort | SSH server port | 22 |
+---------------+---------+-----------------------------+----------+
|SshUsername | string | SSH username | none |
+---------------+---------+-----------------------------+----------+
|SshPassword | string | SSH password | none |
+---------------+---------+-----------------------------+----------+
|IdHashAlgorithm| enum | Hash algorithm used with | none |
| | <idhash>| "IdHash" parameter | |
+---------------+---------+-----------------------------+----------+
|IdHash | string | Expected hash of remote | none |
| | <hex> | public key or certificate | |
+---------------+---------+-----------------------------+----------+
|ColorLevel | enum | Client color depth/mode | none |
| | <clevel>| | |
+---------------+---------+-----------------------------+----------+
|ViewOnly | boolean | Client is view only | false |
+---------------+---------+-----------------------------+----------+
|SaveConnection | boolean | Store connection info | none |
+---------------+---------+-----------------------------+----------+
o ConnectionName, SaveConnection
o ConnectionName、SaveConnection
"ConnectionName" is used to identify a connection profile in both the launching application and VNC client. Profiles are applied as described in Section 2.2.2. If omitted, the client MAY generate a name based on the host, port, and/or other parameters. The VNC client MAY normalize the name as required.
「ConnectionName」は、起動中のアプリケーションとVNCクライアントの両方で接続プロファイルを識別するために使用されます。プロファイルは、セクション2.2.2の説明に従って適用されます。省略した場合、クライアントはホスト、ポート、および/または他のパラメーターに基づいて名前を生成する場合があります。 VNCクライアントは、必要に応じて名前を正規化できます（MAY）。
If true, "SaveConnection" indicates a connection profile should be created or updated and stored in the client connection database. If false, no profile should be updated or persisted.
trueの場合、「SaveConnection」は、接続プロファイルを作成または更新して、クライアント接続データベースに保存する必要があることを示します。 falseの場合、プロファイルを更新または永続化する必要はありません。
o VncUsername, VncPassword, SecurityType
o VncUsername、VncPassword、SecurityType
The "SecurityType" parameter indicates which RFB security type applies to the connection. RFB security types are recorded in the IANA "Remote Framebuffer Security Types" registry created by [RFC6143]. The VNC client will use this information to determine which parameters are required and establish the connection.
「SecurityType」パラメータは、接続に適用されるRFBセキュリティタイプを示します。 RFBセキュリティタイプは、[RFC6143]によって作成されたIANA "Remote Framebuffer Security Types"レジストリに記録されます。 VNCクライアントはこの情報を使用して、必要なパラメーターを判別し、接続を確立します。
VNC clients can sometimes automatically negotiate a security type with a server. Specifying the security type controls the security negotiation. Specifying the security type also allows a client to prompt for necessary security parameters prior to establishing a connection. Parameters may take time to enter on mobile clients and could otherwise result in timeouts and/or security lockouts. If the specified type is not supported by the server, an error SHOULD be indicated as described in Section 2.2.1.
VNCクライアントは、サーバーとセキュリティタイプを自動的にネゴシエートする場合があります。セキュリティタイプを指定すると、セキュリティネゴシエーションが制御されます。セキュリティタイプを指定すると、クライアントは接続を確立する前に必要なセキュリティパラメータを要求することもできます。パラメータはモバイルクライアントに入力するのに時間がかかる場合があり、そうしないとタイムアウトやセキュリティロックアウトが発生する可能性があります。指定されたタイプがサーバーでサポートされていない場合、セクション2.2.1で説明されているようにエラーが表示されるべきです（SHOULD）。
"VncUsername" and "VncPassword" are used when applicable to authenticate to the VNC server using the specified "SecurityType". Since passwords often contain arbitrary characters, they will often require percent encoding.
「VncUsername」と「VncPassword」は、指定された「SecurityType」を使用してVNCサーバーへの認証に適用できる場合に使用されます。多くの場合、パスワードには任意の文字が含まれているため、パーセントエンコードが必要になります。
o ChannelType
o ChannelType
"ChannelType" specifies the transport stream used to carry connection data. This allows a client to initiate a connection using a secure transport protocol such as SSH prior to connecting to the VNC server socket. Use of this value in the context of the "Integrated SSH" and "Secure Tunnel" channel types is provided in Section 2.3.
「ChannelType」は、接続データの伝送に使用されるトランスポートストリームを指定します。これにより、クライアントは、VNCサーバーソケットに接続する前に、SSHなどのセキュアなトランスポートプロトコルを使用して接続を開始できます。 「統合SSH」および「セキュアトンネル」チャネルタイプのコンテキストでのこの値の使用については、セクション2.3で説明しています。
o SshHost, SshPort, SshUsername, SshPassword
o Sshホスト、Sshポート、Sshユーザー名、Sshパスワード
The SSH parameters are intended for use with the "Integrated SSH" channel type described in Section 2.3.1. These parameters can also be used with any future SSH-based channel types. Since passwords often contain arbitrary characters, they will often require percent encoding.
SSHパラメータは、セクション2.3.1で説明されている「統合SSH」チャネルタイプでの使用を目的としています。これらのパラメーターは、将来のSSHベースのチャネルタイプでも使用できます。多くの場合、パスワードには任意の文字が含まれているため、パーセントエンコードが必要になります。
o IdHashAlgorithm, IdHash
o IdHashAlgorithm、IdHash
The "IdHashAlgorithm" and "IdHash" values are used to verify the expected identity of the remote system based on its public key or certificate. Use of these values in the context of the "Integrated SSH" and "Secure Tunnel" channel types is provided in Section 2.3.
「IdHashAlgorithm」および「IdHash」の値は、公開鍵または証明書に基づいて、リモートシステムの予想されるIDを確認するために使用されます。 「統合SSH」および「セキュアトンネル」チャネルタイプのコンテキストでのこれらの値の使用については、セクション2.3で説明しています。
o ColorLevel
o ColorLevel
The "ColorLevel" parameter specifies the color model to use for data transfer and display as specified in Section 2.1.2. If the requested color model is unsupported, the behavior is implementation dependent.
「ColorLevel」パラメータは、セクション2.1.2で指定されているように、データ転送と表示に使用するカラーモデルを指定します。要求されたカラーモデルがサポートされていない場合、動作は実装に依存します。
o ViewOnly
o 表示のみ
If "ViewOnly" is true, the VNC client SHOULD operate in a display-only mode and refrain from sending input data including KeyEvent, PointerEvent, and ClientCutText messages specified in Section 7.5 of [RFC6143] unless this mode is unsupported by the client.
「ViewOnly」がtrueの場合、VNCクライアントは表示専用モードで動作する必要があり（SHOULD）、このモードがクライアントでサポートされていない場合を除き、[RFC6143]のセクション7.5で指定されたKeyEvent、PointerEvent、ClientCutTextメッセージを含む入力データを送信しないでください。
Parameter names SHOULD be provided in the case specified in this document; however, for compatibility, clients SHOULD accept parameters in a case-insensitive manner. Values SHALL be interpreted in a case-sensitive manner, unless otherwise noted.
このドキュメントで指定されているケースでは、パラメータ名を提供する必要があります。ただし、互換性のために、クライアントは大文字と小文字を区別しない方法でパラメータを受け入れる必要があります。特に明記されていない限り、値は大文字と小文字を区別して解釈されるものとします（SHALL）。
Additional parameters likely to be useful with multiple VNC clients can be added to the "VNC URI Parameters" registry as specified in Section 4.6 of this document. Individual clients MAY support parameters specific to that client. VNC clients supporting application-specific parameters SHOULD include a distinguishing prefix within the parameter name, such as the name of the application package specified in source code except when precluded by compatibility constraints. For example:
このドキュメントのセクション4.6で指定されているように、複数のVNCクライアントで役立つと思われる追加のパラメーターを「VNC URIパラメーター」レジストリに追加できます。個々のクライアントは、そのクライアントに固有のパラメーターをサポートする場合があります。アプリケーション固有のパラメーターをサポートするVNCクライアントは、互換性の制約によって除外されている場合を除き、ソースコードで指定されたアプリケーションパッケージの名前など、パラメーター名内に識別プレフィックスを含める必要があります（SHOULD）。例えば：
vnc://?com.dell.vncclient.ScreenMode=2&
It can also be expected that clients will maintain backward compatibility with legacy URI formats and parameters.
また、クライアントがレガシーURI形式およびパラメーターとの下位互換性を維持することも期待できます。
Legacy software applications respond to "vnc" URIs in different ways and may fail to behave as expected. It is advisable to test "vnc" URIs with specific applications or consult application-specific documentation.
レガシーソフトウェアアプリケーションは「vnc」URIにさまざまな方法で応答し、期待どおりに動作しない場合があります。特定のアプリケーションで「vnc」URIをテストするか、アプリケーション固有のドキュメントを参照することをお勧めします。
"vnc" URIs can be percent-encoded as specified in [RFC3986] and MUST be decoded. After decoding, the following type constraints and semantics apply:
「vnc」URIは、[RFC3986]で指定されているようにパーセントエンコードでき、デコードする必要があります。デコード後、次のタイプ制約とセマンティクスが適用されます。
o string
o ストリング
Values of "string" type are UTF-encoded strings as specified in [RFC3629].
「string」タイプの値は、[RFC3629]で指定されているように、UTFエンコードされた文字列です。
The "string<hex>" subtype used in the "IdHash" consists of colon-delimited ":" octets displayed in hexadecimal. For example:
「IdHash」で使用される「string <hex>」サブタイプは、16進数で表示されるコロン区切りの「：」オクテットで構成されます。例えば：
5D:D2:39:57
Comparison of "string<hex>" values SHALL be case insensitive; however, the uppercase notation is preferred for readability.
"string <hex>"値の比較では、大文字と小文字を区別しないものとします。ただし、読みやすくするために大文字表記が推奨されます。
o enum
o 列挙型
The "enum" types consist of specific enumerated subtypes and are represented by their decimal value.
「列挙型」タイプは、特定の列挙型サブタイプで構成され、10進数値で表されます。
The "enum<rfbsec>" values represent an RFB security type included in the IANA "Remote Framebuffer Security Types" registry created by [RFC6143].
"enum <rfbsec>"の値は、[RFC6143]によって作成されたIANA "Remote Framebuffer Security Types"レジストリに含まれるRFBセキュリティタイプを表します。
"enum<chan>" values represent connection channel types listed in the "VNC URI Connection Channel Types" registry created by Section 4.4 of this document. Initial values are:
「enum <chan>」値は、このドキュメントのセクション4.4で作成された「VNC URI接続チャネルタイプ」レジストリにリストされている接続チャネルタイプを表します。初期値は次のとおりです。
Value Description
-------- --------------
1 Standard TCP
23 Secure Tunnel
24 Integrated SSH
The "Standard TCP" channel type represents a generic TCP connection. The "Secure Tunnel" and "Integrated SSH" [RFC4252] channel types are described in Section 2.3.
「標準TCP」チャネルタイプは、一般的なTCP接続を表します。 「セキュアトンネル」および「統合SSH」[RFC4252]チャネルタイプについては、セクション2.3で説明しています。
Values of the "enum<idhash>" parameter represent secure hash algorithms in the "VNC URI Hash Algorithms" registry created by Section 4.5 of this document. The initial values include:
"enum <idhash>"パラメータの値は、このドキュメントのセクション4.5で作成された "VNC URI Hash Algorithms"レジストリの安全なハッシュアルゴリズムを表します。初期値は次のとおりです。
Value Description
-------- ------------
1 MD5
2 SHA1
4 SHA256
The MD5 algorithm is described in [RFC1321]. The SHA-1 and SHA-256 algorithms are described in [SHS].
MD5アルゴリズムは[RFC1321]で説明されています。 SHA-1およびSHA-256アルゴリズムは[SHS]で説明されています。
Values of the "enum<clevel>" subtype represent a color level. In the table below, the columns have the meaning specified in Section 7.4 of [RFC6143]:
「enum <clevel>」サブタイプの値は、カラーレベルを表します。下の表では、列は[RFC6143]のセクション7.4で指定された意味を持っています。
BPP = bits-per-pixel TC = true-color-flag RM = red-max GM = green-max BM = blue-max RS = red-shift GS = green-shift BS = blue-shift
BPP =ビット/ピクセルTC =トゥルーカラーフラグRM =赤最大GM =緑最大BM =青最大RS =赤シフトGS =緑シフトBS =青シフト
The values are:
値は次のとおりです。
Value Description BPP Depth TC RM GM BM RS GS BS
----- --------------- --- ----- -- ---- ---- ---- -- -- --
1 Black and White 8 3 t 1 1 1 2 1 0
2 Grayscale 8 6 t 3 3 3 4 2 0
3 8 Colors 8 3 t 1 1 1 2 1 0
4 64 Colors 8 6 t 3 3 3 4 2 0
5 256 Colors 8 8 t 7 7 3 0 3 6
6 16-bit Color 16 16 t 31 63 31 11 5 0
7 24-bit Color 32 24 t 255 255 255 16 8 0
8 30-bit Color 32 30 t 1023 1023 1023 0 10 20
A value of "t" indicates the true-color-flag should be set. The big-endian-flag (see Section 7.4 of [RFC6143]) should be set as required for the system.
値「t」は、トゥルーカラーフラグを設定する必要があることを示します。 big-endian-flag（[RFC6143]のセクション7.4を参照）は、システムの必要に応じて設定する必要があります。
o ushort
o ushort
The "ushort" values represent unsigned 16-bit integers expressed in decimal digits with value between 0-65535 inclusive.
「ushort」の値は、0から65535までの値を含む10進数で表される符号なし16ビット整数を表します。
o boolean
o ブール値
"boolean" values represent conditions that are true or false and are represented as either "true" or "false" respectively. For maximum compatibility, clients SHOULD accept the value 1 as representing true values and 0 as representing false values. Clients SHOULD perform parsing of "boolean" values in a case-insensitive manner.
「ブール」値は、trueまたはfalseである条件を表し、それぞれ「true」または「false」として表されます。最大の互換性のために、クライアントは真の値を表すものとして値1を受け入れ、偽の値を表すものとして0を受け入れる必要があります。クライアントは、大文字と小文字を区別しない方法で「ブール」値の解析を実行する必要があります（SHOULD）。
An example "vnc" URI including several of these data types is:
これらのデータ型のいくつかを含む「vnc」URIの例は次のとおりです。
vnc://localhost:5900?ConnectionName=Server&SecurityType=2&
IdHash=0D:3A:72:08:57:EA:4D:30&SaveConnection=false&
Note the above example should be considered to be a contiguous string without line breaks or whitespace and is broken into multiple lines in this document for readability.
上記の例は、改行や空白のない連続した文字列であると見なされ、読みやすくするためにこのドキュメントでは複数の行に分割されていることに注意してください。
Conceptually, a "vnc" URI supports only a "VIEW" operation, indicating the user wishes to view the remote desktop accessible via the URI reference.
概念的には、「vnc」URIは「VIEW」操作のみをサポートし、ユーザーがURI参照を介してアクセス可能なリモートデスクトップを表示したいことを示します。
In general, when a VNC client receives a "vnc" URI, it will initiate a remote desktop connection with the RFB protocol using the specified host information and parameter values. Initiating the connection using a connection channel mechanism such as those specified in Section 2.3 might require processing prior to establishing the RFB connection. A client MAY attempt to automatically discover or negotiate appropriate connection channel, security, or other parameter values.
一般に、VNCクライアントが「vnc」URIを受信すると、指定されたホスト情報とパラメーター値を使用して、RFBプロトコルとのリモートデスクトップ接続を開始します。セクション2.3で指定されているような接続チャネルメカニズムを使用して接続を開始するには、RFB接続を確立する前に処理が必要になる場合があります。クライアントは、適切な接続チャネル、セキュリティ、またはその他のパラメータ値を自動的に検出またはネゴシエートしようとする場合があります（MAY）。
The process for negotiating security types is specified in [RFC6143]. Supported connection channels could be discovered by testing channel types to detect when a channel is successfully established. To best integrate with other applications, the VNC client SHOULD initiate the connection with minimal or no user intervention, whenever sufficient information is available and adequate security is preserved.
セキュリティタイプをネゴシエートするプロセスは、[RFC6143]で指定されています。サポートされている接続チャネルは、チャネルが正常に確立されたことを検出するためにチャネルタイプをテストすることによって検出できます。他のアプリケーションと最適に統合するために、VNCクライアントは、十分な情報が利用可能で適切なセキュリティが保持されている場合は常に、ユーザーの介入を最小限またはまったく行わずに接続を開始する必要があります（SHOULD）。
Host information and parameter values may be provided through connection profiles. When a parameter value is not available from either a URI or a connection profile described in Section 2.2.2, the default value specified in Section 2.1.1 SHOULD be applied. If available parameters are not sufficient to establish a connection, the VNC client SHOULD present a session initiation data-entry screen.
ホスト情報とパラメータ値は、接続プロファイルを通じて提供される場合があります。セクション2.2.2で説明されているURIまたは接続プロファイルのいずれかからパラメーター値を使用できない場合は、セクション2.1.1で指定されているデフォルト値を適用する必要があります（SHOULD）。利用可能なパラメータが接続を確立するのに十分でない場合、VNCクライアントはセッション開始データ入力画面を提示する必要があります（SHOULD）。
In a typical interactive environment, if an error prevents a session from being established, the VNC client presents an error message to the user. When the message is acknowledged, the console application can show a session initiation data-entry screen populated with available session parameters, or it can terminate. If an error occurs after a session is successfully established that terminates the connection, the VNC client presents a termination notification to the user. When the termination notification is acknowledged, the client can present a reconnection prompt or terminate.
典型的なインタラクティブ環境では、エラーが原因でセッションを確立できない場合、VNCクライアントはユーザーにエラーメッセージを表示します。メッセージが確認されると、コンソールアプリケーションは、使用可能なセッションパラメータが入力されたセッション開始データ入力画面を表示したり、終了したりできます。接続が終了するセッションが正常に確立された後にエラーが発生した場合、VNCクライアントは終了通知をユーザーに提示します。終了通知が確認されると、クライアントは再接続プロンプトを表示するか、終了できます。
When an error occurs in a dedicated environment (such as a kiosk system), the system can transmit an alert to the remote operator, record a log entry, and execute appropriate fallback behavior such as automatically attempting to reestablish a session or displaying a generic message requesting servicing.
専用環境（キオスクシステムなど）でエラーが発生した場合、システムはアラートをリモートオペレーターに送信し、ログエントリを記録し、セッションの再確立の自動試行や一般的なメッセージの表示など、適切なフォールバック動作を実行できます。サービスをリクエストしています。
VNC clients MAY store remote desktop session settings in connection profiles. If the client is able to uniquely identify and associate a connection request with a connection profile based on the "ConnectionName" parameter value, remote host IP address, or hostname / fully qualified domain name, the VNC client SHOULD apply profile values for those settings that do not have values supplied in the "vnc" URI. When profile data is unavailable, the VNC client MAY apply global application defaults for settings not supplied in the URI and for which the scheme does not specify a default value. The VNC client MUST NOT override supplied parameters with profile values or global defaults.
VNCクライアントは、リモートデスクトップセッション設定を接続プロファイルに保存してもよい（MAY）。クライアントが「ConnectionName」パラメーター値、リモートホストIPアドレス、またはホスト名/完全修飾ドメイン名に基づいて接続要求を一意に識別して関連付けることができる場合、VNCクライアントは、これらの設定にプロファイル値を適用する必要があります（SHOULD）。 「vnc」URIに値が指定されていない。プロファイルデータが利用できない場合、VNCクライアントは、URIで提供されておらず、スキームがデフォルト値を指定していない設定に対して、グローバルアプリケーションのデフォルトを適用してもよい（MAY）。 VNCクライアントは、提供されたパラメーターをプロファイル値またはグローバルデフォルトで上書きしてはなりません（MUST NOT）。
When the "SaveConnection" parameter value is true, within the VNC client, a connection profile SHOULD be created or updated with the values supplied in the "vnc" URI. Profile updates and storage should be consistent with the recommendations in Section 3.4.
「SaveConnection」パラメーター値がtrueの場合、VNCクライアント内で、「vnc」URIで指定された値で接続プロファイルを作成または更新する必要があります（SHOULD）。プロファイルの更新と保存は、セクション3.4の推奨事項と一致している必要があります。
The "Integrated SSH" channel type establishes an SSH connection to a host, authenticates with SSH password authentication, establishes a secure tunnel to the VNC host/port, and then connects to the VNC server using a supported "SecurityType". The secure tunnel will provide encryption and data integrity, while verifying the public key authenticates the server. The SSH architecture is specified in [RFC4251]. The steps are detailed below: 1. The VNC client initiates a transport-level connection to the "SshHost" on the "SshPort" specified in the parameter values with a key exchange as described in [RFC4253].
「統合SSH」チャネルタイプは、ホストへのSSH接続を確立し、SSHパスワード認証で認証し、VNCホスト/ポートへの安全なトンネルを確立し、サポートされている「SecurityType」を使用してVNCサーバーに接続します。安全なトンネルは、暗号化とデータの整合性を提供し、公開鍵がサーバーを認証することを確認します。 SSHアーキテクチャは[RFC4251]で指定されています。手順の詳細は以下のとおりです。1. VNCクライアントは、[RFC4253]で説明されているように、キー交換を使用してパラメーター値で指定された「SshPort」上の「SshHost」へのトランスポートレベルの接続を開始します。
2. When the VNC client receives the server key (or certificate), the hash of the key (or certificate) is computed using the algorithm corresponding to the "IdHashAlgorithm" parameter value and compared with the expected "IdHash" value (if available). If the certificate hash cannot be verified, the client alerts the user or operator. In a typical interactive environment, the alert provides the remote system's identifying information including the hash value and allows the user to terminate the connection. The alert could allow the user to accept the key and continue establishing the connection. In a dedicated environment (such as a kiosk system), the system can transmit an alert to the remote operator, record a log entry, and execute appropriate fallback behavior such as displaying a generic message requesting servicing.
2. VNCクライアントがサーバーキー（または証明書）を受信すると、キー（または証明書）のハッシュが「IdHashAlgorithm」パラメーター値に対応するアルゴリズムを使用して計算され、予想される「IdHash」値（利用可能な場合）と比較されます。証明書のハッシュを検証できない場合、クライアントはユーザーまたはオペレーターに警告します。典型的なインタラクティブ環境では、アラートは、ハッシュ値を含むリモートシステムの識別情報を提供し、ユーザーが接続を終了できるようにします。アラートにより、ユーザーはキーを受け入れ、接続の確立を続行できます。専用環境（キオスクシステムなど）では、システムはアラートをリモートオペレーターに送信し、ログエントリを記録し、サービスを要求する一般的なメッセージを表示するなどの適切なフォールバック動作を実行できます。
3. The SSH client authenticates the user using the "SshUsername" and "SshPassword" parameter values according to the "password" authentication mechanism described in [RFC4252].
3. SSHクライアントは、[RFC4252]で説明されている「パスワード」認証メカニズムに従って、「SshUsername」および「SshPassword」パラメータ値を使用してユーザーを認証します。
4. The SSH client opens a TCP/IP channel as specified in [RFC4254] from the local system to the system indicated by the <host> and <port> information values.
4. SSHクライアントは、[RFC4254]で指定されているTCP / IPチャネルを、ローカルシステムから<host>および<port>情報値で示されるシステムに開きます。
5. The VNC client establishes an RFB connection to the VNC server over the channel and authenticates using the "SecurityType" as described in [RFC6143] or other reference.
5. VNCクライアントは、チャネルを介してVNCサーバーへのRFB接続を確立し、[RFC6143]またはその他のリファレンスで説明されている「SecurityType」を使用して認証します。
The VNC client MAY establish the connection described in this section using an external SSH client, by launching the client and then connecting to a secure tunnel created between a local port and the VNC server.
VNCクライアントは、クライアントを起動し、ローカルポートとVNCサーバーの間に作成された安全なトンネルに接続することにより、外部SSHクライアントを使用して、このセクションで説明する接続を確立できます（MAY）。
If the VNC client is supplied with additional parameters outside the scope of this document, it MAY perform a variation of these steps consistent with the underlying protocols, for example, by using "publickey" SSH client authentication [RFC4252] or providing another form of authentication to the VNC server. The specific negotiation of SSH parameters such as cipher suite configuration is outside the scope of this document.
VNCクライアントにこのドキュメントの範囲外の追加のパラメーターが提供されている場合、たとえば、「publickey」SSHクライアント認証[RFC4252]を使用したり、別の形式の認証を提供したりして、基礎となるプロトコルと一致するこれらの手順のバリエーションを実行できます（MAY） VNCサーバーに。暗号スイート設定などのSSHパラメータの特定のネゴシエーションは、このドキュメントの範囲外です。
Many SSH clients present key hashes using MD5, and it can be expected that launching applications will specify the hash be displayed in the manner its users are familiar with.
多くのSSHクライアントはMD5を使用してキーハッシュを提示します。アプリケーションを起動すると、ユーザーが使い慣れた方法でハッシュを表示するように指定できます。
For compatibility, when the "SecurityType" parameter value is "Integrated SSH" (24), a VNC client MUST treat the value as a request to use "Integrated SSH" as the "ChannelType". However, this value SHOULD NOT be supplied for the "SecurityType" parameter unless required for backward compatibility as the channel is established prior to connecting to the server and is not consistent with the negotiation of other security types.
互換性のために、「SecurityType」パラメーター値が「Integrated SSH」（24）の場合、VNCクライアントはその値を「Integrated SSH」を「ChannelType」として使用するための要求として扱う必要があります。ただし、サーバーに接続する前にチャネルが確立され、他のセキュリティタイプのネゴシエーションと一致しないため、下位互換性のために必要でない限り、この値は「SecurityType」パラメータに指定しないでください。
The "Secure Tunnel" channel type establishes a TLS connection with a remote server using certificate authentication, over which a connection to the VNC server is established using a supported "SecurityType". The secure tunnel will provide encryption and data integrity, while verifying the certificate authenticates the server. The TLS protocol is specified in [RFC5246]. The steps are detailed below:
「Secure Tunnel」チャネルタイプは、証明書認証を使用してリモートサーバーとのTLS接続を確立し、サポートされる「SecurityType」を使用してVNCサーバーへの接続が確立されます。安全なトンネルは、証明書がサーバーを認証していることを確認しながら、暗号化とデータの整合性を提供します。 TLSプロトコルは[RFC5246]で指定されています。手順の詳細は以下のとおりです。
1. The VNC client initiates the TLS Handshake Protocol with a system indicated by the <host> and <port> information values.
1. VNCクライアントは、<host>および<port>情報値で示されるシステムでTLSハンドシェイクプロトコルを開始します。
2. When the server certificate is received, the hash of the key certificate is computed using the algorithm corresponding to the "IdHashAlgorithm" parameter value and compared with the expected "IdHash" value (if available). If the certificate hash cannot be verified, the client alerts the user or operator. In a typical interactive environment, the alert provides the remote system's identifying information and allows the user to terminate the connection. The alert could allow the user to accept the key and continue establishing the connection. In a dedicated environment (such as a kiosk system), the system can transmit an alert to the remote operator, record a log entry, and execute appropriate fallback behavior such as displaying a generic message requesting servicing.
2. サーバー証明書を受信すると、「IdHashAlgorithm」パラメーター値に対応するアルゴリズムを使用してキー証明書のハッシュが計算され、予想される「IdHash」値（利用可能な場合）と比較されます。証明書のハッシュを検証できない場合、クライアントはユーザーまたはオペレーターに警告します。典型的なインタラクティブ環境では、アラートはリモートシステムの識別情報を提供し、ユーザーが接続を終了できるようにします。アラートにより、ユーザーはキーを受け入れ、接続の確立を続行できます。専用環境（キオスクシステムなど）では、システムはアラートをリモートオペレーターに送信し、ログエントリを記録し、サービスを要求する一般的なメッセージを表示するなどの適切なフォールバック動作を実行できます。
When providing identifying information of a host identified by an X.509 certificate [RFC5280] [X.509], the certificate subject, issuer, validity period, and certificate hash is typically included. The VNC client MAY verify the validity of the certificate. If the validity of a certificate is not confirmed, the alert includes a statement indicating such information has not been verified.
X.509証明書[RFC5280] [X.509]によって識別されるホストの識別情報を提供する場合、証明書のサブジェクト、発行者、有効期間、および証明書ハッシュが通常含まれます。 VNCクライアントは、証明書の有効性を検証してもよい（MAY）。証明書の有効性が確認されない場合、アラートにはそのような情報が検証されていないことを示すステートメントが含まれます。
3. The client finishes establishing the TLS tunnel.
3. クライアントはTLSトンネルの確立を完了します。
4. The VNC client establishes an RFB connection to the VNC server over the channel and authenticates using the "SecurityType" as described in [RFC6143] or other reference.
4. VNCクライアントは、チャネルを介してVNCサーバーへのRFB接続を確立し、[RFC6143]またはその他のリファレンスで説明されている「SecurityType」を使用して認証します。
If the VNC client is supplied with additional parameters, it MAY perform a variation of these steps consistent with the underlying protocols, for example, by providing another form of authentication to the VNC server. The negotiation of specific TLS parameters such as cipher suite configuration is outside the scope of this document.
VNCクライアントに追加のパラメーターが提供されている場合、たとえば、VNCサーバーに別の形式の認証を提供することにより、基礎となるプロトコルと一致するこれらの手順のバリエーションを実行できます（MAY）。暗号スイート設定などの特定のTLSパラメータのネゴシエーションは、このドキュメントの範囲外です。
The TLS protocol provides backwards compatibility with SSLv3; however, due to known security flaws, it SHOULD NOT be used.
TLSプロトコルは、SSLv3との下位互換性を提供します。ただし、既知のセキュリティ上の欠陥があるため、使用しないでください。
For compatibility, when the "SecurityType" parameter value is "Secure Tunnel" (23), a VNC client MUST treat the value as a request to use "Secure Tunnel" as the "ChannelType". However, this value SHOULD NOT be supplied for the "SecurityType" parameter unless required for backward compatibility as the channel must be established prior to connecting to the server and is not consistent with the negotiation of other security types.
互換性のために、「SecurityType」パラメーター値が「Secure Tunnel」（23）である場合、VNCクライアントはその値を「Secure Tunnel」を「ChannelType」として使用する要求として扱う必要があります。ただし、サーバーに接続する前にチャネルを確立する必要があり、他のセキュリティタイプのネゴシエーションと一致しないため、下位互換性のために必要でない限り、この値は「SecurityType」パラメータに指定しないでください。
General security concerns involving URI schemes are discussed in [RFC3986]. In implementing support for the "vnc" URI scheme, areas for particular consideration include application trust, URI handling, host identification, and connection database security.
URIスキームを含む一般的なセキュリティ問題は[RFC3986]で議論されています。 「vnc」URIスキームのサポートを実装する際に特に考慮すべき領域には、アプリケーションの信頼、URIの処理、ホストの識別、および接続データベースのセキュリティが含まれます。
Remote desktop connectivity requires the transmission of security credentials, which could be included in a URI. If those credentials are not kept secure, an attacker can gain access to any systems using those credentials. Host addresses and connection parameters might also be considered sensitive, as such information can be used in planning an attack.
リモートデスクトップ接続では、セキュリティ資格情報を送信する必要があります。これは、URIに含めることができます。これらの資格情報が安全に保たれていない場合、攻撃者はそれらの資格情報を使用してすべてのシステムにアクセスできます。ホストアドレスと接続パラメーターも攻撃の計画に使用できるため、機密情報と見なされる場合があります。
URIs can also contain host identification information. It is important to securely identify the remote host system to which a connection is established. If a user connects to an attacker's system, user data, including credentials, can be exposed.
URIには、ホスト識別情報を含めることもできます。接続が確立されるリモートホストシステムを安全に識別することが重要です。ユーザーが攻撃者のシステムに接続すると、資格情報を含むユーザーデータが公開される可能性があります。
Note that the RFB protocol itself may not encrypt data. To protect data in transit, RFB should be tunneled over TLS [RFC5246], SSH [RFC4251], or another secure protocol.
RFBプロトコル自体はデータを暗号化しない場合があることに注意してください。転送中のデータを保護するには、RFBをTLS [RFC5246]、SSH [RFC4251]、または別の安全なプロトコルでトンネリングする必要があります。
Some VNC systems can be used without authentication. To protect the remote host, strong passwords or other authentication mechanisms need to be used.
一部のVNCシステムは、認証なしで使用できます。リモートホストを保護するには、強力なパスワードまたはその他の認証メカニズムを使用する必要があります。
A malicious application receiving VNC credentials via URI or other means can obviously misuse those credentials. To protect against this, users should only install applications from trusted sources. The integrity of application packages can be verified through digital signatures.
URIやその他の手段でVNC資格情報を受け取る悪意のあるアプリケーションは、明らかにこれらの資格情報を悪用する可能性があります。これを防ぐには、ユーザーは信頼できるソースからのアプリケーションのみをインストールする必要があります。アプリケーションパッケージの整合性は、デジタル署名を通じて確認できます。
Applications launching VNC clients can elect to launch only particular trusted clients and can specify those clients through platform-specific mechanisms. Package integrity can be verified programmatically by querying the package manager for digital signatures or other platform-specific means.
VNCクライアントを起動するアプリケーションは、特定の信頼できるクライアントのみを起動することを選択でき、プラットフォーム固有のメカニズムを介してそれらのクライアントを指定できます。パッケージの整合性は、デジタル署名または他のプラットフォーム固有の手段についてパッケージマネージャーにクエリを実行することにより、プログラムで検証できます。
The risk to a VNC client from a launching application is generally much lower, since the launching application will not receive credentials or data from the client. A VNC client can verify its caller thorough platform-specific means.
起動中のアプリケーションはクライアントから資格情報やデータを受信しないため、起動中のアプリケーションからVNCクライアントへのリスクは通常はるかに低くなります。 VNCクライアントは、プラットフォーム固有の手段を使用して発信者を確認できます。
VNC clients ought not to accept potentially destructive parameters from untrusted launching applications without explicit user confirmation. For example, a client-specific parameter that runs an arbitrary command upon establishing an SSH connection used for VNC tunneling is potentially destructive and high risk.
VNCクライアントは、ユーザーの明示的な確認なしに、信頼できない起動アプリケーションからの潜在的に破壊的なパラメーターを受け入れるべきではありません。たとえば、VNCトンネリングに使用されるSSH接続の確立時に任意のコマンドを実行するクライアント固有のパラメーターは、破壊的でリスクが高い可能性があります。
Within a mobile or desktop environment, application launch will typically involve in-memory URI data transmission facilitated and secured by the operating system.
モバイルまたはデスクトップ環境内では、アプリケーションの起動には通常、オペレーティングシステムによって促進および保護されたメモリ内URIデータ送信が含まれます。
When "vnc" URIs are exchanged or used within a system, their contents might be exposed by process listings or other instrumentation. Users need to avoid including sensitive information in "vnc" URIs that could be exposed to unauthorized observation.
「vnc」URIがシステム内で交換または使用されると、それらのコンテンツがプロセスリストまたは他の計測によって公開される可能性があります。ユーザーは、「vnc」URIに機密情報を含めないようにする必要があります。これは、不正な監視にさらされる可能性があります。
If sensitive URI information is exchanged across a network, for example, by providing a list of connection URIs in a web page, the data needs to be encrypted in transit and only be accessible to authorized users.
たとえば、Webページで接続URIのリストを提供するなどして、機密性の高いURI情報がネットワーク上で交換される場合、データは転送中に暗号化され、承認されたユーザーのみがアクセスできる必要があります。
When an application detects potentially sensitive information in a "vnc" URI, it needs to be handled securely or discarded. In particular, URI data on persistent storage needs to be encrypted as described in Section 3.4.
アプリケーションが「vnc」URI内の潜在的な機密情報を検出した場合、その情報は安全に処理するか破棄する必要があります。特に、セクション3.4で説明されているように、永続ストレージ上のURIデータは暗号化する必要があります。
Since "vnc" URIs may contain sensitive information, applications should avoid logging the URIs even when errors occur. Users need to avoid including sensitive information in "vnc" URIs that are used with applications where logging is unavoidable.
「vnc」URIには機密情報が含まれている可能性があるため、エラーが発生した場合でも、アプリケーションはURIのロギングを回避する必要があります。ユーザーは、ロギングが避けられないアプリケーションで使用される「vnc」URIに機密情報を含めないようにする必要があります。
Applications that process URIs in a generic way, such as web browsers, might not detect that sensitive information is contained in a URI and could cache or store that information insecurely. It is advisable to avoid including credentials and other sensitive information in URIs that are likely to be processed in a generic way unless such caching and storage is disabled or otherwise secured.
Webブラウザーなど、URIを一般的な方法で処理するアプリケーションは、機密情報がURIに含まれていることを検出せず、その情報を安全にキャッシュまたは保存できない場合があります。資格情報やその他の機密情報をURIに含めないようにすることをお勧めします。URIには、キャッシュやストレージが無効になっているか、保護されていない限り、一般的な方法で処理される可能性があります。
In the absence of verifiable host identification, a VNC client application is vulnerable to spoofing and man-in-the-middle attacks that capture VNC or host OS credentials and user data. To prevent such attacks, administrators SHOULD secure their VNC communications with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection mechanisms identifying remote hosts via certificate or public key. VNC clients MUST verify the respective certificates or public keys to confirm the remote host's identity.
検証可能なホストIDがない場合、VNCクライアントアプリケーションは、VNCまたはホストOSの資格情報とユーザーデータをキャプチャするなりすましや中間者攻撃に対して脆弱です。このような攻撃を防ぐために、管理者はTLS [RFC5246]またはSSH [RFC4251]トンネル、または証明書または公開鍵を介してリモートホストを識別するその他の接続メカニズムでVNC通信を保護する必要があります。 VNCクライアントは、リモートホストのIDを確認するために、それぞれの証明書または公開鍵を検証する必要があります。
An application launching a VNC client via URI MAY provide a certificate hash or public key hash identifying the remote host. VNC clients maintaining a connection database can also store certificate or public key data suitable for validating a host's identity.
URIを介してVNCクライアントを起動するアプリケーションは、リモートホストを識別する証明書ハッシュまたは公開鍵ハッシュを提供する場合があります。接続データベースを維持するVNCクライアントは、ホストのIDの検証に適した証明書または公開鍵データも保存できます。
If connecting to a system identified by certificate or public key and a remote system ID hash cannot be matched to available identifying data, the VNC client needs to alert the user or operator. In a typical interactive environment, the alert will provide the remote system's identifying information and allow the user to terminate the connection. The alert can allow the user to accept the information and continue establishing the connection. In a dedicated environment (such as a kiosk system), the system can transmit an alert to the remote operator, record a log entry, and execute appropriate fallback behavior such as displaying a generic message requesting servicing.
証明書または公開鍵で識別されたシステムに接続し、リモートシステムIDハッシュが利用可能な識別データと一致しない場合、VNCクライアントはユーザーまたはオペレーターに警告する必要があります。典型的なインタラクティブ環境では、アラートはリモートシステムの識別情報を提供し、ユーザーが接続を終了できるようにします。アラートにより、ユーザーは情報を受け入れ、接続の確立を続行できます。専用環境（キオスクシステムなど）では、システムはアラートをリモートオペレーターに送信し、ログエントリを記録し、サービスを要求する一般的なメッセージを表示するなどの適切なフォールバック動作を実行できます。
When providing identifying information of a host identified by an X.509 certificate [RFC5280] [X.509], the certificate subject, issuer, validity period, and certificate hash need to be included. The VNC client can verify the certificate validity. If the validity of a certificate is not determined, the alert needs to include a statement indicating such information has not been verified.
X.509証明書[RFC5280] [X.509]で識別されるホストの識別情報を提供する場合、証明書のサブジェクト、発行者、有効期間、および証明書ハッシュを含める必要があります。 VNCクライアントは、証明書の有効性を確認できます。証明書の有効性が決定されていない場合、アラートには、そのような情報が検証されていないことを示すステートメントを含める必要があります。
Identifying information of a host identified by public key, such as the endpoint of an SSH connection using a raw key, needs to include a hash of the key.
生の鍵を使用するSSH接続のエンドポイントなど、公開鍵で識別されるホストの識別情報には、鍵のハッシュを含める必要があります。
A VNC client application and/or launching application can maintain a connection database containing remote host information, credentials, and/or connection parameters. Applications storing credentials need to ensure they are stored in an encrypted format with a decryption process requiring user-supplied or device-specific data. If supported, it is advisable for applications to have a setting disabling storage of credentials.
VNCクライアントアプリケーションや起動アプリケーションは、リモートホスト情報、資格情報、接続パラメータを含む接続データベースを維持できます。資格情報を保存するアプリケーションは、ユーザーが提供したデータまたはデバイス固有のデータを必要とする復号化プロセスを使用して、資格情報が暗号化された形式で保存されていることを確認する必要があります。サポートされている場合は、アプリケーションで資格情報の保存を無効にする設定を行うことをお勧めします。
If available, the VNC client connection database can store certificate or public key data used to verify host identification. To prevent a malicious URI from overriding the database, if identification information in the URI conflicts with information in the database, the user or operator needs to be alerted. In a typical interactive environment, the user can be prompted to accept the new information prior to updating the database.
利用可能な場合、VNCクライアント接続データベースは、ホストの識別を検証するために使用される証明書または公開鍵データを保存できます。悪意のあるURIがデータベースを上書きしないようにするには、URIの識別情報がデータベースの情報と競合する場合、ユーザーまたはオペレーターに警告する必要があります。一般的なインタラクティブ環境では、データベースを更新する前に、ユーザーに新しい情報を受け入れるように求めることができます。
The "vnc" scheme has been registered in the "Uniform Resource Identifier (URI) Schemes" registry.
「vnc」スキームは、「Uniform Resource Identifier（URI）Schemes」レジストリに登録されています。
The "Remote Framebuffer Security Types", "VNC URI Connection Channel Types", "VNC URI ID Hash Algorithms", and "VNC URI Parameters" registries support elements of the scheme.
「リモートフレームバッファセキュリティタイプ」、「VNC URI接続チャネルタイプ」、「VNC URI IDハッシュアルゴリズム」、および「VNC URIパラメータ」レジストリは、スキームの要素をサポートしています。
IANA has added the "vnc" scheme to the "Uniform Resource Identifier (URI) Schemes" registry with description "Remote Framebuffer Protocol" and reference to this document. A registration template is provided in Appendix A.
IANAは、「vnc」スキームを「Uniform Resource Identifier（URI）Schemes」レジストリに追加し、「Remote Framebuffer Protocol」という説明とこのドキュメントへの参照を追加しました。登録テンプレートは付録Aにあります。
The IANA schemes registry is currently located at <http://www.iana.org/assignments/uri-schemes>.
IANAスキームのレジストリは現在<http://www.iana.org/assignments/uri-schemes>にあります。
This document references the existing IANA "Remote Framebuffer Security Types" registry in specifying security type options. RFB security types are supported in "vnc" URIs.
このドキュメントでは、セキュリティタイプのオプションを指定する際に、既存のIANA "リモートフレームバッファセキュリティタイプ"レジストリを参照しています。 RFBセキュリティタイプは「vnc」URIでサポートされています。
Security mechanisms integrated with VNC clients might need to alter the process by which a connection is established prior to the security handshake described in Section 7.1.2 of [RFC6143]. Such mechanisms should be reflected in the "VNC URI Connection Channel Types" registry described in Section 4.4 of this document rather than the "Remote Framebuffer Security Types" registry, as their use cannot be negotiated by the mechanism specified in [RFC6143].
VNCクライアントと統合されたセキュリティメカニズムでは、[RFC6143]のセクション7.1.2で説明されているセキュリティハンドシェイクの前に、接続が確立されるプロセスを変更する必要がある場合があります。このようなメカニズムは、[RFC6143]で指定されているメカニズムでは使用をネゴシエートできないため、「リモートフレームバッファセキュリティタイプ」レジストリではなく、このドキュメントのセクション4.4で説明されている「VNC URI接続チャネルタイプ」レジストリに反映する必要があります。
Exceptions can be made for backwards compatibility. IANA has updated the "Secure Tunnel" and "Integrated SSH" security types to refer to this document.
後方互換性のために例外を作成できます。 IANAは、このドキュメントを参照するために、「セキュアトンネル」および「統合SSH」セキュリティタイプを更新しました。
IANA has created a "Virtual Network Computing (VNC) Uniform Resource Identifier (URI)" group. This group contains application-level, URI-related registries distinct from those used by the RFB protocol itself.
IANAは「Virtual Network Computing（VNC）Uniform Resource Identifier（URI）」グループを作成しました。このグループには、RFBプロトコル自体で使用されるものとは異なる、アプリケーションレベルのURI関連のレジストリが含まれています。
IANA has created a "VNC URI Connection Channel Types" registry within the "Virtual Network Computing (VNC) Uniform Resource Identifier (URI)" group. The registry includes Value, Description, and Reference columns. The initial contents of the registry are described in this document. The values of the "Secure Tunnel" and "Integrated SSH" types are copied from the RFB Security Types registry. They are:
IANAは、「Virtual Network Computing（VNC）Uniform Resource Identifier（URI）」グループ内に「VNC URI Connection Channel Types」レジストリを作成しました。レジストリには、値、説明、参照の列が含まれています。レジストリの初期の内容は、このドキュメントで説明されています。 "Secure Tunnel"および "Integrated SSH"タイプの値は、RFB Security Typesレジストリからコピーされます。彼らです：
Value Description Reference
-------- --------------- --------------
0 Reserved this document
1 Standard TCP this document
23 Secure Tunnel this document
24 Integrated SSH this document
The maximum acceptable value is 2,147,483,647.
最大許容値は2,147,483,647です。
Future assignments to this registry should be made through the "First Come First Served" process described in [RFC5226].
このレジストリへの今後の割り当ては、[RFC5226]で説明されている「先着順」プロセスを通じて行う必要があります。
IANA has created a "VNC URI ID Hash Algorithms" registry within the "Virtual Network Computing (VNC) Uniform Resource Identifier (URI)" group. The registry includes Value, Description, and Reference columns.
IANAは、「Virtual Network Computing（VNC）Uniform Resource Identifier（URI）」グループ内に「VNC URI ID Hash Algorithms」レジストリを作成しました。レジストリには、値、説明、参照の列が含まれています。
The initial hash algorithms specified are a subset of the algorithms contained in the "TLS HashAlgorithm Registry". The initial contents of the registry are:
指定された初期ハッシュアルゴリズムは、「TLS HashAlgorithm Registry」に含まれているアルゴリズムのサブセットです。レジストリの初期内容は次のとおりです。
Value Description Reference
-------- ------------ --------------
0 Reserved this document
1 MD5 this document
2 SHA1 this document
4 SHA256 this document
The maximum acceptable value is 2,147,483,647.
最大許容値は2,147,483,647です。
Future assignments to this registry should be made through the "First Come First Served" process described in [RFC5226].
このレジストリへの今後の割り当ては、[RFC5226]で説明されている「先着順」プロセスを通じて行う必要があります。
IANA has created a "VNC URI Parameters" registry within the "VNC URI" group.
IANAは、「VNC URI」グループ内に「VNC URIパラメータ」レジストリを作成しました。
The initial contents are described in this document. They are:
このドキュメントでは、最初の内容について説明します。彼らです：
+-----------------+-----------------------------+-----------------+
| Name | Description | Reference |
+-----------------+-----------------------------+-----------------+
| ConnectionName | Name of connection profile | this document |
+-----------------+-----------------------------+-----------------+
| VncUsername | VNC server username | this document |
+-----------------+-----------------------------+-----------------+
| VncPassword | VNC server password | this document |
+-----------------+-----------------------------+-----------------+
| SecurityType | RFB security type used | this document |
+-----------------+-----------------------------+-----------------+
| ChannelType | Connection channel type | this document |
+-----------------+-----------------------------+-----------------+
| SshHost | SSH server hostname or IP | this document |
+-----------------+-----------------------------+-----------------+
| SshPort | SSH server port | this document |
+-----------------+-----------------------------+-----------------+
| SshUsername | SSH username | this document |
+-----------------+-----------------------------+-----------------+
| SshPassword | SSH password | this document |
+-----------------+-----------------------------+-----------------+
| IdHashAlgorithm | Hash algorithm used with | this document |
| | "IdHash" parameter | |
+-----------------+-----------------------------+-----------------+
| IdHash | Expected hash of remote | this document |
| | public key or certificate | |
+-----------------+-----------------------------+-----------------+
| ColorLevel | Client color depth/mode | this document |
+-----------------+-----------------------------+-----------------+
| ViewOnly | Client is view only | this document |
+-----------------+-----------------------------+-----------------+
| SaveConnection | Store connection info | this document |
+-----------------+-----------------------------+-----------------+
Future assignments to this registry should be made through the "First Come First Served" process described in [RFC5226].
このレジストリへの今後の割り当ては、[RFC5226]で説明されている「先着順」プロセスを通じて行う必要があります。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<http://www.rfc-editor.org/info/rfc1321>。
[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>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4251] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、DOI 10.17487 / RFC4251、2006年1月、<http://www.rfc-editor.org/ info / rfc4251>。
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <http://www.rfc-editor.org/info/rfc4252>.
[RFC4252] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Authentication Protocol」、RFC 4252、DOI 10.17487 / RFC4252、2006年1月、<http://www.rfc-editor.org/ info / rfc4252>。
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <http://www.rfc-editor.org/info/rfc4253>.
[RFC4253] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、DOI 10.17487 / RFC4253、2006年1月、<http://www.rfc-editor.org / info / rfc4253>。
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, January 2006, <http://www.rfc-editor.org/info/rfc4254>.
[RFC4254] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Connection Protocol」、RFC 4254、DOI 10.17487 / RFC4254、2006年1月、<http://www.rfc-editor.org/ info / rfc4254>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。
[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>。
[RFC6143] Richardson, T. and J. Levine, "The Remote Framebuffer Protocol", RFC 6143, DOI 10.17487/RFC6143, March 2011, <http://www.rfc-editor.org/info/rfc6143>.
[RFC6143] Richardson、T. and J. Levine、 "The Remote Framebuffer Protocol"、RFC 6143、DOI 10.17487 / RFC6143、March 2011、<http://www.rfc-editor.org/info/rfc6143>。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard", NIST FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015.
[SHS]米国国立標準技術研究所、「Secure Hash Standard」、NIST FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <http://www.rfc-editor.org/info/rfc7595>.
[RFC7595] Thaler、D.、Ed。、Hansen、T。、およびT. Hardie、「URIスキームのガイドラインと登録手順」、BCP 35、RFC 7595、DOI 10.17487 / RFC7595、2015年6月、<http：// www.rfc-editor.org/info/rfc7595>。
[X.509] ITU-T, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO/IEC 9594-8, 2005.
[X.509] ITU-T、「情報技術-オープンシステム相互接続-ディレクトリ：公開鍵と属性証明書フレームワーク」、ITU-T勧告X.509、ISO / IEC 9594-8、2005。
Appendix A. "vnc" URI Template
付録A.「vnc」URIテンプレート
This template is provided for registration of the "vnc" URI in the IANA "Uniform Resource Identifier (URI) Schemes" registry as specified in [RFC7595].
このテンプレートは、[RFC7595]で指定されているように、IANA "Uniform Resource Identifier（URI）Schemes"レジストリに "vnc" URIを登録するために提供されています。
Scheme name: vnc
スキーム名：vnc
Status: Permanent
ステータス：永久
Applications/protocols that use this scheme name: Virtual Network Computing (VNC) remote desktop applications use vnc URIs. VNC applications use the Remote Framebuffer (RFB) protocol.
このスキーム名を使用するアプリケーション/プロトコル：仮想ネットワークコンピューティング（VNC）リモートデスクトップアプリケーションは、vnc URIを使用します。 VNCアプリケーションは、リモートフレームバッファ（RFB）プロトコルを使用します。
Contact: IESG <iesg@ietf.org>.
連絡先：IESG <iesg@ietf.org>。
Change Controller: See the authors of this document. Change control is through the IESG on behalf of the IETF <iesg@ietf.org>.
コントローラの変更：このドキュメントの作成者を参照してください。変更管理は、IETF <iesg@ietf.org>に代わってIESGを介して行われます。
References: This document.
参照：このドキュメント。
Acknowledgments
謝辞
Dominic Parkes and the staff of RealVNC Ltd. graciously reviewed this document and provided constructive comments.
ドミニクパークスとRealVNC Ltd.のスタッフは、このドキュメントを丁寧にレビューし、建設的なコメントを提供しました。
RFB and VNC are registered trademarks of RealVNC Ltd. in the United States and in other countries.
RFBおよびVNCは、米国およびその他の国におけるRealVNC Ltd.の登録商標です。
Authors' Addresses
著者のアドレス
David Warden Dell Products LP 200 Dell Way Round Rock, TX 78682 United States
David Warden Dell Products LP 200 Dell Way Round Rock、TX 78682 United States
Phone: 512-728-0380
Email: David_Warden@dell.com
URI: http://www.dell.com
Iordan Iordanov Undatech 260 Scarlet Road, Apt. 503 Toronto, ON M6N 4X6 Canada
Iordan Iordanov Undatech 260 Scarlet Road、Apt。 503トロント、オンM6N 4X6カナダ
Email: iiordanov@gmail.com