Network Working Group Request for Comments: 1492 C.Finseth University of Minnesota July 1993 アクセス管理プロトコル（TACACS） このメモの位置づけ この文書はInternetにおける情報を提供する。この勧告はInternetの規格を規定 しない。この文書の配布は無制限である。 Background ARPANETと呼ばれるネットワークがあった。このネットワークは、端末(ホスト)、 ルーティング・ノード(IMP)およびリンクから構成されている。(少なくとも）2つの タイプのIMPがあった:専用線接続およびダイアルアップ接続。後者は「TIPs」と 呼ばれた。 人々はダイヤルアップ接続の制御をすることに要望があった。だれかが、"TACACS" (Terminal Access Controller Access Control System?))と呼ばれるプロトコルを 発明した。それはTIPがユーザ名およびパスワードを受理し、TACACS認証サーバに 質問を送信することを可能にし、daemonあるいは単にTACACSDと呼ばれた。 このサーバは通常ホスト上で走るプログラムだった。ホストは、「要求」を受理する べきかどうかを決定し、「応答」を送り返した。TIPは、「応答」に基づいて、 アクセスするかどうかを決める。 TIPsは、Internetやターミナルサーバ上の主な存在となった。Cisco社は、 このTACACSプロトコルの拡張バージョンを作成した。したがって、アクセス管理は ホストに委任される。また、動作決定過程やアルゴリズムおよび動作決定に使われる データは、TACACS daemonの完全な管理下にある。例えば、「もしラストネームが スミスでないか、スーザンがすでにログインしていなければ、ジョーは、月曜日から 金曜日の午後10:00 以降にログインすることができるだけである。」など。 プロトコルに対する拡張はより多くのタイプの認証「要求」、およびオリジナルの 仕様の中にあったより多くのタイプの「応答」コードに備える。オリジナルの TACACSプロトコル仕様は存在する。しかしながら、著作権の問題で、この文書の コピーを得ることができなかった。これがこの文書を書く主な理由である。 この仕様書は、オリジナルの仕様と互換性をもつと考えられる、TACACSプロトコルを 作成した、Cisco社の援助で開発された。正確には、Cisco社は拡張されていない バージョンおよび拡張されたバージョンをサポートしている。オリジナルの仕様書と 互換性をもつのは拡張されていないバージョンである。 思い出してください。これはRFCの情報であり、規格を指定しない。また、 将来的には、この文書の不正確な部分のより詳しい情報が明かされるかもしれない。 (例えば、オリジナルの仕様が利用可能になる) このRFC文書は、Cisco社のターミナル・サーバによって使用されている、 拡張TACACSプロトコルをドキュメント化する。このプロトコルは、ミネソタ大学の 分散形証明システムでも使用されている。 1. Protocol Semantics このセクションは「要求」および「応答」について記述する。次の2つの セクションは、プロトコルをコード化する異なる2つの方法について記述する。 「要求」/「応答」ペアは対話の基礎的な単位である。このペアでは、 クライアントが「要求」を送信する。また、サーバは「応答」で返答する。 「要求」を「応答」ですべて承認しなければならない。この「要求」は、 "logout"「要求」の否定を試みることはおそらく役立たないが 「要求」をすべて否定することができることを意味する。 1.1 Connections いくつかの場合では、「要求」/「応答」ペアのストリングが、"接続"と呼ばれる、 より大規模なユニットを形成する。 3つのタイプの接続がある: 1) 接続せずに認証するだけ: クライアント:AUTHパケットを送信する サーバ:REPLYで答える 2) ログイン接続: クライアント：LOGINパケットを送信する サーバ：REPLYで答える 0あるいはより多くの回を繰り返す: クライアント:CONNECTパケットを送信する サーバ:REPLYで答える クライアント：LOGOUTパケットを送信する サーバ:REPLYで答える。 3) SLIP接続: クライアント:LOGINパケットを送る。 サーバ:REPLYで答える 0あるいはより多くの回を繰り返す: クライアント:CONNECTパケットを送信する サーバ：REPLYで答える クライアント:SLIPADDRパケットを送信する サーバ:REPLYで答える 0あるいはより多くの回を繰り返す: クライアント:CONNECTパケットを送信する サーバ:REPLYで答える クライアント：SLIPONパケットを送信する サーバ:REPLYで答える クライアント：LOGOUTパケットを送信する（既値） サーバ:REPLYクライアントで答える クライアント:SLIPOFFパケットを送信する サーバ:REPLYで答える。 1.2 Requests このセクションは、プロトコルによってサポートされた「要求」を記す。 「応答」については、後のコード化について説明したセクションで記述する。 AUTH(ユーザ名、パスワード、line、style) この「要求」は認証に用いられる。パラメタは次のとおりである: - ユーザ名 - パスワード - 「要求」方法の表示 - 認証のスタイル ユーザ名はユーザを識別する文字列である。原則として、任意の長さ、 任意の文字を含むことができる。実際には、文字数は128文字までで、 ASCII文字の"！"(10進数の33)から "〜"(10進数の126)までだけを 含んでいるべきである パスワードは、ユーザ名によって識別されたユーザを認証するために 使用される文字列である。原則として、任意の長さ、任意の文字を 含むことができる。実際には、文字数は128文字までで、ASCII文字の "！"(10進数の33)から "〜"(10進数の126)までだけを含んでいるべきである lineは非負の10進数の整数である。クライアントが多数の物理的な アクセス・チャネルをサポートする場合、この値は特別なチャネルを識別する。 協定によって、一から始まる行番号が付けられる。粒上にすべきであるが。 例えば、Cisco社の取り決めはコンソール・ポートを指定するために0を使用し、 その後、1から続けていく。1つのチャネルだけをサポートするクライアントは 行番号0を使用するべきである。 styleはおそらく空の文字列である。それは実行される特別な認証スタイルを 識別する。そのシンタックスおよび意味はローカルである。 例: AUTH("fin@unet.umn.edu","fake-password"、0、"staff") これは、ユーザ名"fin@unet.umn.edu"(これは偶然にも私のe-mailアドレスである)、 パスワード、lineがこの「要求」と結び付けられないという表示、そしてstyle として"staff"を示している。これは、私が”staff”のメンバ (もちろん、 それに加えて、有効なユーザ名とパスワードで満たされて)であるように要求 されることを意味する。サーバは”staff”の情報を確認するために、外部の データ・ベースを調べるだろう。ローカルオプションとして、取り決めは、 ポート番号とスタイル情報を対応づけてコード化することがある。たとえば、 ポート番号4001がスタイル1,ポート番号4002がスタイル2を意味するなど。 UDPコード化を使用して、AUTH「要求」を送ることができないことに注意して ください。 LOGIN(ユーザ名、パスワード、line) 戻り値(result1、result2、result3) この「要求」は、(認証が成功した場合)ログインコネクションが確立されている 証明、および合図を求める。パラメタは次のとおりである: - ユーザ名 - パスワード - 「要求」方法の表示 入力項目はAUTH「要求」と同じである。「要求」が成功した場合、 要求成功レスポンスに加えて3つの結果値を返す。結果値は非負の整数である。 それらの解釈はローカルである。例えば、Cisco社のターミナル・サーバでは result3を補足検証に使用するローカルなアクセス・リストの識別子であると 解釈する。 CONNECT(ユーザ名、パスワード、line、宛先IPアドレス、宛先ポート番号) 戻り値(result1、result2、result3) ユーザ名およびlineがすでに確立されたコネクションを指定する場合のみ、 この要求を出すことができる。そういうものとして、証明は要求されず、 パスワードはたいてい空の文字列になるだろう。指定された目的地IPアドレス および宛先ポートポート番号にTCP接続を確立できるかどうかを尋ねる。 戻り値はLOGIN命令に関するものである。 SUPERUSER(ユーザ名、パスワード、line) ユーザ名およびlineがすでに確立されたコネクションを指定する場合のみ、 この要求を出すことができる。そういうものとして、証明は要求されず、 パスワードはたいてい空の文字列になるだろう。"super-user"モード、 もしくは"enable"モードになれるかどうかを尋ねる。 この全体の仕組みの適応性inherintの例として、Cisco社によって提供された TACACSDは、ユーザ名の部分を無視して、その代わりに、特別なユーザ "$enable$"のパスワードが一致しているかどうかを調べる。 LOGOUT(ユーザ名、パスワード、line、理由) ユーザ名およびlineがすでに確立されたコネクションを指定する場合のみ、 この要求を出すことができる。そういうものとして、証明は要求されず、 パスワードはたいてい空の文字列になるだろう。それは、コネクションが 切断されたことを示す。認証しなければならない。成功／失敗通知は関係ない。 理由値は、なぜコネクションを切断するかを示す。コネクションがSLIPモードに 入っている場合、理由値にはnullが入る。 SLIPON(ユーザ名、パスワード、line、SLIPaddress) 戻り値(result1、result2、result3) ユーザ名およびlineがすでに確立されたコネクションを指定する場合のみ、 この要求を出すことができる。そういうものとして、証明は要求されず、 パスワードはたいてい空の文字列になるだろう。遠隔ログインで、指定された SLIPアドレスが使用できるかどうかを調べる。 サーバが"success"を返答した場合、クライアントはSLIPON「要求」に進むことが できる。(しかしながら、それはすぐに行う必要はない。) "ユーザ名"の意味が毛状になることができることに注意してください。例えば、 Cisco社の規約のコード化情報はこのようになる: - ディフォルトアドレスが割り当てられることをユーザが要求したならば、 ユーザ名を小文字で保持する。 - ユーザが特定のIPアドレスあるいはSLIP接続のホスト名を要求したならば、 要求されたホスト名を大文字で含む。 サーバが"success"を返答した場合、クライアントはLOGOUT要求を直ちに送信する。 しかしながら、SLIPOFF要求が送られるまで、接続は確立されたままとなる。 他の認証要求はそのコネクションに送信されないだろう。 SLIPaddressは、リモートホストによって使用されているIPアドレスを指定する。 SLIPADDR要求が作成された場合、そのIPアドレスになる。そうでなければ、 それはクライアント(たとえばCiscoターミナル・サーバ)によって 割り当てられた、ディフォルトアドレスになるだろう。 戻り値はLOGIN命令に関するものである。 SLIPOFF(ユーザ名、パスワード、line、reason) ユーザ名およびlineが、すでに確立されたSLIPモードのコネクションを指定する 場合のみ、この要求を出すことができる。そういうものとして、証明は 要求されず、パスワードはたいてい空の文字列になるだろう。これは、接続を 終了することを示す。承認しなければならない。成功／失敗通知は関係ない。 "reason"は、なぜコネクションを切断するかを示す。 2.0 UDP Encoding: TACACS このセクションでは、UDPコード化「要求」について記述する。また「応答」に ついても記述する。UDPをコード化することは、TACACSプロトコルの歴史の 基礎である。 このプロトコルはポート番号49を使用する。この割り当てはRFC勧告の中で IANAに よって確認され続ける。(私には、組織に先立ってIANAが割り当てられた、とは 言えない。) 基本的なパケットのフォーマットはここに示される。多重バイト値はすべて ネットワーク バイト順にある。もし他の方法で指定されなかったならば、 与えられる値はすべて10進数である。未使用のフィールドには0が設定されるべきで ある。しかし、受取人はその設定に依存してはならない。 以前に説明したように、単純な形式と拡張された形式 (単純な形式は拡張形式の 適切な部分集合である)がある。サーバは両方をサポートするべきである。 私は平行して両方の形式について記述する。 単純な形式 フィールドは次のとおりである: offset length field 0 1 バージョン 1 1 タイプ 2 2 下値 4 1 サーバへのユーザ名の長さ/クライアントへの応答 5 1 サーバへのパスワードの長さ/クライアントの要求 通常のパケット・レイアウトのフォーマット 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Version : Type : Nonce : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : User len/Resp : PW len/reason : data... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 拡張された形式 フィールドは次のとおりである: offset length field 0 1 バージョン 1 1 タイプ 2 2 下値 4 1 ユーザ名の長さ 5 1 パスワードの長さ 6 1 応答 7 1 理由 8 4 result1 12 4 宛先ホスト、IPアドレス 16 2 宛先ポート番号 18 2 line 20 4 result2 24 2 result3 26 可変 データ：ユーザ名 + パスワード 通常のパケット・レイアウトのフォーマット 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Version : Type : Nonce : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : User len : Pasword len : Response : Reason : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Result 1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Destination Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Dest Port : Line : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Result 2 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Result 3 : data... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1 Fields VERSIONフィールドはバージョン番号を指定する。単純な形式の場合それは0、 拡張形式の場合は128(16進数で80)でなければならない。 TYPEフィールドは「要求」タイプをコード化する。値は次のとおりである: LOGIN 1 RESPONSE 2 (サーバ側からクライアント側方向のみ）) CHANGE 3 FOLLOW 4 CONNECT 5 SUPERUSER 6 LOGOUT 7 RELOAD 8 SLIPON 9 SLIPOFF 10 SLIPADDR 11 128より下の他の値は将来の使用のために取っておかれる。128から255までの値は ローカル使用のために取っておかれる。 CHANGE、FOLLOW、RELOAD「要求」は決定されていないことに注意する。 NONCEフィールドはクライアントによって任意の値がセットされる。複数の未解決 「要求」に対する「応答」を求めるのがその目的です。サーバは、「応答」に この値を変更のないように記述しなければならない。 USERNAME LENGTHフィールドは文字中でクライアントによってユーザ名の長さに セットされる。有効な値は0〜255である。サーバは、「応答」にこの値を変更の ないように記述しなければならない。 PASSWORD LENGTHには、クライアントによってパスワードの長さがセットされる。 有効な値は0〜255である。サーバは、「応答」にこの値を変更のないように 記述しなければならない。 RESPONSEフィールドはクライアントによって0にセットされるべきである。 サーバは、次のうちの1つを値にセットする: value meaning 1 accepted 2 rejected 128より下の他の値は将来の使用のために取っておかれる。128から255までの値は ローカル使用のために取っておかれる。 REASONフィールドは、LOGOUTおよびSLIPOFF「要求」(それの値は4、5あるいは6が 使用されるだろう)を除いて、クライアントによって0にセットされるべきである。 サーバは、次のうちの1つを値にセットする: value meaning notes 0 none ACCEPTEDのために使用しなかったか、サーバが応答しない場合。 1 expiring 2 password 3 denied 4 quit 正常終了 5 idle タイムアウト 6 drop キャリアが低下した 7 bad パスワードが違う 4から6までの値は、LOGOUTあるいはSLIPOFF「要求」のために使用され、サーバから の応答がない。128より下の他の値は将来の使用のために取っておかれる。128から 255までの値はローカル使用のために取っておかれる。 RESULT1フィールドはクライアントによって0がセットされる。LOGINあるいは CONNECT「要求」では、サーバによって「要求」文中に指定される。他のすべての 要求については、サーバによって0がセットされる。 DESTINATION HOSTフィールドはクライアントによってセットされる。CONNECT、 SLIPONおよびSLIPOFFでは、IPアドレスを指定する。他のすべての「要求」では 0にセットされる。SLIPONおよびSLIPOFF「要求」については、この値はラインに 割り当てられたIPアドレスである。CONNECT「要求」では、ユーザが接続を 試みているホストのIPアドレスである。サーバは「応答」にこの値を記述する。 DESTINATION PORTフィールドはクライアントによってセットされる。 CONNECT「要求」では、ユーザが接続を試みているポート番号を指定する。 他のすべての「要求」では0にセットされるべきである。サーバは「応答」に この値を記述する。 LINEフィールドはクライアントによって要求されているline番号がセットされる。 サーバは「応答」にこの値を記述する。 RESULT2フィールドはクライアントによって0にセットされる。LOGINあるいは CONNECT「要求」では、サーバによって「要求」文中に指定される。他のすべての 要求については、サーバによって0がセットされる。 RESULT3フィールドはクライアントによって0にセットされる。LOGINあるいは CONNECT「要求」では、サーバによって「要求」文中に指定される。他のすべての 要求については、サーバによって0にセットされる。 DATAフィールドは、ユーザ名およびパスワードを分割文字なしで含んでいる。 (それを区別するのには、ユーザ名の長さおよびパスワードの長さを使用する) サーバは「応答」に値を記述しない。(しかしながら、サーバは応答にユーザ名の 長さおよびパスワードの長さを記述する。) ユーザ名データは大文字を区別しない。 2.2 What a Client Does クライアントは、UDP「要求」をポート番号49でフォーマットして送信しなければ ならない。以下のように、「要求」メッセージを構築する: - 「version」を128にセットする。 - 「要求」に「type」をセットする。 - すべての未解決「要求」で異なるユニークな値を「nonce」にセットする。 - ユーザ名の長さをセットする。 - パスワードの長さをセットする。 - 「応答」に0をセットする。 - 「reason」に0(LOGOUTとSLIPOFF以外)をセットする。 - 「result1」に0をセットする。 - 「destination address」には、CONNECT、SLIPOFF、SLIPONの場合には IPアドレスを、そうでなければ0をセットする。 - 「destination port」には、CONNECTの場合にはポート番号を、そうでなければ 0をセットする。 - 「line」をセットする。 - 「result2」に0をセットする。 - 「result3」に0をセットする。 - 「result3」の後にユーザ名を記述する。 - ユーザ名の後にパスワードを記述する。 「要求」を送信してください。適切な時間待ってください。 「応答」が返ってこない場合、適切な回数retryしてください。 ディフォルトの待機時間は5秒で、再試行回数は2回である。 「応答」が返ってきた場合、未解決「要求」と「nonce」値とのマッチングを行う。 (他のフィールドは好きなように。) 未解決「要求」と一致しなかった場合、 パケットを破棄したりログを採ったりと、適切な処置をとる。 応答が未解決「要求」と一致する場合、「応答」や「reason」コードを検査し、 あなたが正しいと考える、何かしらの処理を行ってください。LOGINとCONNECTに 対する「応答」に対してもまた、「result1」、「result2」、「result3」の値を 結び付けてください。 2.3 What a Server Does UDPフォーマット「要求」の受取に際して、サーバは「要求」パケット中でデータを 検査し、その「応答」を決定する。以下のように、「応答」を構築する: - 「version」に128をセットする。 - 「type」にRESPONSE(2)をセットする。 - 「nonce」値を記述する。 - ユーザ名の長さの値を記述する。 - パスワードの長さの値を記述する。 - 「response」に応答値をセットする。 - 「reason」に理由値をセットする。 - LOGINあるいはCONNECTの場合はresult1を、その他の場合は0をセットする。 - 宛先ホスト値を記述する。 - 宛先ポート値を記述する。 - 「line」値を記述する。 - LOGINあるいはCONNECTの場合はresult2を、その他の場合は0をセットする。 - LOGINあるいはCONNECTの場合はresult3を、その他の場合は0をセットする。 - ユーザ名とパスワードは記述しない。 （いつものように、あなたの思うままに自由に送信してください） 「応答」を送ってください。リトライが要求されるかどうか決める根拠を 持っていないならば、リトライを行わないでください。任意のリトライは クライアント次第である。もちろんこれは、「要求」がidempotent（等冪）で あることを暗示する。 コネクションへの「要求」を組み立てようと試みる場合、再試行を考慮しなければ ならないということは、もちろんない。 3.0 TCP Encoding このセクションは、「要求」および「応答」のTCPコード化について記述する。 このコード化は歴史上のTACACSプロトコルと互換性をもたない。 しかしながら、それが現在の特徴ニーズに備えるために更新されたという点では、 やや"現代的"である。 このプロトコルは予約ポートを使用しない。代わりに、クライアントとサーバの 両方で使用されるポート番号を形成することが可能でなければならない。 基礎的な「要求」フォーマットを以下に示す。「要求」は、ASCIIテキストの4行から 成る。数値はすべて10進数の整数としてASCIIの中で表現される。 例における各lineは、テキストでは一行に相当する。すなわち、lineは /のペアで分割される(10進数の13/10)。決して"そのまま"あるいは 文字が、フィールド内に現われることはない。さらに、(10進数の0)文字は 送られない。 、およびフィールドは、1つ以上の(10進数の32)あるいは (10進数の9)文字で分割される。 フィールドはオプションである。フィールドは分割され、 内部パラメータはお互いにあるいは文字で分割される。 この行に存在する、やの後に続く文字は、サーバによって 無視されるべきである: それらは空のフィールドの後に含むべきでない。 理論では、lineの長さに限界はない。実際には、lineは255文字 (およびを 数えて)を超過してはならないし、おそらく80文字より少ないあるべきである。 3.1 Fields 「VERSION」フィールドはバージョン番号を指定する。それは1でなければならない。 128より下の他の値は将来の使用のために取っておかれる。128から255までの値は ローカル使用のために取っておかれる。 「TYPE」フィールドは要求タイプをコード化する。値は次のとおりである: AUTH LOGIN CONNECT SUPERUSER LOGOUT SLIPON SLIPOFF つまり、キーワードはそれ自体を単にコード化する。それは大文字でなければ ならない。文字"X"から始まるキーワードはローカル使用のために取っておかれる。 「USERNAME」フィールドには、ユーザ名をテキストで含んでいる。あるいは 文字を前か後に入れることは、重要であると考えられる。ユーザ名データは 大文字である:大文字、小文字を区別しない。 「PASSWORD」フィールドには、パスワードをテキストで含んでいる。 あるいは文字を前か後に入れることは、重要であると考えられる。 「LINEフィールド」にはクライアントによってline番号がセットされる。 3.2 Responses STD 10の付録E、RFC 821には、応答コードに関する一般的な理論が記述されている。 このプロトコルは、以下の記述のようなフォーマットである。きわめて簡潔な フォーマットである: が10進数3桁であり、には表示できる文字である(10進数の32)から "〜"(10進数の126)を含む、任意の文字列である。少なくとも1つの(10進数の32)が numberとtextを分割する。 /シーケンスがtextの後に続く。 3桁のコードで「応答」を完全に決定する。textは、ユーザが理解でしやすいように するための説明文である。しかしながら、すべての値を知らずとも、最初の1桁目は 「応答」のすべての性質を決定するために使用することができる。コード化は 次のとおりである: 1 正常な場合の前処理:「要求」は受理可能である。しかし、補足要求が 作成されるまでは何もアクションを起こさない。（現バージョンのプロトコルを 使用しなかった場合） 2 正常な場合の確立 3 正常な場合の途中処理：「要求」はここまで受理可能であるが、完全な転送は 行われていない。(現バージョンのプロトコルを使用しなかった場合)。 4 一時的な異常:「要求」は今のところ受理可能ではない。 別の実例で異なる結果となる場合には、リトライすることが可能である。 5 恒久的な異常:要求は受理可能ではない。 テキスト部分はオプションである(つまり、空のストリングである場合がある)。 また、それは、人間の判読可能な形式で記述されている。 異なるサーバの規約が異なるメッセージに帰着しているとき、下記を表す: 201 受理された: # # #。 202 受理されて、パスワードは終了している: # # # 401 無応答;リトライ 501 無効のフォーマット 502 アクセスが否定される 最初の2つのメッセージ中の": # # #"はLOGINおよびCONNECT「要求」のために 3つのresultコードを返す。 3.3 What a Client Does クライアントはローカルに形成されたアドレスおよびポートにTCPコネクションを 開く。以下のようなフォーマットのメッセージを送信することで、「要求」を 送信する: - 文字の"1" - 1以上のあるいは - ASCII文字列としての要求タイプ - AUTHの場合には、1以上のあるいは と認証スタイル - CONNECT、SLIPONあるいはSLIPOFFの場合には、1以上のあるいはと 10進数表記のIPアドレス - CONNECTの場合には、1以上のあるいはと10進数のポート番号 - / - ユーザ名(あるいはSLIPADDRのためのホスト名) - / - パスワード - / - ライン - / その後、コネクションから1行読みこんで、コネクションを閉じてください。 コード化は、TCPに、待ち、再試行および要求と応答との一致処理を行う。 応答ラインを検査し、正しいと思える処理を行ってください。 3.4 What a Server Does サーバは、要求用にローカルに形成されたポート上で応対する。1つ作成されると、 入力を4行読む。 1行目で、有効なバージョン番号および「要求」かを検査する。さらに任意の オプションのパラメタも記録する。 「応答」を作成するのに適当に考えられる、他の任意の情報に加えて、ユーザ名、 パスワードおよび行番号を使用する。 応答を1行送り、/で終了させて、コネクションを閉じる。 4.0 Pros and Cons UDPフォーマットの使用の利点: - より低いオーバヘッド - 歴史上の規格と互換性をもつ - サポート実績がある TCPフォーマットの使用の利点 ‐操作が容易、特にUDPをサポートしていないか、サポートが貧弱なマシーンでは - より単純でより清潔なシンタックス - エラー・コードの潜在的なより広い範囲と、一時的なサポート、 証明シーケンスの取り決め 5.0 Security Notes プロトコルがそれ自体記述された場合、言及する価値がある多くの考察がある。 最初にプロトコルは、単一のUDPパケットあるいはTCPストリームのいずれかで ユーザ名及びパスワードを運ぶ。そういうものとして、攻撃者がそのデータを モニタすることができれば、攻撃者はユーザ名とパスワードを獲得することがある。 規約は、この危険を最小限にするいくつかのステップをとることができる: - 可能であれば、point-to-point接続を使用する。 - 送信メディアを物理的に保護してください。 - パケットが多数のネットワーク・セグメントを横断しなければならない場合、 安全なルーティング コンポーネントシステムを使用してください。 以下のようなことです: - ルータ構成に対するしっかりした管理。 - プロトコルをルーティングすることに対するしっかりした管理。 - パケットの複製を通過させるようなブリッジの使用を回避する。 次に、このプロトコルは、ユーザ名とパスワードを調査する新しい方法を潜在的に 切り開く。したがって、サーバに以下の項目を持っていたい。 - 制御されるクライアントのリストに対する応答制限 - 「要求」に対する「応答」の割合を調節する - すべてのエラーログ(可能なら成功ログも)。 第3に、このプロトコルは、受信する／しないの決定をサーバに委ねることができる。 明確な規約は、決定するためにサーバ固有のログイン・メカニズムを簡単に使用でき、 規約をそのメカニズムに制限する必要はない。サーバでは以下のことが可能である: - アカウント(たとえばパスワード・ファイル)の別のリストの使用 - アクセスするための別のメカニズムの使用 （たとえば、データベース、NIS） ‐別のアルゴリズム(たとえばSecureIDカード)の使用 ‐「要求」を別のプロトコルに変換し、意志決定に使用(たとえばKerberos) 第4に、"fanout"サーバ(次のセクションで説明します)は以下のように使用します: - 攻撃を分析したログの集中管理 - 方針の集中管理: - 選択された特定のユーザに対する管理。 - 選択されたユーザ名に対する管理 (たとえば、"root"や"guest"でのアクセスを拒否する) - 貧弱なパスワードに対する管理 (たとえば、設定されたいなかったり、破られやすい） 6.0 Case Study このセクションは、ミネソタの大学で使われている規約の、基本的な手順を示す。 2つの例が使用される。 第1は基本的な、ターミナルのログインである。 第2はデータ・ベース・アクセス検証である。 ユーザ名は、次の3つの形式のうちの1つである: First.M.Last-#@umn.edu First.M.Last-# user@host 最初の形式は、2番目の形式に変換される。 2番目の形式では、大学規模のディレクトリ・システムを検索する。 もし見つかれば、あたかも3番目の形式が入力されたかのように、 対応する電子メールアドレスで処理する。 3番目の形式では、管理者が正当性を立証しているホストコンピュータ名と そのホストコンピュータのアカウント名を詳しく記述している。 我々が使用するシステムは、多くのクライアントが使用することを考慮に入れている。 (典型的な例ではモデムの共有) さらに、各クライアントは、ユーザの様々な共有物をサポートすることができる。 例えば、1-20回線は一般的なアクセスで使用できる。しかし、21-25回線は、 限られた有効なユーザの800-数でありうる。ホストコンピュータが、 接続できる各共有モデムを規定することによって、システムは、この区別を明確に サポートする。 6.1 Terminal Login Cisco社のターミナル・サーバ: - コネクションを確立する。 - ユーザ名およびパスワードを要求する。 - UDP TACACSパケットに「要求」を格納して、Central fanoutに送る。 Central Fanout: - 「要求」を受理する。 - 「要求」が有効なフォーマットでない場合、"nope"を返す。 - 「要求」をロギングする。 - 送信元IPアドレスが有効なクライアントのリストに載っていない場合、 statusを"nope"にする。 - もしくはユーザ名が無効の文字を含んでいる場合、statusを"nope"にする。 - ほかに もしユーザ名の形式が"First.M.Last-#@umn.edu"である場合、 "First.M.Last-#"形式に変換する。 もしユーザ名の形式が"First.M.Last-#"である場合、ディレクトリシステムで 名前を調べる。 名前が見つからなければ、statusを"nope"にして、見つかれば、 e-mailアドレスをユーザ名として使用する。 ユーザが特別な"使用制限"リストに載っている場合、statusを"nope"にして、 アクセスを試みようとしたが使用制限を受けたことを知らせる警告メッセージを 送信する。 ユーザ名を"user"と"host"部に分割して、もし"host"がサーバリストに 登録されていない場合、statusを"nope"にする。もし"host"が、この共有物からの 要求に対して受け取りを許可していない場合、statusを"nope"にする。 「要求」のフォーマットは、ユーザの正当性を検査し、ホストを指定して送信する。 もし「応答」がなかったら、statusを"nope"にする。 そうでなければ、statusに戻り値をセットする。 - 「応答」ログが書かれる。 - 「応答」を返す。 Validation Host: このマシンには、central fanoutの"stripped down"バージョンを実行することが できる。それは1つの例外を除いて、特別の検証あるいはロギングを実行する 必要がない。 - 「要求」を受理する。 - 「要求」が有効なフォーマットでない場合、"nope"を返す。 - 「要求」がcentral fanoutから来ていない場合、"nope"を返す。 - 復帰状態を図に表わす。 - 「応答」を返す。 6.2 Database Access Verification この例では、データ・ベースが"facultry"と"staff"のみにアクセスされると 仮定する。 メインフレーム: - ユーザはメインフレーム上で「要求」を送る。 - プログラムはユーザ名およびパスワードを要求する。 - プログラムはUDP TACACSパケットに「要求」を格納して、central fanoutに 送信する。 Central Fanout: - 「要求」を受理する。 - 「要求」が有効なフォーマットでない場合、"nope"を返す。 - 「要求」をロギングする。 - 送信元IPアドレスが有効なクライアントのリストに載っていない場合、 statusを"nope"にする。 - ユーザ名が無効な文字を含んでいる場合、statusを"nope"にする。 - ほかに、 ユーザ名の形式が"First.M.Last-#@umn.edu"である場合、 "First.M.Last-#"形式に変換する。 ユーザ名の形式が"First.M.Last-#"である場合、ディレクトリシステムで 名前を調べる。名前が見つからなければ、statusを"nope"にして、 見つかれば、e-mailアドレスをユーザ名として使用し、ディレクトリシステムから "staff status"を得る。 ユーザが特別な"使用制限"リストに載っている場合、statusを"nope"にして、 アクセスを試みようとしたが使用制限を受けたことを知らせる警告メッセージを 送信する。 ユーザ名を"user"と"host"部に分割して、もし"host"がサーバリストに 登録されていない場合、statusを"nope"にする。 もし"host"が、この共有物からの要求に対して受け取りを許可していない場合、 statusを"nope"にする。 「要求」のフォーマットは、ユーザの正当性を検査し、ホストを指定して送信する。 もし「応答」がなかったら、statusを"nope"にする。 もし、送信元ユーザ名が"user@host"形式であった場合、ディレクトリシステムを 調べ、"staff status"を得る。 - 「応答」ログが書かれる。 - 「応答」を返す。 検証ホストが不変であることに注意してください。 References [RFC821]Postel, J. "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers," STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. Anderson, Brian; Ruth, Greg; Ditmars, Peter; Eisner, Sharon; Delsignore, John (1985) TAC Access Control System Protocols, Second Edition: August 16 1985. BBN Tech Memo CC-0045. Cisco Systems, Inc. (September 1992) Communications Server Configuration and Reference. Menlo Park, California. Security Consideraions セキュリティ問題はこのメモの主要なトピックである。 Author's Address Craig A. Finseth Networking Services Computer and Information Services University of Minnesota 130 Lind Hall 207 Church St SE Minneapolis MN 55455-0134 Phone: +1 612 624 3375 Fax: +1 612 626 1002 EMail:Craig.A.Finseth-1@umn.ed fin@unet.umn.edu Craig A. Finseth