Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Editor, Ed. Sun Microsystems, Inc Oct 2003 # 訳者 春山征吾 haruyama@unixuser.org SSH Transport Layer Protocol draft-ietf-secsh-transport-17.txt Status of this Memo このメモについて This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. この文書はインターネットドラフトで, RFC2026 の第 10 節のすべての規定に 準拠している. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. インターネットドラフトは Internet Engineering Task Force (IETF) と , その領域, そのワーキンググループで作業中の文書だ. 他のグループも 作業中の文書をインターネットドラフトとして同様に配付していることに 注意せよ. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." インターネットドラフトは, 最大 6 か月間有効な起草された文書で, いつでも 更新されたり, 置換されたり, 他の文書によって陳腐化される. インターネットドラフトを参考文献として使ったり, "進行中の仕事" として以外に引用することは適切ではない. The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. 現在のインターネットドラフトのリストは http://www.ietf.org/ietf/1id-abstracts.txt でアクセスできる. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. インターネットドラフトのミラーサイトのリストは http://www.ietf.org/shadow.html. でアクセスできる. This Internet-Draft will expire on March 31, 2004. このインターネットドラフトは 2004 年 3 月 31 日に期限切れとなる. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract 概要 SSH is a protocol for secure remote login and other secure network services over an insecure network. SSH は, 安全ではないネットワーク越しの, 安全なリモートログイン及び他の 安全なネットワークサービスのためのプロトコルだ. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. この文書では, 典型的には TCP/IP の上で動く SSH のトランスポート層の プロトコルについて記述している. このプロトコルは, 多くの 安全なネットワークサービスの基礎として使うことができる. このプロトコルは, 強力な暗号化やサーバの認証, 完全性の保護を 提供する. また, 圧縮も提供する. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1] Internet-Draft SSH Transport Layer Protocol Oct 2003 all negotiated. 鍵交換の方法や, 公開鍵アルゴリズム, 対称暗号化アルゴリズム, メッセージ認証アルゴリズム, ハッシュアルゴリズムは, すべて 取り決められる. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. この文書は, Diffie-Hellman の鍵交換の方法と SSH のトランスポート層の プロトコルに実装する必要のあるアルゴリズムの最小限の集合について も記述する. Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . 3 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . 4 4.3 Compatibility With Old SSH Versions . . . . . . . . . . . . 4 4.3.1 Old Client, New Server . . . . . . . . . . . . . . . . . . . 5 4.3.2 New Client, Old Server . . . . . . . . . . . . . . . . . . . 5 5. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 5 5.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . 6 5.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 9 5.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 10 5.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . 11 6. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . 13 6.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . 16 6.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . 17 7. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 18 7.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . 19 8. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 20 9. Service Request . . . . . . . . . . . . . . . . . . . . . . 21 10. Additional Messages . . . . . . . . . . . . . . . . . . . . 21 10.1 Disconnection Message . . . . . . . . . . . . . . . . . . . 22 10.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . 22 10.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . 23 10.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . 23 11. Summary of Message Numbers . . . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 13. Security Considerations . . . . . . . . . . . . . . . . . . 24 14. Intellectual Property . . . . . . . . . . . . . . . . . . . 24 15. Additional Information . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 25 Informative . . . . . . . . . . . . . . . . . . . . . . . . 25 A. Contibutors . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . 28 Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2] Internet-Draft SSH Transport Layer Protocol Oct 2003 1. Contributors 1. 寄稿家たち. The major original contributors of this document were: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla) この文書の主要でもともとの寄稿家は以下の通りである: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (以上すべて SSH Communications Security Corp 社), Markku-Juhani O. Saarinen (University of Jyvaskyla). The document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh-charter.html 文書の編者は: Darren.Moffat@Sun.COM だ. このインターネットドラフトに 対するコメントは, IETF SECSH ワーキンググループに送ってほしい. ワーキンググループの詳細は http://ietf.org/html.charters/secsh-charter.html にある. 2. Introduction 2. イントロダクション The SSH transport layer is a secure low level transport protocol. It provides strong encryption, cryptographic host authentication, and integrity protection. SSH のトランスポート層は, 安全な低レベルトランスポートプロトコルだ. これは強力な暗号化や暗号化されたホストの認証, 完全性の保護を 提供する. Authentication in this protocol level is host-based; this protocol does not perform user authentication. A higher level protocol for user authentication can be designed on top of this protocol. このプロトコルのレベルでの認証はホストベースだ. このプロトコルは ユーザの認証を行なわない. ユーザ認証のためのより高いレベルの プロトコルをこのプロコロルの上に設計することができる。 The protocol has been designed to be simple, flexible, to allow parameter negotiation, and to minimize the number of round-trips. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. It is expected that in most environments, only 2 round-trips will be needed for full key exchange, server authentication, service request, and acceptance notification of service request. The worst case is 3 round-trips. このプロトコルはシンプルで, 柔軟性があり, パラメータの交渉を許し 往復の回数を最小化するように設計されている. 鍵交換の方法や 公開鍵アルゴリズム, 対称暗号化アルゴリズム, メッセージ認証アルゴリズム , ハッシュアルゴリズムはすべて (サーバ間で) 交渉される. 多くの環境で, 完全な鍵交換やサーバの認証, サービスの要求, サービスの要求の受諾通知に 2 往復が必要となることが期待されている. もっとも悪い場合で 3 往復が必要となる. 3. Conventions Used in This Document 3. この文書で使う約束事 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. この文書に出てくる "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY" といった キーワードは [RFC2119] に記述されているように解釈される. #http://www.ipa.go.jp/security/rfc/RFC2119JA.html によると #「しなければならない（ MUST ）」「要求されている（ REQUIRED ）」「することになる（ SHALL ）」 #「してはならない（ MUST NOT ）」 「することはない（ SHALL NOT ）」 #「する必要がある（ SHOULD ）」「推奨される（ RECOMMENDED ）」 #「しないほうがよい（ SHOULD NOT ）」 「推奨されない（ NOT RECOMENDED ）」 #「してもよい（ MAY ）」「選択できる（ OPTIONAL ）」 The used data types and terminology are specified in the architecture document [SSH-ARCH]. 使用されるデータのタイプや用語はアーキテクチャのドキュメント [SSH-ARCH] で定義されている. The architecture document also discusses the algorithm naming conventions that MUST be used with the SSH protocols. アーキテクチャのドキュメントでは, SSHプロトコルと共に使わなければならない アルゴリズムの命名規則についても議論している. 4. Connection Setup 4. 接続のセットアップ SSH works over any 8-bit clean, binary-transparent transport. The underlying transport SHOULD protect against transmission errors as such errors cause the SSH connection to terminate. SSH はどんな 8bit クリーンでバイナリ透過なトランスポートでも動く. 下にあるトランスポートは転送エラーに対する保護をする必要がある. このようなエラーは SSH の接続の終了を引きおこすから. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3] Internet-Draft SSH Transport Layer Protocol Oct 2003 The client initiates the connection. クライアントが接続を開始する. 4.1 Use over TCP/IP 4.1 TCP/IP 上での使用 When used over TCP/IP, the server normally listens for connections on port 22. This port number has been registered with the IANA, and has been officially assigned for SSH. TCP/IP 上で使用される場合, サーバは普通接続を 22 番ポートで待つ. このポート番号は IANA に登録されていて, SSH のために公式に 割当てられている. 4.2 Protocol Version Exchange 4.2 プロトコルバージョンの交換 When the connection has been established, both sides MUST send an identification string of the form "SSH-protoversion-softwareversion comments", followed by carriage return and newline characters (ASCII 13 and 10, respectively). Both sides MUST be able to process identification strings without carriage return character. No null character is sent. The maximum length of the string is 255 characters, including the carriage return and newline. 接続が確立されると, サーバクライアントの両方とも "SSH-プロトコルのバージョン-ソフトウェアのバージョン コメント" という形の識別文字列をキャリッジリターンとニューラインの文字 (それぞれ ASCII では 13 と 10) を付けて送らなければならない. 両側ともキャリッジリターン文字抜きの識別文字列も扱かえなくては ならない. ヌル文字は送らない. この文字列の最大長は キャリッジリターンとニューラインを含めて 255 文字だ. The part of the identification string preceding carriage return and newline is used in the Diffie-Hellman key exchange (see Section Section 7). キャリッジリターンとニューラインの前にある識別文字列の部分は Diffie-Hellman 鍵交換で使用される (セクション 7 を参照). The server MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a carriage return and newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). Clients MUST be able to process such lines; they MAY be silently ignored, or MAY be displayed to the client user; if they are displayed, control character filtering discussed in [SSH-ARCH] SHOULD be used. The primary use of this feature is to allow TCP-wrappers to display an error message before disconnecting. サーバはバージョン文字列を送る前に別のデータを複数行送ってもよい. それぞれの行はキャリッジリターンとニューラインによって終端されて いる必要がある. これらの行は, "SSH-"で始まってはならず, ISO-10646 UTF-8 [RFC2279] でエンコードされている必要がある. (言語は指定されない). クライアントはこれらの行を処理することが でき*なくてはならない*. これらは静かに無視されてもよいし, クライアントのユーザに表示されてもよい. それらが表示されるなら [SSH-ARCH] で議論されているコントロール文字のフィルタをする 必要がある. この特徴の主な用途は, TCP-wrappers に 接続を切る前にエラーメッセージを表示させることだ. Version strings MUST consist of printable US-ASCII characters, not including whitespaces or a minus sign (-). The version string is primarily used to trigger compatibility extensions and to indicate the capabilities of an implementation. The comment string should contain additional information that might be useful in solving user problems. バージョン文字列はホワイトスペースやマイナス符号 (-) を含まない 印刷可能な US-ASCII 文字で構成されてなくてはならない. このバージョン文字列は, 互換性の拡張を始動させたり 実装の特性を示すために主として使われる. コメント文字列は ユーザの問題を解決するのに有用と思われる追加の情報を含めなくては ならない. The protocol version described in this document is 2.0. この文書で記述されるプロトコルのバージョンは 2.0 だ. Key exchange will begin immediately after sending this identifier. All packets following the identification string SHALL use the binary packet protocol, to be described below. この識別子を送ったあとすぐに鍵の交換が始まる. この識別文字列に続くすべてのパケットは, 以下に示される バイナリパケットプロトコルを使うことになる. 4.3 Compatibility With Old SSH Versions 4.3 古い SSH のバージョンとの互換性 During the transition period, it is important to be able to work in a Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4] Internet-Draft SSH Transport Layer Protocol Oct 2003 way that is compatible with the installed SSH clients and servers that use an older version of the protocol. Information in this section is only relevant for implementations supporting compatibility with SSH versions 1.x. There is no standards track or informational draft available that defines the SSH 1.x protocol. The only known documentation of the 1.x protocol is contained in README files that are shipped along with the source code. 過渡期には, より古いプロトコルのバージョンを使う (導入された) SSH のクライアントとサーバと互換性のある方式で 動作できることが重要だ. このセクションの情報は SSH version 1.x との互換性をサポートする実装にのみ関連がある. SSH 1.x プロトコルを定義する標準課程やドラフトは存在しない. 1.xプロトコルについてただ一つ知られた文書は, ソースコードと共に 発行された README ファイル群に含まれている. 4.3.1 Old Client, New Server 4.3.1 古いクライアントで新しいサーバの場合 Server implementations MAY support a configurable "compatibility" flag that enables compatibility with old versions. When this flag is on, the server SHOULD identify its protocol version as "1.99". Clients using protocol 2.0 MUST be able to identify this as identical to "2.0". In this mode the server SHOULD NOT send the carriage return character (ASCII 13) after the version identification string. サーバの実装は古いバージョンとの互換性を持つ設定可能な"compatibility" フラグをサポートしてもよい. このフラグが有効ならば, サーバは そのプロトコルバージョンを"1.99"と名乗る必要がある. プロトコル 2.0 を使っているクライアントは, "2.0"と自分を名乗れ なければならない. このモードでは, サーバはバージョン識別文字列 のあとでキャリッジリターン (ASCII 13) を送らないほうがよい. In the compatibility mode the server SHOULD NOT send any further data after its initialization string until it has received an identification string from the client. The server can then determine whether the client is using an old protocol, and can revert to the old protocol if required. In the compatibility mode, the server MUST NOT send additional data before the version string. 互換モードでは, サーバはこの初期化文字のあとはクライアントからの 識別文字列を受けとるまで, どんなさらなるデータも送らないほうがよい. サーバはそれで, クライアントが古いプロトコルを使っているのか, 必要とされているなら 古いプロトコルに戻ることができる (つまり 2.0 も使える) かを決定する. この互換モードでは, サーバはバージョン文字列の前に別のデータを 送ってはならない. When compatibility with old clients is not needed, the server MAY send its initial key exchange data immediately after the identification string. 古いクライアントの互換性が必要ではない場合, サーバは識別文字列のあと すぐに最初に鍵交換のデータを送ってもよい. 4.3.2 New Client, Old Server 4.3.2 新しいクライアントで古いサーバ Since the new client MAY immediately send additional data after its identification string (before receiving server's identification), the old protocol may already have been corrupted when the client learns that the server is old. When this happens, the client SHOULD close the connection to the server, and reconnect using the old protocol. 新しいクライアントは (サーバの識別文字列を受けとる前に) 自分の 識別文字列のあと別のデータをすぐに送ってもよいので, クライアントがサーバが古いと気付いたときには, 古いプロトコルは すでに崩壊しているだろう. こうなったら, クライアントは サーバとの接続を閉じ, そして古いクライアントを使って再接続 する必要がある. 5. Binary Packet Protocol 5. バイナリパケットプロトコル Each packet is in the following format: それぞれのパケットは次のフォーマットに従う uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length packet_length パケット長 Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5] Internet-Draft SSH Transport Layer Protocol Oct 2003 The length of the packet (bytes), not including MAC or the packet_length field itself. パケットの長さ (バイト). MAC や packet_length フィールドそのもの を含まない. padding_length パディング長 Length of padding (bytes). パディングの長さ (バイト). payload ペイロード The useful contents of the packet. If compression has been negotiated, this field is compressed. Initially, compression MUST be "none". パケットの有効な中身. 圧縮が取り決められていたら, このフィールドは圧縮されている. 最初のうちは 圧縮は"none"でなくてはならない. random padding ランダムパディング Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || padding) is a multiple of the cipher block size or 8, whichever is larger. (packet_length || padding_length || payload || padding) の 全ての長さが暗号のブロックサイズか 8 のどちらか大きいほうの 倍数になるような, 任意の長さのパディング. There MUST be at least four bytes of padding. The padding SHOULD consist of random bytes. The maximum amount of padding is 255 bytes. すくなくとも 4 バイトのパディングがなくてはならない. このパディングはランダムなバイトで構成されている必要がある. パディングの最大量は 255 バイトだ. mac mac Message authentication code. If message authentication has been negotiated, this field contains the MAC bytes. Initially, the MAC algorithm MUST be "none". メッセージ認証コード. メッセージ認証が取り決められていたら このフィールドは MAC を含む. 最初のうちは, MAC のアルゴリズムは "none"でなければならない. Note that length of the concatenation of packet length, padding length, payload, and padding MUST be a multiple of the cipher block size or 8, whichever is larger. This constraint MUST be enforced even when using stream ciphers. Note that the packet length field is also encrypted, and processing it requires special care when sending or receiving packets. packet length, padding length, payload, padding の連なりの長さは 暗号のブロックサイズか 8 のどちらか大きいほうの倍数でなくてはならない ことに注意. この制限は, ストリーム暗号を用いた場合でも強制される. パケットの長さのフィールドも暗号化されて, それを処理するには パケットの送受信時に特別な注意が必要なことに注意せよ. The minimum size of a packet is 16 (or the cipher block size, whichever is larger) bytes (plus MAC); implementations SHOULD decrypt the length after receiving the first 8 (or cipher block size, whichever is larger) bytes of a packet. パケットの最小のサイズは 16 (ないし暗号のブロックのサイズ, どちらか大きいほう) バイト (に MAC) だ. 実装はパケットの最初の 8 (ないし 暗号のブロックのサイズ, どちらか大きいほう) バイトを受信した あとで, その長さを復号する必要がある. 5.1 Maximum Packet Length 5.1 最大パケット長 All implementations MUST be able to process packets with uncompressed payload length of 32768 bytes or less and total packet size of 35000 bytes or less (including length, padding length, payload, padding, and MAC.). The maximum of 35000 bytes is an arbitrary chosen value larger than uncompressed size. Implementations SHOULD support longer packets, where they might be needed, e.g. if an implementation wants to send a very large number of certificates. Such packets MAY be sent if the version string indicates that the other party is able to process them. However, implementations SHOULD check that the packet Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6] Internet-Draft SSH Transport Layer Protocol Oct 2003 length is reasonable for the implementation to avoid denial-of-service and/or buffer overflow attacks. すべての実装は圧縮されていないペイロードの長さが 32768 バイト以下で 全パケットのサイズ (length, padding length, payload, padding ,MAC が含まれる) が 35000 バイト以下のパケットを処理できなければならない. 35000 バイトという最大値は, 圧縮されていないサイズよりも大きい 勝手に選んだ値だ. 実装はより長いパケットもサポートする必要がある, それはおそらく必要になるだろう, たとえば, 実装が 非常に大量の証明書を送りたい場合に. それらのパケットは バージョン文字列が, 相手もそれを処理できることを示している場合に 送られてもよい. しかし, パケットの長さが, サービス不能攻撃やバッファオーバーフロー攻撃を避けるために 実装にとって合理的であるか, 実装は検査する必要がある. 5.2 Compression 5.2 圧縮 If compression has been negotiated, the payload field (and only it) will be compressed using the negotiated algorithm. The length field and MAC will be computed from the compressed payload. Encryption will be done after compression. 圧縮が取り決められたら, ペイロードフィールド (そしてそれのみ) が 取り決めらえたアルゴリズムによって圧縮される. 長さのフィールドや MAC は圧縮されたペイロードに対して計算される. 暗号化は圧縮のあとで 行なわれる. Compression MAY be stateful, depending on the method. Compression MUST be independent for each direction, and implementations MUST allow independently choosing the algorithm for each direction. 圧縮は, その方法に依存して, ステートフルでもよい (状態情報を持ってもよい). 圧縮は方向それぞれに対して独立で なければならない. また, 実装は方向それぞれに対してアルゴリズムを 独立に選べるようにしなければならない. The following compression methods are currently defined: 以下の圧縮法が現在定義されている: none REQUIRED no compression zlib OPTIONAL ZLIB (LZ77) compression The "zlib" compression is described in [RFC1950] and in [RFC1951]. The compression context is initialized after each key exchange, and is passed from one packet to the next with only a partial flush being performed at the end of each packet. A partial flush means that the current compressed block is ended and all data will be output. If the current block is not a stored block, one or more empty blocks are added after the current block to ensure that there are at least 8 bits counting from the start of the end-of-block code of the current block to the end of the packet payload. "zlib"圧縮は [RFC1950] と [RFC1951] で記述されている. 圧縮コンテキストは, それぞれの鍵を交換した後で初期化され, それぞれのパケットの最後で行われる部分的な (partial) flush のみとともに 一つのパケットから次のものに伝わる. 部分的な flush が行なわれると, 現在圧縮されているブロックが最後までいって, すべてのデータが出力に なる. もし現在のブロックが保存されて (stored) いないなら, 現在のブロックの ブロックの最後のコードの開始から パケットのペイロードの最後まですくなくとも 8bit 単位で数えられること を保証するように現在のブロックのあとに一つ以上の 空のブロックが足される. (ようは align する) # zlib 的には sync flush となった #define Z_PARTIAL_FLUSH 1 /* will be removed, use Z_SYNC_FLUSH instead */ #define Z_SYNC_FLUSH 2 # zlib.h の説明を見たほうがわかりやすい. 上のではわからん. # ssh の実装的には zlib を使って # status = deflate (&outgoing_stream, Z_PARTIAL_FLUSH); # などとするだけである. (OpenSSH 3.1p1 compress.c) # zlib.h より ##### If the parameter flush is set to Z_SYNC_FLUSH, all pending output is flushed to the output buffer and the output is aligned on a byte boundary, so that the decompressor can get all input data available so far. (In particular avail_in is zero after the call if enough output space has been provided before the call.) Flushing may degrade compression for some compression algorithms and so it should be used only when necessary. ##### Additional methods may be defined as specified in [SSH-ARCH]. 別の方法が [SSH-ARCH] で定義されているかもしれない. 5.3 Encryption 5.3 暗号化 An encryption algorithm and a key will be negotiated during the key exchange. When encryption is in effect, the packet length, padding length, payload and padding fields of each packet MUST be encrypted with the given algorithm. 暗号化アルゴリズムと鍵は鍵交換の際に取り決められる. 暗号化が 実施されたら, それぞれのパケットの packet length, padding length, payload, padding フィールドは与えられたアルゴリズムで暗号化 されなければならない The encrypted data in all packets sent in one direction SHOULD be considered a single data stream. For example, initialization vectors SHOULD be passed from the end of one packet to the beginning of the next packet. All ciphers SHOULD use keys with an effective key length of 128 bits or more. 一方向に送られるすべてのパケットの暗号化されたデータは 単一のデータストリームとみなせる必要がある. たとえば, (暗号の) 初期化ベクトル (初期化配列) は, あるパケットの最後から 次のパケットの最初に伝えられる必要がある. すべての暗号が 128bit かそれ以上の有効な長さを持つ鍵を使う必要がある. The ciphers in each direction MUST run independently of each other, and implementations MUST allow independently choosing the algorithm for each direction (if multiple algorithms are allowed by local policy). それぞれの方向の暗号は互いに独立に動かねばならないし, 実装はそれぞれの方向のアルゴリズムを独立に選べるようにしなければ ならない (もし複数のアルゴリズムがローカルなポリシーによって許されているなら). Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7] Internet-Draft SSH Transport Layer Protocol Oct 2003 The following ciphers are currently defined: 以下の暗号が現在定義されている: 3des-cbc REQUIRED three-key 3DES in CBC mode blowfish-cbc OPTIONALi Blowfish in CBC mode twofish256-cbc OPTIONAL Twofish in CBC mode, with 256-bit key twofish-cbc OPTIONAL alias for "twofish256-cbc" (this is being retained for historical reasons) twofish192-cbc OPTIONAL Twofish with 192-bit key twofish128-cbc OPTIONAL Twofish with 128-bit key aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, with 256-bit key aes192-cbc OPTIONAL AES with 192-bit key aes128-cbc RECOMMENDED AES with 128-bit key serpent256-cbc OPTIONAL Serpent in CBC mode, with 256-bit key serpent192-cbc OPTIONAL Serpent with 192-bit key serpent128-cbc OPTIONAL Serpent with 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher idea-cbc OPTIONAL IDEA in CBC mode cast128-cbc OPTIONAL CAST-128 in CBC mode none OPTIONAL no encryption; NOT RECOMMENDED ###訳注: OPTIONALiは誤植か. The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). To implement CBC mode, outer chaining MUST be used (i.e., there is only one initialization vector). This is a block cipher with 8 byte blocks. This algorithm is defined in [FIPS-46-3] "3des-cbc"暗号は, 3 つの鍵の triple-DES (暗号化-復号化-暗号化) で, 鍵の最初の 8bytes が最初の暗号化に次の 8 バイトが復号化に そして次の 8 バイトが最後の暗号化に使われる. こえは, 鍵のデータが 24byte であることを要求する (その中で実際に使われるのは 168bit だ). CBC モードで実装されるので, outer chaining が使われなければならない. ([SCHNEIER] p360, また Biham has shown that inner chaining weakens 3DES. らしい) (すなわち, 初期化ベクトルはたった一つ). これは 8 バイトのブロックを持つブロック暗号だ. このアルゴリズムは [FIPS-46-3] で定義されている. The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys [SCHNEIER]. This is a block cipher with 8 byte blocks. "blowfish-cbc" 暗号は CBC モードで 128bit の鍵の Blowfish だ [SCHNEIER]. これは 8 バイトのブロックを持つブロック暗号だ. The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, with 256 bit keys as described [TWOFISH]. This is a block cipher with 16 byte blocks. "twofish-cbc"ないし "twofish256-cbc" 暗号は [TWOFISH] に記述されている CBC モードで 256 ビットの鍵を持つ Twofish だ. これは 16 バイトのブロックを持つブロック暗号だ. The "twofish192-cbc" cipher. Same as above but with 192-bit key. "twofish192-cbc" 暗号. 上と同様だが鍵が 192 ビット. The "twofish128-cbc" cipher. Same as above but with 128-bit key. "twofish128-cbc" 暗号. 上と同様だが鍵が 128 ビット The "aes256-cbc" cipher is AES (Advanced Encryption Standard) [FIPS-197], formerly Rijndael, in CBC mode. This version uses 256-bit key. "aes256-cbc" 暗号は CBC モードの, 以前は Rijndael と言った AES (Advanced Encryption Standard)[FIPS-197] だ. このバージョンは 256bit の鍵を持つ. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8] Internet-Draft SSH Transport Layer Protocol Oct 2003 The "aes192-cbc" cipher. Same as above but with 192-bit key. "aes192-cbc" 暗号. 上と同様だが鍵が 192 ビット. The "aes128-cbc" cipher. Same as above but with 128-bit key. "aes128-cbc" 暗号. 上と同様だが鍵が 128 ビット. The "serpent256-cbc" cipher in CBC mode, with 256-bit key as described in the Serpent AES submission. "serpent256-cbc" 暗号は CBC モードで 256bit の鍵を持つ Serpent AES 提案で記述されたもの. The "serpent192-cbc" cipher. Same as above but with 192-bit key. "serpent192-cbc" 暗号. 上と同様だが鍵が 192 ビット. The "serpent128-cbc" cipher. Same as above but with 128-bit key. "serpent128-cbc" 暗号. 上と同様だが鍵が 128 ビット. The "arcfour" is the Arcfour stream cipher with 128 bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. Arcfour (and RC4) has problems with weak keys, and should be used with caution. "arcfour"は 128bit の鍵を持つ Arcfour ストリーム暗号だ. Arcfour 暗号は RC4 暗号 [SCHNEIER] と互換性があると思われている. RC4 は RSA データセキュリティの登録商標だ. Arcfour (と RC4) は弱い鍵があるという問題を持っているので, 使う際には注意が必要だ. The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. "idea-cbc"暗号は CBC モードの IDEA 暗号だ [SCHNEIER]. ##訳注: IDEAの特許は切れた. The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode [RFC2144]. "cast128-cbc" 暗号は CBC モードの CAST-128 暗号だ [RFC2114]. The "none" algorithm specifies that no encryption is to be done. Note that this method provides no confidentiality protection, and it is not recommended. Some functionality (e.g. password authentication) may be disabled for security reasons if this cipher is chosen. "none" アルゴリズムはどんな暗号化もされていないことを示す. この方法は 秘密の保護をまったく提供しないし, 勧めれられない. この暗号が選ばれた場合 いくつかの機能 (たとえば パスワード認証) は セキュリティ上の理由から無効にしたほうがよい. Additional methods may be defined as specified in [SSH-ARCH]. 別の方法が [SSH-ARCH] で定義されているかもしれない. 5.4 Data Integrity 5.4 データの完全性 Data integrity is protected by including with each packet a message authentication code (MAC) that is computed from a shared secret, packet sequence number, and the contents of the packet. データの完全性 は それぞれのパケットに含まれる 共通で秘密のパケットのシーケンス番号とパケットの内容から計算される メッセージ認証コード (MAC) によって保護される. The message authentication algorithm and key are negotiated during key exchange. Initially, no MAC will be in effect, and its length MUST be zero. After key exchange, the selected MAC will be computed before encryption from the concatenation of packet data: メッセージ認証アルゴリズムとその鍵は, 鍵交換の際に取り決められる. 最初は, MAC は有効ではなく, その流さは ゼロでなくてはならない. 鍵交換のあと, 選択された MAC が パケットのデータのつらなりから 暗号化の前に計算される. mac = MAC (key, sequence_number || unencrypted_packet) where unencrypted_packet is the entire packet without MAC (the length fields, payload and padding), and sequence_number is an implicit packet sequence number represented as uint32. The sequence number is initialized to zero for the first packet, and is incremented after every packet (regardless of whether encryption or MAC is in use). It Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9] Internet-Draft SSH Transport Layer Protocol Oct 2003 is never reset, even if keys/algorithms are renegotiated later. It wraps around to zero after every 2^32 packets. The packet sequence number itself is not included in the packet sent over the wire. ここで unencrypted_packet は MAC を除いたパケットの全て (the length fields, payload , padding) で, sequence_number は uint32 で表わされる 暗黙のパケットシーケンス番号だ. このシーケンス番号は最初のパッケトで ゼロに初期化され, パケットごとに増えていく (どんな暗号や MAC が使われて いても). これは決してリセットされない, たとえ 鍵やアルゴリズムが あとで再び取り決められても. これは, 2^32 個のパケットごとに 0 に戻る. パケットのシーケンス番号自体は, 通信で送られるパケットには 含まれない. The MAC algorithms for each direction MUST run independently, and implementations MUST allow choosing the algorithm independently for both directions. それぞれの方向の MAC のアルゴリズムは独立に動かなくてはならないし, 実装はそれぞれの方向のアルゴリズムを独立に選べるようにしなければ ならない. The MAC bytes resulting from the MAC algorithm MUST be transmitted without encryption as the last part of the packet. The number of MAC bytes depends on the algorithm chosen. MAC アルゴリズムから得られる MAC バイトは パケットの最後の部分に 暗号化なしで転送されなければならない. MAC の大きさは 選ばれたアルゴリズムに依存する. The following MAC algorithms are currently defined: 以下の MAC アルゴリズムが現在定義されている. hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key length = 20) hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest length = 12, key length = 20) hmac-md5 OPTIONAL HMAC-MD5 (digest length = key length = 16) hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest length = 12, key length = 16) none OPTIONAL no MAC; NOT RECOMMENDED Figure 1 The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use only the first n bits of the resulting value. "hmac-*"アルゴリズムは [RFC2104] で記述されている. "*-n" MAC は 結果の値の最初の n bit のみを使う. The hash algorithms are described in [SCHNEIER]. ハッシュアルゴリズムについては [SCHNEIER] に記述されている. Additional methods may be defined as specified in [SSH-ARCH]. 別の方法が [SSH-ARCH] で定義されているかもしれない. 5.5 Key Exchange Methods 5.5 鍵交換の方法 The key exchange method specifies how one-time session keys are generated for encryption and for authentication, and how the server authentication is done. この鍵交換の方法では 暗号化と認証のための一時セッション鍵がどのように 生成されるか, またどのようにサーバの認証が行なわれるかを定義する. Only one REQUIRED key exchange method has been defined: 一つだけ要求されている鍵交換の方法が定義されている. diffie-hellman-group1-sha1 REQUIRED This method is described later in this document. この方法についてはこの文書で後述する. Additional methods may be defined as specified in [SSH-ARCH]. 別の方法が [SSH-ARCH] で定義されているかもしれない. #Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol # draft-ietf-secsh-dh-group-exchange-xx.txt #OpenSSH にも実装されている Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10] Internet-Draft SSH Transport Layer Protocol Oct 2003 5.6 Public Key Algorithms 5.6 公開鍵アルゴリズム This protocol has been designed to be able to operate with almost any public key format, encoding, and algorithm (signature and/or encryption). このプロトコルは, ほぼあらゆる鍵のフォーマット, エンコーディング アルゴリズム (署名と/または暗号化) を操作できるように設計されている. There are several aspects that define a public key type: 公開鍵の種類を定義するのにいくつかの見地がある. o Key format: how is the key encoded and how are certificates represented. The key blobs in this protocol MAY contain certificates in addition to keys. o 鍵のフォーマット: どのように鍵がエンコードされどのように 証明が表されるか. このプロトコルでは鍵のブロブ (かたまり) は鍵に加えて 証明書も持ってもよい. o Signature and/or encryption algorithms. Some key types may not support both signing and encryption. Key usage may also be restricted by policy statements in e.g. certificates. In this case, different key types SHOULD be defined for the different policy alternatives. o 署名 と/ないし 暗号化のアルゴリズム. いくつかの種類の鍵は 署名と暗号化の双方をサポートしていない. 鍵の使い方は, たとえば証明書中のポリシーの声明によって制限されることもある. この場合, 異なる種類の鍵は異なるポリシーの選択肢として 定義される必要がある. o Encoding of signatures and/or encrypted data. This includes but is not limited to padding, byte order, and data formats. o 署名 と/ないし 暗号化のエンコーディング. これは (データを? 含んでいるが) パディングやバイトオーダー, データフォーマットに制限されない. The following public key and/or certificate formats are currently defined: 次に示す公開鍵 と/ないし 証明書のフォーマットが現在定義されている. ssh-dss REQUIRED sign Raw DSS Key ssh-rsa RECOMMENDED sign Raw RSA Key x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key) x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key) spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) Additional key types may be defined as specified in [SSH-ARCH]. 別の種類の鍵が [SSH-ARCH] で定義されているかもしれない. The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. 鍵の種類は常にはっきりと (アルゴリズムの決定やその他のソースから) 知らされなければならない. これは普通は鍵のブロブの中には含まれない. Certificates and public keys are encoded as follows: 証明書と公開鍵は次のようにエンコードされる: string certificate or public key format identifier byte[n] key/certificate data The certificate part may have be a zero length string, but a public key is required. This is the public key that will be used for authentication; the certificate sequence contained in the certificate blob can be used to provide authorization. 証明書の部分は長さ 0 の文字列かもしれないが, 公開鍵は必要だ. これは, 認証に使われる公開鍵だ. 証明書のブロブに含まれる 証明書のシークエンスは認証を提供するのに使われる. Public key / certifcate formats that do not explicitly specify a signature format identifier MUST use the public key / certificate format identifier as the signature identifier. 署名のフォーマット識別子を明示的には定義しない 公開鍵 / 証明書のフォーマットは, 署名の識別子と同様に 公開鍵 / 証明書のフォーマット識別子を使わなくてはならない. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11] Internet-Draft SSH Transport Layer Protocol Oct 2003 Signatures are encoded as follows: 署名は以下のようにエンコードされる. string signature format identifier (as specified by the public key / cert format) byte[n] signature blob in format specific encoding. The "ssh-dss" key format has the following specific encoding: "ssh-dss" 鍵のフォーマットは以下のような明確なエンコーディングを持つ. string "ssh-dss" mpint p mpint q mpint g mpint y Here the p, q, g, and y parameters form the signature key blob. ここで, パラメータ p,q,g,y は 署名鍵のブロブからのものだ. Signing and verifying using this key format is done according to the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A description can also be found in [SCHNEIER]. この鍵のフォーマットを使っての署名と検証は, SHA-1 ハッシュを使う Digital Signature Standard [FIPS-186] によって行なわれる. 詳細は [SCHNEIER] にもある. The resulting signature is encoded as follows: ここから生じる署名は次のようにエンコードされる. string "ssh-dss" string dss_signature_blob dss_signature_blob is encoded as a string containing r followed by s (which are 160 bits long integers, without lengths or padding, unsigned and in network byte order). dss_signature_blob は (長さ (の情報?) やパディングなしの, 符号無しで ネットワークバイトオーダーの 160bit の整数) s のあとに r を含む 文字列としてエンコードされている. The "ssh-rsa" key format has the following specific encoding: "ssh-rsa" 鍵のフォーマットは以下のような明確なエンコーディングを持つ. string "ssh-rsa" mpint e mpint n Here the e and n parameters form the signature key blob. ここで, パラメータ e,n は 署名鍵のブロブからのものだ. Signing and verifying using this key format is done according to [SCHNEIER] and [PKCS1] using the SHA-1 hash. この鍵のフォーマットを使っての署名と検証は, SHA-1 ハッシュを利用して [SCHNEIER] と [PKCS1] に従って行なわれる. The resulting signature is encoded as follows: ここから生じる署名は次のようにエンコードされる. string "ssh-rsa" string rsa_signature_blob rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned and in network byte order). rsa_signature_blob は (長さ (の情報?) やパディングなしの, 符号無しで ネットワークバイトオーダーの整数) s を含む文字列として エンコードされる. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12] Internet-Draft SSH Transport Layer Protocol Oct 2003 The "spki-sign-rsa" method indicates that the certificate blob contains a sequence of SPKI certificates. The format of SPKI certificates is described in [RFC2693]. This method indicates that the key (or one of the keys in the certificate) is an RSA-key. "spki-sign-rsa" 法は, 証明書のブロブが SPKI 証明書のシークエンス を含むことを示す. SPKI 証明書のフォーマットは [RFC2693] に記述されている. この方法は 鍵 (ないし証明書中の鍵の一つ) が RSA 鍵であることを示す. The "spki-sign-dss". As above, but indicates that the key (or one of the keys in the certificate) is a DSS-key. "spki-sign-dss". 上と同様だが, 鍵 (ないし証明書中の鍵の一つ) が DSS 鍵であることを示す. The "pgp-sign-rsa" method indicates the certificates, the public key, and the signature are in OpenPGP compatible binary format ([RFC2440]). This method indicates that the key is an RSA-key. "pgp-sign-rsa" 法は, 証明書, 公開鍵, 署名が OpenPGP 互換 バイナリフォーマット ([RFC2440]) であることを示す. この方法は鍵が RSA 鍵であることを示す. The "pgp-sign-dss". As above, but indicates that the key is a DSS-key. pgp-sign-dss". 上と同様だが, この方法は鍵が DSS 鍵であることを示す. 6. Key Exchange 6. 鍵の交換 Key exchange begins by each side sending lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations at any given time will use the same preferred algorithm. Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm if appropriate for the preferred method. 鍵の交換はお互いがサポートするアルゴリズムのリストを送りあって 始まる. お互いがその範疇で優先するアルゴリズムがあるが, その時々で多くの実装が同じアルゴリズムを優先して 使うことが仮定されている. どちらの側ももう一方の側がどんなアルゴリズムを使うかを推測しても よいし, 好む方法にとって適切ならそのアルゴリズムに従って 最初の鍵交換パケットを送ってもよい. Guess is considered wrong, if: 以下の場合は推測が間違っているとみなされる: o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or o 鍵交換のアルゴリズム と/ないし ホスト鍵のアルゴリズムが 誤って推測された (サーバとクライアントが異なるアルゴリズムを 優先している) か, o if any of the other algorithms cannot be agreed upon (the procedure is defined below in Section Section 6.1). o もう一方の側のアルゴリズムのどれにも一致できない. (この手続きは 以下のセクション 6.1 で定義される) Otherwise, the guess is considered to be right and the optimistically sent packet MUST be handled as the first key exchange packet. さもなければ, 推測は正しいと見なされ, 楽観的に送られたパケットは 最初の鍵交換のパケットとして扱われなくてはならない. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet. しかし, 推測が間違っていて一方からないし両方から楽観的に送られた パケットがあるなら, そのようなパケットは無視されなければならない (たとえその推測の誤りが最初のパケットの内容に影響しなくても) し, 適当な側が正しい最初のパケットを送らなければならない. Server authentication in the key exchange MAY be implicit. After a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. 鍵認証でのサーバの認証は, 明示的でなくてもよい. サーバ認証が明示的でない場合は鍵交換のあと, クライアントは その先のデータを送る前に自らのサービス要求メッセージの前に 反応を待たなくてはならない. 6.1 Algorithm Negotiation 6.1 アルゴリズムの取り決め Key exchange begins by each side sending the following packet: 鍵交換は, それぞれの側から送られる 次のようなパケットによって始められる. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13] Internet-Draft SSH Transport Layer Protocol Oct 2003 byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string mac_algorithms_client_to_server string mac_algorithms_server_to_client string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension) Each of the algorithm strings MUST be a comma-separated list of algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each supported (allowed) algorithm MUST be listed in order of preference. どのアルゴリズム文字列の, アルゴリズム名のコンマ区切りリスト でなければならない ( [SSH-ARCH] のアルゴリズム命名規則を見よ) どのサポートする (許可する) アルゴリズムも, 優先する順に並べなくてはならない. The first algorithm in each list MUST be the preferred (guessed) algorithm. Each string MUST contain at least one algorithm name. どのリストにおいても最初のアルゴリズムが, 優先する (推測する) アルゴリズムでなくてはならない. それぞれの文字列は 少なくとも一つのアルゴリズム名を含まねばならない. cookie The cookie MUST be a random value generated by the sender. Its purpose is to make it impossible for either side to fully determine the keys and the session identifier. このクッキーは送り手によって生成されたランダムな値でなければ ならない. この目的は, 鍵とセッションの識別子をもう一方の側が 完全に割り出すことを不可能にすることだ. kex_algorithms Key exchange algorithms were defined above. The first algorithm MUST be the preferred (and guessed) algorithm. If both sides make the same guess, that algorithm MUST be used. Otherwise, the following algorithm MUST be used to choose a key exchange method: iterate over client's kex algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: 鍵交換のアルゴリズムは上で定義された. 最初のアルゴリズムが 優先する ( また 推測した) アルゴリズムでなくてはならない. 両側が同じ推測をしたなら, そのアルゴリズムが使われなければ ならない. そうでないなら, 次のアルゴリズムによって 鍵交換の方法の選択がされなければならない. これはクライアントの 鍵アルゴリズムに対して一つずつ繰り返す. 次の条件を見たす 最初のアルゴリズムを選択する. + the server also supports the algorithm, + サーバもそのアルゴリズムをサポートする. + if the algorithm requires an encryption-capable host key, there is an encryption-capable algorithm on the server's server_host_key_algorithms that is also supported by the client, and + そのアルゴリズムが暗号化可能なホスト鍵を必要としているなら サーバの, クライアントもサポートしている, server_host_key_algorithms に暗号化可能なアルゴリズム がある, また + if the algorithm requires a signature-capable host key, there is a signature-capable algorithm on the server's server_host_key_algorithms that is also supported by the client. + アルゴリズムが署名可能なホスト鍵を必要としていなら, サーバの, クライアントもサポートしている server_host_key_algorithms に 署名可能なアルゴリズムが ある. + If no algorithm satisfying all these conditions can be found, the connection fails, and both sides MUST disconnect. + これらすべての条件を見たすアルゴリズムを見つけることができない なら, 接続は失敗し, 両方の側は接続を切らなければならない. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14] Internet-Draft SSH Transport Layer Protocol Oct 2003 server_host_key_algorithms List of the algorithms supported for the server host key. The server lists the algorithms for which it has host keys; the client lists the algorithms that it is willing to accept. (There MAY be multiple host keys for a host, possibly with different algorithms.) サーバホスト鍵についてサポートするアルゴリズムのリスト. サーバは自らが保持しているホスト鍵のアルゴリズムを列挙 する. クライアントは受け入れることのできる アルゴリズムを列挙する. (ホストに複数の, ことによると 異なるアルゴリズムのホスト鍵があってもよい) Some host keys may not support both signatures and encryption (this can be determined from the algorithm), and thus not all host keys are valid for all key exchange methods. ホスト鍵のうちいくつかは署名と暗号化の両方をサポートしないかも しれない (これはアルゴリズムによって決められる) し,それゆえ すべてのホスト鍵がすべての鍵交換の方法にとって有効ということは ない. Algorithm selection depends on whether the chosen key exchange algorithm requires a signature or encryption capable host key. It MUST be possible to determine this from the public key algorithm name. The first algorithm on the client's list that satisfies the requirements and is also supported by the server MUST be chosen. If there is no such algorithm, both sides MUST disconnect. アルゴリズムの選択は選ばれた鍵交換アルゴリズムが署名ないし暗号化 可能な鍵を必要とするかどうかに依存する. 公開鍵アルゴリズム名 からこのアルゴリズムを決定することが可能でなくてはならない. この必要を見たしサーバによってもサポートされる クライアントの リストの最初のアルゴリズムが選ばれなければならない. そのようなアルゴリズムがなければ, 両側で接続を切らねば ならない. encryption_algorithms Lists the acceptable symmetric encryption algorithms in order of preference. The chosen encryption algorithm to each direction MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. 優先する順に並べられた受け入れられる対称暗号化アルゴリズムを 列挙する. それぞれの方向で選ばれる暗号化アルゴリズムは クライアント側のリストでもサーバ側のリストでも最初のアルゴリズム でなければならない. そのようなアルゴリズムがなかったら. 両側で接続を切らねばならない. Note that "none" must be explicitly listed if it is to be acceptable. The defined algorithm names are listed in Section Section 5.3. "none" は, それがもし受け入れられる場合は, 明示的に列挙されなければならないことに注意. 定義された アルゴリズム名はセクション 5.3 に列挙されている. mac_algorithms Lists the acceptable MAC algorithms in order of preference. The chosen MAC algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. 優先する順に並べられた受け入れられる MAC のアルゴリズムを 列挙する. それぞれの方向で選ばれる MAC アルゴリズムは クライアント側のリストでもサーバ側のリストでも最初のアルゴリズム でなければならない. そのようなアルゴリズムがなかったら. 両側で接続を切らねばならない. Note that "none" must be explicitly listed if it is to be acceptable. The MAC algorithm names are listed in Section Figure 1. "none" は, それがもし受け入れられる場合は, 明示的に列挙されなければならないことに注意. MAC アルゴリズム名は図 1 に列挙されている. compression_algorithms Lists the acceptable compression algorithms in order of preference. The chosen compression algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. 優先する順に並べられた受け入れられる圧縮アルゴリズムを 列挙する. それぞれの方向で選ばれる圧縮アルゴリズムは クライアント側のリストでもサーバ側のリストでも最初のアルゴリズム でなければならない. そのようなアルゴリズムがなかったら. 両側で接続を切らねばならない. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15] Internet-Draft SSH Transport Layer Protocol Oct 2003 Note that "none" must be explicitly listed if it is to be acceptable. The compression algorithm names are listed in Section Section 5.2. "none" は, それがもし受け入れられる場合は, 明示的に列挙されなければならないことに注意. 圧縮 アルゴリズム名は Section 5.2 に列挙されている. languages This is a comma-separated list of language tags in order of preference [RFC3066]. Both parties MAY ignore this list. If there are no language preferences, this list SHOULD be empty. Language tags SHOULD NOT be present unless they are known to be needed by the sending party. これは優先する順に並べられた言語タグのコンマ区切りリストだ [RFC3066]. どちらの側もこのリストは無視してよい. もし優先する言語が ないなら, このリストは空にしておく必要がある. 言語タグは, 送り手側が必要としていると知られていなければ 存在しないほうがいい. first_kex_packet_follows Indicates whether a guessed key exchange packet follows. If a guessed packet will be sent, this MUST be TRUE. If no guessed packet will be sent, this MUST be FALSE. 推測した交換のパケットが続くかを示す. 推測したパケットが送られるなら, ここは TRUE でなければならない. 推測したパケットが送られないなら, ここは FALSE でなければならない. After receiving the SSH_MSG_KEXINIT packet from the other side, each party will know whether their guess was right. If the other party's guess was wrong, and this field was TRUE, the next packet MUST be silently ignored, and both sides MUST then act as determined by the negotiated key exchange method. If the guess was right, key exchange MUST continue using the guessed packet. 一方の側から SSH_MSG_KEXINIT パケットを受けとると それぞれの側で推測が正しかったかどうかわかる. もし一方の側の推測が間違っていて, このフィールドが TRUE であったら, 次のパケットはまったく無視され, そして両側が 鍵交換法が交渉して決定されたとして働かなければ ならない. もし推測が正しいなら, 鍵交換はその推測されたパケット を用いて続けられる. After the KEXINIT packet exchange, the key exchange algorithm is run. It may involve several packet exchanges, as specified by the key exchange method. KEXINIT パケットが交換されたら, 鍵交換アルゴリズムが進行する. この鍵交換の方法で定義されているように, いくつかのパケットの交換が 行なわれるかもしれない. 6.2 Output from Key Exchange 6.2 鍵交換からの出力 The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. 鍵交換は 2 つの値を生成する. 共有の秘密 K と 交換のハッシュ H だ. 暗号と認証の鍵はこれらから導出される. 最初の鍵交換による 交換ハッシュ H は これとは別に, この接続にとって特有な識別子として セッション識別子としても使われる. これは秘密鍵を持っている証拠 として署名するデータの一部として, 認証法に使われる. 一度計算されたら セッション識別子は変更されない, たとえあとで鍵交換がまた行なわれても. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we'll call it HASH. それぞれの鍵交換の方法では鍵交換で使うハッシュ関数が定義されている. 同じハッシュ関数が鍵の導出に使われなければならない. ここでは それを HASH と呼ぶ. Encryption keys MUST be computed as HASH of a known value and K as follows: 暗号化鍵は次のように既知の値と K のハッシュによって計算されなければ ならない. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16] Internet-Draft SSH Transport Layer Protocol Oct 2003 o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data."A" means the single character A, ASCII 65). o クライアントからサーバへの最初の初期化ベクトル : HASH(K || H || "A" || session_id) (ここで K は mpint で "A"はバイトで session_id は生のデータで エンコードされている. "A" は一文字の A,ASCII 65 の A だ) o Initial IV server to client: HASH(K || H || "B" || session_id) o サーバからクライアントへの最初の初期化ベクトル: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o 以下略 o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. 128 bits (16 bytes) MUST be used for algorithms with variable-length keys. The only variable key length algorithm defined in this document is arcfour). For other algorithms, as many bytes as are needed are taken from the beginning of the hash value. If the key length needed is longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words: 鍵のデータはハッシュの出力の最初から取られなければならない. 可変長の鍵のアルゴリズムでは 128bit (16 バイト) 使う必要がある. (この文書で定義している唯一の鍵の長さが可変のアルゴリズムは arcfour だけ (訳注: 原文は'('が足りないと思われる.) その他のアルゴリズムでは, 必要なバイトを ハッシュ値の最初から得る. もし鍵の長さが HASH の出力よりも長いなら, 鍵は, K と H といままでの鍵の連結の HASH を計算しその結果のバイト (HASH が生成するのと同じ長さ) を鍵に追加して, 拡張される. この過程は 十分な鍵の材料が得られるまで繰り返される. 鍵はこの値の最初から 取られる. いいかれれば: K1 = HASH(K || H || X || session_id) (X is e.g. "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH. この過程は, もし K の中のエントロピー量が HASH の内部状態のサイズよりも 大きかったなら, エントロピーを失なわせる. 6.3 Taking Keys Into Use 6.3 鍵の使用 Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms. 鍵交換はそれぞれの側が SSH_MSG_NEWKEYS メッセージを送ることで 終了する. このメッセージは古い鍵とアルゴリズムによって送られる. このメッセージの後のすべてのメッセージは, 新しい鍵とアルゴリズム を使わなければならない. When this message is received, the new keys and algorithms MUST be taken into use for receiving. このメッセージを受け取ったなら, 新しい鍵とアルゴリズムが受信のために 使われなければならない. This message is the only valid message after key exchange, in addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages. The purpose of this message is to ensure that a party is able to respond with a disconnect message that the other party can understand if something goes wrong with the key exchange. Implementations MUST NOT accept any other messages after key exchange before receiving SSH_MSG_NEWKEYS. このメッセージは鍵交換に加えて SSH_MSG_DEBUG,SSH_MSG_DISCONNECT,SSH_MSG_IGNORE メッセージの 後でのみ有効なメッセージだ. このメッセージの目的は, もし鍵交換でなにかが失敗した場合にもう一方が理解できる 切断メッセージを送れることを保証することだ. 実装は 鍵交換のあとで SSH_MSG_NEWKEYS を受けとる前には他のどんなメッセージも 受け付けてはならない. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17] Internet-Draft SSH Transport Layer Protocol Oct 2003 byte SSH_MSG_NEWKEYS 7. Diffie-Hellman Key Exchange 7. Diffie-Hellman 鍵交換 The Diffie-Hellman key exchange provides a shared secret that can not be determined by either party alone. The key exchange is combined with a signature with the host key to provide host authentication. Diffie-Hellman 鍵交換は 一方だけでは決定できない共有の秘密を提供 する. 鍵交換は ホスト認証を提供するホスト鍵による署名と 結合されている. In the following description (C is the client, S is the server; p is a large safe prime, g is a generator for a subgroup of GF(p), and q is the order of the subgroup; V_S is S's version string; V_C is C's version string; K_S is S's public host key; I_C is C's KEXINIT message and I_S S's KEXINIT message which have been exchanged before this part begins): 以下に解説を示す ( C はクライアント S はサーバ p は大きく安全な素数 g は GF (p) 部分群のジェネレータ q は部分群のオーダ.V_S は S のバージョン文字列 V_C は C のバージョン文字列.K_S は S の公開ホスト鍵,I_C は C の KEXINIT メッセージ I_S は S の KEXINIT メッセージで それぞれこの部分が始まる前に交換されている) 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. C sends "e" to S. 1. C は 乱数 x (1