idnits 2.17.1 draft-ietf-opsawg-tacacs-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Start and stop records for the same event MUST have matching task_id attribute values. The client MUST ensure that active task_ids are not duplicated: a client MUST NOT reuse a task_id a start record until it has sent a stop record for that task_id. Servers MUST not make assumptions about the format of a task_id. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: TACACS+ servers and clients MUST treat shared secrets as sensitive data to be managed securely, as would be expected for other sensitive data such as identity credential information. TACACS+ servers MUST not leak sensitive data. For example, TACACS+ servers should not expose shared secrets in logs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft SHOULD not be used, due to their security implications. TACACS+ servers SHOULD NOT implement them. 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. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2, 2018) is 1971 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations T. Dahm 3 Internet-Draft A. Ota 4 Intended status: Informational Google Inc 5 Expires: June 5, 2019 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 December 2, 2018 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-12 15 Abstract 17 TACACS+ provides Device Administration for routers, network access 18 servers and other networked computing devices via one or more 19 centralized servers. This document describes the protocol that is 20 used by TACACS+. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 5, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 71 4. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 5 72 4.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.3. Single Connection Mode . . . . . . . . . . . . . . . . . 5 75 4.4. Session Completion . . . . . . . . . . . . . . . . . . . 6 76 4.5. Treatment of Enumerated Protocol Values . . . . . . . . . 7 77 4.6. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 7 78 4.7. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 8 79 4.8. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 9 80 4.9. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 11 81 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 12 82 5.1. The Authentication START Packet Body . . . . . . . . . . 12 83 5.2. The Authentication REPLY Packet Body . . . . . . . . . . 15 84 5.3. The Authentication CONTINUE Packet Body . . . . . . . . . 16 85 5.4. Description of Authentication Process . . . . . . . . . . 17 86 5.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 87 5.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 88 5.4.3. Aborting an Authentication Session . . . . . . . . . 21 89 6. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 90 6.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23 91 6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 92 7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 94 7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 95 8. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 96 8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 97 8.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 98 8.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 99 9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 100 10. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 101 10.1. General Security of the Protocol . . . . . . . . . . . . 37 102 10.2. Security of Authentication Sessions . . . . . . . . . . 38 103 10.3. Security of Authorization Sessions . . . . . . . . . . . 38 104 10.4. Security of Accounting Sessions . . . . . . . . . . . . 39 105 10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39 106 10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39 107 10.5.2. Connections and Obfuscation . . . . . . . . . . . . 40 108 10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41 109 10.5.4. Authorization . . . . . . . . . . . . . . . . . . . 41 110 10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 42 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 115 1. Introduction 117 Terminal Access Controller Access-Control System Plus (TACACS+) was 118 conceived initially as a general Authentication, Authorization and 119 Accounting protocol. It is primarily used today for Device 120 Administration: authenticating access to network devices, providing 121 central authorization of operations, and audit of those operations. 123 A wide range of TACACS+ clients and servers are already deployed in 124 the field. The TACACS+ protocol they are based on is defined in a 125 draft document that was originally intended for IETF publication. 126 This document is known as `The Draft' [TheDraft] . 128 It is intended that all implementations which conform to this 129 document will conform to `The Draft'. However, attention is drawn to 130 the following specific adjustments of the protocol specification from 131 'The Draft': 133 This document officially removes SENDPASS for security reasons. 135 The normative description of Legacy features such as ARAP and 136 outbound authentication has been removed, however, the required 137 enumerations are kept. 139 The Support for forwarding to an alternative daemon 140 (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated. 142 The TACACS+ protocol separates the functions of Authentication, 143 Authorization and Accounting. It allows for arbitrary length and 144 content authentication exchanges, to support future authentication 145 mechanisms. It is extensible to provide for site customization and 146 future development features, and it uses TCP to ensure reliable 147 delivery. The protocol allows the TACACS+ client to request very 148 fine-grained access control and allows the server to respond to each 149 component of that request. 151 The separation of authentication, authorization and accounting was a 152 key element of the design of TACACS+ protocol. Essentially it makes 153 TACACS+ a suite of three protocols. This document will address each 154 one in separate sections. Although TACACS+ defines all three, an 155 implementation or configuration is not required to employ all three. 156 Separating the elements is useful for Device Administration use case, 157 specifically, for authorization of individual commands in a session. 158 Note that there is no provision made at the protocol level for 159 association of an authentication to each authorization request. 161 2. Conventions 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC2119 [RFC2119] 167 3. Technical Definitions 169 This section provides a few basic definitions that are applicable to 170 this document 172 Client 174 The client is any device, (often a Network Access Server) that 175 provides access services. The clients usually provide a character 176 mode front end and then allow the user to telnet or rlogin to another 177 host. 179 Server 181 The server receives TACACS+ protocol requests, and replies according 182 to its business model, in accordance with the flows defined in this 183 document. 185 Packet 187 All uses of the word packet in this document refer to TACACS+ 188 protocol packets unless explicitly noted otherwise. 190 4. TACACS+ Connections and Sessions 192 4.1. Connection 194 TACACS+ uses TCP for its transport. Server port 49 is allocated for 195 TACACS+ traffic. 197 4.2. Session 199 The concept of a session is used throughout this document. A TACACS+ 200 session is a single authentication sequence, a single authorization 201 exchange, or a single accounting exchange. 203 An accounting and authorization session will consist of a single pair 204 of packets (the request and its reply). An authentication session 205 may involve an arbitrary number of packets being exchanged. The 206 session is an operational concept that is maintained between the 207 TACACS+ client and server. It does not necessarily correspond to a 208 given user or user action. 210 4.3. Single Connection Mode 212 Single Connection Mode is intended to improve performance by allowing 213 a client to multiplex multiple session on a single TCP connection. 215 The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by 216 the client and server to negotiate the use of Single Connect Mode. 218 The client sets this flag, to indicate that it supports multiplexing 219 TACACS+ sessions over a single TCP connection. The client MUST NOT 220 send a second packet on a connection until single-connect status has 221 been established. 223 To indicate it will support Single Connection Mode, the server sets 224 this flag in the first reply packet in response to the first request 225 from a client. The server may set this flag even if the client does 226 not set it, but the client may ignore the flag and close the 227 connection after the session completes. 229 The flag is only relevant for the first two packets on a connection, 230 to allow the client and server to establish Single Connection Mode. 231 No provision is made for changing Single Connection Mode after the 232 first two packets: the client and server MUST ignore the flag after 233 the second packet on a connection. 235 If single Connection Mode has not been established in the first two 236 packets of a TCP connection, then both the client and the server 237 close the connection at the end of the first session. 239 The client negotiates Single Connection Mode to improve efficiency. 240 The server may refuse to allow Single Connection Mode for the client. 241 For example, it may not be appropriate to allocate a long-lasting TCP 242 connection to a specific client in some deployments. Even if the 243 server is configured to permit single Connection Mode for a specific 244 client, the server may close the connection. For example: a server 245 may be configured to time out a Single Connection Mode TCP Connection 246 after a specific period of inactivity to preserve its resources. The 247 client MUST accommodate such closures on a TCP session even after 248 Single Connection Mode has been established. 250 4.4. Session Completion 252 The REPLY packets defined for the packets types in the sections below 253 (Authentication, Authorization and Accounting) contain a status 254 field. The complete set of options for this field depend upon the 255 packet type, but all three REPLY packet types define values 256 representing PASS, ERROR and FAIL, which indicate the last packet of 257 a regular session (one which is not aborted). 259 The server responds with a PASS or a FAIL to indicate that the 260 processing of the request completed and the client can apply the 261 result (PASS or FAIL) to control the execution of the action which 262 prompted the request to be sent to the server. 264 The server responds with an ERROR to indicate that the processing of 265 the request did not complete. The client can not apply the result 266 and it MUST behave as if the server could not be connected to. For 267 example, the client tries alternative methods, if they are available, 268 such as sending the request to a backup server, or using local 269 configuration to determine whether the action which prompted the 270 request should be executed. 272 Refer to the section (Section 5.4.3) on Aborting Authentication 273 Sessions for details on handling additional status options. 275 When the session is complete, then the TCP connection should be 276 handled as follows, according to whether Single Connection Mode was 277 negotiated: 279 If Single Connection Mode was not negotiated, then the connection 280 should be closed 282 If Single Connection Mode was enabled, then the connection SHOULD be 283 left open (see section (Section 4.3) ), but may still be closed after 284 a timeout period to preserve deployment resources 285 If Single Connection Mode was enabled, but an ERROR occurred due to 286 connection issues (such as an incorrect secret, see section 287 (Section 4.7) ), then any further new sessions MUST NOT be accepted 288 on the connection. If there are any sessions that have already been 289 established then they MAY be completed. Once all active sessions are 290 completed then the connection MUST be closed. 292 It is recommended that client implementations provide robust schemes 293 for dealing with servers which cannot be connected to. Options 294 include providing a list of servers for redundancy, and an option for 295 a local fallback configuration if no servers can be reached. Details 296 will be implementation specific. 298 The client should manage connections and handle the case of a server 299 which establishes a connection, but does not respond. The exact 300 behavior is implementation specific. It is recommended that the 301 client should close the connection after a configurable timeout. 303 4.5. Treatment of Enumerated Protocol Values 305 This document describes various enumerated values in the packet 306 header and the headers for specific packet types. For example in the 307 Authentication start packet type, this document defines the action 308 field with three values TAC_PLUS_AUTHEN_LOGIN, TAC_PLUS_AUTHEN_CHPASS 309 and TAC_PLUS_AUTHEN_SENDAUTH. 311 If the server does not implement one of the defined options in a 312 packet that it receives, or it encounters an option that is not 313 listed in this document for a header field, then it should respond 314 with a ERROR and terminate the session. This will allow the client 315 to try a different option. 317 If an error occurs but the type of the incoming packet cannot be 318 determined, a packet with the identical cleartext header but with a 319 sequence number incremented by one and the length set to zero MUST be 320 returned to indicate an error. 322 4.6. Text Encoding 324 All text fields in TACACS+ MUST be printable US-ASCII, excepting 325 special consideration given to user field and data fields used for 326 passwords. 328 To ensure interoperability of current deployments, the TACACS+ client 329 and server MUST handle user fields and those data fields used for 330 passwords as 8-bit octet strings. The deployment operator MUST 331 ensure that consistent character encoding is applied from the end 332 client to the server. The encoding SHOULD be UTF-8, and other 333 encodings outside printable US-ASCII SHOULD be deprecated. 335 4.7. Data Obfuscation 337 The body of packets may be obfuscated. The following sections 338 describe the obfuscation method that is supported in the protocol. 339 In 'The Draft' this process was actually referred to as Encryption, 340 but the algorithm would not meet modern standards, and so will not be 341 termed as encryption in this document. 343 The obfuscation mechanism relies on a secret key, a shared secret 344 value that is known to both the client and the server. The secret 345 keys MUST remain secret. 347 Server implementations MUST allow a unique secret key to be 348 associated with every client. It is a site-dependent decision as to 349 whether the use of separate keys is appropriate. 351 The flag field may be set as follows: 353 TAC_PLUS_UNENCRYPTED_FLAG = 0x0 355 In this case, the packet body is obfuscated by XOR-ing it byte-wise 356 with a pseudo-random pad. 358 ENCRYPTED {data} = data ^ pseudo_pad 360 The packet body can then be de-obfuscated by XOR-ing it byte-wise 361 with a pseudo random pad. 363 data = ENCRYPTED {data} ^ pseudo_pad 365 The pad is generated by concatenating a series of MD5 hashes (each 16 366 bytes long) and truncating it to the length of the input data. 368 Whenever used in this document, MD5 refers to the "RSA Data Security, 369 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 370 . 372 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 374 The first MD5 hash is generated by concatenating the session_id, the 375 secret key, the version number and the sequence number and then 376 running MD5 over that stream. All of those input values are 377 available in the packet header, except for the secret key which is a 378 shared secret between the TACACS+ client and server. 380 The version number and session_id are used as extracted from the 381 header 383 Subsequent hashes are generated by using the same input stream, but 384 concatenating the previous hash value at the end of the input stream. 386 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 387 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 388 version, seq_no, MD5_n-1} 390 When a server detects that the secret(s) it has configured for the 391 device mismatch, it MUST return ERROR. For details of TCP connection 392 handling on ERROR, refer to section (Section 4.4) 394 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 396 In this case, the entire packet body is in cleartext. Obfuscation 397 and de-obfuscation are null operations. This method should be 398 avoided unless absolutely required for debug purposes, when tooling 399 does not permit de-obfuscation. 401 If deployment is configured for obfuscating a connection then the 402 request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. 404 After a packet body is de-obfuscated, the lengths of the component 405 values in the packet are summed. If the sum is not identical to the 406 cleartext datalength value from the header, the packet MUST be 407 discarded, and an ERROR signaled. For details of TCP connection 408 handling on ERROR, refer to section (Section 4.4) 410 Commonly such failures are seen when the keys are mismatched between 411 the client and the TACACS+ server. 413 4.8. The TACACS+ Packet Header 415 All TACACS+ packets begin with the following 12-byte header. The 416 header describes the remainder of the packet: 418 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 419 +----------------+----------------+----------------+----------------+ 420 |major | minor | | | | 421 |version| version| type | seq_no | flags | 422 +----------------+----------------+----------------+----------------+ 423 | | 424 | session_id | 425 +----------------+----------------+----------------+----------------+ 426 | | 427 | length | 428 +----------------+----------------+----------------+----------------+ 430 major_version 432 This is the major TACACS+ version number. 434 TAC_PLUS_MAJOR_VER := 0xc 436 minor_version 438 The minor TACACS+ version number. 440 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 442 TAC_PLUS_MINOR_VER_ONE := 0x1 444 type 446 This is the packet type. Legal values are: 448 TAC_PLUS_AUTHEN := 0x01 (Authentication) 450 TAC_PLUS_AUTHOR := 0x02 (Authorization) 452 TAC_PLUS_ACCT := 0x03 (Accounting) 454 seq_no 456 This is the sequence number of the current packet. The first packet 457 in a session MUST have the sequence number 1 and each subsequent 458 packet will increment the sequence number by one. Thus clients only 459 send packets containing odd sequence numbers, and TACACS+ servers 460 only send packets containing even sequence numbers. 462 The sequence number must never wrap i.e. if the sequence number 2^8-1 463 is ever reached, that session must terminate and be restarted with a 464 sequence number of 1. 466 flags 468 This field contains various bitmapped flags. 470 The flag bit: 472 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 474 This flag indicates that the sender did not obfuscate the body of the 475 packet. The application of this flag will be covered in the security 476 section (Section 10) . 478 This flag SHOULD be clear in all deployments. Modern network traffic 479 tools support encrypted traffic when configured with the shared 480 secret (see section below), so obfuscated mode can and SHOULD be used 481 even during test. 483 The single-connection flag: 485 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 487 This flag is used to allow a client and server to negotiate Single 488 Connection Mode. 490 session_id 492 The Id for this TACACS+ session. This field does not change for the 493 duration of the TACACS+ session. This number MUST be generated by a 494 cryptographically strong random number generation method. Failure to 495 do so will compromise security of the session. For more details 496 refer to RFC 1750 [RFC1750] 498 length 500 The total length of the packet body (not including the header). 502 4.9. The TACACS+ Packet Body 504 The TACACS+ body types are defined in the packet header. The next 505 sections of this document will address the contents of the different 506 TACACS+ bodies. The following general rules apply to all TACACS+ 507 body types: 509 - To signal that any variable length data fields are unused, their 510 length value is set to zero. Such fields MUST be ignored, and 511 treated as if not present. 513 - the lengths of data and message fields in a packet are specified 514 by their corresponding length fields, (and are not null 515 terminated.) 517 - All length values are unsigned and in network byte order. 519 5. Authentication 521 Authentication is the action of determining who a user (or entity) 522 is. Authentication can take many forms. Traditional authentication 523 employs a name and a fixed password. However, fixed passwords are 524 vulnerable security, so many modern authentication mechanisms utilize 525 "one-time" passwords or a challenge-response query. TACACS+ is 526 designed to support all of these, and be flexible enough to handle 527 any future mechanisms. Authentication generally takes place when the 528 user first logs in to a machine or requests a service of it. 530 Authentication is not mandatory; it is a site-configured option. 531 Some sites do not require it. Others require it only for certain 532 services (see authorization below). Authentication may also take 533 place when a user attempts to gain extra privileges, and must 534 identify himself or herself as someone who possesses the required 535 information (passwords, etc.) for those privileges. 537 5.1. The Authentication START Packet Body 539 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 540 +----------------+----------------+----------------+----------------+ 541 | action | priv_lvl | authen_type | authen_service | 542 +----------------+----------------+----------------+----------------+ 543 | user_len | port_len | rem_addr_len | data_len | 544 +----------------+----------------+----------------+----------------+ 545 | user ... 546 +----------------+----------------+----------------+----------------+ 547 | port ... 548 +----------------+----------------+----------------+----------------+ 549 | rem_addr ... 550 +----------------+----------------+----------------+----------------+ 551 | data... 552 +----------------+----------------+----------------+----------------+ 554 Packet fields are as follows: 556 action 558 This indicates the authentication action. Legal values are listed 559 below. 561 TAC_PLUS_AUTHEN_LOGIN := 0x01 563 TAC_PLUS_AUTHEN_CHPASS := 0x02 565 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 567 priv_lvl 569 This indicates the privilege level that the user is authenticating 570 as. Please refer to the Privilege Level section (Section 9) below. 572 authen_type 574 The type of authentication. Legal values are: 576 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 578 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 580 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 582 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 584 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 586 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 588 authen_service 590 This is the service that is requesting the authentication. Legal 591 values are: 593 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 595 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 597 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 599 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 601 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 603 TAC_PLUS_AUTHEN_SVC_PT := 0x05 605 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 607 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 608 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 610 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 612 The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization 613 application of this field that indicates that no authentication was 614 performed by the device. 616 The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as 617 opposed to ENABLE) to a client device. 619 The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE 620 authen_service, which refers to a service requesting authentication 621 in order to grant the user different privileges. This is comparable 622 to the Unix "su(1)" command, which substitutes the current user's 623 identity with another. An authen_service value of NONE is only to be 624 used when none of the other authen_service values are appropriate. 625 ENABLE may be requested independently, no requirements for previous 626 authentications or authorizations are imposed by the protocol. 628 Other options are included for legacy/backwards compatibility. 630 user, user_len 632 The username is optional in this packet, depending upon the class of 633 authentication. If it is absent, the client MUST set user_len to 0. 634 If included, the user_len indicates the length of the user field, in 635 bytes. 637 port, port_len 639 The printable US-ASCII name of the client port on which the 640 authentication is taking place, and its length in bytes. The value 641 of this field is client specific. (For example, Cisco uses "tty10" 642 to denote the tenth tty line and "Async10" to denote the tenth async 643 interface). The port_len indicates the length of the port field, in 644 bytes. 646 rem_addr, rem_addr_len 648 A printable US-ASCII string indicating the remote location from which 649 the user has connected to the client. It is intended to hold a 650 network address if the user is connected via a network, a caller ID 651 is the user is connected via ISDN or a POTS, or any other remote 652 location information that is available. This field is optional 653 (since the information may not be available). The rem_addr_len 654 indicates the length of the user field, in bytes. 656 data, data_len 658 This field is used to send data appropriate for the action and 659 authen_type. It is described in more detail in the section Common 660 Authentication flows (Section 5.4.2) . The data_len indicates the 661 length of the data field, in bytes. 663 5.2. The Authentication REPLY Packet Body 665 The TACACS+ server sends only one type of authentication packet (a 666 REPLY packet) to the client. 668 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 669 +----------------+----------------+----------------+----------------+ 670 | status | flags | server_msg_len | 671 +----------------+----------------+----------------+----------------+ 672 | data_len | server_msg ... 673 +----------------+----------------+----------------+----------------+ 674 | data ... 675 +----------------+----------------+ 677 status 679 The current status of the authentication. Legal values are: 681 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 683 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 685 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 687 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 689 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 691 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 693 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 695 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 697 flags 699 Bitmapped flags that modify the action to be taken. The following 700 values are defined: 702 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 704 server_msg, server_msg_len 706 A message to be displayed to the user. This field is optional. The 707 printable US-ASCII charset MUST be used. The server_msg_len 708 indicates the length of the server_msg field, in bytes. 710 data, data_len 712 This field holds data that is a part of the authentication exchange 713 and is intended for the client, not the user. Examples of its use 714 are shown in the section Common Authentication flows (Section 5.4.2) 715 . The data_len indicates the length of the data field, in bytes. 717 5.3. The Authentication CONTINUE Packet Body 719 This packet is sent from the client to the server following the 720 receipt of a REPLY packet. 722 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 723 +----------------+----------------+----------------+----------------+ 724 | user_msg len | data_len | 725 +----------------+----------------+----------------+----------------+ 726 | flags | user_msg ... 727 +----------------+----------------+----------------+----------------+ 728 | data ... 729 +----------------+ 731 user_msg, user_msg_len 733 This field is the string that the user entered, or the client 734 provided on behalf of the user, in response to the server_msg from a 735 REPLY packet. The user_len indicates the length of the user field, 736 in bytes. 738 data, data_len 740 This field carries information that is specific to the action and the 741 authen_type for this session. Valid uses of this field are described 742 below. The data_len indicates the length of the data field, in 743 bytes. 745 flags 747 This holds the bitmapped flags that modify the action to be taken. 748 The following values are defined: 750 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 752 5.4. Description of Authentication Process 754 The action, authen_type and authen_service fields (described above) 755 combine to indicate what kind of authentication is to be performed. 756 Every authentication START, REPLY and CONTINUE packet includes a data 757 field. The use of this field is dependent upon the kind of the 758 Authentication. 760 This document defines a core set of authentication flows to be 761 supported by TACACS+. Each authentication flow consists of a START 762 packet. The server responds either with a request for more 763 information (GETDATA, GETUSER or GETPASS) or a termination PASS, 764 FAIL, ERROR or RESTART. The actions and meanings when the server 765 sends a RESTART or ERROR are common and are described further below. 767 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 768 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 769 then authentication continues and the server SHOULD provide 770 server_msg content for the client to prompt the user for more 771 information. The client MUST then return a CONTINUE packet 772 containing the requested information in the user_msg field. 774 The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a 775 request for username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request 776 for password. The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic 777 request for more information to flexibly support future requirements. 779 If the information being requested by the server form the client is 780 sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO 781 flag. When the client queries the user for the information, the 782 response MUST NOT be echoed as it is entered. 784 The data field is only used in the REPLY where explicitly defined 785 below. 787 5.4.1. Version Behaviour 789 The TACACS+ protocol is versioned to allow revisions while 790 maintaining backwards compatibility. The version number is in every 791 packet header. The changes between minor_version 0 and 1 apply only 792 to the authentication process, and all deal with the way that CHAP 793 and PAP authentications are handled. minor_version 1 may only be used 794 for authentication kinds that explicitly call for it in the table 795 below: 797 LOGIN CHPASS SENDAUTH 798 ASCII v0 v0 - 799 PAP v1 - v1 800 CHAP v1 - v1 801 MS-CHAPv1/2 v1 - v1 803 The '-' symbol represents that the option is not valid. 805 All authorisation and accounting and ASCII authentication use 806 minor_version number of 0. 808 PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange 809 is a single START packet from the client and a single REPLY from the 810 server. 812 The removal of SENDPASS was prompted by security concerns, and is no 813 longer considered part of the TACACS+ protocol. 815 5.4.2. Common Authentication Flows 817 This section describes common authentication flows. If the server 818 does not implement an option, it MUST respond with 819 TAC_PLUS_AUTHEN_STATUS_FAIL. 821 5.4.2.1. ASCII Login 823 action = TAC_PLUS_AUTHEN_LOGIN 824 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 825 minor_version = 0x0 827 This is a standard ASCII authentication. The START packet MAY 828 contain the username. If the user does not include the username then 829 the server MUST obtain it from the client with a CONTINUE 830 TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user does not provide a 831 username then the server can send another 832 TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server MUST limit the 833 number of retries that are permitted, recommended limit is three 834 attempts. When the server has the username, it will obtain the 835 password using a continue with TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII 836 login uses the user_msg field for both the username and password. 837 The data fields in both the START and CONTINUE packets are not used 838 for ASCII logins, any content MUST be ignored. The session is 839 composed of a single START followed by zero or more pairs of REPLYs 840 and CONTINUEs, followed by a final REPLY indicating PASS, FAIL or 841 ERROR. 843 5.4.2.2. PAP Login 845 action = TAC_PLUS_AUTHEN_LOGIN 846 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 847 minor_version = 0x1 849 The entire exchange MUST consist of a single START packet and a 850 single REPLY. The START packet MUST contain a username and the data 851 field MUST contain the PAP ASCII password. A PAP authentication only 852 consists of a username and password RFC 1334 [RFC1334] . The REPLY 853 from the server MUST be either a PASS, FAIL or ERROR. 855 5.4.2.3. CHAP login 857 action = TAC_PLUS_AUTHEN_LOGIN 858 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 859 minor_version = 0x1 861 The entire exchange MUST consist of a single START packet and a 862 single REPLY. The START packet MUST contain the username in the user 863 field and the data field is a concatenation of the PPP id, the 864 challenge and the response. 866 The length of the challenge value can be determined from the length 867 of the data field minus the length of the id (always 1 octet) and the 868 length of the response field (always 16 octets). 870 To perform the authentication, the server calculates the PPP hash as 871 defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then 872 compare that value with the response. The MD5 algorithm option is 873 always used. The REPLY from the server MUST be a PASS, FAIL or 874 ERROR. 876 The selection of the challenge and its length are not an aspect of 877 the TACACS+ protocol. However, it is strongly recommended that the 878 client/endstation interaction is configured with a secure challenge. 879 The TACACS+ server can help by rejecting authentications where the 880 challenge is below a minimum length (Minimum recommended is 8 bytes). 882 5.4.2.4. MS-CHAP v1 login 884 action = TAC_PLUS_AUTHEN_LOGIN 885 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 886 minor_version = 0x1 888 The entire exchange MUST consist of a single START packet and a 889 single REPLY. The START packet MUST contain the username in the user 890 field and the data field will be a concatenation of the PPP id, the 891 MS-CHAP challenge and the MS-CHAP response. 893 The length of the challenge value can be determined from the length 894 of the data field minus the length of the id (always 1 octet) and the 895 length of the response field (always 49 octets). 897 To perform the authentication, the server will use a combination of 898 MD4 and DES on the user's secret and the challenge, as defined in RFC 899 2433 [RFC2433] and then compare the resulting value with the 900 response. The REPLY from the server MUST be a PASS or FAIL. 902 For best practices, please refer to RFC 2433 [RFC2433] . The TACACS+ 903 server MUST reject authentications where the challenge deviates from 904 8 bytes as defined in the RFC. 906 5.4.2.5. MS-CHAP v2 login 908 action = TAC_PLUS_AUTHEN_LOGIN 909 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 910 minor_version = 0x1 912 The entire exchange MUST consist of a single START packet and a 913 single REPLY. The START packet MUST contain the username in the user 914 field and the data field will be a concatenation of the PPP id, the 915 MS-CHAP challenge and the MS-CHAP response. 917 The length of the challenge value can be determined from the length 918 of the data field minus the length of the id (always 1 octet) and the 919 length of the response field (always 49 octets). 921 To perform the authentication, the server will use the algorithm 922 specified RFC 2759 [RFC2759] on the user's secret and challenge and 923 then compare the resulting value with the response. The REPLY from 924 the server MUST be a PASS or FAIL. 926 For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] 927 . The TACACS+ server MUST rejects authentications where the challenge 928 deviates from 16 bytes as defined in the RFC. 930 5.4.2.6. Enable Requests 931 action = TAC_PLUS_AUTHEN_LOGIN 932 priv_lvl = implementation dependent 933 authen_type = not used 934 service = TAC_PLUS_AUTHEN_SVC_ENABLE 936 This is an ENABLE request, used to change the current running 937 privilege level of a user. The exchange MAY consist of multiple 938 messages while the server collects the information it requires in 939 order to allow changing the principal's privilege level. This 940 exchange is very similar to an ASCII login (Section 5.4.2.1) . 942 In order to readily distinguish enable requests from other types of 943 request, the value of the authen_service field MUST be set to 944 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 945 set to this value when requesting any other operation. 947 5.4.2.7. ASCII change password request 949 action = TAC_PLUS_AUTHEN_CHPASS 950 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 952 This exchange consists of multiple messages while the server collects 953 the information it requires in order to change the user's password. 954 It is very similar to an ASCII login. The status value 955 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 956 "new" password. It MAY be sent multiple times. When requesting the 957 "old" password, the status value MUST be set to 958 TAC_PLUS_AUTHEN_STATUS_GETDATA. 960 5.4.3. Aborting an Authentication Session 962 The client may prematurely terminate a session by setting the 963 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 964 flag is set, the data portion of the message may contain an ASCII 965 message explaining the reason for the abort. This information will 966 be handled by the server according to the requirements of the 967 deployment. The session is terminated, for more details about 968 session termination, refer to section (Section 4.4) 970 In cases of PASS, FAIL or ERROR, the server can insert a message into 971 server_msg to be displayed to the user. 973 The Draft `The Draft' [TheDraft] defined a mechanism to direct 974 authentication requests to an alternative server. This mechanism is 975 regarded as insecure, is deprecated, and not covered here. The 976 client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as 977 TAC_PLUS_AUTHEN_STATUS_FAIL 979 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 980 indicating that it is experiencing an unrecoverable error and the 981 authentication will proceed as if that host could not be contacted. 982 The data field may contain a message to be printed on an 983 administrative console or log. 985 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 986 authentication sequence is restarted with a new START packet from the 987 client, with new session Id, and seq_no set to 1. This REPLY packet 988 indicates that the current authen_type value (as specified in the 989 START packet) is not acceptable for this session. The client may try 990 an alternative authen_type. 992 If a client does not implement TAC_PLUS_AUTHEN_STATUS_RESTART option, 993 then it MUST process the response as if the status was 994 TAC_PLUS_AUTHEN_STATUS_FAIL. 996 6. Authorization 998 In the TACACS+ Protocol, authorization is the action of determining 999 what a user is allowed to do. Generally authentication precedes 1000 authorization, though it is not mandatory that a client use the same 1001 service for authentication that it will use for authorization. An 1002 authorization request may indicate that the user is not authenticated 1003 (we don't know who they are). In this case it is up to the server to 1004 determine, according to its configuration, if an unauthenticated user 1005 is allowed the services in question. 1007 Authorization does not merely provide yes or no answers, but it may 1008 also customize the service for the particular user. A common use of 1009 authorization is to provision a shell session when a user first logs 1010 into a device to administer it. The TACACS+ server might respond to 1011 the request by allowing the service, but placing a time restriction 1012 on the login shell. For a list of common attributes used in 1013 authorization, see the Authorization Attributes section (Section 8.2) 1014 . 1016 In the TACACS+ protocol an authorization is always a single pair of 1017 messages: a REQUEST from the client followed by a REPLY from the 1018 server. 1020 The authorization REQUEST message contains a fixed set of fields that 1021 indicate how the user was authenticated and a variable set of 1022 arguments that describe the services and options for which 1023 authorization is requested. 1025 The REPLY contains a variable set of response arguments (attribute- 1026 value pairs) that can restrict or modify the client's actions. 1028 6.1. The Authorization REQUEST Packet Body 1030 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 1031 +----------------+----------------+----------------+----------------+ 1032 | authen_method | priv_lvl | authen_type | authen_service | 1033 +----------------+----------------+----------------+----------------+ 1034 | user_len | port_len | rem_addr_len | arg_cnt | 1035 +----------------+----------------+----------------+----------------+ 1036 | arg_1_len | arg_2_len | ... | arg_N_len | 1037 +----------------+----------------+----------------+----------------+ 1038 | user ... 1039 +----------------+----------------+----------------+----------------+ 1040 | port ... 1041 +----------------+----------------+----------------+----------------+ 1042 | rem_addr ... 1043 +----------------+----------------+----------------+----------------+ 1044 | arg_1 ... 1045 +----------------+----------------+----------------+----------------+ 1046 | arg_2 ... 1047 +----------------+----------------+----------------+----------------+ 1048 | ... 1049 +----------------+----------------+----------------+----------------+ 1050 | arg_N ... 1051 +----------------+----------------+----------------+----------------+ 1053 authen_method 1055 This indicates the authentication method used by the client to 1056 acquire the user information. As this information is not always 1057 subject to verification, it is recommended that this field is 1058 ignored. 1060 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1062 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1064 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1066 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1068 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1070 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1072 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1073 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1075 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1077 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1079 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1081 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1082 password associated with the terminal line used to gain access. 1083 LOCAL is a client local user database. ENABLE is a command that 1084 authenticates in order to grant new privileges. TACACSPLUS is, of 1085 course, TACACS+. GUEST is an unqualified guest authentication, such 1086 as an ARAP guest login. RADIUS is the Radius authentication 1087 protocol. RCMD refers to authentication provided via the R-command 1088 protocols from Berkeley Unix. 1090 priv_lvl 1092 This field is used in the same way as the priv_lvl field in 1093 authentication request and is described in the Privilege Level 1094 section (Section 9) below. It indicates the users current privilege 1095 level. 1097 authen_type 1099 This field coresponds to the authen_type field in the authentication 1100 section (Section 5) above. It indicates the type of authentication 1101 that was performed. If this information is not available, then the 1102 client will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. 1103 This value is valid only in authorization and accounting requests. 1105 authen_service 1107 This field is the same as the authen_service field in the 1108 authentication section (Section 5) above. It indicates the service 1109 through which the user authenticated. 1111 user, user_len 1113 This field contains the user's account name. The user_len MUST 1114 indicate the length of the user field, in bytes. 1116 port, port_len 1118 This field matches the port field in the authentication section 1119 (Section 5) above. The port_len indicates the length of the port 1120 field, in bytes. 1122 rem_addr, rem_addr_len 1124 This field matches the rem_addr field in the authentication section 1125 (Section 5) above. The rem_addr_len indicates the length of the port 1126 field, in bytes. 1128 arg_cnt 1130 The number of authorization arguments to follow 1132 arg_1 ... arg_N, arg_1_len .... arg_N_len 1134 The arguments are the primary elements of the authorization 1135 interaction. In the request packet they describe the specifics of 1136 the authorization that is being requested. Each argument is encoded 1137 in the packet as a single arg filed (arg_1... arg_N) with a 1138 corresponding length fields (which indicates the length of each 1139 argument in bytes). 1141 The authorization arguments in both the REQUEST and the REPLY are 1142 attribute-value pairs. The attribute and the value are in a single 1143 printable US-ASCII string and are separated by either a "=" (0X3D) or 1144 a "*" (0X2A). The equals sign indicates a mandatory argument. The 1145 asterisk indicates an optional one. 1147 It is not legal for an attribute name to contain either of the 1148 separators. It is legal for attribute values to contain the 1149 separators. This means that the arguments must be parsed until the 1150 first separator is encountered, all characters in the argument, after 1151 this separator, are interpreted as the argument value. 1153 Optional arguments are ones that may be disregarded by either client 1154 or server. Mandatory arguments require that the receiving side can 1155 handle the attribute, that is: its implementation and configuration 1156 includes the details of how to act on it. If the client receives a 1157 mandatory argument that it cannot handle, it MUST consider the 1158 authorization to have failed. It is legal to send an attribute-value 1159 pair with a zero length value. 1161 Attribute-value strings are not NULL terminated, rather their length 1162 value indicates their end. The maximum length of an attribute-value 1163 string is 255 characters. The minimum is two characters (one name- 1164 value character and the separator) 1166 Though the attributes allow extensibility, a common core set of 1167 authorization attributes SHOULD be supported by clients and servers, 1168 these are listed in the Authorization Attributes (Section 8.2) 1169 section below. 1171 6.2. The Authorization REPLY Packet Body 1173 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 1174 +----------------+----------------+----------------+----------------+ 1175 | status | arg_cnt | server_msg len | 1176 +----------------+----------------+----------------+----------------+ 1177 + data_len | arg_1_len | arg_2_len | 1178 +----------------+----------------+----------------+----------------+ 1179 | ... | arg_N_len | server_msg ... 1180 +----------------+----------------+----------------+----------------+ 1181 | data ... 1182 +----------------+----------------+----------------+----------------+ 1183 | arg_1 ... 1184 +----------------+----------------+----------------+----------------+ 1185 | arg_2 ... 1186 +----------------+----------------+----------------+----------------+ 1187 | ... 1188 +----------------+----------------+----------------+----------------+ 1189 | arg_N ... 1190 +----------------+----------------+----------------+----------------+ 1192 status This field indicates the authorization status 1194 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1196 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1198 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1200 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1202 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1204 server_msg, server_msg_len 1206 This is a printable US-ASCII string that may be presented to the 1207 user. The server_msg_len indicates the length of the server_msg 1208 field, in bytes. 1210 data, data_len 1212 This is a printable US-ASCII string that may be presented on an 1213 administrative display, console or log. The decision to present this 1214 message is client specific. The data_len indicates the length of the 1215 data field, in bytes. 1217 arg_cnt 1218 The number of authorization arguments to follow. 1220 arg_1 ... arg_N, arg_1_len .... arg_N_len 1222 The arguments describe the specifics of the authorization that is 1223 being requested. For details of the content of the args, refer to: 1224 Authorization Attributes (Section 8.2) section below. Each argument 1225 is encoded in the packet as a single arg field (arg_1... arg_N) with 1226 a corresponding length fields (which indicates the length of each 1227 argument in bytes). 1229 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested 1230 authorization MUST be denied. 1232 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1233 arguments specified in the request are authorized and the arguments 1234 in the response MUST be applied according to the rules described 1235 above. 1237 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client 1238 MUST use the authorization attribute-value pairs (if any) in the 1239 response, instead of the authorization attribute-value pairs from the 1240 request. 1242 To approve the authorization with no modifications, the server sets 1243 the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. 1245 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1246 on the server. For the differences between ERROR and FAIL, refer to 1247 section Session Completion (Section 4.4) . None of the arg values 1248 have any relevance if an ERROR is set, and must be ignored. 1250 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1251 arg_cnt MUST be 0. In that case, the actions to be taken and the 1252 contents of the data field are identical to the 1253 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1255 7. Accounting 1257 Accounting is typically the third action after authentication and 1258 authorization. But again, neither authentication nor authorization 1259 is required. Accounting is the action of recording what a user is 1260 doing, and/or has done. Accounting in TACACS+ can serve two 1261 purposes: It may be used as an auditing tool for security services. 1262 It may also be used to account for services used, such as in a 1263 billing environment. To this end, TACACS+ supports three types of 1264 accounting records. Start records indicate that a service is about 1265 to begin. Stop records indicate that a service has just terminated, 1266 and Update records are intermediate notices that indicate that a 1267 service is still being performed. TACACS+ accounting records contain 1268 all the information used in the authorization records, and also 1269 contain accounting specific information such as start and stop times 1270 (when appropriate) and resource usage information. A list of 1271 accounting attributes is defined in the accounting section 1272 (Section 7) . 1274 7.1. The Account REQUEST Packet Body 1276 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 1277 +----------------+----------------+----------------+----------------+ 1278 | flags | authen_method | priv_lvl | authen_type | 1279 +----------------+----------------+----------------+----------------+ 1280 | authen_service | user_len | port_len | rem_addr_len | 1281 +----------------+----------------+----------------+----------------+ 1282 | arg_cnt | arg_1_len | arg_2_len | ... | 1283 +----------------+----------------+----------------+----------------+ 1284 | arg_N_len | user ... 1285 +----------------+----------------+----------------+----------------+ 1286 | port ... 1287 +----------------+----------------+----------------+----------------+ 1288 | rem_addr ... 1289 +----------------+----------------+----------------+----------------+ 1290 | arg_1 ... 1291 +----------------+----------------+----------------+----------------+ 1292 | arg_2 ... 1293 +----------------+----------------+----------------+----------------+ 1294 | ... 1295 +----------------+----------------+----------------+----------------+ 1296 | arg_N ... 1297 +----------------+----------------+----------------+----------------+ 1299 flags 1301 This holds bitmapped flags. 1303 TAC_PLUS_ACCT_FLAG_START := 0x02 1305 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1307 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1309 All other fields are defined in the authorization and authentication 1310 sections above and have the same semantics. They provide details for 1311 the conditions on the client, and authentication context, so that 1312 these details may be logged for accounting purposes. 1314 See section 12 Accounting Attribute-value Pairs for the dictionary of 1315 attributes relevant to accounting. 1317 7.2. The Accounting REPLY Packet Body 1319 The purpose of accounting is to record the action that has occurred 1320 on the client. The server MUST reply with success only when the 1321 accounting request has been recorded. If the server did not record 1322 the accounting request then it MUST reply with ERROR. 1324 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 1325 +----------------+----------------+----------------+----------------+ 1326 | server_msg len | data_len | 1327 +----------------+----------------+----------------+----------------+ 1328 | status | server_msg ... 1329 +----------------+----------------+----------------+----------------+ 1330 | data ... 1331 +----------------+ 1333 status 1335 This is the return status. Values are: 1337 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1339 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1341 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1343 server_msg, server_msg_len 1345 This is a printable US-ASCII string that may be presented to the 1346 user. The server_msg_len indicates the length of the server_msg 1347 field, in bytes. 1349 data, data_len 1351 This is a printable US-ASCII string that may be presented on an 1352 administrative display, console or log. The decision to present this 1353 message is client specific. The data_len indicates the length of the 1354 data field, in bytes. 1356 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1357 to be taken and the contents of the data field are identical to the 1358 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1360 TACACS+ accounting is intended to record various types of events on 1361 clients, for example: login sessions, command entry, and others as 1362 required by the client implementation. These events are collectively 1363 referred to in `The Draft' [TheDraft] as "tasks". 1365 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1366 accounting message. Start messages will only be sent once when a 1367 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1368 a stop record and that the task has terminated. The 1369 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1371 Summary of Accounting Packets 1373 +----------+-------+-------+-------------+-------------------------+ 1374 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1375 +----------+-------+-------+-------------+-------------------------+ 1376 | 0 | 0 | 0 | 0 | INVALID | 1377 | 0 | 0 | 1 | 2 | Start Accounting Record | 1378 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1379 | 0 | 1 | 1 | 6 | INVALID | 1380 | 1 | 0 | 0 | 8 | Watchdog, no update | 1381 | 1 | 0 | 1 | A | Watchdog, with update | 1382 | 1 | 1 | 0 | C | INVALID | 1383 | 1 | 1 | 1 | E | INVALID | 1384 +----------+-------+-------+-------------+-------------------------+ 1386 The START and STOP flags are mutually exclusive. 1388 The WATCHDOG flag is used by the client to communicate ongoing status 1389 of a long-running task. Update records are sent at the client's 1390 discretion. The frequency of the update depends upon the intended 1391 application: A watchdog to provide progress indication will require 1392 higher frequency than a daily keep-alive. When the WATCHDOG flag is 1393 set along with the START flag, it indicates that the update record 1394 provides additional or updated arguments from the original START 1395 record. If the START flag is not set, then this indicates only that 1396 task is still running, and no new information is provided (servers 1397 MUST ignore any arguments). The STOP flag MUST NOT be set in 1398 conjunction with the WATCHDOG flag. 1400 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1401 requests an INVALID option. 1403 8. Attribute-Value Pairs 1405 TACACS+ is intended to be an extensible protocol. The attributes 1406 used in Authorization and Accounting are not limited by this 1407 document. Some attributes are defined below for common use cases, 1408 clients MUST use these attributes when supporting the corresponding 1409 use cases. 1411 8.1. Value Encoding 1413 All attribute values are encoded as printable US-ASCII strings. The 1414 following type representations SHOULD be followed 1416 Numeric 1418 All numeric values in an attribute-value string are provided as 1419 decimal printable US-ASCII numbers, unless otherwise stated. 1421 Boolean 1423 All boolean attributes are encoded as printable US-ASCII with values 1424 "true" or "false". 1426 IP-Address 1428 It is recommended that hosts be specified as a IP address so as to 1429 avoid any ambiguities. IPV4 address are specified as US-ASCII octet 1430 numerics separated by dots ('.'), IPV6 address text representation 1431 defined in RFC 4291 [RFC4291] 1433 Date Time 1435 Absolute date/times are specified in seconds since the epoch, 12:00am 1436 Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is 1437 specified. Stardate is canonically inconsistent and so SHOULD NOT be 1438 used. 1440 String 1442 Many values have no specific type representation and so are 1443 interpreted as plain strings. 1445 Empty Values 1447 Attributes may be submitted with no value, in which case they consist 1448 of the name and the mandatory or optional separator. For example, 1449 the attribute "cmd" which has no value is transmitted as a string of 1450 four characters "cmd=" 1452 8.2. Authorization Attributes 1454 service (String) 1456 The primary service. Specifying a service attribute indicates that 1457 this is a request for authorization or accounting of that service. 1459 For example: "shell", "tty-server", "connection", "system" and 1460 "firewall". This attribute MUST always be included. 1462 protocol (String) 1464 the protocol field may be used to indicate a subset of a service. 1466 cmd (String) 1468 a shell (exec) command. This indicates the command name of the 1469 command that is to be run. The "cmd" attribute MUST be specified if 1470 service equals "shell". 1472 Authorization of shell commands is a common use-case for the TACACS+ 1473 protocol. Command Authorization generally takes one of two forms: 1474 session-based and command-based. 1476 For session-based shell authorization, the "cmd" argument will have 1477 an empty value. The client determines which commands are allowed in 1478 a session according to the arguments present in the authorization. 1480 In command-based authorization, the client requests that the server 1481 determine whether a command is allowed by making an authorization 1482 request for each command. The "cmd" argument will have the command 1483 name as its value. 1485 cmd-arg (String) 1487 an argument to a shell (exec) command. This indicates an argument 1488 for the shell command that is to be run. Multiple cmd-arg attributes 1489 may be specified, and they are order dependent. 1491 acl (Numeric) 1493 printable US-ASCII number representing a connection access list. 1494 Applicable only to session-based shell authorization. 1496 inacl (String) 1498 printable US-ASCII identifier for an interface input access list. 1500 outacl (String) 1502 printable US-ASCII identifier for an interface output access list. 1504 addr (IP-Address) 1506 a network address 1507 addr-pool (String) 1509 The identifier of an address pool from which the client can assign an 1510 address. 1512 routing (Boolean) 1514 Specifies whether routing information is to be propagated to, and 1515 accepted from this interface. 1517 route (String) 1519 Indicates an IPv4 route that is to be applied to this interface. 1520 Values MUST be of the form " []". 1521 If a is not specified, the resulting route is via the 1522 requesting peer. 1524 timeout (Numeric) 1526 an absolute timer for the connection (in minutes). A value of zero 1527 indicates no timeout. 1529 idletime (Numeric) 1531 an idle-timeout for the connection (in minutes). A value of zero 1532 indicates no timeout. 1534 autocmd (String) 1536 an auto-command to run. Applicable only to session-based shell 1537 authorization. 1539 noescape (Boolean) 1541 Prevents user from using an escape character. Applicable only to 1542 session-based shell authorization. 1544 nohangup (Boolean) 1546 Boolean. Do not disconnect after an automatic command. Applicable 1547 only to session-based shell authorization. 1549 priv-lvl (Numeric) 1551 privilege level to be assigned. Please refer to the Privilege Level 1552 section (Section 9) below. 1554 remote_user (String) 1555 remote userid (authen_method must have the value 1556 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1557 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1558 remote_user and remote_host attributes will provide the remote user 1559 and host information to enable rhost style authorization. The 1560 response may request that a privilege level be set for the user. 1562 remote_host (String) 1564 remote host (authen_method must have the value 1565 TAC_PLUS_AUTHEN_METH_RCMD) 1567 8.3. Accounting Attributes 1569 The following attributes are defined for TACACS+ accounting only. 1570 They MUST precede any attribute-value pairs that are defined in the 1571 authorization section (Section 6) above. 1573 task_id (String) 1575 Start and stop records for the same event MUST have matching task_id 1576 attribute values. The client MUST ensure that active task_ids are 1577 not duplicated: a client MUST NOT reuse a task_id a start record 1578 until it has sent a stop record for that task_id. Servers MUST not 1579 make assumptions about the format of a task_id. 1581 start_time (Date Time) 1583 The time the action started (in seconds since the epoch.). 1585 stop_time (Date Time) 1587 The time the action stopped (in seconds since the epoch.) 1589 elapsed_time (Numeric) 1591 The elapsed time in seconds for the action. 1593 timezone (String) 1595 The timezone abbreviation for all timestamps included in this packet. 1596 A database of timezones is maintained here: TZDB [TZDB] 1598 event (String) 1600 Used only when "service=system". Current values are "net_acct", 1601 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1603 These indicate system-level changes. The flags field SHOULD indicate 1604 whether the service started or stopped. 1606 reason (String) 1608 Accompanies an event attribute. It describes why the event occurred. 1610 bytes (Numeric) 1612 The number of bytes transferred by this action 1614 bytes_in (Numeric) 1616 The number of bytes transferred by this action from the endstation to 1617 the client port 1619 bytes_out (Numeric) 1621 The number of bytes transferred by this action from the client to the 1622 endstation port 1624 paks (Numeric) 1626 The number of packets transferred by this action. 1628 paks_in (Numeric) 1630 The number of input packets transferred by this action from the 1631 endstation to the client port. 1633 paks_out (Numeric) 1635 The number of output packets transferred by this action from the 1636 client port to the endstation. 1638 err_msg (String) 1640 A printable US-ASCII string describing the status of the action. 1642 9. Privilege Levels 1644 The TACACS+ Protocol supports flexible authorization schemes through 1645 the extensible attributes. 1647 One scheme is built into the protocol and has been extensively used 1648 for Session-based shell authorization: Privilege Levels. Privilege 1649 Levels are ordered values from 0 to 15 with each level being a 1650 superset of the next lower value. Configuration and implementation 1651 of the client will map actions (such as the permission to execute of 1652 specific commands) to different privilege levels. Pre-defined values 1653 are: 1655 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1657 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1659 TAC_PLUS_PRIV_LVL_USER := 0x01 1661 TAC_PLUS_PRIV_LVL_MIN := 0x00 1663 A Privilege level can be assigned to a shell (EXEC) session when it 1664 starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will permit 1665 the actions associated with this level to be executed. This 1666 privilege level is returned by the Server in a session-based shell 1667 authorization (when "service" equals "shell" and "cmd" is empty). 1668 When a user required to perform actions that are mapped to a higher 1669 privilege level, then an ENABLE type reauthentication can be 1670 initiated by the client. The client will insert the required 1671 privilege level into the authentication header for enable 1672 authentication request. 1674 The use of Privilege levels to determine session-based access to 1675 commands and resources is not mandatory for clients. Although the 1676 privilege level scheme is widely supported, its lack of flexibility 1677 in requiring a single monotonic hierarchy of permissions means that 1678 other session-based command authorization schemes have evolved, and 1679 so it is no longer mandatory for clients to use it. However, it is 1680 still common enough that it SHOULD be supported by servers. 1682 10. TACACS+ Security Considerations 1684 The original TACACS+ Draft `The Draft' [TheDraft] from 1998 did not 1685 address all of the key security concerns which are considered when 1686 designing modern standards. This section addresses known limitations 1687 and concerns which will impact overall security of the protocol and 1688 systems where this protocol is deployed to manage central 1689 authentication, authorization or accounting for network device 1690 administration. 1692 Multiple implementations of the protocol described in the original 1693 TACACS+ Draft `The Draft' [TheDraft] have been deployed. As the 1694 protocol was never standardized, current implementations may be 1695 incompatible in non-obvious ways, giving rise to additional security 1696 risks. This section does not claim to enumerate all possible 1697 security vulnerabilities. 1699 10.1. General Security of the Protocol 1701 TACACS+ protocol does not include a security mechanism that would 1702 meet modern-day requirements. Support for MD5-based crypto pad 1703 encryption fails to provide any kind of transport integrity, which 1704 presents at least the following risks: 1706 Accounting information may be modified by the man-in-the-middle 1707 attacker, making such logs unsuitable and untrustable for auditing 1708 purposes. 1710 Only the body of the request is obfuscated which leaves all header 1711 fields open to trivial modification by the man-in-the-middle 1712 attacker. For this reason, deployments SHOULD NOT use connections 1713 with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the Best Practices 1714 section (Section 10.5) . 1716 Invalid or misleading values may be inserted by the man-in-the- 1717 middle attacker in various fields at known offsets to try and 1718 circumvent the authentication or authorization checks even inside 1719 the obfuscated body. 1721 While the protocol provides some measure of transport privacy, it is 1722 vulnerable to at least the following attacks: 1724 Brute force attacks exploiting increased efficiency of MD5 digest 1725 computation. 1727 Known plaintext attacks which may decrease the cost of brute force 1728 attack. 1730 Chosen plaintext attacks which may decrease the cost of a brute 1731 force attack. 1733 No forward secrecy. 1735 Even though, to the best knowledge of authors, this method of 1736 encryption wasn't rigorously tested, enough information is available 1737 that it is best referred to as "obfuscation" and not "encryption". 1739 For these reasons, users deploying TACACS+ protocol in their 1740 environments MUST limit access to known clients and MUST control the 1741 security of the entire transmission path. Attackers who can guess 1742 the key or otherwise break the obfuscation will gain unrestricted and 1743 undetected access to all TACACS+ traffic. Ensuring that a 1744 centralized AAA system like TACACS+ is deployed on a secured 1745 transport is essential to managing the security risk of such an 1746 attack. 1748 The following parts of this section enumerate only the session- 1749 specific risks which are in addition to general risk associated with 1750 bare obfuscation and lack of integrity checking. 1752 10.2. Security of Authentication Sessions 1754 Authentication sessions SHOULD be used via a secure transport (see 1755 Best Practices section (Section 10.5) ) as the man-in-the-middle 1756 attack may completely subvert them. Even CHAP, which may be 1757 considered resistant to password interception, is unsafe as it does 1758 not protect the username from a trivial man-in-the-middle attack. 1760 This document deprecates the redirection mechanism using the 1761 TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the 1762 original draft. As part of this process, the secret key for a new 1763 server was sent to the client. This public exchange of secret keys 1764 means that once one session is broken, it may be possible to leverage 1765 that key to attacking connections to other servers. This mechanism 1766 SHOULD NOT be used in modern deployments. It MUST NOT be used 1767 outside a secured deployment. 1769 10.3. Security of Authorization Sessions 1771 Authorization sessions SHOULD be used via a secure transport (see 1772 Best Practices section (Section 10.5) ) as it's trivial to execute a 1773 successful man-in-the-middle attacks that changes well-known 1774 plaintext in either requests or responses. 1776 As an example, take the field "authen_method". It's not unusual in 1777 actual deployments to authorize all commands received via the device 1778 local serial port (a console port) as that one is usually considered 1779 secure by virtue of the device located in a physically secure 1780 location. If an administrator would configure the authorization 1781 system to allow all commands entered by the user on a local console 1782 to aid in troubleshooting, that would give all access to all commands 1783 to any attacker that would be able to change the "authen_method" from 1784 TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In 1785 this regard, the obfuscation provided by the protocol itself wouldn't 1786 help much, because: 1788 Lack of integrity means that any byte in the payload may be 1789 changed without either side detecting the change. 1791 Known plaintext means that an attacker would know with certainty 1792 which octet is the target of the attack (in this case, 1st octet 1793 after the header). 1795 In combination with known plaintext, the attacker can determine 1796 with certainty the value of the crypto-pad octet used to obfuscate 1797 the original octet. 1799 10.4. Security of Accounting Sessions 1801 Accounting sessions are not directly involved in authentication or 1802 authorizing operations on the device. However, man-in-the-middle 1803 attacker may do any of the following: 1805 Replace accounting data with new valid or garbage which prevents 1806 to provide distraction or hide information related to their 1807 authentication and/or authorization attack attempts. 1809 Try and poison accounting log with entries designed to make 1810 systems behave in unintended ways (which includes TACACS+ server 1811 and any other systems that would manage accounting entries). 1813 In addition to these direct manipulations, different client 1814 implementations pass different fidelity of accounting data. Some 1815 vendors have been observed in the wild that pass sensitive data like 1816 passwords, encryption keys and similar as part of the accounting log. 1817 Due to lack of strong encryption with perfect forward secrecy, this 1818 data may be revealed in future, leading to a security incident. 1820 10.5. TACACS+ Best Practices 1822 With respect to the observations about the security issues described 1823 above, a network administrator MUST NOT rely on the obfuscation of 1824 the TACACS+ protocol and TACACS+ MUST be deployed over networks which 1825 ensure privacy and integrity of the communication. TACACS+ MUST be 1826 used within a secure deployment. Failure to do so will impact 1827 overall network security. 1829 TACACS+ SHOULD be deployed over a network which is separated from 1830 other traffic. 1832 The following recommendations impose restrictions on how the protocol 1833 is applied. These restrictions were not imposed in the original 1834 draft. New implementations, and upgrades of current implementations, 1835 MUST implement these recommendations. 1837 10.5.1. Shared Secrets 1839 TACACS+ servers and clients MUST treat shared secrets as sensitive 1840 data to be managed securely, as would be expected for other sensitive 1841 data such as identity credential information. TACACS+ servers MUST 1842 not leak sensitive data. For example, TACACS+ servers should not 1843 expose shared secrets in logs. 1845 TACACS+ servers MUST allow a dedicated secret key to be defined for 1846 each client. 1848 TACACS+ servers SHOULD warn administrators if secret keys are not 1849 unique per client. 1851 TACACS+ server administrators SHOULD always define a secret for each 1852 client. 1854 TACACS+ servers and clients MUST support shared keys that are at 1855 least 32 characters long. 1857 TACACS+ servers MUST support policy to define minimum complexity for 1858 shared keys. 1860 TACACS+ clients SHOULD NOT allow servers to be configured without 1861 shared secret key, or shared key that is less than 16 characters 1862 long. 1864 TACACS+ server administrators SHOULD configure secret keys of minimum 1865 16 characters length. 1867 TACACS+ server administrators SHOULD change secret keys at regular 1868 intervals. 1870 10.5.2. Connections and Obfuscation 1872 TACACS+ servers MUST allow the definition of individual clients. The 1873 servers MUST only accept network connection attempts from these 1874 defined, known clients. 1876 TACACS+ servers MUST reject connections with 1877 TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on 1878 the server for the client requesting the connection. 1880 If an invalid shared secret is detected when processing packets for a 1881 client, TACACS+ servers MUST NOT accept any new sessions on that 1882 connection. TACACS+ servers MUST terminate the connection on 1883 completion of any sessions that were previously established with a 1884 valid shared secret on that connection. 1886 TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG when a secret 1887 is defined. Clients MUST be implemented in a way that requires 1888 explicit configuration to enable the use of 1889 TAC_PLUS_UNENCRYPTED_FLAG. 1891 When a TACACS+ client receives responses from servers where: 1893 the response packet was received from the server configured with 1894 shared key, but the packet jas TAC_PLUS_UNENCRYPTED_FLAG set. 1896 the response packet was received from the server configured not to 1897 use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not 1898 set. 1900 then the TACACS+ client MUST close TCP session, and process the 1901 response in the same way that a TAC_PLUS_AUTHEN_STATUS_FAIL 1902 (authentication sessions) or TAC_PLUS_AUTHOR_STATUS_FAIL 1903 (authorization sessions) was received. 1905 10.5.3. Authentication 1907 To help TACACS+ administraots select the stronger authentication 1908 options, TACACS+ servers MUST allow the administrator to configure 1909 the server to only accept challenge/response options for 1910 authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or 1911 TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for 1912 authen_type). 1914 TACACS+ server administrators SHOULD enable the option mentioned in 1915 the previous paragraph. TACACS+ Server deployments SHOULD ONLY 1916 enable other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or 1917 TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of 1918 identity/password systems. 1920 TACACS+ server administrators SHOULD NOT allow the same credentials 1921 to be applied in challenge-based (TAC_PLUS_AUTHEN_TYPE_CHAP or 1922 TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non 1923 challenge-based authen_type options as the insecurity of the latter 1924 will compromise the security of the former. 1926 TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options 1927 mentioned in the original draft SHOULD not be used, due to their 1928 security implications. TACACS+ servers SHOULD NOT implement them. 1929 If they must be implemented, the servers MUST default to the options 1930 being disabled and MUST warn the administrator that these options are 1931 not secure. 1933 10.5.4. Authorization 1935 The authorization and accounting features are intended to provide 1936 extensibility and flexibility. There is a base dictionary defined in 1937 this document, but it may be extended in deployments by using new 1938 attribute names. The cost of the flexibility is that administrators 1939 and implementors MUST ensure that the attribute and value pairs 1940 shared between the clients and servers have consistent 1941 interpretation. 1943 TACACS+ clients that receive an unrecognised mandatory attribute MUST 1944 evaluate server response as if they received 1945 TAC_PLUS_AUTHOR_STATUS_FAIL. 1947 10.5.5. Redirection Mechanism 1949 The original draft described a redirection mechanism 1950 (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to 1951 secure. The option to send secret keys in the server list is 1952 particularly insecure, as it can reveal client shared secrets. 1954 TACACS+ servers SHOULD deprecate the redirection mechanism. 1956 If the redirection mechanism is implemented then TACACS+ servers MUST 1957 disable it by default, and MUST warn TACACS+ server administrators 1958 that it must only be enabled within a secure deployment due to the 1959 risks of revealing shared secrets. 1961 TACACS+ clients SHOULD deprecate this feature by treating 1962 TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. 1964 11. Acknowledgements 1966 The authors would like to thank the following reviewers whose 1967 comments and contributions made considerable improvements to the 1968 document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch, 1969 Robert Drake, among many others. 1971 The authors would particularly like to thank Alan DeKok, who provided 1972 significant insights and recommendations on all aspects of the 1973 document and the protocol. Alan DeKok has dedicated considerable 1974 time and effort to help improve the document, identifying weaknesses 1975 and providing remediation. 1977 The authors would also like to thanks the support from the OPSAWG 1978 Chairs and advisors. 1980 12. References 1982 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1983 April 1992. 1985 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1986 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1987 . 1989 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1990 "Randomness Recommendations for Security", RFC 1750, 1991 DOI 10.17487/RFC1750, December 1994, 1992 . 1994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1995 Requirement Levels", BCP 14, RFC 2119, 1996 DOI 10.17487/RFC2119, March 1997, 1997 . 1999 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 2000 RFC 2433, DOI 10.17487/RFC2433, October 1998, 2001 . 2003 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 2004 RFC 2759, DOI 10.17487/RFC2759, January 2000, 2005 . 2007 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2008 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2009 2006, . 2011 [TheDraft] 2012 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 2013 1.78", June 1997, 2014 . 2016 [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and 2017 Daylight Saving Time Data", 1987, 2018 . 2020 Authors' Addresses 2022 Thorsten Dahm 2023 Google Inc 2024 1600 Amphitheatre Parkway 2025 Mountain View, CA 94043 2026 US 2028 EMail: thorstendlux@google.com 2029 Andrej Ota 2030 Google Inc 2031 1600 Amphitheatre Parkway 2032 Mountain View, CA 94043 2033 US 2035 EMail: andrej@ota.si 2037 Douglas C. Medway Gash 2038 Cisco Systems, Inc. 2039 170 West Tasman Dr. 2040 San Jose, CA 95134 2041 US 2043 EMail: dcmgash@cisco.com 2045 David Carrel 2046 vIPtela, Inc. 2047 1732 North First St. 2048 San Jose, CA 95112 2049 US 2051 EMail: dcarrel@viptela.com 2053 Lol Grant 2055 EMail: lol.grant@gmail.com