--- 1/draft-ietf-opsawg-tacacs-16.txt 2020-01-27 11:13:13.013178794 -0800 +++ 2/draft-ietf-opsawg-tacacs-17.txt 2020-01-27 11:13:13.097180924 -0800 @@ -1,52 +1,52 @@ Operations T. Dahm Internet-Draft A. Ota Intended status: Informational Google Inc -Expires: May 20, 2020 D. Medway Gash +Expires: July 30, 2020 D. Medway Gash Cisco Systems, Inc. D. Carrel vIPtela, Inc. L. Grant - November 17, 2019 + January 27, 2020 The TACACS+ Protocol - draft-ietf-opsawg-tacacs-16 + draft-ietf-opsawg-tacacs-17 Abstract - Terminal Access Controller Access-Control System Plus (TACACS+) - provides Device Administration for routers, network access servers - and other networked computing devices via one or more centralized - servers. This document describes the protocol that is used by - TACACS+. + This document describes the Terminal Access Controller Access-Control + System Plus (TACACS+) protocol which is widely deployed today to + provide Device Administration for routers, network access servers and + other networked computing devices via one or more centralized + servers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 20, 2020. + This Internet-Draft will expire on July 30, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -62,91 +62,98 @@ outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Packet . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6. Treatment of Enumerated Protocol Values . . . . . . . . . 5 - 3.7. Treatment of Text Strings . . . . . . . . . . . . . . . . 5 + 3.7. Treatment of Text Strings . . . . . . . . . . . . . . . . 6 4. TACACS+ Packets and Sessions . . . . . . . . . . . . . . . . 6 4.1. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 6 4.2. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 8 4.3. Single Connection Mode . . . . . . . . . . . . . . . . . 8 4.4. Session Completion . . . . . . . . . . . . . . . . . . . 9 - 4.5. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 10 + 4.5. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 11 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1. The Authentication START Packet Body . . . . . . . . . . 12 + 5.1. The Authentication START Packet Body . . . . . . . . . . 13 5.2. The Authentication REPLY Packet Body . . . . . . . . . . 15 - 5.3. The Authentication CONTINUE Packet Body . . . . . . . . . 16 + 5.3. The Authentication CONTINUE Packet Body . . . . . . . . . 17 5.4. Description of Authentication Process . . . . . . . . . . 17 - 5.4.1. Version Behavior . . . . . . . . . . . . . . . . . . 17 - 5.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 - 5.4.3. Aborting an Authentication Session . . . . . . . . . 21 - 6. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.4.1. Version Behavior . . . . . . . . . . . . . . . . . . 18 + 5.4.2. Common Authentication Flows . . . . . . . . . . . . . 19 + 5.4.3. Aborting an Authentication Session . . . . . . . . . 22 + 6. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23 - 6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 + 6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 27 7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 - 7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 + 7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 29 + 7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 30 8. Argument-Value Pairs . . . . . . . . . . . . . . . . . . . . 31 - 8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 - 8.2. Authorization Arguments . . . . . . . . . . . . . . . . . 32 - 8.3. Accounting Arguments . . . . . . . . . . . . . . . . . . 34 - 9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 32 + 8.2. Authorization Arguments . . . . . . . . . . . . . . . . . 33 + 8.3. Accounting Arguments . . . . . . . . . . . . . . . . . . 35 + 9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 36 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 10.1. General Security of the Protocol . . . . . . . . . . . . 37 10.2. Security of Authentication Sessions . . . . . . . . . . 38 - 10.3. Security of Authorization Sessions . . . . . . . . . . . 38 + 10.3. Security of Authorization Sessions . . . . . . . . . . . 39 10.4. Security of Accounting Sessions . . . . . . . . . . . . 39 - 10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39 - 10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39 - 10.5.2. Connections and Obfuscation . . . . . . . . . . . . 40 - 10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41 + 10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 40 + 10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 40 + 10.5.2. Connections and Obfuscation . . . . . . . . . . . . 41 + 10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 42 10.5.4. Authorization . . . . . . . . . . . . . . . . . . . 42 - 10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 42 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 + 10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 43 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . 44 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction - Terminal Access Controller Access-Control System Plus (TACACS+) was - conceived initially as a general Authentication, Authorization and - Accounting protocol. It's use today is mainly confined to Device - Administration: authenticating access to network devices, providing - central authorization of operations, and audit of those operations. + This document describes the Terminal Access Controller Access-Control + System Plus (TACACS+) protocol. It was conceived initially as a + general Authentication, Authorization and Accounting (AAA) protocol. + It is widely deployed today but is mainly confined for a specific + subset of AAA: Device Administration, that is: authenticating access + to network devices, providing central authorization of operations, + and audit of those operations. A wide range of TACACS+ clients and servers are already deployed in the field. The TACACS+ protocol they are based on is defined in a - draft document that was originally intended for IETF publication, and - is known as `The Draft' [TheDraft]. This did not address all of the + draft document that was originally intended for IETF publication, but + was never standardized. The draft document is known as `The Draft' + [TheDraft]. + + This Draft was a product of its time, and did not address all of the key security concerns which are considered when designing modern standards. Deployment must therefore be executed with care. These concerns are addressed in the security section (Section 10). - This is intended to document the TACACS+ protocol as it is currently - deployed. It is intended that all implementations which conform to - this document will conform to `The Draft'. However, attention is - drawn to the following specific adjustments of the protocol - specification from 'The Draft': + The primary intent of this informational document is to clarify the + subset of `The Draft' which is common to implementations supporting + Device Administration. It is intended that all implementations which + conform to this document will conform to `The Draft'. However, it is + not intended that all implementations which conform to 'The Draft' + will conform to this document. The following features from `The + Draft' have been removed: This document officially removes SENDPASS for security reasons. The normative description of Legacy features such as ARAP and outbound authentication has been removed. The Support for forwarding to an alternative daemon (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated. The TACACS+ protocol allows for arbitrary length and content @@ -269,31 +276,32 @@ +----------------+----------------+----------------+----------------+ | | | session_id | +----------------+----------------+----------------+----------------+ | | | length | +----------------+----------------+----------------+----------------+ The following general rules apply to all TACACS+ packet types: - - To signal that any variable length data fields are unused, their - length value is set to zero. Such fields MUST be ignored, and - treated as if not present. + - To signal that any variable length data fields are unused, the + corresponding length values are set to zero. Such fields MUST be + ignored, and treated as if not present. - the lengths of data and message fields in a packet are specified by their corresponding length fields, (and are not null terminated.) - All length values are unsigned and in network byte order. major_version + This is the major TACACS+ version number. TAC_PLUS_MAJOR_VER := 0xc minor_version The minor TACACS+ version number. TAC_PLUS_MINOR_VER_DEFAULT := 0x0 @@ -315,30 +323,29 @@ in a session MUST have the sequence number 1 and each subsequent packet will increment the sequence number by one. TACACS+ Clients only send packets containing odd sequence numbers, and TACACS+ servers only send packets containing even sequence numbers. The sequence number must never wrap i.e. if the sequence number 2^8-1 is ever reached, that session must terminate and be restarted with a sequence number of 1. flags - This field contains various bitmapped flags. The flag bit: TAC_PLUS_UNENCRYPTED_FLAG := 0x01 This flag indicates that the sender did not obfuscate the body of the - packet. The application of this flag will be covered in the security - section (Section 10). + packet. This option MUST NOT be used in production. The application + of this flag will be covered in the security section (Section 10). This flag SHOULD be clear in all deployments. Modern network traffic tools support encrypted traffic when configured with the shared secret (see section below), so obfuscated mode can and SHOULD be used even during test. The single-connection flag: TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 @@ -361,22 +368,23 @@ The total length of the packet body (not including the header). 4.2. The TACACS+ Packet Body The TACACS+ body types are defined in the packet header. The next sections of this document will address the contents of the different TACACS+ bodies. 4.3. Single Connection Mode - Single Connection Mode is intended to improve performance by allowing - a client to multiplex multiple session on a single TCP connection. + Single Connection Mode is intended to improve performance where there + is a lot of traffic between a client and a server by allowing the + client to multiplex multiple session on a single TCP connection. The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by the client and server to negotiate the use of Single Connect Mode. The client sets this flag, to indicate that it supports multiplexing TACACS+ sessions over a single TCP connection. The client MUST NOT send a second packet on a connection until single-connect status has been established. To indicate it will support Single Connection Mode, the server sets @@ -394,67 +402,75 @@ If single Connection Mode has not been established in the first two packets of a TCP connection, then both the client and the server close the connection at the end of the first session. The client negotiates Single Connection Mode to improve efficiency. The server may refuse to allow Single Connection Mode for the client. For example, it may not be appropriate to allocate a long-lasting TCP connection to a specific client in some deployments. Even if the server is configured to permit single Connection Mode for a specific client, the server may close the connection. For example: a server - may be configured to time out a Single Connection Mode TCP Connection - after a specific period of inactivity to preserve its resources. The - client MUST accommodate such closures on a TCP session even after - Single Connection Mode has been established. + MUST be configured to time out a Single Connection Mode TCP + Connection after a specific period of inactivity to preserve its + resources. The client MUST accommodate such closures on a TCP + session even after Single Connection Mode has been established. + + The TCP connection underlying the Single Connection Mode will close + eventually, either because of the timeout from the server or from an + intermediate link. If a session is in progress when the client + detects disconnect then the client should handle it as described in + Section 4.4. If a session is not in progress, then the client will + need to detect this, and restart the single connection mode when the + it initiates the next session. 4.4. Session Completion The REPLY packets defined for the packets types in the sections below (Authentication, Authorization and Accounting) contain a status field. The complete set of options for this field depend upon the packet type, but all three REPLY packet types define values representing PASS, ERROR and FAIL, which indicate the last packet of a regular session (one which is not aborted). The server responds with a PASS or a FAIL to indicate that the processing of the request completed and the client can apply the result (PASS or FAIL) to control the execution of the action which prompted the request to be sent to the server. The server responds with an ERROR to indicate that the processing of - the request did not complete. The client can not apply the result - and it MUST behave as if the server could not be connected to. For + the request did not complete. The client cannot apply the result and + it MUST behave as if the server could not be connected to. For example, the client tries alternative methods, if they are available, such as sending the request to a backup server, or using local configuration to determine whether the action which prompted the request should be executed. - Refer to the section (Section 5.4.3) on Aborting Authentication - Sessions for details on handling additional status options. + Refer to Section 5.4.3 on Aborting Authentication Sessions for + details on handling additional status options. When the session is complete, then the TCP connection should be handled as follows, according to whether Single Connection Mode was negotiated: If Single Connection Mode was not negotiated, then the connection should be closed If Single Connection Mode was enabled, then the connection SHOULD be - left open (see section (Section 4.3)), but may still be closed after - a timeout period to preserve deployment resources. + left open (see Section 4.3), but may still be closed after a timeout + period to preserve deployment resources. If Single Connection Mode was enabled, but an ERROR occurred due to - connection issues (such as an incorrect secret, see section - (Section 4.5)), then any further new sessions MUST NOT be accepted on - the connection. If there are any sessions that have already been - established then they MAY be completed. Once all active sessions are - completed then the connection MUST be closed. + connection issues (such as an incorrect secret, see Section 4.5), + then any further new sessions MUST NOT be accepted on the connection. + If there are any sessions that have already been established then + they MAY be completed. Once all active sessions are completed then + the connection MUST be closed. It is recommended that client implementations provide robust schemes for dealing with servers which cannot be connected to. Options include providing a list of servers for redundancy, and an option for a local fallback configuration if no servers can be reached. Details will be implementation specific. The client should manage connections and handle the case of a server which establishes a connection, but does not respond. The exact behavior is implementation specific. It is recommended that the @@ -469,25 +485,26 @@ termed as encryption in this document. The obfuscation mechanism relies on a secret key, a shared secret value that is known to both the client and the server. The secret keys MUST remain secret. Server implementations MUST allow a unique secret key to be associated with each client. It is a site-dependent decision as to whether the use of separate keys is appropriate. - The flag field may be set as follows: + The flag field MUST be configured with the following bit as follows: TAC_PLUS_UNENCRYPTED_FLAG = 0x0 - In this case, the packet body is obfuscated by XOR-ing it byte-wise - with a pseudo-random pad. + + So that the packet body is obfuscated by XOR-ing it byte-wise with a + pseudo-random pad. ENCRYPTED {data} = data ^ pseudo_pad The packet body can then be de-obfuscated by XOR-ing it byte-wise with a pseudo random pad. data = ENCRYPTED {data} ^ pseudo_pad The pad is generated by concatenating a series of MD5 hashes (each 16 bytes long) and truncating it to the length of the input data. @@ -498,47 +515,42 @@ pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) The first MD5 hash is generated by concatenating the session_id, the secret key, the version number and the sequence number and then running MD5 over that stream. All of those input values are available in the packet header, except for the secret key which is a shared secret between the TACACS+ client and server. The version number and session_id are extracted from the header - Subsequent hashes are generated by using the same input stream, but concatenating the previous hash value at the end of the input stream. MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, version, seq_no, MD5_n-1} When a server detects that the secret(s) it has configured for the device mismatch, it MUST return ERROR. For details of TCP connection - handling on ERROR, refer to section (Section 4.4). + handling on ERROR, refer to Section 4.4. TAC_PLUS_UNENCRYPTED_FLAG == 0x1 - In this case, the entire packet body is in cleartext. Obfuscation - and de-obfuscation are null operations. This method should be - avoided unless absolutely required for debug purposes, when tooling - does not permit de-obfuscation. - - If deployment is configured for obfuscating a connection then the - request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. + This option is deprecated and MUST NOT be used in production. In + this case, the entire packet body is in cleartext. A request MUST be + dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. After a packet body is de-obfuscated, the lengths of the component values in the packet are summed. If the sum is not identical to the cleartext datalength value from the header, the packet MUST be discarded, and an ERROR signaled. For details of TCP connection - handling on ERROR, refer to section (Section 4.4). + handling on ERROR, refer to Section 4.4. Commonly such failures are seen when the keys are mismatched between the client and the TACACS+ server. 5. Authentication Authentication is the action of determining who a user (or entity) is. Authentication can take many forms. Traditional authentication employs a name and a fixed password. However, fixed passwords are vulnerable security, so many modern authentication mechanisms utilize @@ -985,21 +1000,21 @@ 5.4.3. Aborting an Authentication 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 a message explaining the reason for the abort. For details of text encoding, see (Section 3.7). This information will be handled by the server according to the requirements of the deployment. The session is terminated, for more details about session termination, refer to - section (Section 4.4). + Section 4.4. In cases of PASS, FAIL or ERROR, the server can insert a message into server_msg to be displayed to the user. The Draft `The Draft' [TheDraft] defined a mechanism to direct authentication requests to an alternative server. This mechanism is regarded as insecure, is deprecated, and not covered here. The client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL @@ -1083,42 +1097,43 @@ subject to verification, it is recommended that this field is ignored. TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 TAC_PLUS_AUTHEN_METH_NONE := 0x01 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 TAC_PLUS_AUTHEN_METH_LINE := 0x03 + TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 - TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 - KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed - password associated with the terminal line used to gain access. - LOCAL is a client local user database. ENABLE is a command that - authenticates in order to grant new privileges. TACACSPLUS is, of - course, TACACS+. GUEST is an unqualified guest authentication. - RADIUS is the Radius authentication protocol. RCMD refers to - authentication provided via the R-command protocols from Berkeley - Unix. + KRB5 and KRB4 are Kerberos version 5 and 4. This document does not + cover how the client performed the authentication, so normative + references will not be given . LINE refers to a fixed password + associated with the terminal line used to gain access. LOCAL is a + client local user database. ENABLE is a command that authenticates + in order to grant new privileges. TACACSPLUS is, of course, TACACS+. + GUEST is an unqualified guest authentication. RADIUS is the Radius + authentication protocol. RCMD refers to authentication provided via + the R-command protocols from Berkeley Unix. priv_lvl This field is used in the same way as the priv_lvl field in authentication request and is described in the Privilege Level section (Section 9) below. It indicates the users current privilege level. authen_type @@ -1263,22 +1277,22 @@ If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client MUST use the authorization argument-value pairs (if any) in the response, instead of the authorization argument-value pairs from the request. To approve the authorization with no modifications, the server sets the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred on the server. For the differences between ERROR and FAIL, refer to - section Session Completion (Section 4.4). None of the arg values - have any relevance if an ERROR is set, and must be ignored. + Session Completion (Section 4.4). None of the arg values have any + relevance if an ERROR is set, and must be ignored. When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the arg_cnt MUST be 0. In that case, the actions to be taken and the contents of the data field are identical to the TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 7. Accounting Accounting is typically the third action after authentication and authorization. But again, neither authentication nor authorization @@ -1461,22 +1476,23 @@ separated by dots ('.'), IPv6 address text representation defined in RFC 5952 [RFC5952]. Date Time Absolute date/times are specified in seconds since the epoch, 12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone argument is specified. String - Many values have no specific type representation and so are - interpreted as plain strings. + + Many values have no specific type representation and are interpreted + as plain strings. Empty Values Arguments may be submitted with no value, in which case they consist of the name and the mandatory or optional separator. For example, the argument "cmd" which has no value is transmitted as a string of four characters "cmd=" 8.2. Authorization Arguments @@ -1678,23 +1693,23 @@ and "cmd" is empty). When a user required to perform actions that are mapped to a higher privilege level, then an ENABLE type reauthentication can be initiated by the client. The client will insert the required privilege level into the authentication header for enable authentication request. The use of Privilege levels to determine session-based access to commands and resources is not mandatory for clients. Although the privilege level scheme is widely supported, its lack of flexibility in requiring a single monotonic hierarchy of permissions means that - other session-based command authorization schemes have evolved, and - so it is no longer mandatory for clients to use it. However, it is - still common enough that it SHOULD be supported by servers. + other session-based command authorization schemes have evolved. + However, it is still common enough that it SHOULD be supported by + servers. 10. Security Considerations The original TACACS+ Draft `The Draft' [TheDraft] from 1998 did not address all of the key security concerns which are considered when designing modern standards. This section addresses known limitations and concerns which will impact overall security of the protocol and systems where this protocol is deployed to manage central authentication, authorization or accounting for network device administration. @@ -1877,33 +1892,33 @@ TACACS+ server administrators SHOULD configure secret keys of minimum 16 characters length. 10.5.2. Connections and Obfuscation TACACS+ servers MUST allow the definition of individual clients. The servers MUST only accept network connection attempts from these defined, known clients. TACACS+ servers MUST reject connections with - TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on - the server for the client requesting the connection. + TAC_PLUS_UNENCRYPTED_FLAG set. There MUST always be a shared secret + set on the server for the client requesting the connection. If an invalid shared secret is detected when processing packets for a client, TACACS+ servers MUST NOT accept any new sessions on that connection. TACACS+ servers MUST terminate the connection on completion of any sessions that were previously established with a valid shared secret on that connection. - TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG when a secret - is defined. Clients MUST be implemented in a way that requires - explicit configuration to enable the use of - TAC_PLUS_UNENCRYPTED_FLAG. + TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG. Clients MUST + be implemented in a way that requires explicit configuration to + enable the use of TAC_PLUS_UNENCRYPTED_FLAG, this option MUST NOT be + used when the client is in production When a TACACS+ client receives responses from servers where: the response packet was received from the server configured with shared key, but the packet has TAC_PLUS_UNENCRYPTED_FLAG set. the response packet was received from the server configured not to use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not set. @@ -1939,21 +1954,21 @@ If they must be implemented, the servers MUST default to the options being disabled and MUST warn the administrator that these options are not secure. 10.5.4. Authorization The authorization and accounting features are intended to provide extensibility and flexibility. There is a base dictionary defined in this document, but it may be extended in deployments by using new argument names. The cost of the flexibility is that administrators - and implementors MUST ensure that the argument and value pairs shared + and implementers MUST ensure that the argument and value pairs shared between the clients and servers have consistent interpretation. TACACS+ clients that receive an unrecognized mandatory argument MUST evaluate server response as if they received TAC_PLUS_AUTHOR_STATUS_FAIL. 10.5.5. Redirection Mechanism The original draft described a redirection mechanism (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to