[要約] RFC 8308は、SSHプロトコルでの拡張機能の交渉に関する仕様です。その目的は、クライアントとサーバーが使用する拡張機能を効果的に交渉し、セキュアな通信を確立することです。
Internet Engineering Task Force (IETF) D. Bider
Request for Comments: 8308 Bitvise Limited
Updates: 4251, 4252, 4253, 4254 March 2018
Category: Standards Track
ISSN: 2070-1721
Extension Negotiation in the Secure Shell (SSH) Protocol
セキュアシェル（SSH）プロトコルでの拡張ネゴシエーション
Abstract
概要
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.
このメモは、Secure Shell（SSH）クライアントとサーバーがSSHキー交換後にサポートされているプロトコル拡張に関する情報を秘密に交換するメカニズムを定義することにより、RFC 4251、4252、4253、4254を更新します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8308.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8308で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview and Rationale ..........................................3
1.1. Requirements Terminology ...................................3
1.2. Wire Encoding Terminology ..................................3
2. Extension Negotiation Mechanism .................................3
2.1. Signaling of Extension Negotiation in SSH_MSG_KEXINIT ......3
2.2. Enabling Criteria ..........................................4
2.3. SSH_MSG_EXT_INFO Message ...................................4
2.4. Message Order ..............................................5
2.5. Interpretation of Extension Names and Values ...............6
3. Initially Defined Extensions ....................................6
3.1. "server-sig-algs" ..........................................6
3.2. "delay-compression" ........................................7
3.2.1. Awkwardly Timed Key Re-Exchange .....................9
3.2.2. Subsequent Re-Exchange ..............................9
3.2.3. Compatibility Note: OpenSSH up to Version 7.5 .......9
3.3. "no-flow-control" .........................................10
3.3.1. Prior "No Flow Control" Practice ...................10
3.4. "elevation" ...............................................11
4. IANA Considerations ............................................12
4.1. Additions to Existing Registries ..........................12
4.2. New Registry: Extension Names .............................12
4.2.1. Future Assignments to Extension Names Registry .....12
5. Security Considerations ........................................12
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
Acknowledgments ...................................................14
Author's Address ..................................................14
Secure Shell (SSH) is a common protocol for secure communication on the Internet. The original design of the SSH transport layer [RFC4253] lacks proper extension negotiation. Meanwhile, diverse implementations take steps to ensure that known message types contain no unrecognized information. This makes it difficult for implementations to signal capabilities and negotiate extensions without risking disconnection. This obstacle has been recognized in the process of updating SSH to support RSA signatures using SHA-256 and SHA-512 [RFC8332]. To avoid trial and error as well as authentication penalties, a client must be able to discover public key algorithms a server accepts. This extension mechanism permits this discovery.
Secure Shell（SSH）は、インターネット上の安全な通信のための一般的なプロトコルです。 SSHトランスポート層[RFC4253]の元の設計には、適切な拡張ネゴシエーションが欠けています。一方、さまざまな実装では、既知のメッセージタイプに未認識の情報が含まれないようにするための措置が講じられています。これにより、実装が機能を通知し、切断の危険を冒さずに拡張機能をネゴシエートすることが難しくなります。この障害は、SHA-256およびSHA-512を使用してRSA署名をサポートするようにSSHを更新するプロセスで認識されています[RFC8332]。試行錯誤や認証ペナルティを回避するために、クライアントはサーバーが受け入れる公開鍵アルゴリズムを発見できなければなりません。この拡張メカニズムにより、この発見が可能になります。
This memo updates RFCs 4251, 4252, 4253, and 4254.
このメモはRFC 4251、4252、4253、4254を更新します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The wire encoding types in this document -- "byte", "uint32", "string", "boolean", "name-list" -- have meanings as described in [RFC4251].
このドキュメントのワイヤエンコーディングタイプ-"byte"、 "uint32"、 "string"、 "boolean"、 "name-list"-は、[RFC4251]で説明されている意味を持っています。
Applications implementing this mechanism MUST add one of the following indicator names to the field kex_algorithms in the SSH_MSG_KEXINIT message sent by the application in the first key exchange:
このメカニズムを実装するアプリケーションは、最初の鍵交換でアプリケーションによって送信されるSSH_MSG_KEXINITメッセージのフィールドkex_algorithmsに次のインジケーター名のいずれかを追加する必要があります。
o When acting as server: "ext-info-s"
o サーバーとして機能する場合： "ext-info-s"
o When acting as client: "ext-info-c"
o クライアントとして機能する場合：「ext-info-c」
The indicator name is added without quotes and MAY be added at any position in the name-list, subject to proper separation from other names as per name-list conventions.
インジケーター名は引用符なしで追加され、名前リストの規則に従って他の名前から適切に分離されることを条件として、名前リストの任意の位置に追加される場合があります。
The names are added to the kex_algorithms field because this is one of two name-list fields in SSH_MSG_KEXINIT that do not have a separate copy for each data direction.
これは、データ方向ごとに個別のコピーを持たないSSH_MSG_KEXINITの2つの名前リストフィールドの1つであるため、名前はkex_algorithmsフィールドに追加されます。
The indicator names inserted by the client and server are different to ensure these names will not produce a match and therefore not affect the algorithm chosen in key exchange algorithm negotiation.
クライアントとサーバーによって挿入されるインジケーター名は、これらの名前が一致を生成せず、したがって鍵交換アルゴリズムのネゴシエーションで選択されたアルゴリズムに影響を与えないようにするために異なります。
The inclusion of textual indicator names is intended to provide a clue for implementers to discover this mechanism.
テキストインジケーター名を含めることは、実装者がこのメカニズムを発見するための手がかりを提供することを目的としています。
If a client or server offers "ext-info-c" or "ext-info-s" respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO message from the peer.
クライアントまたはサーバーがそれぞれ「ext-info-c」または「ext-info-s」を提供する場合は、ピアからのSSH_MSG_EXT_INFOメッセージを受け入れる準備ができている必要があります。
A server only needs to send "ext-info-s" if it intends to process SSH_MSG_EXT_INFO from the client. A client only needs to send "ext-info-c" if it plans to process SSH_MSG_EXT_INFO from the server.
サーバーは、クライアントからのSSH_MSG_EXT_INFOを処理する場合にのみ、「ext-info-s」を送信する必要があります。クライアントは、サーバーからSSH_MSG_EXT_INFOを処理することを計画している場合にのみ、「ext-info-c」を送信する必要があります。
If a server receives an "ext-info-c", or a client receives an "ext-info-s", it MAY send an SSH_MSG_EXT_INFO message but is not required to do so.
サーバーが「ext-info-c」を受信した場合、またはクライアントが「ext-info-s」を受信した場合、SSH_MSG_EXT_INFOメッセージを送信できますが、必須ではありません。
Neither party needs to wait for the other's SSH_MSG_KEXINIT in order to decide whether to send the appropriate indicator in its own SSH_MSG_KEXINIT.
どちらのパーティも、適切なインジケーターを自身のSSH_MSG_KEXINITで送信するかどうかを決定するために、相手のSSH_MSG_KEXINITを待つ必要はありません。
Implementations MUST NOT send an incorrect indicator name for their role. Implementations MAY disconnect if the counterparty sends an incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being negotiated as a key exchange method, the parties MUST disconnect.
実装は、それらの役割に対して誤ったインジケーター名を送信してはなりません（MUST NOT）。カウンターパーティが誤ったインジケーターを送信した場合、実装は切断される場合があります。 「ext-info-c」または「ext-info-s」が鍵交換方法として交渉されることになる場合、当事者は切断しなければなりません。
A party that received the "ext-info-c" or "ext-info-s" indicator MAY send the following message:
「ext-info-c」または「ext-info-s」インジケータを受信したパーティは、次のメッセージを送信できます。
byte SSH_MSG_EXT_INFO (value 7) uint32 nr-extensions repeat the following 2 fields "nr-extensions" times: string extension-name string extension-value (binary)
バイトSSH_MSG_EXT_INFO（値7）uint32 nr-extensionsは、次の2つのフィールドを「nr-extensions」回繰り返します：string extension-name string extension-value（binary）
Implementers should pay careful attention to Section 2.5, in particular to the requirement to tolerate any sequence of bytes (including null bytes at any position) in an unknown extension's extension-value.
実装者はセクション2.5、特に不明な拡張機能の拡張値のバイトシーケンス（任意の位置のnullバイトを含む）を許容する要件に注意を払う必要があります。
If a client sends SSH_MSG_EXT_INFO, it MUST send it as the next packet following the client's first SSH_MSG_NEWKEYS message to the server.
クライアントがSSH_MSG_EXT_INFOを送信する場合、クライアントの最初のSSH_MSG_NEWKEYSメッセージに続く次のパケットとしてサーバーに送信する必要があります。
If a server sends SSH_MSG_EXT_INFO, it MAY send it at zero, one, or both of the following opportunities:
サーバーがSSH_MSG_EXT_INFOを送信する場合、次の機会のゼロ、1つ、または両方で送信することができます：
o As the next packet following the server's first SSH_MSG_NEWKEYS.
o サーバーの最初のSSH_MSG_NEWKEYSに続く次のパケットとして。
Where clients need information in the server's SSH_MSG_EXT_INFO to authenticate, it is helpful if the server sends its SSH_MSG_EXT_INFO not only as the next packet after SSH_MSG_NEWKEYS, but without delay.
クライアントが認証するためにサーバーのSSH_MSG_EXT_INFOの情報を必要とする場合、サーバーがSSH_MSG_EXT_INFOをSSH_MSG_NEWKEYSの後の次のパケットとして送信するだけでなく、遅延なく送信すると便利です。
Clients cannot rely on this because the server is not required to send the message at this time; if sent, it may be delayed by the network. However, if a timely SSH_MSG_EXT_INFO is received, a client can pipeline an authentication request after its SSH_MSG_SERVICE_REQUEST, even when it needs extension information.
サーバーは現時点ではメッセージを送信する必要がないため、クライアントはこれに依存できません。送信された場合、ネットワークによって遅延する可能性があります。ただし、タイムリーなSSH_MSG_EXT_INFOを受信した場合、クライアントは、拡張情報が必要な場合でも、SSH_MSG_SERVICE_REQUESTの後に認証要求をパイプライン処理できます。
o Immediately preceding the server's SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252].
o [RFC4252]で定義されているように、サーバーのSSH_MSG_USERAUTH_SUCCESSの直前。
The server MAY send SSH_MSG_EXT_INFO at this second opportunity, whether or not it sent it at the first. A client that sent "ext-info-c" MUST accept a server's SSH_MSG_EXT_INFO at both opportunities but MUST NOT require it.
サーバーは、最初に送信したかどうかに関係なく、この2番目の機会にSSH_MSG_EXT_INFOを送信する場合があります。 「ext-info-c」を送信したクライアントは、両方の機会でサーバーのSSH_MSG_EXT_INFOを受け入れなければならないが、それを要求してはならない（MUST NOT）。
This allows a server to reveal support for additional extensions that it was unwilling to reveal to an unauthenticated client. If a server sends a second SSH_MSG_EXT_INFO, this replaces any initial one, and both the client and the server re-evaluate extensions in effect. The server's second SSH_MSG_EXT_INFO is matched against the client's original.
これにより、サーバーは、認証されていないクライアントに明らかにしたくない追加の拡張機能のサポートを明らかにできます。サーバーが2番目のSSH_MSG_EXT_INFOを送信した場合、これにより最初のSSH_MSG_EXT_INFOが置き換えられ、クライアントとサーバーの両方が有効な拡張機能を再評価します。サーバーの2番目のSSH_MSG_EXT_INFOは、クライアントの元のSSH_MSG_EXT_INFOと照合されます。
The timing of the second opportunity is chosen for the following reasons. If the message was sent earlier, it would not allow the server to withhold information until the client has authenticated. If it was sent later, a client that needs information from the second SSH_MSG_EXT_INFO immediately after it authenticates would have no way to reliably know whether to expect the message.
2番目の機会のタイミングは、次の理由により選択されます。メッセージが以前に送信された場合、クライアントが認証されるまでサーバーは情報を保留できません。後で送信された場合、認証直後に2番目のSSH_MSG_EXT_INFOからの情報を必要とするクライアントは、メッセージを予期するかどうかを確実に知る方法がありません。
Each extension is identified by its extension-name and defines the conditions under which the extension is considered to be in effect. Applications MUST ignore unrecognized extension-names.
各拡張機能は、その拡張名によって識別され、拡張機能が有効であると見なされる条件を定義します。アプリケーションは、認識されない拡張子名を無視する必要があります。
When it is specified, an extension MAY dictate that, in order to take effect, both parties must include it in their SSH_MSG_EXT_INFO or that it is sufficient for only one party to include it. However, other rules MAY be specified. The relative order in which extensions appear in an SSH_MSG_EXT_INFO message MUST be ignored.
それが指定されている場合、拡張機能は、有効にするために、両方のパーティがSSH_MSG_EXT_INFOにそれを含める必要があるか、または1つのパーティのみがそれを含めることで十分であることを指示する場合があります。ただし、他のルールを指定してもよい（MAY）。 SSH_MSG_EXT_INFOメッセージに表示される拡張の相対的な順序は無視する必要があります。
Extension-value fields are interpreted as defined by their respective extension. This field MAY be empty if permitted by the extension. Applications that do not implement or recognize an extension MUST ignore its extension-value, regardless of its size or content. Applications MUST tolerate any sequence of bytes -- including null bytes at any position -- in an unknown extension's extension-value.
拡張値フィールドは、それぞれの拡張によって定義されたものとして解釈されます。エクステンションで許可されている場合、このフィールドは空の場合があります。拡張機能を実装または認識しないアプリケーションは、サイズや内容に関係なく、その拡張値を無視する必要があります。アプリケーションは、不明な拡張機能の拡張値のバイトシーケンス（任意の位置のnullバイトを含む）を許容する必要があります。
The cumulative size of an SSH_MSG_EXT_INFO message is limited only by the maximum packet length that an implementation may apply in accordance with [RFC4253]. Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages up to the maximum packet length they accept.
SSH_MSG_EXT_INFOメッセージの累積サイズは、[RFC4253]に従って実装が適用できる最大パケット長によってのみ制限されます。実装は、受け入れ可能な最大パケット長まで、整形式のSSH_MSG_EXT_INFOメッセージを受け入れる必要があります。
This extension is sent with the following extension name and value:
この拡張機能は、次の拡張機能の名前と値とともに送信されます。
string "server-sig-algs" name-list public-key-algorithms-accepted
文字列 "server-sig-algs" name-list public-key-algorithms-accepted
The name-list type is a strict subset of the string type and is thus permissible as an extension-value. See [RFC4251] for more information.
名前リスト型は、文字列型の厳密なサブセットであるため、extension-valueとして使用できます。詳細については、[RFC4251]を参照してください。
This extension is sent by the server and contains a list of public key algorithms that the server is able to process as part of a "publickey" authentication request. If a client sends this extension, the server MAY ignore it and MAY disconnect.
この拡張機能はサーバーによって送信され、サーバーが「公開鍵」認証リクエストの一部として処理できる公開鍵アルゴリズムのリストが含まれています。クライアントがこの拡張機能を送信した場合、サーバーはそれを無視して切断してもよい（MAY）。
In this extension, a server MUST enumerate all public key algorithms it might accept during user authentication. However, early server implementations that do not enumerate all accepted algorithms do exist. For this reason, a client MAY send a user authentication request using a public key algorithm not included in "server-sig-algs".
この拡張では、サーバーはユーザー認証中に受け入れる可能性のあるすべての公開鍵アルゴリズムを列挙する必要があります。ただし、受け入れられているすべてのアルゴリズムを列挙しない初期のサーバー実装は存在します。このため、クライアントは、「server-sig-algs」に含まれていない公開鍵アルゴリズムを使用してユーザー認証要求を送信できます。
A client that wishes to proceed with public key authentication MAY wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" authentication request with an appropriate public key algorithm, rather than resorting to trial and error.
公開鍵認証を続行したいクライアントは、試行錯誤に頼るのではなく、適切な公開鍵アルゴリズムを使用して「公開鍵」認証要求を送信できるように、サーバーのSSH_MSG_EXT_INFOを待つ場合があります。
Servers that implement public key authentication SHOULD implement this extension.
公開鍵認証を実装するサーバーは、この拡張機能を実装する必要があります（SHOULD）。
If a server does not send this extension, a client MUST NOT make any assumptions about the server's public key algorithm support, and MAY proceed with authentication requests using trial and error. Note that implementations are known to exist that apply authentication penalties if the client attempts to use an unexpected public key algorithm.
サーバーがこの拡張機能を送信しない場合、クライアントはサーバーの公開鍵アルゴリズムのサポートについていかなる仮定も行わないでください。試行錯誤を使用して認証要求を続行できます（MAY）。クライアントが予期しない公開鍵アルゴリズムを使用しようとした場合に認証ペナルティを適用する実装が存在することが知られていることに注意してください。
Authentication penalties are applied by servers to deter brute-force password guessing, username enumeration, and other types of behavior deemed suspicious by server administrators or implementers. Penalties may include automatic IP address throttling or blocking, and they may trigger email alerts or auditing.
サーバーが認証ペナルティを適用して、ブルートフォースパスワードの推測、ユーザー名の列挙、およびサーバー管理者や実装者によって疑わしいと見なされるその他の種類の動作を阻止します。ペナルティには、自動IPアドレススロットリングまたはブロックが含まれる場合があり、電子メールアラートまたは監査をトリガーする場合があります。
This extension MAY be sent by both parties as follows:
この拡張子は、次のように両方の当事者から送信される場合があります。
string "delay-compression" string: name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client
string "delay-compression" string：name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client
The extension-value is a string that encodes two name-lists. The name-lists themselves have the encoding of strings. For example, to indicate a preference for algorithms "foo,bar" in the client-to-server direction and "bar,baz" in the server-to-client direction, a sender encodes the extension-value as follows (including its length):
extension-valueは、2つの名前リストをエンコードする文字列です。名前リスト自体は文字列のエンコーディングを持っています。たとえば、クライアントからサーバーへの方向にアルゴリズム「foo、bar」、サーバーからクライアントへの方向に「bar、baz」のアルゴリズムの設定を示すために、送信者は拡張値を次のようにエンコードします（長さを含む） ）：
00000016 00000007 666f6f2c626172 00000007 6261722c62617a
00000016 00000007 666f6f2c626172 00000007 6261722c62617a
This same encoding could be sent by either party -- client or server.
この同じエンコーディングは、クライアントまたはサーバーのどちらの側からも送信できます。
This extension allows the server and client to renegotiate compression algorithm support without having to conduct a key re-exchange, which puts new algorithms into effect immediately upon successful authentication.
この拡張により、サーバーとクライアントは、鍵の再交換を行わなくても圧縮アルゴリズムのサポートを再ネゴシエートできるため、認証が成功するとすぐに新しいアルゴリズムが有効になります。
This extension takes effect only if both parties send it. Name-lists MAY include any compression algorithm that could have been negotiated in SSH_MSG_KEXINIT, except algorithms that define their own delayed compression semantics. This means "zlib,none" is a valid algorithm list in this context, but "zlib@openssh.com" is not.
この拡張機能は、双方が送信した場合にのみ有効になります。名前リストには、独自の遅延圧縮セマンティクスを定義するアルゴリズムを除いて、SSH_MSG_KEXINITでネゴシエートされた可能性のある圧縮アルゴリズムを含めることができます（MAY）。つまり、「zlib、none」はこのコンテキストでは有効なアルゴリズムリストですが、「zlib@openssh.com」はそうではありません。
If both parties send this extension, but the name-lists do not contain a common algorithm in either direction, the parties MUST disconnect in the same way as if negotiation failed as part of SSH_MSG_KEXINIT.
両方のパーティがこの拡張を送信するが、名前リストにどちらの方向にも共通のアルゴリズムが含まれていない場合、パーティは、SSH_MSG_KEXINITの一部としてネゴシエーションが失敗した場合と同じ方法で切断する必要があります。
If this extension takes effect, the renegotiated compression algorithm is activated for the very next SSH message after the trigger message:
この拡張機能が有効になると、トリガーメッセージの後の次のSSHメッセージに対して再ネゴシエートされた圧縮アルゴリズムがアクティブになります。
o Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS.
o サーバーから送信されるトリガーメッセージはSSH_MSG_USERAUTH_SUCCESSです。
o Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS.
o クライアントから送信されるトリガーメッセージはSSH_MSG_NEWCOMPRESSです。
If this extension takes effect, the client MUST send the following message within a reasonable number of outgoing SSH messages after receiving SSH_MSG_USERAUTH_SUCCESS, but not necessarily as the first such outgoing message:
この拡張機能が有効になる場合、クライアントはSSH_MSG_USERAUTH_SUCCESSを受信した後、妥当な数の送信SSHメッセージ内で次のメッセージを送信する必要がありますが、必ずしも最初の送信メッセージとして送信する必要はありません。
byte SSH_MSG_NEWCOMPRESS (value 8)
バイトSSH_MSG_NEWCOMPRESS（値8）
The purpose of SSH_MSG_NEWCOMPRESS is to avoid a race condition where the server cannot reliably know whether a message sent by the client was sent before or after receiving the server's SSH_MSG_USERAUTH_SUCCESS. For example, clients may send keep-alive messages during logon processing.
SSH_MSG_NEWCOMPRESSの目的は、サーバーがクライアントの送信したメッセージがサーバーのSSH_MSG_USERAUTH_SUCCESSの受信前または受信後に送信されたかどうかをサーバーが確実に認識できないという競合状態を回避することです。たとえば、クライアントはログオン処理中にキープアライブメッセージを送信する場合があります。
As is the case for all extensions unless otherwise noted, the server MAY delay including this extension until its secondary SSH_MSG_EXT_INFO, sent before SSH_MSG_USERAUTH_SUCCESS. This allows the server to avoid advertising compression until the client has authenticated.
特に明記されていない限り、すべての拡張機能の場合と同様に、SSH_MSG_USERAUTH_SUCCESSの前に送信されるセカンダリSSH_MSG_EXT_INFOまで、サーバーはこの拡張機能を含めて遅延する場合があります。これにより、サーバーはクライアントが認証されるまで広告の圧縮を回避できます。
If the parties renegotiate compression using this extension in a session where compression is already enabled and the renegotiated algorithm is the same in one or both directions, then the internal compression state MUST be reset for each direction at the time the renegotiated algorithm takes effect.
圧縮がすでに有効になっていて、再ネゴシエートされたアルゴリズムが一方向または両方向で同じであるセッションで、パーティがこの拡張を使用して圧縮を再ネゴシエートする場合、再ネゴシエートされたアルゴリズムが有効になるときに、各方向の内部圧縮状態をリセットする必要があります。
A party that has signaled, or intends to signal, support for this extension in an SSH session MUST NOT initiate key re-exchange in that session until either of the following occurs:
SSHセッションでこの拡張機能のサポートを通知した、または通知する予定の当事者は、次のいずれかが発生するまで、そのセッションで鍵の再交換を開始してはなりません（MUST NOT）。
o This extension was negotiated, and the party that's about to start key re-exchange already sent its trigger message for compression.
o この拡張機能が交渉され、キーの再交換を開始しようとしている当事者は、圧縮のためのトリガーメッセージをすでに送信しています。
o The party has sent (if server) or received (if client) the message SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated.
o パーティはメッセージSSH_MSG_USERAUTH_SUCCESSを送信（サーバーの場合）または受信（クライアントの場合）し、この拡張はネゴシエーションされませんでした。
If a party violates this rule, the other party MAY disconnect.
パーティがこのルールに違反した場合、相手は切断することができます。
In general, parties SHOULD NOT start key re-exchange before successful user authentication but MAY tolerate it if not using this extension.
一般に、当事者は、ユーザー認証が成功する前にキーの再交換を開始してはいけません（SHOULD NOT）が、この拡張機能を使用しない場合は、それを許容してもかまいません（MAY）。
In subsequent key re-exchanges that unambiguously begin after the compression trigger messages, the compression algorithms negotiated in re-exchange override the algorithms negotiated with this extension.
圧縮トリガーメッセージの後に明確に開始する後続のキー再交換では、再交換でネゴシエートされた圧縮アルゴリズムが、この拡張機能でネゴシエートされたアルゴリズムをオーバーライドします。
This extension uses a binary extension-value encoding. OpenSSH clients up to and including version 7.5 advertise support to receive SSH_MSG_EXT_INFO but disconnect on receipt of an extension-value containing null bytes. This is an error fixed in OpenSSH version 7.6.
この拡張機能は、バイナリの拡張値のエンコーディングを使用します。バージョン7.5までのOpenSSHクライアントは、SSH_MSG_EXT_INFOを受信するサポートをアドバタイズしますが、ヌルバイトを含む拡張値の受信時に切断します。これはOpenSSHバージョン7.6で修正されたエラーです。
Implementations that wish to interoperate with OpenSSH 7.5 and earlier are advised to check the remote party's SSH version string and omit this extension if an affected version is detected. Affected versions do not implement this extension, so there is no harm in omitting it. The extension SHOULD NOT be omitted if the detected OpenSSH version is 7.6 or higher. This would make it harder for the OpenSSH project to implement this extension in a higher version.
OpenSSH 7.5以前との相互運用を希望する実装では、リモートパーティのSSHバージョン文字列を確認し、影響を受けるバージョンが検出された場合はこの拡張機能を省略することをお勧めします。影響を受けるバージョンはこの拡張機能を実装していないため、省略しても害はありません。検出されたOpenSSHバージョンが7.6以降の場合、拡張機能を省略しないでください。これにより、OpenSSHプロジェクトがこの拡張機能を上位バージョンで実装することが難しくなります。
This extension is sent with the following extension name and value:
この拡張機能は、次の拡張機能の名前と値とともに送信されます。
string "no-flow-control" string choice of: "p" for preferred | "s" for supported
文字列 "no-flow-control"文字列の選択： "p"を推奨|サポートされている場合は「s」
A party SHOULD send "s" if it supports "no-flow-control" but does not prefer to enable it. A party SHOULD send "p" if it prefers to enable the extension if the other party supports it. Parties MAY disconnect if they receive a different extension value.
パーティは、「フロー制御なし」をサポートしているが有効にしたくない場合は「s」を送信する必要があります（SHOULD）。パーティが拡張を有効にしたい場合は、相手がサポートしている場合に「p」を送信する必要があります（SHOULD）。異なる延長値を受け取った場合、当事者は切断してもよい（MAY）。
For this extension to take effect, the following must occur:
この拡張機能を有効にするには、以下が発生する必要があります。
o This extension MUST be sent by both parties.
o この拡張機能は、両方の側から送信する必要があります。
o At least one party MUST have sent the value "p" (preferred).
o 少なくとも1つのパーティが値 "p"（推奨）を送信している必要があります。
If this extension takes effect, the "initial window size" fields in SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined in [RFC4254], become meaningless. The values of these fields MUST be ignored, and a channel behaves as if all window sizes are infinite. Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST messages, and if received, such messages MUST be ignored.
この拡張機能が有効になると、[RFC4254]で定義されているSSH_MSG_CHANNEL_OPENおよびSSH_MSG_CHANNEL_OPEN_CONFIRMATIONの「初期ウィンドウサイズ」フィールドは無意味になります。これらのフィールドの値は無視する必要があり、チャネルはすべてのウィンドウサイズが無限であるかのように動作します。どちらの側もSSH_MSG_CHANNEL_WINDOW_ADJUSTメッセージを送信する必要はありません。受信した場合、そのようなメッセージは無視する必要があります。
This extension is intended for, but not limited to, use by file transfer applications that are only going to use one channel and for which the flow control provided by SSH is an impediment, rather than a feature.
この拡張機能は、1つのチャネルのみを使用し、SSHによって提供されるフロー制御が機能ではなく障害となるファイル転送アプリケーションでの使用を目的としていますが、これらに限定されません。
Implementations MUST refuse to open more than one simultaneous channel when this extension is in effect. Nevertheless, server implementations SHOULD support clients opening more than one non-simultaneous channel.
この拡張機能が有効な場合、実装は複数の同時チャネルを開くことを拒否する必要があります。それにもかかわらず、サーバーの実装は、複数の非同時チャネルを開くクライアントをサポートする必要があります（SHOULD）。
Before this extension, some applications would simply not implement SSH flow control, sending an initial channel window size of 2^32 - 1. Applications SHOULD NOT do this for the following reasons:
この拡張の前は、一部のアプリケーションはSSHフロー制御を実装せず、2 ^ 32-1の初期チャネルウィンドウサイズを送信していました。アプリケーションは、次の理由でこれを行わないでください。
o It is plausible to transfer more than 2^32 bytes over a channel. Such a channel will hang if the other party implements SSH flow control according to [RFC4254].
o チャネルを介して2 ^ 32バイト以上を転送することはもっともらしいことです。 [RFC4254]に従って相手がSSHフロー制御を実装している場合、そのようなチャネルはハングします。
o Implementations that cannot handle large channel window sizes exist, and they can exhibit non-graceful behaviors, including disconnect.
o 大きなチャネルウィンドウサイズを処理できない実装が存在し、接続解除などの正常でない動作を示す可能性があります。
The terms "elevation" and "elevated" refer to an operating system mechanism where an administrator's logon session is associated with two security contexts: one limited and one with administrative rights. To "elevate" such a session is to activate the security context with full administrative rights. For more information about this mechanism on Windows, see [WINADMIN] and [WINTOKEN].
「昇格」および「昇格」という用語は、管理者のログオンセッションが2つのセキュリティコンテキスト（1つは制限付き、もう1つは管理者権限付き）に関連付けられているオペレーティングシステムメカニズムを指します。このようなセッションを「昇格」するには、完全な管理者権限でセキュリティコンテキストをアクティブ化します。 Windowsでのこのメカニズムの詳細については、[WINADMIN]および[WINTOKEN]を参照してください。
This extension MAY be sent by the client as follows:
この拡張子は、次のようにクライアントによって送信される場合があります。
string "elevation"
string choice of: "y" | "n" | "d"
A client sends "y" to indicate its preference that the session should be elevated; "n" to not be elevated; and "d" for the server to use its default behavior. The server MAY disconnect if it receives a different extension value. If a client does not send the "elevation" extension, the server SHOULD act as if "d" was sent.
クライアントは "y"を送信して、セッションを昇格する必要があることを示します。 「n」は昇格されません。サーバーがデフォルトの動作を使用する場合は「d」。別の拡張値を受信した場合、サーバーは切断してもよい（MAY）。クライアントが「高度」拡張を送信しない場合、サーバーは「d」が送信されたかのように動作する必要があります。
If a client has included this extension, then after authentication, a server that supports this extension SHOULD indicate to the client whether elevation was done by sending the following global request:
クライアントにこの拡張機能が含まれている場合、認証後、この拡張機能をサポートするサーバーは、次のグローバルリクエストを送信して昇格が行われたかどうかをクライアントに示す必要があります（SHOULD）。
byte SSH_MSG_GLOBAL_REQUEST string "elevation" boolean want reply = false boolean elevation performed
バイトSSH_MSG_GLOBAL_REQUEST文字列「昇格」ブール値の応答を要求= falseブール値の昇格を実行
Clients that implement this extension help reduce attack surface for Windows servers that handle administrative logins. Where clients do not support this extension, servers must elevate sessions to allow full access by administrative users always. Where clients support this extension, sessions can be created without elevation unless requested.
この拡張機能を実装するクライアントは、管理ログインを処理するWindowsサーバーの攻撃対象を減らすのに役立ちます。クライアントがこの拡張機能をサポートしていない場合、サーバーはセッションを昇格させて、常に管理ユーザーによるフルアクセスを許可する必要があります。クライアントがこの拡張をサポートしている場合、要求されない限り、昇格なしでセッションを作成できます。
IANA has added the following entries to the "Message Numbers" registry [IANA-M] under the "Secure Shell (SSH) Protocol Parameters" registry [RFC4250]:
IANAは、「Secure Shell（SSH）Protocol Parameters」レジストリ[RFC4250]の下の「Message Numbers」レジストリ[IANA-M]に次のエントリを追加しました。
Value Message ID Reference
-----------------------------------------
7 SSH_MSG_EXT_INFO RFC 8308
8 SSH_MSG_NEWCOMPRESS RFC 8308
IANA has also added the following entries to the "Key Exchange Method Names" registry [IANA-KE]:
IANAはまた、「キー交換メソッド名」レジストリ[IANA-KE]に次のエントリを追加しました。
Method Name Reference Note
------------------------------------------
ext-info-s RFC 8308 Section 2
ext-info-c RFC 8308 Section 2
Also under the "Secure Shell (SSH) Protocol Parameters" registry, IANA has created a new "Extension Names" registry, with the following initial content:
また、「Secure Shell（SSH）Protocol Parameters」レジストリの下に、IANAは次の初期コンテンツを持つ新しい「Extension Names」レジストリを作成しました。
Extension Name Reference Note
------------------------------------------------
server-sig-algs RFC 8308 Section 3.1
delay-compression RFC 8308 Section 3.2
no-flow-control RFC 8308 Section 3.3
elevation RFC 8308 Section 3.4
Names in the "Extension Names" registry MUST follow the conventions for names defined in [RFC4250], Section 4.6.1.
「Extension Names」レジストリの名前は、[RFC4250]、セクション4.6.1で定義された名前の規則に従う必要があります。
Requests for assignments of new non-local names in the "Extension Names" registry (i.e., names not including the '@' character) MUST be done using the IETF Review policy, as described in [RFC8126].
[Extension Names]レジストリでの新しい非ローカル名（つまり、「@」文字を含まない名前）の割り当てのリクエストは、[RFC8126]で説明されているように、IETFレビューポリシーを使用して行う必要があります。
Security considerations are discussed throughout this document. This document updates the SSH protocol as defined in [RFC4251] and related documents. The security considerations of [RFC4251] apply.
セキュリティに関する考慮事項は、このドキュメント全体で説明されています。このドキュメントは、[RFC4251]および関連ドキュメントで定義されているSSHプロトコルを更新します。 [RFC4251]のセキュリティに関する考慮事項が適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.
[RFC4250] Lehtinen、S。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Assigned Numbers」、RFC 4250、DOI 10.17487 / RFC4250、2006年1月、<https://www.rfc-editor.org / info / rfc4250>。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://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月、<https://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, <https://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月、<https://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, <https://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月、<https://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, <https://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月、<https://www.rfc-editor.org/ info / rfc4254>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[IANA-KE] IANA, "Key Exchange Method Names", <https://www.iana.org/assignments/ssh-parameters/>.
[IANA-KE] IANA、「Key Exchange Method Names」、<https://www.iana.org/assignments/ssh-parameters/>。
[IANA-M] IANA, "Message Numbers", <https://www.iana.org/assignments/ssh-parameters/>.
[IANA-M] IANA、「メッセージ番号」、<https://www.iana.org/assignments/ssh-parameters/>。
[RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol", RFC 8332, DOI 10.17487/RFC8332, March 2018, <https://www.rfc-editor.org/info/rfc8332>.
[RFC8332] Bider、D。、「Secure Shell（SSH）プロトコルでのSHA-256およびSHA-512でのRSAキーの使用」、RFC 8332、DOI 10.17487 / RFC8332、2018年3月、<https：//www.rfc -editor.org/info/rfc8332>。
[WINADMIN] Microsoft, "How to launch a process as a Full Administrator when UAC is enabled?", March 2013, <https://blogs.msdn.microsoft.com/winsdk/2013/03/22/ how-to-launch-a-process-as-a-full-administrator-when-uac-is-enabled/>.
[WINADMIN] Microsoft、「UACが有効な場合に完全管理者としてプロセスを起動する方法」、2013年3月、<https://blogs.msdn.microsoft.com/winsdk/2013/03/22/ how-to- launch-a-process-as-a-full-administrator-when-uac-is-enabled />。
[WINTOKEN] Microsoft, "TOKEN_ELEVATION_TYPE enumeration", <https://msdn.microsoft.com/en-us/library/windows/desktop/ bb530718.aspx>.
[WINTOKEN] Microsoft、「TOKEN_ELEVATION_TYPE enumeration」、<https://msdn.microsoft.com/en-us/library/windows/desktop/ bb530718.aspx>。
Acknowledgments
謝辞
Thanks to Markus Friedl and Damien Miller for comments and initial implementation. Thanks to Peter Gutmann, Roumen Petrov, Mark D. Baushke, Daniel Migault, Eric Rescorla, Matthew A. Miller, Mirja Kuehlewind, Adam Roach, Spencer Dawkins, Alexey Melnikov, and Ben Campbell for reviews and feedback.
Markus FriedlとDamien Millerにコメントと初期実装について感謝します。レビューとフィードバックを提供してくれたPeter Gutmann、Roumen Petrov、Mark D. Baushke、Daniel Migault、Eric Rescorla、Matthew A. Miller、Mirja Kuehlewind、Adam Roach、Spencer Dawkins、Alexey Melnikov、Ben Campbellに感謝します。
Author's Address
著者のアドレス
Denis Bider Bitvise Limited 4105 Lombardy Court Colleyville, TX 76034 United States of America
Denis Bider Bitvise Limited 4105 Lombardy Court Colleyville、TX 76034アメリカ合衆国
Email: ietf-ssh3@denisbider.com
URI: https://www.bitvise.com/