rfc1492.txt
来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,179 行 · 第 1/3 页
TXT
1,179 行
Finseth [Page 7] RFC 1492 TACACS July 1993 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 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... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2.1 Fields The VERSION field specifies the version number. It must be zero for simple or 128 (80 hexadecimal) for extended.Finseth [Page 8] RFC 1492 TACACS July 1993 The TYPE field encodes the request type. Values are: 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 Other values below 128 are reserved for future use. Values from 128 to 255 are reserved for local use. Note that the semantics of the CHANGE, FOLLOW, RELOAD requests have not been determined. 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. 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. 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. The RESPONSE field should be set by the client to zero. The server sets the value to one of: value meaning 1 accepted 2 rejected Other values below 128 are reserved for future use. Values from 128 to 255 are reserved for local use.Finseth [Page 9] RFC 1492 TACACS July 1993 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: 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 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. 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. 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. 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. 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. 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 requestFinseth [Page 10] RFC 1492 TACACS July 1993 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.2.2 What a Client Does The client must format and send a UDP request to port 49. It constructs the request by following these steps: - 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 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. 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. ForFinseth [Page 11] RFC 1492 TACACS July 1993 responses to LOGIN and CONNECT requests, also incorporate the result1, result2, and result3 values as you deem correct.2.3 What a Server Does 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: - 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 (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 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. 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.Finseth [Page 12] RFC 1492 TACACS July 1993 <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. The <version> and <type> fields are separated with one or more <SPACE> (32 decimal) or <TAB> (9 decimal) characters. 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. 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.3.1 Fields 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. The TYPE field encodes the request type. Values are: AUTH LOGIN CONNECT SUPERUSER LOGOUT 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. 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. The PASSWORD field contains the text of the password. Leading andFinseth [Page 13] RFC 1492 TACACS July 1993 trailing <SPACE> or <TAB> characters are considered significant. The LINE field is set by the client to the line number that the request is for.3.2 Responses 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: <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. 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: 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) 2 Positive Completion 3 Positive Intermediate: the request is acceptable so far, but has not been completely transferred (not used in this version of the protocol) 4 Transient Negative: the request is not acceptable for now. It is acceptable to retry, as another instance may have a different result. 5 Permanent Negative: the request is not acceptable 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]⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?