RFC1492 日本語訳
1492 An Access Control Protocol, Sometimes Called TACACS. C. Finseth. July 1993. (Format: TXT=41880 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Finseth
Request for Comments: 1492 University of Minnesota
July 1993
Finsethがコメントのために要求するワーキンググループC.をネットワークでつないでください: 1492 ミネソタ大学1993年7月
An Access Control Protocol, Sometimes Called TACACS
時々TACACSと呼ばれるアクセス制御プロトコル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Background
バックグラウンド
There used to be a network called ARPANET. This network consisted of end nodes (hosts), routing nodes (IMPs) and links. There were (at least) two types of IMPs: those that connected dedicated lines only and those that could accept dial up lines. The latter were called "TIPs."
アルパネットと呼ばれるネットワークがありました。 このネットワークはエンドノード(ホスト)、ルーティングノード(IMPs)、およびリンクから成りました。 IMPsの(少なくとも)の2つのタイプがありました: 接続したものはダイヤルアップ系列を受け入れることができた系列だけとものを捧げました。 後者は「チップ」と呼ばれました。
People being what they were, there was a desire to control who could use the dial up lines. Someone invented a protocol, called "TACACS" (Terminal Access Controller Access Control System?), which allowed a TIP to accept a username and password and send a query to a TACACS authentication server, sometimes called a TACACS daemon or simply TACACSD. This server was normally a program running on a host. The host would determine whether to accept or deny the request and sent a response back. The TIP would then allow access or not, based upon the response.
人々が昔の彼らである、だれがダイヤルアップ系列を使用できたかを制御する願望がありました。 TACACSデーモンか単にTACACSDが、時々だれかがユーザ名とパスワードを受け入れて、TACACS認証サーバに質問を送るためにチップを許容した「TACACS」(端末の入場管理者アクセス制御システム?)と呼ばれるプロトコルを発明したと呼びました。 通常、このサーバはホストで動くプログラムでした。 ホストは、受け入れるか、または要求であって送りにされるのに対して応答を否定し返すかを決心しているでしょう。 そして、応答に基づいて、TIPはアクセスを許すでしょう。
While TIPs are -- shall we say? -- no longer a major presence on the Internet, terminal servers are. Cisco Systems terminal servers implement an extended version of this TACACS protocol. Thus, the access control decision is delegated to a host. In this way, the process of making the decision is "opened up" and the algorithms and data used to make the decision are under the complete control of whoever is running the TACACS daemon. For example, "anyone with a first name of Joe can only login after 10:00 PM Mon-Fri, unless his last name is Smith or there is a Susan already logged in."
TIPsがそうですが、--言いましょうか? -- もう、インターネットでの主要な存在、ターミナルサーバはそうです。 シスコシステムズターミナルサーバはこのTACACSプロトコルの拡張版を実装します。 したがって、アクセス制御決定をホストへ代表として派遣します。 このように、決定をするプロセスは「開けられます」、そして、決定をするのに使用されるアルゴリズムとデータがTACACSデーモンを実行している人なら誰でもに関する完全なコントロールの下にあります。 例えば、「彼の姓がスミスであるかいない場合スーザンが午後10時の月曜日から金曜日に既にログインした後にジョーの名と一緒にいるだれでもログインできるだけです」。
The extensions to the protocol provide for more types of authentication requests and more types of response codes than were in the original specification.
プロトコルへの拡大は正式仕様書にあったより多くの認証要求のタイプとさらに多くのタイプの応答コードに備えます。
The original TACACS protocol specification does exist. However, due to copyright issues, I was not able to obtain a copy of this document
当初のTACACSプロトコル仕様は存在しています。 しかしながら、著作権問題のため、私はこのドキュメントのコピーを入手できませんでした。
Finseth [Page 1] RFC 1492 TACACS July 1993
Finseth[1ページ]RFC1492TACACS1993年7月
and this lack of access is the main reason for the writing of this document. This version of the specification was developed with the assistance of Cisco Systems, who has an implementation of the TACACS protocol that is believed to be compatible with the original specification. To be precise, the Cisco Systems implementation supports both the simple (non-extended) and extended versions. It is the simple version that would be compatible with the original.
そして、アクセスのこの不足はこのドキュメントの書くことの主な理由です。 仕様のこのバージョンはシスコシステムズの支援で開発されました。(シスコシステムズには、正式仕様書と互換性があると信じられているTACACSプロトコルの実装がいます)。 正確に言うと、シスコシステムズ実装は、両方が簡単(非拡張している)で拡張しているバージョンであるとサポートします。 それはオリジナルと互換性がある簡単なバージョンです。
Please keep in mind that this is an informational RFC and does not specify a standard, and that more information may be uncovered in the future (i.e., the original specification may become available) that could cause parts of this document to be known to be incorrect.
これが情報のRFCであり、規格を指定しないで、詳しい情報が不正確であることをこのドキュメントの部分を知ることができた未来(すなわち、正式仕様書は利用可能になるかもしれない)に暴露されるかもしれないのを覚えておいてください。
This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system.
このRFCはシスコシステムズターミナルサーバで拡張TACACSプロトコル使用を記録します。 この同じプロトコルはミネソタ大学の分配された認証システムによって使用されます。
1. Protocol Semantics
1. プロトコル意味論
This section will describe the requests and responses. The following two sections will describe two different ways of encoding the protocol.
このセクションは要求と応答について説明するでしょう。 以下の2つのセクションがプロトコルをコード化する2つの異なった方法を述べるでしょう。
A request/response pair is the basic unit of interaction. In this pair, the client sends a request and the server replies with a response. All requests must be acknowledged with a response. This requirement implies that all requests can be denied, although it is probably futile to attempt to deny a "logout" request.
要求/応答組は相互作用の原単位です。 この組で、クライアントは応答と共に要求とサーバ回答を送ります。 応答ですべての要求を承諾しなければなりません。 この要件は、すべての要求が否定される場合があるのを含意します、「ログアウトしてください」という要求を否定するのを試みるのがたぶん空しいのですが。
1.1 Connections
1.1 コネクションズ
In some cases, a string of request/response pairs forms a larger unit, called a "connection."
「接続」は、いくつかの場合、一連の要求/応答組が、より大きい単位を形成すると呼びました。
There are three types of connections:
3つのタイプの接続があります:
1) Authenticate only, no connection:
1) 接続だけを認証しないでください:
client: sends an AUTH packet
server: responds with a REPLY
クライアント: AUTHパケットサーバを送ります: REPLYと共に応じます。
Finseth [Page 2] RFC 1492 TACACS July 1993
Finseth[2ページ]RFC1492TACACS1993年7月
2) Login connection:
2) ログイン接続:
client: sends a LOGIN packet
server: responds with a REPLY
クライアント: LOGINパケットサーバを送ります: REPLYと共に応じます。
repeat zero or more times:
client: sends a CONNECT packet
server: responds with a REPLY
反復ゼロか、より多くの回: クライアント: CONNECTパケットサーバを送ります: REPLYと共に応じます。
client: sends a LOGOUT packet
server: responds with a REPLY
クライアント: LOGOUTパケットサーバを送ります: REPLYと共に応じます。
3) SLIP connection:
3) SLIP接続:
client: sends a LOGIN packet
server: responds with a REPLY
クライアント: LOGINパケットサーバを送ります: REPLYと共に応じます。
repeat zero or more times:
client: sends a CONNECT packet
server: responds with a REPLY
反復ゼロか、より多くの回: クライアント: CONNECTパケットサーバを送ります: REPLYと共に応じます。
client: sends a SLIPADDR packet
server: responds with a REPLY
クライアント: SLIPADDRパケットサーバを送ります: REPLYと共に応じます。
repeat zero or more times:
client: sends a CONNECT packet
server: responds with a REPLY
反復ゼロか、より多くの回: クライアント: CONNECTパケットサーバを送ります: REPLYと共に応じます。
client: sends a SLIPON packet
server: responds with a REPLY
client: sends a LOGOUT packet (immediate)
server: responds with a REPLY
クライアント: SLIPONパケットサーバを送ります: REPLYクライアントと共に応じます: LOGOUTのパケットの(即座)のサーバを送ります: REPLYと共に応じます。
client: sends a SLIPOFF packet
server: responds with a REPLY
クライアント: SLIPOFFパケットサーバを送ります: REPLYと共に応じます。
1.2 Requests
1.2 要求
This section lists the requests supported by the protocol. The responses are described in the later encodings sections.
このセクションはプロトコルで後押しされている要求をリストアップします。 応答は後のencodings部で説明されます。
AUTH(username, password, line, style)
AUTH(ユーザ名、パスワード、系列、スタイル)
This request asks for an authentication. The parameters are:
この要求は認証を求めます。 パラメタは以下の通りです。
Finseth [Page 3] RFC 1492 TACACS July 1993
Finseth[3ページ]RFC1492TACACS1993年7月
- the username
- the password
- an indication of which line the request is for, and
- a style of authentication
- そして、ユーザ名--パスワード--要求がどの系列のためにあるか指示、--、認証のスタイル
The username is a string that identifies the user. In principle,
it can be of any length and contain any characters. In practice,
it should be no longer than 128 characters and should contain only
the ASCII characters "!" (33 decimal) through "~" (126 decimal),
inclusive.
ユーザ名はユーザを特定するストリングです。 原則として、それは、どんな長さもあって、どんなキャラクタも含むことができます。 実際には、128のキャラクタよりもうであるべきです、そして、ASCII文字“!"だけを含むべきです。 (33小数) 通じて、「~」的(126小数)で、包括的です。
The password is a string that is used to authenticate the user
identified by the username. In principle, it can be of any length
and contain any characters. In practice, it should be no longer
than 128 characters and should contain only the ASCII characters
"!" (33 decimal) through "~" (126 decimal), inclusive.
パスワードはユーザ名によって特定されたユーザを認証するのに使用されるストリングです。 原則として、それは、どんな長さもあって、どんなキャラクタも含むことができます。 実際には、128のキャラクタよりもうであるべきです、そして、ASCII文字“!"だけを含むべきです。 (33小数) 通じて、「~」的(126小数)で、包括的です。
The line is a non-negative decimal integer. If the client
supports multiple physical access channels, this value identifies
the particular channel. By convention, lines are numbered
starting from one, although this should be taken with a grain of
salt. For example, Cisco Systems' implementation uses zero to
designate the console port, then continues with one for the "main"
serial lines. Clients that support only one channel should use
line zero.
系列は非負の10進整数です。 クライアントが複数の物理的なアクセスチャンネルを支えるなら、この値は特定のチャンネルを特定します。 コンベンションで、割り引いてこれを取るべきですが、1つから始めて、系列は番号付です。 例えば、シスコシステムズの実装は、コンソールポートを指定するのにゼロを使用して、次に、「主な」シリアル・ラインへの1つを続行します。 1個のチャンネルだけを支えるクライアントは系列ゼロを使用するべきです。
The authentication style is a possibly empty string. It
identifies the particular style of authentication to be performed.
Its syntax and semantics are local.
認証スタイルはことによると空のストリングです。 それは、実行されるために特定のスタイルの認証を特定します。 その構文と意味論はローカルです。
Example:
例:
AUTH("fin@unet.umn.edu", "fake-password", 0, "staff")
AUTH(" fin@unet.umn.edu "、0、「スタッフ」という「にせのパスワード」)
This specifies a username of "fin@unet.umn.edu" (which happens to
be my e-mail address), a password, an indication that no line is
associated with this request, and a style of "staff". The
semantics for this style might be that I am required to be a staff
member (in addition, of course, to supplying a valid username and
password). The server would presumably consult an external
database to verify the staff status.
これは「スタッフ」の" fin@unet.umn.edu "(たまたま私のEメールアドレスである)に関するユーザ名、パスワード、どんな系列もこの要求に関連していないという指示、およびスタイルを指定します。 このスタイルのための意味論は私が職員であることが必要であるという(もちろん、さらに、供給への有効なユーザ名とパスワード)ことであるかもしれません。 おそらく、サーバは、スタッフ状態について確かめるために外部のデータベースに相談するでしょう。
As a local option, the implementation may choose to encode the
style information by using alternate port numbers. E.g. port 4001
would mean style 1, 4002 would be style 2, etc.
地方選択権として、実装は、代替のポートナンバーを使用することによってスタイル情報をコード化するのを選ぶかもしれません。 例えば、ポート4001は、スタイルが2であったのなどなら1、4002を流行に合わせることを意味するでしょう。
Note that the AUTH request type cannot be sent using the UDP
encoding.
AUTHが、タイプにUDPコード化を使用させることができないよう要求することに注意してください。
Finseth [Page 4] RFC 1492 TACACS July 1993
Finseth[4ページ]RFC1492TACACS1993年7月
LOGIN(username, password, line) returns (result1, result2, result3)
LOGIN(ユーザ名、パスワードは立ち並んでいる)は戻ります。(result1、result2、result3)
This request asks for an authentication and signals that -- if the
authentication succeeds -- a login connection is starting. The
parameters are:
認証が成功するなら、この要求は、認証を求めて、それを示します--ログイン接続は始まっています。 パラメタは以下の通りです。
- the username
- the password
- an indication of which line the request is for
- ユーザ名--パスワード--要求がどの系列のためにあるか指示
The meanings of the input fields are the same as the AUTH request.
If the request is successful, this request returns three result
values in addition to the success status. The result values are
non-negative integers. Their interpretation is local. For
example, Cisco Systems terminal servers interpret result3 to be
the identifier of a local access list to use for additional
validation.
入力フィールドの意味はAUTHが要求するのと同じです。 要求がうまくいくなら、この要求は成功状態に加えて3つの結果値を返します。 結果値は非負の整数です。 解釈は地元です。 例えば、シスコシステムズターミナルサーバは、追加合法化に使用するローカルのアクセスリストに関する識別子になるようにresult3を解釈します。
CONNECT(username, password, line, destinationIP, destinationPort) returns (result1, result2, result3)
CONNECT(ユーザ名、パスワード、系列、destinationIP、destinationPort)は戻ります。(result1、result2、result3)
This request can only be issued when the username and line specify
an already-existing connection. As such, no authentication is
required and the password will in general be the empty string. It
asks, in the context of that connection, whether a TCP connection
can be opened to the specified destination IP address and port.
ユーザ名と系列が既に既存の接続を指定すると、この要求を出すことができるだけです。 そういうものとして、認証は全く必要ではありません、そして、一般に、パスワードは空のストリングになるでしょう。 それは尋ねます、その接続の文脈で、指定された送付先IPアドレスとポートにTCP接続を開くことができるか否かに関係なく。
The return values are as for LOGIN.
リターン値はLOGINに似ています。
SUPERUSER(username, password, line)
SUPERUSER(ユーザ名、パスワードは立ち並んでいます)
This request can only be issued when the username and line specify
an already-existing connection. As such, no authentication is
required and the password will in general be the empty string. It
asks, in the context of that connection, whether the user can go
into "super-user" or "enable" mode on the terminal server.
ユーザ名と系列が既に既存の接続を指定すると、この要求を出すことができるだけです。 そういうものとして、認証は全く必要ではありません、そして、一般に、パスワードは空のストリングになるでしょう。 それは尋ねます、その接続の文脈で、ユーザが「スーパーユーザ」に入るか、またはターミナルサーバでモードを「可能にすることができること」にかかわらず。
As an example of the flexibility inherint in this whole scheme,
the TACACSD supplied by Cisco Systems ignores the username part
and instead checks wether the password matches that of the special
user "$enable$".
「シスコシステムズによって供給されたTACACSDがこの全体の体系における柔軟性inherintに関する例として、ユーザ名部分を無視して、代わりにパスワードがそれに合っている去勢した雄羊をチェックする、」 $が可能にする特別なユーザ、$、」
LOGOUT(username, password, line, reason)
ログアウトしてください。(ユーザ名、パスワードに立ち並んで、推論してください)
This request can only be issued when the username and line specify
an already-existing connection. As such, no authentication is
required and the password will in general be the empty string. It
indicates that the connection should be terminated (but see
ユーザ名と系列が既に既存の接続を指定すると、この要求を出すことができるだけです。 そういうものとして、認証は全く必要ではありません、そして、一般に、パスワードは空のストリングになるでしょう。 それが、接続が終えられるべきであるのを示す、(見てください。
Finseth [Page 5] RFC 1492 TACACS July 1993
Finseth[5ページ]RFC1492TACACS1993年7月
SLIPON). It must be acknowledged, but the success/fail status of
the acknowledgment is irrelevant. The reason value indicates why
the connection is terminating. A null reason value is supplied
when the connection is going into SLIP mode.
SLIPON) それを承認しなければなりませんが、承認の成功/やり損ない状態は無関係です。 理由値は、接続がなぜ終わっているかを示します。 接続がSLIPモードを調べているとき、ヌル理由値を供給します。
SLIPON(username, password, line, SLIPaddress) returns (result1, result2, result3)
SLIPON(SLIPaddress、ユーザ名、パスワードは立ち並んでいる)は戻ります。(result1、result2、result3)
This request can only be issued when the username and line specify
an already-existing connection. As such, no authentication is
required and the password will in general be the empty string. It
asks, in the context of that connection, whether the specified
SLIPaddress can be used for the remote end of the connection.
ユーザ名と系列が既に既存の接続を指定すると、この要求を出すことができるだけです。 そういうものとして、認証は全く必要ではありません、そして、一般に、パスワードは空のストリングになるでしょう。 それは尋ねます、その接続の文脈で、接続のリモートエンドに指定されたSLIPaddressを使用できるか否かに関係なく。
If the server replies with a success, the client can proceed to a
SLIPON request. (It need not do so right away, however.)
サーバが成功で返答するなら、クライアントはSLIPON要求に続くことができます。 (しかしながら、それはすぐ、そうする必要はありません。)
Note that semantics of "username" can get hairy. For example, the
Cisco Systems implementation encodes information in this way:
「ユーザ名」の意味論が毛深くなることができることに注意してください。 例えば、シスコシステムズ実装はこのように情報をコード化します:
- If the user just requested the default address be assigned, this
field holds the username in lower case.
- ユーザがただデフォルトアドレスを要求したなら、割り当てられてください、そして、この分野は小文字のユーザ名を保持します。
- If the user requested a specific IP address or host name for the
SLIP connection, this field contains the requested host name in
UPPER case.
- ユーザがSLIP接続のために特定のIPアドレスかホスト名を要求したなら、この分野はUPPER場合における要求されたホスト名を含んでいます。
If the server replies with a success, the client will immediately
send a LOGOUT request. However, the connection will remain
established until a SLIPOFF request is sent. No other
authentication requests will be sent for that connection.
サーバが成功で返答すると、クライアントはすぐに、LOGOUT要求を送るでしょう。 しかしながら、接続はSLIPOFF要求を送るまで確立していたままでいるでしょう。 その接続のために他の認証要求を全く送らないでしょう。
SLIPaddress specifies the IP address used by the remote host. If
a SLIPADDR request has been made, it will be that address.
Otherwise, it will be the default address assigned by the client
(e.g., Cisco terminal server).
SLIPaddressはリモートホストによって使用されたIPアドレスを指定します。 SLIPADDR要求をしたなら、それはそのアドレスになるでしょう。 さもなければ、それはクライアント(例えば、シスコターミナルサーバ)によって割り当てられたデフォルトアドレスになるでしょう。
The return values are as for LOGIN.
リターン値はLOGINに似ています。
SLIPOFF(username, password, line, reason)
SLIPOFF(ユーザ名、パスワードに立ち並んで、推論してください)
This request can only be issued when the username and line specify
an already-existing connection that is in "SLIP" mode. As such,
no authentication is required and the password will in general be
the empty string. It indicates that the connection should be
terminated. It must be acknowledged, but the success/fail status
of the acknowledgment is irrelevant. The reason value indicates
why the connection is terminating.
ユーザ名と系列が「メモ用紙」モードである既に既存の接続を指定すると、この要求を出すことができるだけです。 そういうものとして、認証は全く必要ではありません、そして、一般に、パスワードは空のストリングになるでしょう。 それは、接続が終えられるべきであるのを示します。 それを承認しなければなりませんが、承認の成功/やり損ない状態は無関係です。 理由値は、接続がなぜ終わっているかを示します。
Finseth [Page 6] RFC 1492 TACACS July 1993
Finseth[6ページ]RFC1492TACACS1993年7月
2.0 UDP Encoding: TACACS
2.0 UDPコード化: TACACS
This section describes the UDP encoding of the requests that have just been described. It also describes the responses. This UDP encoding forms the basis of the historical TACACS protocol.
このセクションはちょうど説明される要求のUDPコード化について説明します。 また、それは応答について説明します。 このUDPコード化は歴史的なTACACSプロトコルの基礎を形成します。
This protocol uses port 49. This assignment continues to be confirmed by the IANA in the Assigned Numbers RFCs. (I can't say that it was assigned by the IANA as the assignment preceded the organization.)
このプロトコルはポート49を使用します。 この課題は、Assigned民数記RFCsのIANAによって確認され続けています。 (私は、課題が組織に先行したときそれがIANAによって割り当てられたと言うことができません。)
The basic packet format is shown here. All multi-bytes values are in network byte order. Unless otherwise specified, all values given are in decimal. Unused fields should be set to zero, but the recipient should not depend on that setting.
基本的なパケット・フォーマットはここに示されます。 ネットワークバイトオーダーにはすべてのマルチバイト値があります。 別の方法で指定されない場合、小数には与えられたすべての値があります。 未使用の分野はゼロに設定されるべきですが、受取人はその設定に依存するべきではありません。
As was mentioned earlier, there are both simple and extended forms, of which the simple form is a proper subset of the extended form. A server should support both. I will describe both forms in parallel.
より早く言及されたように、簡単なものと同様に拡張しているフォームがあります。(そこでは、単純形が拡張型の真部分集合です)。 サーバは両方をサポートするべきです。 私は平行な両方のフォームについて説明するつもりです。
Simple Form
単純形
The fields are:
分野は以下の通りです。
offset length field
オフセット長さの分野
0 1 version
1 1 type
2 2 nonce value
4 1 username length (to server) / response (to client)
5 1 password length (to server) / reason (to client)
0 1バージョン1 1 2 2一回だけの値4 1ユーザ名の長さ(サーバへの)/応答(クライアントへの)5 1パスワードの長さ(サーバへの)/理由をタイプしてください。(クライアントへの)
in the usual packet layout format:
普通のパケットレイアウト形式で:
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... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : バージョン: 以下をタイプしてください。 一回だけ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ユーザlen/Resp: PW len/理由: データ… : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Finseth [Page 7] RFC 1492 TACACS July 1993
Finseth[7ページ]RFC1492TACACS1993年7月
Extended Form
拡張型
The fields are:
分野は以下の通りです。
offset length field
オフセット長さの分野
0 1 version
1 1 type
2 2 nonce value
4 1 username length
5 1 password length
6 1 response
7 1 reason
8 4 result1
12 4 destination host, IP address
16 2 destination port
18 2 line
20 4 result2
24 2 result3
26 varies data: username + password
0 1バージョン1 1 12 4の目的地が接待するタイプ一回だけの2 2の長さの6 1応答7 1値の4 1ユーザ名長さの5 1パスワード理由8 4result1、IPアドレス16 2仕向港18 2系列20 4result2 24 2result3 26はデータを変えます: ユーザ名+パスワード
in the usual packet layout format:
普通のパケットレイアウト形式で:
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 : Password len : Response : Reason :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Result 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Destination Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Dest Port : Line :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Result 2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Result 3 : data... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : バージョン: 以下をタイプしてください。 一回だけ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ユーザlen: パスワードlen: 応答: 理由: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 結果1: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 送付先アドレス: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Destポート: 線: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 結果2: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 結果3: データ… : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1 Fields
2.1 フィールズ
The VERSION field specifies the version number. It must be zero for simple or 128 (80 hexadecimal) for extended.
バージョン分野はバージョン番号を指定します。 それがゼロであるに違いない、簡単である、128(80 16進)、広げられます。
Finseth [Page 8] RFC 1492 TACACS July 1993
Finseth[8ページ]RFC1492TACACS1993年7月
The TYPE field encodes the request type. Values are:
TYPE分野は要求タイプをコード化します。 値は以下の通りです。
LOGIN 1
RESPONSE 2 (server to client only)
CHANGE 3
FOLLOW 4
CONNECT 5
SUPERUSER 6
LOGOUT 7
RELOAD 8
SLIPON 9
SLIPOFF 10
SLIPADDR 11
LOGIN1RESPONSE2(クライアントだけへのサーバ)CHANGE3FOLLOW4CONNECT5SUPERUSER6LOGOUT7RELOAD8SLIPON9SLIPOFF10SLIPADDR11
Other values below 128 are reserved for future use. Values from 128 to 255 are reserved for local use.
128の下における他の値は今後の使用のために予約されます。 128〜255までの値は地方の使用のために予約されます。
Note that the semantics of the CHANGE, FOLLOW, RELOAD requests have not been determined.
CHANGE、FOLLOW、RELOAD要求の意味論が決定していないことに注意してください。
The NONCE field is set by the client to an arbitrary value. Its purpose is to allow clients that may have multiple outstanding requests to determine which request a response is for. The server must copy this value to the reply unaltered.
NONCE分野はクライアントによって任意の値に設定されます。 目的はどれが、応答があるよう要求するかを決定するという複数の傑出している要求を持っているかもしれないクライアントを許容することです。 サーバは非変更された回答にこの値をコピーしなければなりません。
The USERNAME LENGTH field is set by the client to the length of the username in characters. Legal values are 0 to 255, inclusive. The server must copy this value to the reply unaltered.
USERNAME LENGTH分野はキャラクタのユーザ名の長さへのクライアントによるセットです。 正当な値は、0〜255です。包括的。 サーバは非変更された回答にこの値をコピーしなければなりません。
The PASSWORD LENGTH is set by the client to the length of the password in characters. Legal values are 0 to 255, inclusive. The server must copy this value to the reply unaltered.
PASSWORD LENGTHはキャラクタのパスワードの長さへのクライアントによるセットです。 正当な値は、0〜255です。包括的。 サーバは非変更された回答にこの値をコピーしなければなりません。
The RESPONSE field should be set by the client to zero. The server sets the value to one of:
RESPONSE分野はクライアントによってゼロに設定されるべきです。 サーバは以下について1つに値を設定します。
value meaning
値の意味
1 accepted
2 rejected
1は、2が拒絶されていると受け入れました。
Other values below 128 are reserved for future use. Values from 128 to 255 are reserved for local use.
128の下における他の値は今後の使用のために予約されます。 128〜255までの値は地方の使用のために予約されます。
Finseth [Page 9] RFC 1492 TACACS July 1993
Finseth[9ページ]RFC1492TACACS1993年7月
The REASON field should be set by the client to zero, except for LOGOUT and SLIPOFF requests, which may use values of 4, 5, or 6. The server sets the value to one of:
LOGOUTとSLIPOFFを除いて、REASON分野が4、5、または6の値を使用するかもしれない要求のゼロに合うようにクライアントによって設定されるべきです。 サーバは以下について1つに値を設定します。
value meaning notes
値の意味注意
0 none used for ACCEPTED or if the server
is ornery
1 expiring
2 password
3 denied
4 quit user quit normally
5 idle idle timeout
6 drop carrier dropped
7 bad too many bad passwords
通常、ACCEPTEDかそれともサーバが2パスワード3を吐き出す強情な1が、4がユーザをやめることを否定したということであるかどうかのためになにも使用しなかった0が活動していないアイドルタイムアウト6低下キャリヤーが下げた5をやめる、7、悪、あまりに多くの無効なパスワード
The values from 4 to 6 will only be used for reasons for LOGOUT or SLIPOFF requests: they will not be returned by the server. Other values below 128 are reserved for future use. Values from 128 to 255 are reserved for local use.
4〜6までの値はLOGOUTの理由かSLIPOFF要求に使用されるだけでしょう: それらはサーバによって返されないでしょう。128の下における他の値は今後の使用のために予約されます。 128〜255までの値は地方の使用のために予約されます。
The RESULT1 field should be set by the client to zero. For LOGIN or CONNECT requests, it is set by the server as specified in the request description. For all other requests, it should be set by the server to zero.
RESULT1分野はクライアントによってゼロに設定されるべきです。 LOGINかCONNECT要求において、それは要求記述における指定されるとしてのサーバによって設定されます。 他のすべての要求において、それはサーバによってゼロに設定されるべきです。
The DESTINATION HOST field is set by the client. On CONNECT, SLIPON, and SLIPOFF requests it specifies an IP address. It should be set to zero on all other requests. For SLIPON and SLIPOFF request, this value should be the IP address assigned to the line. For CONNECT requests, this value is the IP address of the host that the user is attempting to connect to. The server copies this value to the reply.
DESTINATION HOST分野はクライアントによって設定されます。 CONNECT、SLIPON、およびSLIPOFF要求のときに、それはIPアドレスを指定します。 それは他のすべての要求のゼロに設定されるべきです。 SLIPONとSLIPOFF要求のために、この値は系列に割り当てられたIPアドレスであるべきです。 CONNECT要求のために、この値は接するユーザが、試みているホストのIPアドレスです。 サーバはこの値を回答にコピーします。
The DESTINATION PORT field is set by the client. On CONNECT requests it specifies the port number that the user is attempting to connect to. It should be set to zero on all other requests. The server copies this value to the reply.
DESTINATION PORT分野はクライアントによって設定されます。 CONNECT要求のときに、それは接続するユーザが、試みているポートナンバーを指定します。 それは他のすべての要求のゼロに設定されるべきです。 サーバはこの値を回答にコピーします。
The LINE field is set by the client to the line number that the request is for. The server copies this value to the reply.
線分野はクライアントによって要求がある行番号に設定されます。 サーバはこの値を回答にコピーします。
The RESULT2 field should be set by the client to zero. For LOGIN or CONNECT requests, it is set by the server as specified in the request description. For all other requests, it should be set by the server to zero.
RESULT2分野はクライアントによってゼロに設定されるべきです。 LOGINかCONNECT要求において、それは要求記述における指定されるとしてのサーバによって設定されます。 他のすべての要求において、それはサーバによってゼロに設定されるべきです。
The RESULT3 field should be set by the client to zero. For LOGIN or CONNECT requests, it is set by the server as specified in the request
RESULT3分野はクライアントによってゼロに設定されるべきです。 LOGINかCONNECT要求において、それは要求における指定されるとしてのサーバによって設定されます。
Finseth [Page 10] RFC 1492 TACACS July 1993
Finseth[10ページ]RFC1492TACACS1993年7月
description. For all other requests, it should be set by the server to zero.
記述。 他のすべての要求において、それはサーバによってゼロに設定されるべきです。
The DATA field contains just the text of the username and password, with no separator characters (you use username length and password length to sort them out). The server does not copy the values to the reply. (However, the server does copy the username length and password length fields to the reply.) The username data may be in upper case: comparisons should be case-insensitive.
DATA分野はまさしくユーザ名とパスワードのテキストを含んでいます、分離符キャラクタなしで(あなたは彼らを整理するのにユーザ名の長さとパスワードの長さを使用します)。 サーバは回答に値をコピーしません。 (しかしながら、サーバは、ユーザ名の長さをコピーにして、パスワードの長さに回答への分野をします。) 大文字の中にユーザ名データがあるかもしれません: 比較は大文字と小文字を区別しないはずです。
2.2 What a Client Does
2.2 クライアントがすること
The client must format and send a UDP request to port 49. It constructs the request by following these steps:
クライアントは、49を移植するというUDP要求をフォーマットして、送らなければなりません。 それはこれらの方法に従うことで要求を構成します:
- set the version to 128
- set the type to that of the request
- set the nonce to a unique value that is different from all
outstanding requests
- set the username length
- set the password length
- set the response to zero
- set the reason to zero (except for LOGOUT and SLIPOFF)
- set the result1 to zero
- if CONNECT, SLIPON, or SLIPOFF, set the destination address
to the IP address, otherwise set it to zero
- if CONNECT, set the destination port to the port, otherwise
set it to zero
- set the line
- set the result2 to zero
- set the result3 to zero
- copy the username to the location just after result3
- copy the password to the location just after the end of the
username
- 128にバージョンを設定してください--要求のものにタイプを設定してください--すべての傑出している要求と異なったユニークな値に一回だけを設定してください--ユーザ名の長さを設定してください--パスワードの長さを設定してください--ゼロに応答を設定してください--ゼロ(LOGOUTとSLIPOFFを除いた)に理由を設定してください--CONNECT(SLIPON、またはSLIPOFF)がIPアドレスに送付先アドレスを設定するなら、ゼロにresult1を設定してください; さもなければ、ゼロにそれを設定してください--さもなければ、ゼロにそれを設定してください--系列を設定してください--ゼロにresult2を設定してください--ゼロにresult3を設定してください--ユーザ名をresult3のすぐ後の位置までコピーしてください--CONNECTであるなら、ポートに仕向港を設定してください、そして、パスワードをまさしくユーザ名の終わり以降位置までコピーしてください。
Send the request. Wait for a reasonable (and hopefully configurable) period of time. If no response has been received, retry a reasonable (and hopefully configurable) number of times. Reasonable default wait times are 5 seconds and retries are 2.
要求を送ってください。 妥当で(願わくは構成可能)の期間の間、待ってください。 応答を全く受けていないなら、妥当で(願わくは構成可能)の回数を再試行してください。 妥当なデフォルト待ち回数は5秒です、そして、再試行は2です。
If a response has been received, use the nonce value (and as many other fields as you like) to match it to an outstanding request. If there is no matching outstanding request, take appropriate (and hopefully configurable) action such as discarding and/or logging the packet.
応答を受けたなら、一回だけの値(そして、他の好きなだけ多くの分野)を使用して、傑出している要求にそれを合わせてください。 どんな合っている傑出している要求もなければ、パケットを捨てる、そして/または、登録などなどの適切で(願わくは構成可能)の行動を取ってください。
If the response matches an outstanding request, examine the response and reason codes and take whatever action you deem correct. For
応答が傑出している要求に合っているなら、応答と理由コードを調べてください、そして、あなたが正しいと考えるどんな行動も取ってください。 for
Finseth [Page 11] RFC 1492 TACACS July 1993
Finseth[11ページ]RFC1492TACACS1993年7月
responses to LOGIN and CONNECT requests, also incorporate the result1, result2, and result3 values as you deem correct.
あなたが、正しいと考えるように、LOGINとCONNECTへの応答は、result1、result2、およびresult3値を要求して、また、組み込みます。
2.3 What a Server Does
2.3 サーバがすること
Upon receipt of a UDP format request, the server examines the data in the request packet and determines its response. It constructs the reply by following these steps:
UDP形式要求を受け取り次第、サーバは、リクエスト・パケットでデータを調べて、応答を決定します。 それはこれらの方法に従うことで回答を構成します:
- set the version to 128
- set the type to RESPONSE (2)
- copy the nonce value
- copy the username length value
- copy the password length value
- set the response value to the desired response
- set the reason value to the desired reason
- if LOGIN or CONNECT, set the result1 else zero the result1
- copy the destination host value
- copy the destination port value
- copy the line value
- if LOGIN or CONNECT, set the result2 else zero the result2
- if LOGIN or CONNECT, set the result3 else zero the result3
- do NOT copy the username or password data
- 128にバージョンを設定してください--RESPONSE(2)にタイプを設定してください--一回だけの値をコピーしてください--ユーザ名長さの価値をコピーしてください--パスワード長さの価値をコピーしてください--必要な応答に応答値を設定してください--LOGINかCONNECTであるなら必要な理由に理由値を設定してください; 設定されて、result1はほかのresult1のゼロに合っています--あて先ホスト値をコピーしてください--仕向港値をコピーしてください--系列値をコピーしてください--LOGINかCONNECTであるなら、設定されて、result2はほかのresult2のゼロに合っています--LOGINかCONNECTであるなら、設定されて、result3はほかのresult3のゼロに合っています--ユーザ名かパスワードデータをコピーしないでください。
(As always, be liberal in what you expect and conservative in what you send.) Send the response. Do not attempt to retry, as you have no basis for determining whether a retry is required. Any retries are up to the client. This, of course, implies that requests are idempotent. They aren't, of course, so the retries must be considered when trying to assemble requests into connections.
(いつものように、あなたが予想することで寛容であって、あなたが送るもので保守的であってください。) 応答を送ってください。 再試行が必要であるかどうか決定する基礎が全くないとき、再試行するのを試みないでください。 どんな再試行もクライアント次第です。 これは、要求がベキ等元であることをもちろん含意します。 それらがそうでない、もちろん接続に要求を組み立てようとするとき、再試行を考えなければならなくて。
3.0 TCP Encoding
3.0 TCPコード化
This section describes the TCP encoding of the requests and responses. This encoding is not compatible with the historical TACACS protocol. However, it is somewhat more "modern" in that it has been updated to provide for current feature needs.
このセクションは要求と応答のTCPコード化について説明します。 このコード化は歴史的なTACACSプロトコルと互換性がありません。 しかしながら、それは、現在の特徴の必要性に備えるためにそれをアップデートしたので、いくらかより「現代的です」。
This protocol does not use a reserved port. Instead, it must be possible to configure the ports used by both the the client and server.
このプロトコルは予約されたポートを使用しません。 代わりに、クライアントとサーバの両方によって使用されるポートを構成するのは可能でなければなりません。
The basic request format is shown here. The request consists of four lines of ASCII text. All numeric values are expressed in ASCII as decimal integers.
基本的な要求書式はここに示されます。 要求はASCIIテキストの4つの系列から成ります。 すべての数値が10進整数としてASCIIで言い表されます。
Finseth [Page 12] RFC 1492 TACACS July 1993
Finseth[12ページ]RFC1492TACACS1993年7月
<version> <type> <parameters>
<username>
<password>
<line>
<バージョン><タイプ><パラメタ><ユーザ名><パスワード><系列>。
Each line in the example corresponds to one line of text. That is, the lines are separated with <CR>/<LF> (13/10 decimal) pairs. In no event may "bare" <CR> or <LF> characters appear within a field. In addition, <NUL> (0 decimal) characters may not be sent.
例の各系列は1個のテキスト行に対応しています。 すなわち、系列は<CR>/<LF>(13/10小数)組と共に切り離されます。 「むき出し」の<CR>か<LF>キャラクタが分野の中に決して、現れませんように。 さらに、<NUL>(0小数)キャラクタは送られないかもしれません。
The <version> and <type> fields are separated with one or more <SPACE> (32 decimal) or <TAB> (9 decimal) characters.
<バージョン>とタイプ>がさばく<は1<SPACE>(32小数)か<TAB>(9小数)キャラクタと共に切り離されます。
The <parameters> field is optional. If present, it is separated from the <type> field and internal parameters separated from each other by or more <SPACE> or <TAB> characters. Any trailing <SPACE> or <TAB> characters present on this line should be ignored by the server: they should not be taken to imply a trailing empty field.
<パラメタ>分野は任意です。 存在していると、それはタイプ>がさばいて、内部のパラメタが互いから分離した<、より多くの<SPACE>または<TAB>キャラクタと切り離されます。 この系列に出席しているどんな引きずっている<SPACE>や<TAB>キャラクタもサーバによって無視されるべきです: 引きずっている何もない草原を含意するためにそれらを取るべきではありません。
In theory there are no line length limits. In practice, lines should not exceed 255 characters (counting the <CR> and <LF>) and probably should be 80 characters or less.
理論上、行長限界が全くありません。 実際には、系列は、255のキャラクタ(<CR>と<LF>を数える)を超えるべきでなくて、たぶん80以下のキャラクタであるべきです。
3.1 Fields
3.1 フィールズ
The VERSION field specifies the version number. It must be 1. Other values below 128 are reserved for future use. Values from 128 to 255 are reserved for local use.
バージョン分野はバージョン番号を指定します。 それは1であるに違いありません。 128の下における他の値は今後の使用のために予約されます。 128〜255までの値は地方の使用のために予約されます。
The TYPE field encodes the request type. Values are:
TYPE分野は要求タイプをコード化します。 値は以下の通りです。
AUTH
LOGIN
CONNECT
SUPERUSER
LOGOUT
SLIPON
SLIPOFF
AUTHログインがSUPERUSERを接続する、ログアウト、SLIPON SLIPOFF
I.e., the keyword simply encodes itself. It must be in upper case. Keywords that begin with the letter "X" are reserved for local use.
すなわち、キーワードは単にそれ自体をコード化します。 大文字の中にそれはあるに違いありません。 文字「X」で始まるキーワードは地方の使用のために予約されます。
The USERNAME field contains the text of the username. Leading and trailing <SPACE> or <TAB> characters are considered significant. The username data may be in upper case: comparisons should be case- insensitive.
USERNAME分野はユーザ名のテキストを含んでいます。 主で引きずっている<SPACE>か<TAB>キャラクタが重要であると考えられます。 大文字の中にユーザ名データがあるかもしれません: 比較はケース神経が鈍いはずです。
The PASSWORD field contains the text of the password. Leading and
PASSWORD分野はパスワードのテキストを含んでいます。 そして主である。
Finseth [Page 13] RFC 1492 TACACS July 1993
Finseth[13ページ]RFC1492TACACS1993年7月
trailing <SPACE> or <TAB> characters are considered significant.
引きずっている<SPACE>か<TAB>キャラクタが重要であると考えられます。
The LINE field is set by the client to the line number that the request is for.
線分野はクライアントによって要求がある行番号に設定されます。
3.2 Responses
3.2 応答
Appendix E of STD 10, RFC 821 describes the general theory of reply codes. The this protocol follows the format described in that document. In a nutshell, replies are of the form:
STD10の付録E、RFC821は回答コードの一般理論について説明します。 このプロトコルはそのドキュメントで説明された形式に続きます。 殻では、回答はフォームのものです:
<number> <text>
<数の><テキスト>。
Where <number> is a three-digit decimal value and <text> is an arbitrary text string, presumably containing only printing text characters (<SP> (32 decimal) through "~" (126 decimal)). At least one <SP> (32 decimal) character separates the number from the text. A <CR>/<LF> sequence follows the text.
<番号>がどこの3ケタのデシマル値であるか、そして、<テキスト>は任意のテキスト文字列です、おそらく、印刷テキストキャラクタ(「~」(126小数)を通した<SP>(32小数))だけを含んでいて。 少なくとも1<SP>(32小数)キャラクタはテキストと数を切り離します。 <CR>/<LF>系列はテキストに従います。
The three digit codes completely determine the response. The text should be considered an explanatory comment for human understanding. However, even without knowing all values, the first digit can be used to determine the overall nature of the response. The encodings are:
3つのケタコードが応答を完全に決定します。 テキストは人知のための説明しているコメントであると考えられるべきです。 しかしながら、すべての値を知りさえするというわけではなくて、応答の総合的な本質を決定するのに最初のケタを使用できます。 encodingsは以下の通りです。
1 Positive Preliminary: the request is acceptable,
but no action will be taken until an additional
request is made (not used in this version of the
protocol)
1つの陽の準備段階: 要求は許容できますが、追加要求をするまで行動を全く取らないでしょう。(プロトコルのこのバージョンで中古でない)です。
2 Positive Completion
2 積極的な完成
3 Positive Intermediate: the request is acceptable
so far, but has not been completely transferred
(not used in this version of the protocol)
3の積極的な中間介在物: 要求を今までのところ、許容できますが、完全に移すというわけではありませんでした。(プロトコルのこのバージョンで中古でない)です。
4 Transient Negative: the request is not acceptable
for now. It is acceptable to retry, as another
instance may have a different result.
4の一時的なネガ: 要求は当分許容できません。 別のインスタンスには異なった結果があるかもしれないので、再試行するのは許容できます。
5 Permanent Negative: the request is not acceptable
5の永久的なネガ: 要求は許容できません。
The text portion is optional (i.e., may be the empty string) and it describes the meaning of the message in human readable form.
テキスト部分は任意です、そして、(すなわち、空のストリングであるかもしれません)それは人間の読み込み可能なフォームでメッセージの意味について説明します。
Finseth [Page 14] RFC 1492 TACACS July 1993
Finseth[14ページ]RFC1492TACACS1993年7月
While different server implementations will result in different messages, the following are suggested:
異なったサーバ実装が異なったメッセージをもたらす間、以下は示されます:
201 accepted: # # #
202 accepted, password is expiring: # # #
401 no response; retry
501 invalid format
502 access denied
201は受け入れました: # # # 202は受け入れて、パスワードは期限が切れています: # # # 401 応答がありません。 501の無効の形式502アクセス拒否を再試行してください。
The ": # # #" in the first two messages is the suggested way of returning the three result codes for LOGIN and CONNECT requests.
「The」、: # # #「最初の2つのメッセージに、LOGINとCONNECT要求のために3つの結果コードを返す提案された方法があります。」
3.3 What a Client Does
3.3 クライアントがすること
The client opens a TCP connection to the locally-configured address and port. It sends the request by sending:
クライアントは局所的に構成されたアドレスとポートにTCP接続を開きます。 それは発信することによって、要求を送ります:
- the character "1"
- one or more <SPACE> or <TAB> characters
- the request type as an ASCII string
- if an AUTH, send one or more <SPACE> or <TAB> characters
and the authentication style
- if a CONNECT, SLIPON, or SLIPOFF, send one or more <SPACE>
or <TAB> characters and the IP address in dotted decimal
notation
- if a CONNECT, send one or more <SPACE> or <TAB> characters
and the port number in decimal
- a <CR>/<LF>
- the username (or hostname for SLIPADDR)
- a <CR>/<LF>
- the password
- a <CR>/<LF>
- the line
- a <CR>/<LF>
- キャラクタ「1インチ--1<のスペース>か<タブ>キャラクタ--ASCIIストリングとしての要求タイプ--AUTHであるなら、タブ>キャラクタと認証スタイルを1<のスペースの>か<に送ってください--SLIPON、またはSLIPOFFがドット付き10進法でタブ>キャラクタとIPアドレスを1<のスペースの>か<に送ります--aであるなら接続してください、そして、aであるなら接続してください」; 小数における>キャラクタとポートナンバー--<CR>/<LF>--ユーザ名(または、SLIPADDRのためのホスト名)--<CR>/<LF>--パスワード--<CR>/<LF>--系列を1<SPACE>か<TABに送ってください--、<CR>/<LF>。
Then read one line from the connection and close the connection. This encoding lets TCP take care of waiting, retries, and matching up requests and responses.
次に、接続から1つの系列を読んでください、そして、接続を終えてください。 このコード化で、TCPは待ちと、再試行と、要求と応答を合わせるように注意します。
Examine the response line and take whatever action you deem correct.
応答系列を調べてください、そして、あなたが正しいと考えるどんな行動も取ってください。
3.4 What the Server Does
3.4 サーバがすること
The server waits on the locally-specified port for requests. When one is made, it reads four lines of input.
サーバは要求のために局所的に指定されたポートで待っています。 1つが作られているとき、それは入力の4つの系列を読みます。
It examines the first line for a valid version number and request. It also records any optional parameters.
それは有効なバージョン番号と要求がないかどうか最初の系列を調べます。 また、それはどんな任意のパラメタも記録します。
Finseth [Page 15] RFC 1492 TACACS July 1993
Finseth[15ページ]RFC1492TACACS1993年7月
It uses the username, password, and line number along with any other information it deems fit to determine its response.
それはそれが応答を決定するのが適任であると考えるいかなる他の情報に伴うユーザ名、パスワード、および行番号も使用します。
It then sends exactly one line of response, terminated by a <CR>/<LF>, and closes the connection.
それは、次に、まさに応答の1つの系列を送って、<CR>/<LF>で終わって、接続を終えます。
4.0 Pros and Cons
4.0 賛否両論
Advantages to using the UDP format:
UDPを使用する利点は以下をフォーマットします。
- lower overhead
- compatible with historical standard
- some existing equipment supports it
- 何らかの既存の設備がそれをサポートする歴史的な規格とのコンパチブル低いオーバーヘッド
Advantages to using the TCP format:
TCPを使用する利点は以下をフォーマットします。
- easier to implement, especially on machines with no or
poor UDP support
- simpler, cleaner syntax
- potentially wider range of error codes, and support for
temporary and negotiated authentication sequences
- ノーか不十分なUDPサポート--より簡単で、より清潔な構文--潜在的により広い誤差の範囲コードがあるマシンの特に上で実装して、一時的で交渉された認証系列のためにサポートするのは、より簡単です。
5.0 Security Notes
5.0 セキュリティ紙幣
While the protocol itself has been described, there are a number of other considerations worth mentioning.
プロトコル自体は説明されますが、言及する価値がある他の多くの問題があります。
First, the protocol carries the username and password in clear text in either a single UDP packet or a TCP stream. As such, if an attacker is capable of monitoring that data, the attacker could capture username/password pairs. Implementations can take several steps to minimize this danger:
まず最初に、プロトコルは単一のUDPパケットかTCPストリームのどちらかにおけるクリアテキストのユーザ名とパスワードを運びます。 そういうものとして、攻撃者がそのデータをモニターできるなら、攻撃者はユーザ名/パスワード組をキャプチャするかもしれません。 実装はこの危険を最小にするためにいくつかの方法を採ることができます:
- Use point-to-point links where possible.
- 可能であるところでポイントツーポイント接続を使用してください。
- Physically secure the transmission medium.
- 物理的にトランスミッション媒体を保証してください。
- If packets must traverse multiple network segments, use a secure routing subsystem. This implies:
- パケットが複数のネットワークセグメントを横断しなければならないなら、安全なルーティングサブシステムを使用してください。 これは以下を含意します。
- Tight control over router configurations.
- Tight control over routing protocols.
- Avoid use of bridges, as they can be silently fooled into
duplicating packets.
- ルータ構成の厳格な管理。 - ルーティング・プロトコルの厳格な管理。 - パケットをコピーするように静かにそれらをだますことができるようにブリッジの使用を避けてください。
Second, this protocol potentially opens up a new way of probing usernames and passwords. Thus, implementations may wish to have
2番目に、このプロトコルは潜在的にユーザ名とパスワードを調べる新しい方法を開けます。 その結果、実装は持ちたがっているかもしれません。
Finseth [Page 16] RFC 1492 TACACS July 1993
Finseth[16ページ]RFC1492TACACS1993年7月
servers:
サーバ:
- limit responses to a controlled list of clients,
- throttle the rate of responding to requests,
- log all failures (and possibly successes, too).
- 応答を制御顧客リストに制限してください--応じる対要求のレートを阻止してください--すべての失敗を登録してください、(そして、ことによると成功、また)
Third, this protocol essentially allows clients to offload accept/reject decisions to servers. While an obvious implementation would simply use the server's native login mechanism to make the determination, there is no reason to limit implementations to that mechanism. Servers could:
3番目に、クライアントがプロトコルで本質的には積み下ろすことができるこれは、サーバに決定を受け入れるか、または拒絶します。 明白な実装は決定を下すのに単にサーバの固有のログインメカニズムを使用するでしょうが、実装をそのメカニズムに制限する理由が全くありません。 サーバはそうすることができました:
- use alternate lists of accounts (e.g., password files),
- use alternate mechanisms for accessing the accounts (e.g.,
a database, NIS),
- use alternate algorithms (e.g., SecureID cards),
- translate the request to another protocol and use that
protocol to make the determination (e.g., Kerberos).
- アカウント(例えば、パスワードファイル)に関する補欠リストを使用してください--アカウント(例えば、データベース、NIS)にアクセスするのに代替のメカニズムを使用してください--代替のアルゴリズム(例えば、SecureIDカード)を使用してください--別のプロトコルに要求を翻訳してください、そして、決定を下すこと(例えば、ケルベロス)にそのプロトコルを使用してください。
Fourth, the use of a "fanout" server (described in the next section) allows for:
4番目に、"fanout"サーバ(次のセクションで、説明される)の使用は以下を考慮します。
- centralized logging of usage for attack analysis
- centralized policy:
- 攻撃分析--方針を集結する用法の集結された伐採:
- ability to block selected specific users
- ability to block selected user names (e.g., don't
allow "root" or "guest")
- ability to block poor passwords (e.g., none or weak)
- 選択された特定のユーザを妨げる能力--選択されたユーザー名(例えば、「根」か「ゲスト」を許容しない)を妨げる能力--不十分なパスワードを妨げる能力(例えば、なにもか弱者)
6.0 Case Study
6.0 ケーススタディ
This section presents the basic steps used by the implementation at the University of Minnesota. Two examples will be used. The first is a basic terminal login. The second is a database access verification.
このセクションはミネソタ大学の実装によって使用される基本的なステップを提示します。 2つの例が使用されるでしょう。 1番目は基本的な端末のログインです。 2番目はデータベースアクセス検証です。
Usernames are in one of three forms:
ユーザ名が3つのフォームの1つにあります:
First.M.Last-#@umn.edu
First.M.Last-#
user@host
First.M.Last-#@umn.edu First.M.Last-# user@host
A name in the first form is converted to one in the second.
最初のフォームでの名前は秒に1つに転向しています。
A name in the second form is looked up in the University-wide directory system. If found, the associated electronic mail address is treated as if the third form was entered.
2番目のフォームでの名前は大学全体のディレクトリシステムで調べられます。 見つけられるなら、まるで3番目のフォームが入れられるかのように関連電子メールアドレスは扱われます。
Finseth [Page 17] RFC 1492 TACACS July 1993
Finseth[17ページ]RFC1492TACACS1993年7月
The third form specifics the name of a computer whose manager has agreed to perform validations and the name of an account on that computer.
3番目は詳細を形成します。マネージャが合法化を実行するのに同意したコンピュータの名前とそのコンピュータの上のアカウントの名前。
The system that we use allows for many requesting clients (typically modem pools). Further, each client can support multiple distinct pools of users. For example, lines 1-20 could be general access, but lines 21-25 could be 800-numbers with a restricted set of valid users. The system supports this distinction by specifying which validation computers are legal for each modem pool.
私たちが使用するシステムは、クライアント(通常モデムプール)を要求しながら、多くを考慮します。 さらに、各クライアントはユーザの複数の異なったプールを支えることができます。 例えば、系列1-20は一般的なアクセスであるかもしれませんが、系列21-25は制限されたセットの正規ユーザーがいる800番号であるかもしれません。 それぞれのモデムプールに、どの合法化コンピュータが法的であるかを指定することによって、システムはこの区別をサポートします。
6.1 Terminal Login
6.1 端末のログイン
On the Cisco Terminal Server:
コクチマスターミナルサーバに関して:
- accept a connection
- request a username and password
- pack the request into a UDP TACACS packet and send to the central
fanout
- 接続を受け入れてください--ユーザ名とパスワードを要求してください--UDP TACACSパケットに要求に詰め込んでください、そして、中央のfanoutに発信してください。
Central Fanout:
中央のFanout:
- accept a request
- if the request is not in a valid format, return "nope"
- log the request
- if the source IP address is not in a list of valid clients,
status = "nope"
- else if the username contains invalid characters, status = "nope"
- else
if the username is of the form First.M.Last-#@umn.edu,
convert to First.M.Last-#
if the username is of the form First.M.Last-#,
look up the name in the directory
if the name is not found, status = "nope"
otherwise, use the e-mail address as the username
- accept a request - if the request is not in a valid format, return "nope" - log the request - if the source IP address is not in a list of valid clients, status = "nope" - else if the username contains invalid characters, status = "nope" - else if the username is of the form First.M.Last-#@umn.edu, convert to First.M.Last-# if the username is of the form First.M.Last-#, look up the name in the directory if the name is not found, status = "nope" otherwise, use the e-mail address as the username
if the user is on a special "blocked" list, status = "nope"
and send mail warning that access to a blocked
account was attempted
split the username into user and host parts
if the host is not on a list of known servers,
status = "nope"
else if the host is not allowed to validate this type of
request for this pool, status = "nope"
ユーザが「妨げられる」という特別番組にいるなら、状態=「ありません」とリストアップしてください、そして、ホストが知られているサーバのリストにいないなら封鎖勘定へのアクセスが試みられたのがユーザ名をユーザとホストの部品に分けて、ホストが「なく」このプール、状態=を求めるこのタイプの要求を有効にすることができないなら状態がほかに「ないのと」等しいというメール警告を送ってください。
now format a request for validation of the user and send it
to the specified host
今、ユーザの合法化を求める要求をフォーマットしてください、そして、指定されたホストにそれを送ってください。
Finseth [Page 18] RFC 1492 TACACS July 1993
Finseth[18ページ]RFC1492TACACS1993年7月
if no response, status = "nope"
otherwise set the status to the returned status
そうでなければ、応答がない、状態=「ありません」が返された状態に状態を設定したなら
- log what response is going to be returned - return the response
- 応答が返されることを登録してください--応答を返してください。
Validation Host:
合法化ホスト:
This machine can run a "stripped down" version of the central fanout. It need perform no special validation or logging, with one exception.
このマシンは「解体されて」中央のfanoutのバージョンを実行できます。 それは1つの例外でどんな特別な合法化も伐採も実行する必要はありません。
- accept a request - if the request is not in a valid format, return "nope" - if the request is not from the central fanout, return "nope" - figure the return status - return the response
- 申し込みに応じてください--有効な形式に要求がないなら、「ありません」(要求が中央のfanoutから来ていないなら、「なく」戻る)という図にリターン状態を返してください--応答を返してください。
6.2 Database Access Verification
6.2 データベースアクセス検証
In this example, assume that a database is only to be accessed by faculty and staff.
この例では、データベースが教授陣とスタッフによって単にアクセスされることであると仮定してください。
Mainframe:
メインフレーム:
- the user is on the mainframe and makes a request
- the program requests username and password
- the program packs the request into a UDP TACACS packet and send to
the central fanout
- ユーザは、メインフレームにいて、要求--プログラム要求ユーザ名とパスワード--プログラムがUDP TACACSパケットに要求に詰め込んで、中央のfanoutに発信するのを作ります。
Central Fanout:
中央のFanout:
- accept a request
- if the request is not in a valid format, return "nope"
- log the request
- if the source IP address is not in a list of valid clients,
status = "nope"
- else if the username contains invalid characters, status = "nope"
- else
if the username is of the form First.M.Last-#@umn.edu,
convert to First.M.Last-#
if the username is of the form First.M.Last-#,
look up the name in the directory
if the name is not found, status = "nope"
otherwise, use the e-mail address as the username
and obtain the staff status from the directory
if the user is on a special "blocked" list, status = "nope"
and send mail warning that access to a blocked
account was attempted
ユーザ名であるなら、最後の#、はフォームFirst.M. Last-#のものです、そして、名前がユーザが特別な「妨げられた」リスト、状態=に「なく」いるなら、別の方法で状態=「ありません」がわかって、ユーザ名としてEメールアドレスを使用して、ディレクトリからスタッフ状態を得ないことであるならディレクトリの名前を調べてください、そして、封鎖勘定へのアクセスが試みられたというメール警告を送ってください。
Finseth [Page 19] RFC 1492 TACACS July 1993
Finseth[19ページ]RFC1492TACACS1993年7月
split the username into user and host parts
if the host is not on a list of known servers,
status = "nope"
else if the host is not allowed to validate this type of
request for this pool, status = "nope"
ユーザ名をユーザに分けてください、そして、ホストがほかに知られているサーバ、状態=「ありません」のリストにいないで、ホストが「なく」このプール、状態=を求めるこのタイプの要求を有効にすることができないなら、部品を接待してください。
now format a request for validation of the user and send it
to the specified host
今、ユーザの合法化を求める要求をフォーマットしてください、そして、指定されたホストにそれを送ってください。
if no response or status is "nope", status = "nope"
応答かどんな状態も「ありません」、「なく」状態=でないなら
else if the user originally gave a user@host mail address,
do a directory lookup and obtain the staff status
ユーザが元々 user@host 郵便の宛先を与えたなら、ほかに、ディレクトリルックアップをしてください、そして、スタッフ状態を得てください。
set the status to the staff status
- log what response is going to be returned
- return the response
スタッフ状態に状態を設定してください--応答が返されることを登録してください--応答を返してください。
Note that the validation host is unchanged.
合法化ホストが変わりがないことに注意してください。
References
参照
[RFC821] Postel, J. "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.
[RFC821]ポステル、J.「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers," STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.
[RFC1340] 科学が1992年7月に任命するレイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1340、USC/情報。
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.
アンダーソン、ブライアン。 ルース、グレッグ。 ディトマーズ、ピーター。 アイスナー、シャロン。 Delsignore、TACがアクセスするジョン(1985)がシステムプロトコル、第2版を制御します: 1985年8月16日。 BBNの科学技術のメモCC-0045。
Cisco Systems, Inc. (September 1992) Communications Server Configuration and Reference. Menlo Park, California.
シスコシステムズInc.(1992年9月)コミュニケーションサーバ構成と参照。 メンローパーク(カリフォルニア)。
Finseth [Page 20] RFC 1492 TACACS July 1993
Finseth[20ページ]RFC1492TACACS1993年7月
Security Considerations
セキュリティ問題
Security issues are the main topic of this memo.
安全保障問題はこのメモの主な話題です。
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
サービスコンピュータと情報をネットワークでつなぐクレイグA.Finsethがミネソタ大学130リンドHall207教会通りSEミネアポリスミネソタ55455-0134にサービスを提供します。
Phone: +1 612 624 3375 Fax: +1 612 626 1002
以下に電話をしてください。 +1 612 624、3375Fax: +1 612 626 1002
EMail: Craig.A.Finseth-1@umn.edu, or
fin@unet.umn.edu
メール: Craig.A.Finseth-1@umn.edu 、またはフィン@unet.umn.edu
Finseth [Page 21]
Finseth[21ページ]
一覧
スポンサーリンク
