新規
編集
添付6. Body types
All further discussions of TACACS+ packet bodies assumes that any encryption/decryption has already been performed. From here on, we are only concerned with the cleartext data.
There are several constant fields in many of the following bodies. A few merit mention here as they apply to most packet bodies.
The user is the username or user id that is authenticated or being authenticated.
The port is an ascii description of the port on which the user is connected.
The rem_addr is a "best effort" description of the remote location from which the user has connected to the client. In many cases, the remote address will not be available or will be unreliable at best, but it may be useful when included.
The user_msg is always the ASCII input from the user.
The server_msg is always used to hold a message that is intended to be presented to the user. In some contexts it may be optional as to whether to actually present it.
The data field has several uses but is not used in all packets.
6.1. Authentication
TACACS+ authentication has three packet types: START, CONTINUE and REPLY. START and CONTINUE are always sent by the client and REPLY is always sent by the daemon.
Authentication begins with the client sending a START message to the daemon. The START message describes the type of authentication to be performed, and may contain the username and some authentication data. The START packet is only ever sent as the first message in a TACACS+ authentication session, or as the packet immediately following a res- tart. (A restart may be requested by the daemon in a REPLY packet). A START packet always has seq_no equal to 1.
In response to a START packet, the daemon sends a REPLY. The REPLY message indicates whether the authentication is finished, or whether it should continue. If the REPLY indicates that authentication should continue, then it will also indicate what new information is requested. The client will get that information and return it in a CONTINUE message.
The daemon MUST always send a REPLY to both the START and the CON- TINUE messages, the only exception being if the client indicates an abort in the CONTINUE, in which case the session is immediately aborted.
Thus, there are zero or more pairs of packets where the client sends a CONTINUE and the daemon sends a REPLY.
The authentication START packet body
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+----------------+----------------+----------------+----------------+
| action | priv_lvl | authen_type | service |
+----------------+----------------+----------------+----------------+
| user len | port len | rem_addr len | data len |
+----------------+----------------+----------------+----------------+
| user ...
+----------------+----------------+----------------+----------------+
| port ...
+----------------+----------------+----------------+----------------+
| rem_addr ...
+----------------+----------------+----------------+----------------+
| data...
+----------------+----------------+----------------+----------------+
Packet fields are as follows:
action
This describes the authentication action to be performed. Legal values are:
TAC_PLUS_AUTHEN_LOGIN := 0x01
TAC_PLUS_AUTHEN_CHPASS := 0x02
TAC_PLUS_AUTHEN_SENDPASS := 0x03 (deprecated)
TAC_PLUS_AUTHEN_SENDAUTH := 0x04
priv_lvl
This indicates the privilege level that the user is authenticating as. Privilege levels are ordered values from 0 to 15 with each level representing a privilege level that is a superset of the next lower value. If a NAS client uses a different privilege level scheme, then mapping must be provided. Pre-defined values are:
TAC_PLUS_PRIV_LVL_MAX := 0x0f
TAC_PLUS_PRIV_LVL_ROOT := 0x0f
TAC_PLUS_PRIV_LVL_USER := 0x01
TAC_PLUS_PRIV_LVL_MIN := 0x00
authen_type
The type of authentication that is being performed. Legal values are:
TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01
TAC_PLUS_AUTHEN_TYPE_PAP := 0x02
TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03
TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04
TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05
service
This is the service that is requesting the authentication. Legal values are:
TAC_PLUS_AUTHEN_SVC_NONE := 0x00
TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01
TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02
TAC_PLUS_AUTHEN_SVC_PPP := 0x03
TAC_PLUS_AUTHEN_SVC_ARAP := 0x04
TAC_PLUS_AUTHEN_SVC_PT := 0x05
TAC_PLUS_AUTHEN_SVC_RCMD := 0x06
TAC_PLUS_AUTHEN_SVC_X25 := 0x07
TAC_PLUS_AUTHEN_SVC_NASI := 0x08
TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09
The ENABLE service refers to a service requesting authentication in order to grant the user different privileges. This is comparable to the Unix "su(1)" command. A service value of NONE should only be used when none of the other service values are appropriate.
user
The username. It is optional in this packet.
port
The ASCII name of the client port on which the authentication is tak- ing place. The value of this field is client specific. (For example, Cisco uses "tty10" to denote the tenth tty line and "Async10" to denote the tenth async interface).
rem_addr
An ASCII string that describes the user's remote location. This field is optional (since the information may not be available). It is intended to hold a network address if the user is connected via a
network, a caller ID is the user is connected via ISDN or a POTS, or any other remote location information that is available. This field value is client specified.
data
This field is used to send data appropriate for the action and authen_type. It is described in more detail below.
7. The authentication REPLY packet body
The TACACS+ daemon sends only one type of authentication packet (a REPLY packet) to the client. The REPLY packet body looks as follows:
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+----------------+----------------+----------------+----------------+
| status | flags | server_msg len |
+----------------+----------------+----------------+----------------+
| data len | server_msg ...
+----------------+----------------+----------------+----------------+
| data ...
+----------------+----------------+
status
The current status of the authentication. Legal values are:
TAC_PLUS_AUTHEN_STATUS_PASS := 0x01
TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02
TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03
TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04
TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05
TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06
TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07
TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21
flags
Bitmapped flags that modify the action to be taken. The following values are defined:
TAC_PLUS_REPLY_FLAG_NOECHO := 0x01
server_msg
A message to be displayed to the user. This field is optional. If it exists, it is intended to be presented to the user.
data
This field holds data that is a part of the authentication exchange and is intended for the NAS, not the user. Valid uses of this field are described below.
8. The authentication CONTINUE packet body
This packet is sent from the NAS to the daemon following the receipt of a REPLY packet.
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+----------------+----------------+----------------+----------------+
| user_msg len | data len |
+----------------+----------------+----------------+----------------+
| flags | user_msg ...
+----------------+----------------+----------------+----------------+
| data ...
+----------------+
user_msg
This field is the string that the user entered, or the NAS provided on behalf of the user, in response to the server_msg from a REPLY packet.
data
This field carries information that is specific to the action and the authen_type for this session. Valid uses of this field are described below.
flags
This holds the bitmapped flags that modify the action to be taken. The following values are defined:
TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01
9. The authentication process
The flavor of the authentication is determined by the action and the authen_type fields in the START packet. First we should discuss some general fields that apply to all flavors of authentication exchanges. The user and data fields in the START packet are defined below for each flavor.
The priv_lvl, service, port and rem_addr in the START packet are all provided to help identify the conditions on the NAS. In the CONTINUE packet, the user_msg and data fields are defined below for each fla- vor. For all REPLY packets, the server_msg may contain a message to be displayed to the user, but the data field usage varies and is described below.
The descriptions below first describe "normal" authentication where, in response to a START packet, the daemon either sends a request for more information (GETDATA, GETUSER or GETPASS) or a termination (PASS or FAIL). The actions and meanings when the daemon sends a RESTART, ERROR or FOLLOW are common and are described further below.
When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, then authentication continues and the server_msg may be used by the client to prompt the user for more information. The client MUST then return a CONTINUE packet containing the requested information in the user_msg field.
TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic request for more infor- mation. All three cause the same action to be performed, but in the case of TAC_PLUS_AUTHEN_STATUS_GETUSER, the client can know that the information that the user responds with is a username, and for TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a password.
If the TAC_PLUS_REPLY_FLAG_NOECHO flag is set in the REPLY, then the user response should not be echoed as it is entered. The data field is only used in the REPLY where explicitly defined below.
9.0.1. Enable Requests
action = TAC_PLUS_AUTHEN_LOGIN
priv_lvl = implementation dependent
authen_type = not used
service = TAC_PLUS_AUTHEN_SVC_ENABLE
This is an ENABLE request, used to change the current running privilege level of a principal. The exchange MAY consist of multiple messages while the daemon collects the information it requires in order to allow changing the principal's privilege level. This exchange is very similar to an Inbound ASCII login (which see).
In order to readily distinguish enable requests from other types of request, the value of the service field MUST be set to TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be set to this value when requesting any other operation.
9.0.2. Inbound ASCII Login
action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
This is a standard ASCII authentication. The START packet may contain the username, but need not do so. The data fields in both the START and CONTINUE packets are not used for ASCII logins. There is a single START followed by zero or more pairs of REPLYs and CONTINUEs, fol- lowed by a terminating REPLY (PASS or FAIL).
9.0.3. Inbound PAP Login
action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
minor_version = 0x1
The entire exchange MUST consist of a single START packet and a sin- gle REPLY. The START packet MUST contain a username and the data field MUST contain the PAP ASCII password. A PAP authentication only consists of a username and password ["PPP Authentication Protocols" 4]. The REPLY from the daemon MUST be either a PASS or FAIL.
9.0.4. Inbound CHAP login
action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP
minor_version = 0x1
The entire exchange MUST consist of a single START packet and a sin- gle REPLY. The START packet MUST contain the username in the user field and the data field will be a concatenation of the PPP id, the challenge and the response.
The length of the challenge value can be determined from the length of the data field minus the length of the id (always 1 octet) and the length of the response field (always 16 octets).
To perform the authentication, the daemon will run MD5 over the id, the user's secret and the challenge, as defined in the PPP Authenti- cation RFC ["PPP Authentication Protocols" 4] and then compare that value with the response. The REPLY from the daemon MUST be a PASS or FAIL.
9.0.5. Inbound MS-CHAP login
action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP
minor_version = 0x1
The entire exchange MUST consist of a single START packet and a sin- gle REPLY. The START packet MUST contain the username in the user field and the data field will be a concatenation of the PPP id, the MS-CHAP challenge and the MS-CHAP response.
The length of the challenge value can be determined from the length of the data field minus the length of the id (always 1 octet) and the length of the response field (always 49 octets).
To perform the authentication, the daemon will use a combination of MD4 and DES on the user's secret and the challenge, as defined in [7] and then compare the resulting value with the response. The REPLY from the daemon MUST be a PASS or FAIL.
9.0.6. Outbound MS-CHAP request
action = TAC_PLUS_AUTHEN_SENDAUTH
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP
minor_version = 0x1
This is used when the NAS needs to provide MS-CHAP authentication credentials to the remote PPP peer. The entire exchange MUST consist of a single START packet and a single REPLY. The START packet MUST contain the username in the user field and the data field will be a concatenation of the PPP id and the challenge.
The length of the challenge value can be determined from the length of the data field minus the length of the id (always 1 octet). The daemon will use MD4 and DES to process the user's secret and the challenge, as defined in [7].
The REPLY from the daemon MUST be a PASS or FAIL. If the status is PASS, then the data field MUST contain the 49-octet output, in which 24 octets are MD4 output for the Microsoft LAN Manager compatible challenge response, 24 octets are MD4 output for the Microsoft Win- dows NT compatible challenge response and 1 octet is the flag to determine which part of the response packet should be utilized.
9.0.7. Inbound ARAP login
action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_ARAP
minor_version = 0x1
The entire exchange MUST consist of a single START packet and a sin- gle REPLY. The START packet MUST contain the username in the user field and the data field will be a concatenation of the NAS's chal- lenge to the remote peer (8 octets) the remote peer's challenge to the NAS (8 octets) and the remote peer's response to the NAS's chal- lenge (8 octets).
The daemon must run DES encryption over both the challenges using the user's secret as the DES key, as described in the ARAP specification [Randomness Recommendations for Securityo 5]. For a successful authentication, the encrypted NAS challenge MUST be identical to the peer's response. The REPLY from the daemon MUST be a PASS or FAIL. The encrypted peer challenge (8 octets) is returned in the data field of a REPLY packet if the status is set to PASS.
9.0.8. Outbound PAP request
action = TAC_PLUS_AUTHEN_SENDAUTH
authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
minor_version = 0x1
This is used when the NAS needs to provide PAP authentication creden- tials to the remote PPP peer. The entire exchange MUST consist of a single START packet and a single REPLY. The START packet contains a username in the user field. A REPLY with status set to PASS MUST con- tain a cleartext password in the data field. Caution is urged when using this. By sending a cleartext password to the NAS, that password will then be passed to the remote PPP peer. It should be ensured that the provided password can never be used to authenticate back to the NAS. Use of this is discouraged, but supported for complete intero- perability with the PPP protocol.
9.0.9. Outbound CHAP request
action = TAC_PLUS_AUTHEN_SENDAUTH
authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP
minor_version = 0x1
This is used when the NAS needs to provide CHAP authentication
credentials to the remote PPP peer. The entire exchange MUST consist of a single START packet and a single REPLY. The START packet MUST contain the username in the user field and the data field will be a concatenation of the PPP id and the challenge.
The length of the challenge value can be determined from the length of the data field minus the length of the id (always 1 octet). The daemon will run MD5 over the id, the user's secret and the challenge, as defined in the PPP Authentication RFC [4].
The REPLY from the daemon MUST be a PASS or FAIL. If the status is PASS, then the data field MUST contain the 16 octet MD5 output
9.0.10. Outbound ASCII and ARAP request
action = TAC_PLUS_AUTHEN_SENDAUTH
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
authen_type = TAC_PLUS_AUTHEN_TYPE_ARAP
This is an error. This action is not supported for ASCII logins and in not needed for ARAP since ARAP authentication is already a two way protocol.
9.0.11. ASCII change password request
action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
This exchange consists of multiple messages while the daemon collects the information it requires in order to change the user's password. It is very similar to an ASCII login. The status value TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the "new" password. It MAY be sent multiple times. When requesting the "old" password, the status value MUST be set to TAC_PLUS_AUTHEN_STATUS_GETDATA.
9.0.12. PPP change password request
action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP
This is never valid. The PPP protocol does not support password changing.
9.0.13. ARAP change password request
action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_ARAP
This exchange consists of a single START packet and a single REPLY. The START packet MUST contain the username and the data field con- tains both the old and the new passwords encrypted (**FORMAT NOT KNOWN AT THIS TIME **). The reply is a PASS or FAIL and the data field is unused.
10. Aborting a session
The client may prematurely terminate a session by setting the TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this flag is set, the data portion of the message may contain an ASCII message explaining the reason for the abort. The session is ter- minated and no REPLY message is sent.
There are three other possible return status values that can be used in a REPLY packet. These can be sent regardless of the action or authen_type. Each of these indicates that the TACACS+ authentication session should be terminated. In each case, the server_msg may con- tain a message to be displayed to the user.
When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet indi- cates that the TACACS+ daemon requests that authentication should be performed with an alternate daemon. The data field MUST contain ASCII text describing one or more daemons. A daemon description appears like this:
[@<protocol>@]<host>[@<key>]
The protocol and key are optional. The protocol can describe an
alternate way of performing the authentication, other than TACACS+. If the protocol is not present, then TACACS+ is assumed.
Protocols are ASCII numbers corresponding to the methods listed in the authen_method field of authorization packets (defined below). The host is specified as either a fully qualified domain name, or an ASCII numeric IP address specified as octets separated by dots (`.').
If a key is supplied, the client MAY use the key in order to authen- ticate to that host. If more than one host is specified, they MUST be separated by an ASCII <CR> (0x0D).
Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the discretion of the TACACS+ client. It may choose to use any one, all or none of these hosts. If it chooses to use none, then it MUST treat the authentication as if the return status was TAC_PLUS_AUTHEN_STATUS_FAIL.
While the order of hosts in this packet indicates a preference, but the client is not obliged to use that ordering.
If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is indicating that it is experiencing an unrecoverable error and the authentication should proceed as if that host could not be contacted. The data field may contain a message to be printed on an administra- tive console or log.
If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the authen- tication sequence should be restarted with a new START packet from the client. This REPLY packet indicates that the current authen_type value (as specified in the START packet) is not acceptable for this session, but that others may be.
The TAC_PLUS_AUTHEN_STATUS_RESTART REPLY packet may contain a list of valid authen_type values in the data portion of the packet. The authen_type values are a single byte in length so the data_len value indicates the number of authen_type values included. This packet is only currently intended for PPP authentication when multiple authen- tication mechanisms are available and can be negotiated between the client and the remote peer. This also requires future PPP authentica- tion extensions which have not yet been passed through the IETF. If a client chooses not to accept the TAC_PLUS_AUTHEN_STATUS_RESTART packet, then it should be TREATED as if the status was TAC_PLUS_AUTHEN_STATUS_FAIL.
