Network Working Group T. Ylonen Internet-Draft T. Kivinen Expires: August 29, 2002 SSH Communications Security Corp M. Saarinen University of Jyvaskyla T. Rinne S. Lehtinen SSH Communications Security Corp February 28, 2002 SSH Authentication Protocol draft-ietf-secsh-userauth-15.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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-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." The list of current Internet-Drafts can be accessed at 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. This Internet-Draft will expire on August 29, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract 概要 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host- based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides Ylonen, et. al. Expires August 29, 2002 [Page 1] Internet-Draft SSH Authentication Protocol February 2002 a single authenticated tunnel for the SSH connection protocol. SSH は, 安全ではないネットワーク越しの, 安全なリモートログイン及び他の 安全なネットワークサービスのためのプロトコルだ. この文書では、 SSH認証プロトコルフレームワークと、公開鍵、パスワード、ホストベース のクライアント認証方について記述している。それ以外の認証法については 別々の文書に記述されている。SSH認証プロトコルはSSHトランスポート層 プロトコルの上で動き、SSHコネクションプロトコルのための 一つの認証されたトンネルを提供する。 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Authentication Protocol Framework . . . . . . . . . . . . 3 2.1 Authentication Requests . . . . . . . . . . . . . . . . . . . 4 2.2 Responses to Authentication Requests . . . . . . . . . . . . . 4 2.3 The "none" Authentication Request . . . . . . . . . . . . . . 6 2.4 Completion of User Authentication . . . . . . . . . . . . . . 6 2.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Authentication Protocol Message Numbers . . . . . . . . . . . 7 4. Public Key Authentication Method: publickey . . . . . . . . . 7 5. Password Authentication Method: password . . . . . . . . . . . 9 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 13 9. Additional Information . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 Ylonen, et. al. Expires August 29, 2002 [Page 2] Internet-Draft SSH Authentication Protocol February 2002 1. Introduction 1. イントロダクション The SSH authentication protocol is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. This protocol assumes that the underlying protocols provide integrity and confidentiality protection. SSH認証プロトコルは汎用のユーザ認証プロトコルだ。SSH トランスポート層プロトコル[SSH-TRANS]上で動くことを意図している。 このプロトコルは、その下のプロトコルが 完全性と秘密の保持を 提供していることを仮定している。 This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation. この文書は、SSH アーキテクチャ文書[SSH-ARCH]を読んだあとで 読むべきだ。この文書はアーキテクチャ文書からの用語や表記を 参照やさらなる説明なしで自由に使う。 The service name for this protocol is "ssh-userauth". このプロトコルのサービス名は "ssh-userauth"だ。 When this protocol starts, it receives the session identifier from the lower-level protocol (this is the exchange hash H from the first key exchange). The session identifier uniquely identifies this session and is suitable for signing in order to prove ownership of a private key. This protocol also needs to know whether the lower- level protocol provides confidentiality protection. このプロトコルが始まるとき、プロトコルは低レベルのプロトコルからの セッション識別子を受けとる(これは 最初の鍵交換の際の交換ハッシュ Hだ)。 このセッション識別子はユニークにこのセッションを識別し、秘密鍵の 所有を証明するための署名に適している。このプロトコルは秘密の保持を 提供する低レベルのプロトコルがあるかどうか知る必要もある。 2. The Authentication Protocol Framework 2. アーキテクチャプロトコルの枠組 The server drives the authentication by telling the client which authentication methods can be used to continue the exchange at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user, when multiple methods are offered by the server. サーバは、クライアントに、やり取りを続けるのにどの認証法を使うことが できるか伝えることで、認証を始る。クライアントはサーバが 挙げた方法を順序にかかわらず試すことができる。これはサーバに もし望むなら認証の過程を完全に管理することを許しているが、 サーバから複数の方法が提供される場合にはクライアントが サポートしているかユーザにとってもっとも便利な方法を使う十分な 自由度も与えている。 Authentication methods are identified by their name, as defined in [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, unless the client is to be allowed in without any authentication, in which case the server MUST accept this request. The main purpose of sending this request is to get the list of supported methods from the server. 認証法はその名前で識別され、[SSH-ARCH]で定義されている。 認証法 "none" は予約されているが、サポートしているとリストに挙げて はならない。しかしこれはクライアントから送られてくるかもしれない。 クライアントが認証がなくてもよいとしていない限り、 サーバはこの要求をいつも拒否しなくてはならない。認証がないことを 許している場合は、サーバはこの要求を受入れなければならない。この要求を 送る主要な目的は、サーバからサポートしている方法のリストを 得ることだ。 The server SHOULD have a timeout for authentication, and disconnect if the authentication has not been accepted within the timeout period. The RECOMMENDED timeout period is 10 minutes. Additionally, the implementation SHOULD limit the number of failed authentication attempts a client may perform in a single session (the RECOMMENDED limit is 20 attempts). If the threshold is exceeded, the server SHOULD disconnect. サーバは認証のためのタイムアウトを持ちタイムアウトの期限内に 認証が受入れられなかったら切断する必要がある。推奨されるタイムアウト の期限は10分だ。さらに、実装は、クライアントが一度のセッションの なかで試みて失敗した認証の試行回数を制限する必要がある(推奨される 試行回数は20回だ)このスレッショルドを超えたら、サーバは接続を 切断する必要がある。 Ylonen, et. al. Expires August 29, 2002 [Page 3] Internet-Draft SSH Authentication Protocol February 2002 2.1 Authentication Requests 2.1 認証の要求 All authentication requests MUST use the following message format. Only the first few fields are defined; the remaining fields depend on the authentication method. すべての認証の要求は次のメッセージフォーマットを使わなくてはならない。 最初のわずかのフィールドだけが定義されている。残りのフィールドは 認証法に依存する。 byte SSH_MSG_USERAUTH_REQUEST string user name (in ISO-10646 UTF-8 encoding [RFC2279]) string service name (in US-ASCII) string method name (US-ASCII) The rest of the packet is method-specific. パケットの残りの部分は方法に依存している。 The user name and service are repeated in every new authentication attempt, and MAY change. The server implementation MUST carefully check them in every message, and MUST flush any accumulated authentication states if they change. If it is unable to flush some authentication state, it MUST disconnect if the user or service name changes. ユーザ名とサービスは新しい認証の試みのたびに繰り返され、 変わってもよい。サーバの実装はすべてのメッセージに対して 注意深くこれらを検査しなければならず、もし変わっていたら これまで蓄積していた認証の情報をすべてはき出して捨てなければならない。 もし捨てられない認証の状態があるなら、ユーザかサービスの名前が変更 されたら切断しなければならない。 The service name specifies the service to start after authentication. There may be several different authenticated services provided. If the requested service is not available, the server MAY disconnect immediately or at any later time. Sending a proper disconnect message is RECOMMENDED. In any case, if the service does not exist, authentication MUST NOT be accepted. サービス名は認証のあとで始めるサービスを指定する。いくつかの異なる 認証されたサービスが提供されているだろう。要求されたサービスが 利用できないなら、サーバはすぐに切断してもよいし、 あとで切断してもよい。適切な disconnect メッセージを送ることが 推奨される. どんな場合でも、サービスが存在しないなら、認証を 受け入れてはならない。 If the requested user does not exist, the server MAY disconnect, or MAY send a bogus list of acceptable authentication methods, but never accept any. This makes it possible for the server to avoid disclosing information on which accounts exist. In any case, if the user does not exist, the authentication request MUST NOT be accepted. 要求されたユーザが存在しないなら、サーバは切断してもよし、 受け入れ可能な認証法の 嘘のリストを送ってもよいが、 受け入れてはならない。これによってサーバが アカウントが存在するかどうかの情報を明らかにするのを避ける ことができる。どんな場合でも、ユーザが存在しないなら、 認証を受け入れてはならない。 While there is usually little point for clients to send requests that the server does not list as acceptable, sending such requests is not an error, and the server SHOULD simply reject requests that it does not recognize. クライアントにとって、サーバが受け入れると挙げていない要求を おくることは普通意味がないことだが、それらの要求を送ることは エラーではなく、サーバは要求が理解できないならそれを単純に 拒否する必要がある。 An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication method used, and the client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one. 認証の要求はメッセージのさらなる交換により終ってもよい。 これらのメッセージのすべてが、使う認証法に依存する。クライアントは 新しい SSH_MSG_USERAUTH_REQUEST メッセージをいつでも続けてもよい この時サーバは、前の認証の試行を捨てて新しいもので続けなければ ならない。 2.2 Responses to Authentication Requests 2.2 認証の要求に対する応答 If the server rejects the authentication request, it MUST respond with the following: サーバが認証の要求を拒否するなら、次のものを返さなければならない。 Ylonen, et. al. Expires August 29, 2002 [Page 4] Internet-Draft SSH Authentication Protocol February 2002 byte SSH_MSG_USERAUTH_FAILURE string authentications that can continue boolean partial success "Authentications that can continue" is a comma-separated list of authentication method names that may productively continue the authentication dialog. "Authentications that can continue" は 認証の交渉を有効に続ける ことができる認証法の名前のコンマ区切りリストだ。 It is RECOMMENDED that servers only include those methods in the list that are actually useful. However, it is not illegal to include methods that cannot be used to authenticate the user. サーバはリストに実際に使える方法のみを含めることが推奨される。しかし ユーザを認証するのに使うことができない方法を含めることも不法ではない。 Already successfully completed authentications SHOULD NOT be included in the list, unless they really should be performed again for some reason. すでに成功して終了した認証はリストにリストに含めないほうがよい。 ただし何らかの理由で再び実際に実行されなければならない場合の除いて。 "Partial success" MUST be TRUE if the authentication request to which this is a response was successful. It MUST be FALSE if the request was not successfully processed. "Partial success" は このパケットが返答である 認証要求が成功した場合はTRUEでなくてはならない。要求が 成功裏に処理されなかった場合はFALSEでなければならない。 #複数の認証を要求している際にさらなる認証を要求する場合に使う When the server accepts authentication, it MUST respond with the following: サーバが認証を受け付けるなら、次のものを返さなければならない。 byte SSH_MSG_USERAUTH_SUCCESS Note that this is not sent after each step in a multi-method authentication sequence, but only when the authentication is complete. 複数の方法での認証シーケンスのそれぞれのステップの後では これは送られなく、認証がすべて完了した際にのも送られることに注意。 The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST process each request completely and acknowledge any failed requests with a SSH_MSG_USERAUTH_FAILURE message before processing the next request. クライアントは、先の要求に対する返答を待つことなしに 複数の認証要求を送ってもよい。サーバはそれぞれの要求を完全に 処理しなくてはならず、次の要求を処理する前に どんな失敗した要求も SSH_MSG_USERAUTH_FAILURE メッセージで知らせなくてはならない。 A request that results in further exchange of messages will be aborted by a second request. It is not possible to send a second request without waiting for a response from the server, if the first request will result in further exchange of messages. No SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. さらなるメッセージの交換が必要な要求に対して2番目の要求を 送ってしまうと認証は中止される。 最初の要求がさらなるメッセージの交換を必要とするなら サーバからの返答を待たずに2番目の要求を送ることはできない。(...) SSH_MSG_USERAUTH_FAILURE メッセージは 中止された方法に対しては 送られない。 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. SSH_MSG_USERAUTH_SUCCESS は たった一度だけ送られなければならない。 SSH_MSG_USERAUTH_SUCCESS が送られたなら、それ以後に受けとった さらなる認証要求は静かに無視される必要がある。 Any non-authentication messages sent by the client after the request that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to the service being run on top of this protocol. Such messages can be identified by their message numbers (see Section Message Numbers Ylonen, et. al. Expires August 29, 2002 [Page 5] Internet-Draft SSH Authentication Protocol February 2002 (Section 3)). SSH_MSG_USERAUTH_SUCCESSが送られた要求のあとにクライアントから 送られるどんな認証関係でないメッセージも、このプロトコルの上で 走るサービスを経由されなければならない。そのようなメッセージは メッセージの番号によって識別される(メッセージ番号のSection( Section 3 を見よ) 2.3 The "none" Authentication Request 2.3 "none" 認証要求 A client may request a list of authentication methods that may continue by using the "none" authentication method. クライアントは "none"認証法を使って続けることができる認証法 リストを要求してもよい。 If no authentication at all is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication methods that can continue. どんな認証もユーザに対して必要でないのなら、サーバは SSH_MSG_USERAUTH_SUCCESS を返さなくてはならない。そうでないなら サーバは SSH_MSG_USERAUTH_FAILUREを返さねばならない。このとき 続けることのできる認証法のリストを共に返してもよい。 This method MUST NOT be listed as supported by the server. この方法は、サーバがサポートしているとリストに載せてはならない。 2.4 Completion of User Authentication 2.4 ユーザ認証の完了 Authentication is complete when the server has responded with SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received after sending this message SHOULD be silently ignored. サーバが SSH_MSG_USERAUTH_SUCCESS を返したとき認証は完了する。 このメッセージを送ったあとに受け取ったすべての認証に関連したメッセージ は静かに無視される必要がある。 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested service. SSH_MSG_USERAUTH_SUCCESS を送ったあと、サーバは要求されたサービスを 始める。 2.5 Banner Message 2.5 バナー メッセージ In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from `/etc/issue', or use "tcp wrappers" or similar software to display a banner before issuing a login prompt. いくつかの司法では、認証の前に警告のメッセージを送ることが 法的な保護を得るのに適切だとされている。たとえば 多くのUNIXマシンでは 普通 `/etc/issue' からのテキストを表示したり ログインプロンプトを出すまえにバナーを表示する "tcp wrappers" や 同種のソフトウェアを使う。 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time before authentication is successful. This message contains text to be displayed to the client user before authentication is attempted. The format is as follows: SSHサーバは、認証が成功する前にいつでも SSH_MSG_USERAUTH_BANNER メッセージを送ることができる。このメッセージは認証を試みる前に クライアントのユーザに表示されるテキストを含んでいる。その形式は 以下のようになっている。 byte SSH_MSG_USERAUTH_BANNER string message (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) The client SHOULD by default display the message on the screen. However, since the message is likely to be sent for every login attempt, and since some client software will need to open a separate window for this warning, the client software may allow the user to explicitly disable the display of banners from the server. The message may consist of multiple lines. クライアントはデフォルトでスクリーンにメッセージを表示する必要がある。 しかし、メッセージがすべてのログインの試行に対して送られ、 幾つかのクライアントソフトウェアがこの警告のために別のウィンドウを 開く必要があるので、クライアントソフトウェアはユーザが明示的に サーバからのバナーの表示を無効にすることを許してもよい。この メッセージは複数行からなってもよい。 If the message string is displayed, control character filtering Ylonen, et. al. Expires August 29, 2002 [Page 6] Internet-Draft SSH Authentication Protocol February 2002 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending terminal control characters. このメッセージ文字列が表示されるなら、端末コントロール文字を送ることに よる攻撃を避けるために[SSH-ARCH] で議論されている コントロール文字のフィルタをする必要がある. 3. Authentication Protocol Message Numbers 3。認証プロトコルのメッセージ番号 All message numbers used by this authentication protocol are in the range from 50 to 79, which is part of the range reserved for protocols running on top of the SSH transport layer protocol. この認証プロトコルで使われるメッセージ番号はすべて 50から 79の範囲 にある。SSHトランスポート層プロトコルの上で動くプロトコルのために 予約されている範囲の一部だ。 Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so receiving one of them before authentication is complete is an error, to which the server MUST respond by disconnecting (preferably with a proper disconnect message sent first to ease troubleshooting). 80とそれより上のメッセージ番号はこの認証プロトコルの後で動く プロトコルのために予約されている。認証が完了するより前に それらを受けとったらエラーであり、サーバは切断で反応しなければならない (なるべく、トラブルシューティングを容易にするために適切な切断 メッセージをまず送って)。 After successful authentication, such messages are passed to the higher-level service. サーバ認証が成功したあとは、これらのメッセージは高レベルのサービス へ渡される。 These are the general authentication message codes: これらは一般の認証メッセージのコードだ: #define SSH_MSG_USERAUTH_REQUEST 50 #define SSH_MSG_USERAUTH_FAILURE 51 #define SSH_MSG_USERAUTH_SUCCESS 52 #define SSH_MSG_USERAUTH_BANNER 53 In addition to the above, there is a range of message numbers (60..79) reserved for method-specific messages. These messages are only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST messages). Different authentication methods reuse the same message numbers. 上に挙げられてくるもの加えて、(60..79)の範囲のメッセージ番号が 方法に特有のメッセージとして予約されている。これらのメッセージは サーバからのも送られる(クライアントは SSH_MSG_USERAUTH_REQUEST のみ を送る)。 異なる認証法で同じメッセージ番号を再利用してよい。 4. Public Key Authentication Method: publickey 4. 公開鍵認証法 : publickey The only REQUIRED authentication method is public key authentication. All implementations MUST support this method; however, not all users need to have public keys, and most local policies are not likely to require public key authentication for all users in the near future. 要求されている唯一の認証法が、公開鍵認証だ。すべての実装は この方法をサポートしなればならない。しかしすべてのユーザが公開鍵を 持つ必要はなく、多くのローカルなポリシーは そのうちすべての ユーザに対して公開鍵認証を必要としなくなるだろう(?)。 With this method, the possession of a private key serves as authentication. This method works by sending a signature created with a private key of the user. The server MUST check that the key is a valid authenticator for the user, and MUST check that the signature is valid. If both hold, the authentication request MUST be accepted; otherwise it MUST be rejected. (Note that the server MAY require additional authentications after successful authentication.) この方法を使うと、秘密鍵を所有していることが認証となる。この方法は ユーザの秘密鍵で作った署名を送ることで働く。サーバはこの鍵が ユーザの正当な認証符号かを検査しなければならず、署名が正当か検査 しなければならない。両方とも有効なら、認証要求は受け付けられねば ならない。そうでかければ拒否されなければならない。(サーバは 認証が成功したあとに別の認証を要求してもよいことに注意) Private keys are often stored in an encrypted form at the client host, and the user must supply a passphrase before the signature can Ylonen, et. al. Expires August 29, 2002 [Page 7] Internet-Draft SSH Authentication Protocol February 2002 be generated. Even if they are not, the signing operation involves some expensive computation. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the key would be acceptable. 秘密鍵は、クライアントのホストでしばしば暗号化された形で 格納されており、ユーザは署名を生成する前にパスフレーズを入力 しなければならない。それがなくてさえ、署名の操作は いくらか手間のかかる 計算を引き起こす。必要のない処理とユーザとのやりとりを避けるために、 鍵を使った認証が受け入れられるかどうかを尋ねるために 次のメッセージが提供されている。 byte SSH_MSG_USERAUTH_REQUEST string user name string service string "publickey" boolean FALSE string public key algorithm name string public key blob Public key algorithms are defined in the transport layer specification [SSH-TRANS]. The public key blob may contain certificates. 公開鍵アルゴリズムはトランスポート層明細 [SSH-TRANS]のなかで 定義されている。公開鍵ブロブは証明書を含んでもよい。 Any public key algorithm may be offered for use in authentication. In particular, the list is not constrained by what was negotiated during key exchange. If the server does not support some algorithm, it MUST simply reject the request. どんな公開鍵アルゴリズムが認証で使うために提供されてもよい。 特に、鍵交換の間に取り決められたものにリストは制限されない。 サーバがアルゴリズムをサポートしていなかったら、単に要求を拒否 しなければならない。 The server MUST respond to this message with either SSH_MSG_USERAUTH_FAILURE or with the following: サーバは このメッセージに対して SSH_MSG_USERAUTH_FAILUREが 以下のものを応答しなければならない。 byte SSH_MSG_USERAUTH_PK_OK string public key algorithm name from the request string public key blob from the request To perform actual authentication, the client MAY then send a signature generated using the private key. The client MAY send the signature directly without first verifying whether the key is acceptable. The signature is sent using the following packet: 実際の認証を行なう場合、 クライアントは秘密鍵を使って生成された 署名をこれから送ってもよい。クライアントは鍵が受け入れられるか どうかまず検証することなしに直接署名を送ってもよい。 署名は次にパケットを使って送られる。 byte SSH_MSG_USERAUTH_REQUEST string user name string service string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication string signature Signature is a signature by the corresponding private key over the following data, in the following order: Signature は 以下の順序の以下のデータに対して秘密鍵で署名した署名だ。 string session identifier byte SSH_MSG_USERAUTH_REQUEST Ylonen, et. al. Expires August 29, 2002 [Page 8] Internet-Draft SSH Authentication Protocol February 2002 string user name string service string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication When the server receives this message, it MUST check whether the supplied key is acceptable for authentication, and if so, it MUST check whether the signature is correct. サーバはこのメッセージを受け取ったら、提供された鍵が認証のために 受け入れられるかを検査しなければならず、もし受け入れられたら 署名が正しいかどうか検査しなければならない。 If both checks succeed, this method is successful. Note that the server may require additional authentications. The server MUST respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed). 両方の検査が成功したら、この方法は成功だ。サーバは別の認証を要求 してもよいことに注意。サーバは SSH_MSG_USERAUTH_SUCCESS (さらなる認証が必要ない場合) か SSH_MSG_USERAUTH_FAILURE (要求が失敗した、ないしさらなる認証が必要な場合) を返さなければならない。 The following method-specific message numbers are used by the publickey authentication method. 次の方法に特有なメッセージ番号が、公開鍵認証法で使われる。 /* Key-based */ #define SSH_MSG_USERAUTH_PK_OK 60 5. Password Authentication Method: password 5. パスワード認証法: password Password authentication uses the following packets. Note that a server MAY request the user to change the password. All implementations SHOULD support password authentication. パスワード認証は次のパケットを使う。サーバはユーザにパスワードを 変えるよう要求してもよい。すべての実装はパスワード認証をサポートする 必要がある。 byte SSH_MSG_USERAUTH_REQUEST string user name string service string "password" boolean FALSE string plaintext password (ISO-10646 UTF-8) Note that the password is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the password and validates it against the password database. However, if the client reads the password in some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the password to ISO-10646 UTF-8 before transmitting, and the server MUST convert the password to the encoding used on that system for passwords. パスワードは ISO-10646 UTF-8 で エンコードされることに注意。 パスワードをどのように解釈しパスワードデータベースに対してどう 検証するかはサーバ次第だ。しかし、クライアントはその他の エンコーディング(例 ISO 8859-1 (ISO Latin1))でパスワード読む場合 クライアントは転送する前にパスワードを ISO-10646 UTF-8 に変換 しなければならず、サーバは、パスワードに対するシステムが使う エンコードにパスワードを変換しなければならない。 Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. Both the server and the client should check whether the underlying Ylonen, et. al. Expires August 29, 2002 [Page 9] Internet-Draft SSH Authentication Protocol February 2002 transport layer provides confidentiality (i.e., if encryption is being used). If no confidentiality is provided (none cipher), password authentication SHOULD be disabled. If there is no confidentiality or no MAC, password change SHOULD be disabled. このパケットの中で平文のパスワードが転送されるとはいっても パケット全体はトランスポート層によって暗号化されていることに注意。 サーバとクライアント双方が、下のトランスポート層が秘密性を 提供しているかどうか検査する必要がある (すなわち、暗号化が使われているか)。もし秘密性が提供されていないなら (暗号なし)、パスワード認証は無効とする必要がある。 秘密性もMACもないなら、パスワードの変更も無効とする必要がある。 Normally, the server responds to this message with success or failure. However, if the password has expired the server SHOULD indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In anycase the server MUST NOT allow an expired password to be used for authentication. 一般にサーバはこのメッセージに対して成功ないし失敗と返答する。 しかし、パスワードサーバで期限が切れている場合、サーバは SSH_MSG_USERAUTH_PASSWD_CHANGEREQを返してそれを示さなければならない。 どんな場合も、サーバは期限切れのパスワードを認証に使用することを 許してはならない。 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it. この場合、クライアントは別の認証法でもって続けてもよいし、 ユーザから新しいパスワードを要求して次のメッセージでパスワード 認証を再試行してもよい。クライアントは、 サーバがパスワードを聞いていないくても 普通のパスワード認証要求の 代わりにこのメッセージを送ってもよい。 byte SSH_MSG_USERAUTH_REQUEST string user name string service string "password" boolean TRUE string plaintext old password (ISO-10646 UTF-8) string plaintext new password (ISO-10646 UTF-8) The server must reply to request message with SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as follows: サーバは SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE,と それ以外にSSH_MSG_USERAUTH_PASSWD_CHANGEREQ のどれかのメッセージで 要求に答えなければならない。これらの意味は以下の通りだ。 SSH_MSG_USERAUTH_SUCCESS The password has been changed, and authentication has been successfully completed. SSH_MSG_USERAUTH_SUCCESS パスワードは変更され、 認証も成功裏に完了した。 SSH_MSG_USERAUTH_FAILURE with partial success The password has been changed, but more authentications are needed. partial success 付きの SSH_MSG_USERAUTH_FAILURE パスワードは変更されたが、さらなる認証が必要だ。 SSH_MSG_USERAUTH_FAILURE without partial success The password has not been changed. Either password changing was not supported, or the old password was bad. Note that if the server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports changing the password. partial success なしの SSH_MSG_USERAUTH_FAILURE パスワードは変更されていない。パスワードの変更がサポートされて いないか、古いパスワードが間違っている。サーバがすでに SSH_MSG_USERAUTH_FAILURE を送っている場合は、サーバは パスワードの変更をサポートしていることがわかっている SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because the new password was not acceptable (e.g. too easy to guess). SSH_MSG_USERAUTH_CHANGEREQ 新しいパスワードが 受けいれられなかった(例えば、簡単に推測できる)ので パスワードは変更されていない。 Ylonen, et. al. Expires August 29, 2002 [Page 10] Internet-Draft SSH Authentication Protocol February 2002 The following method-specific message numbers are used by the password authentication method. 次の方法に特有なメッセージ番号が、パスワード認証法で使われる。 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 6. Host-Based Authentication: hostbased 6. ホストベース認証: hostbased Some sites wish to allow authentication based on the host where the user is coming from, and the user name on the remote host. While this form of authentication is not suitable for high-security sites, it can be very convenient in many environments. This form of authentication is OPTIONAL. When used, special care SHOULD be taken to prevent a regular user from obtaining the private host key. いくつかのサイトは、ユーザがやってくるホストと リモートホストでのユーザ名に基いた認証を 許したいと思っている。この認証法は、高いレベルのセキュリティ を求めるサイトには適していないが、多くの環境で非常に便利だ。 この認証法は 選択できる(OPTIONAL)。使われる場合は、 一般のユーザが秘密ホスト鍵を得ることを妨げるよう、特別な配慮をする 必要がある。 The client requests this form of authentication by sending the following message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of authentication, except that the identity of the client host is checked more rigorously. クライアントはこの認証法を以下のメッセージを送ることで要求する。 これは UNIXの "rhosts"や"hosts.equiv"スタイルの認証と似ているが、 クライアントホストの身元がより厳密に検査されるところが違っている。 This method works by having the client send a signature created with the private key of the client host, which the server checks with that host's public key. Once the client host's identity is established, authorization (but no further authentication) is performed based on the user names on the server and the client, and the client host name. この方法は クライアントホストの秘密鍵を使って作られた署名を クライアントが送り、サーバがそのホストの公開鍵で検査することで動く。 一度クライアントホストの識別が確立したら、 サーバとクライアントのユーザ名と クライアントのホストを元にして認証(さらなる認証ではない)が 行なわれる。 byte SSH_MSG_USERAUTH_REQUEST string user name string service string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name (FQDN; US-ASCII) string user name on the client host (ISO-10646 UTF-8) string signature Public key algorithm names for use in "public key algorithm for host key" are defined in the transport layer specification. The "public host key for client host" may include certificates. "public key algorithm for host key" で使う公開鍵アルゴリズ名は トランスポート層明細に定義されている。"public host key for client host" は証明書を含んでもよい。 Signature is a signature with the private host key of the following data, in this order: Signature は 次の順序のデータの秘密ホスト鍵による署名だ。 string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service Ylonen, et. al. Expires August 29, 2002 [Page 11] Internet-Draft SSH Authentication Protocol February 2002 string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name (FQDN; US-ASCII) string user name on the client host(ISO-10646 UTF-8) The server MUST verify that the host key actually belongs to the client host named in the message, that the given user on that host is allowed to log in, and that the signature is a valid signature on the appropriate value by the given host key. The server MAY ignore the client user name, if it wants to authenticate only the client host. サーバは、ホスト鍵が実際にメッセージ中で示されたクライアントホスト に属しているか、そのホスト上の与えられたユーザがログインを 許されているか、その署名が与えられたホスト鍵によって適切な値に対する 正しい署名となっているか、を検証しなければならない。 It is RECOMMENDED that whenever possible, the server perform additional checks to verify that the network address obtained from the (untrusted) network matches the given client host name. This makes exploiting compromised host keys more difficult. Note that this may require special handling for connections coming through a firewall. 可能ならばいつでも、(信用されてない)ネットワークから得られた ネットワークから得られたネットワークアドレスが与えらえたクライアント ホスト名とマッチするか、サーバが検証することが推奨される。 これは、危険なホスト鍵を悪用することをより難しくする。 これには、ファイヤウォール越しから来る接続のために特別な処理が 必要になるだろう。 7. Security Considerations 7. セキュリティに関する考察 The purpose of this protocol is to perform client user authentication. It assumed that this runs over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. The transport layer provides forward secrecy for password authentication and other methods that rely on secret data. このプロトコルの目的は クライアントのユーザ認証を実行することだ。 これは、すでにサーバマシンが認証され、暗号化された通信チャンネルが 確立し、このセッションにおけるユニークなセッション識別子が 計算されている安全なトランスポート層プロトコル上で 走ることが仮定されている。トランスポート層は、パスワード認証や 秘密のデータに依存している他の方法に対して(進んだ?)秘密を提供する。 The server may go into a "sleep" period after repeated unsuccessful authentications to make key search harder. サーバは、繰り返される成功しない認証のあとで鍵の探索を難しくするために "sleep" 期 / 冬眠状態 に入ってもよい。 If the transport layer does not provide encryption, authentication methods that rely on secret data SHOULD be disabled. If it does not provide MAC protection, requests to change authentication data (e.g. password change) SHOULD be disabled to avoid an attacker from modifying the ciphertext without being noticed, rendering the new authentication data unusable (denial of service). もしトランスポート層が暗号化を提供していないなら、秘密の情報に頼る 認証法は無効にする必要がある。MACの保護が提供されていないなら、 認証データの変更(例えば パスワードの変更)の要求は、 攻撃者が 断わりなしに暗号文を変更して新しい認証データを使えなく する(DOS,サービス拒否)を避けるために無効にする必要がある。 Several authentication methods with different security characteristics are allowed. It is up to the server's local policy to decide which methods (or combinations of methods) it is willing to accept for each user. Authentication is no stronger than the weakest combination allowed. 異なるセキュリティの特徴を持つ複数の認証法が許されている。 それぞれのユーザに対してどの方法(ないし方法の組合せ)を 進んで受けいれるかは、ユーザのローカルなポリシー次第だ。 このとき 認証は、許されたもっとも弱い組合せよりも強くありません。 Special care should be taken when designing debug messages. These messages may reveal surprising amounts of information about the host if not properly designed. Debug messages can be disabled (during Ylonen, et. al. Expires August 29, 2002 [Page 12] Internet-Draft SSH Authentication Protocol February 2002 user authentication phase) if high security is required. デバッグメッセージの設計には特別な配慮が必要となる。これらの メッセージは、適切に設計されていないホストについての驚くべき量の 情報をさらしてしまうかもしれない。デバッグメッセージは、 高いセキュリティが必要となるなら、(ユーザ認証の段階の間は) 無効にできるようにする。 8. Trademark Issues As of this writing, SSH Communications Security Oy claims ssh as its trademark. As with all IPR claims the IETF takes no position regarding the validity or scope of this trademark claim. 9. Additional Information The current 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 References [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- ietf-architecture-12.txt, July 2001. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-13.txt, July 2001. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- ietf-userauth-15.txt, July 2001. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- ietf-connect-15.txt, July 2001. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Ylonen, et. al. Expires August 29, 2002 [Page 13] Internet-Draft SSH Authentication Protocol February 2002 Tero Kivinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: kivinen@ssh.com Markku-Juhani O. Saarinen University of Jyvaskyla Timo J. Rinne SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: tri@ssh.com Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Ylonen, et. al. Expires August 29, 2002 [Page 14] Internet-Draft SSH Authentication Protocol February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen, et. al. Expires August 29, 2002 [Page 15]