idnits 2.17.1 draft-ietf-opsawg-tacacs-09.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 213: '...e TCP connection. The client MUST NOT...' RFC 2119 keyword, line 226: '...lient and server MUST ignore the flag ...' RFC 2119 keyword, line 241: '... client MUST accommodate such closur...' RFC 2119 keyword, line 260: '... and it MUST behave as if the server...' RFC 2119 keyword, line 276: '...enabled, then the connection SHOULD be...' (96 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 'SHOULD not' in this paragraph: Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks that are considered 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 (March 21, 2018) is 2228 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1692 ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: September 22, 2018 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 March 21, 2018 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-09 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 September 22, 2018. 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. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 70 3. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 4 71 3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.3. Single Connection Mode . . . . . . . . . . . . . . . . . 5 74 3.4. Session Completion . . . . . . . . . . . . . . . . . . . 6 75 3.5. Treatment of Enumerated Protocol Values . . . . . . . . . 7 76 3.6. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 7 77 3.7. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 7 78 3.8. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 9 79 3.9. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 11 80 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.1. The Authentication START Packet Body . . . . . . . . . . 12 82 4.2. The Authentication REPLY Packet Body . . . . . . . . . . 14 83 4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 16 84 4.4. Description of Authentication Process . . . . . . . . . . 16 85 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 86 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 87 4.4.3. Aborting an Authentication Session . . . . . . . . . 21 88 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 89 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 22 90 5.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 91 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 93 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 94 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 95 7.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 96 7.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 97 7.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 98 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 99 9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 100 9.1. General Security of The Protocol . . . . . . . . . . . . 36 101 9.2. Security of Authentication Sessions . . . . . . . . . . . 38 102 9.3. Security of Authorization Sessions . . . . . . . . . . . 38 103 9.4. Security of Accounting Sessions . . . . . . . . . . . . . 39 104 9.5. TACACS+ Deployment Recommendations . . . . . . . . . . . 39 105 9.6. TACACS+ Client Implementation Recommendations . . . . . . 40 106 9.7. TACACS+ Server Implementation Recommendations . . . . . . 41 107 9.8. TACACS+ Security and Operational Concerns . . . . . . . . 41 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 112 1. Introduction 114 Terminal Access Controller Access-Control System Plus (TACACS+) was 115 conceived initially as a general Authentication, Authorization and 116 Accounting protocol. It is primarily used today for Device 117 Administration: authenticating access to network devices, providing 118 central authorization of operations, and audit of those operations. 120 A wide range of TACACS+ clients and servers are already deployed in 121 the field. The TACACS+ protocol they are based on is defined in a 122 draft document that was originally intended for IETF publication. 123 This document is known as `The Draft' [TheDraft] . 125 It is intended that all implementations which conform to this 126 document will conform to `The Draft'. However, attention is drawn to 127 the following specific adjustments of the protocol specification from 128 'The Draft': 130 This document officially removes SENDPASS for security reasons. 132 The normative description of Legacy features such as ARAP and 133 outbound authentication has been removed, however, the required 134 enumerations are kept. 136 The Support for forwarding to an alternative daemon 137 (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated. 139 The TACACS+ protocol separates the functions of Authentication, 140 Authorization and Accounting. It allows for arbitrary length and 141 content authentication exchanges, to support future authentication 142 mechanisms. It is extensible to provide for site customization and 143 future development features, and it uses TCP to ensure reliable 144 delivery. The protocol allows the TACACS+ client to request very 145 fine-grained access control and allows the server to respond to each 146 component of that request. 148 The separation of authentication, authorization and accounting was a 149 key element of the design of TACACS+ protocol. Essentially it makes 150 TACACS+ a suite of three protocols. This document will address each 151 one in separate sections. Although TACACS+ defines all three, but an 152 implementation or configuration is not required to employ all three. 153 Separating the elements is useful for Device Administration use case, 154 specifically, for authorization of individual commands in a session. 155 Note that there is no provision made at the protocol level for 156 association of an authentication to each authorization request. 158 This document restricts itself to a description of the protocol that 159 is used by TACACS+. It does not cover deployment or best practices. 161 2. Technical Definitions 163 This section provides a few basic definitions that are applicable to 164 this document 166 Client 168 The client is any device, (often a Network Access Server) that 169 provides access services. The clients usually provide a character 170 mode front end and then allow the user to telnet or rlogin to another 171 host. 173 Server 175 The server receives TACACS+ protocol requests, and replies according 176 to its business model, in accordance with the flows defined in this 177 document. 179 Packet 181 All uses of the word packet in this document refer to TACACS+ 182 protocol packets unless explicitly noted otherwise. 184 3. TACACS+ Connections and Sessions 186 3.1. Connection 188 TACACS+ uses TCP for its transport. Server port 49 is allocated for 189 TACACS+ traffic. 191 3.2. Session 193 The concept of a session is used throughout this document. A TACACS+ 194 session is a single authentication sequence, a single authorization 195 exchange, or a single accounting exchange. 197 An accounting and authorization session will consist of a single pair 198 of packets (the request and its reply). An authentication session 199 may involve an arbitrary number of packets being exchanged. The 200 session is an operational concept that is maintained between the 201 TACACS+ client and server. It does not necessarily correspond to a 202 given user or user action. 204 3.3. Single Connection Mode 206 Single Connection Mode is intended to improve performance by allowing 207 a client to multiplex multiple session on a single TCP connection. 209 The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by 210 the client and server to negotiate the use of Single Connect Mode. 212 The client sets this flag, to indicate that it supports multiplexing 213 TACACS+ sessions over a single TCP connection. The client MUST NOT 214 send a second packet on a connection until single-connect status has 215 been established. 217 To indicate it will support Single Connection Mode, the server sets 218 this flag in the first reply packet in response to the first request 219 from a client. The server may set this flag even if the client does 220 not set it, but the client may ignore the flag and close the 221 connection after the session completes. 223 The flag is only relevant for the first two packets on a connection, 224 to allow the client and server to establish Single Connection Mode. 225 No provision is made for changing Single Connection Mode after the 226 first two packets: the client and server MUST ignore the flag after 227 the second packet on a connection. 229 If single Connection Mode has not been established in the first two 230 packets of a TCP connection, then both the client and the server 231 close the connection at the end of the first session. 233 The client negotiates Single Connection Mode to improve efficiency. 234 The server may refuse to allow Single Connection Mode for the client. 235 For example, it may not be appropriate to allocate a long-lasting TCP 236 connection to a specific client in some deployments. Even if the 237 server is configured to permit single Connection Mode for a specific 238 client, the server may close the connection. For example: a server 239 may be configured to time out a Single Connection Mode TCP Connection 240 after a specific period of inactivity to preserve its resources. The 241 client MUST accommodate such closures on a TCP session even after 242 Single Connection Mode has been established. 244 3.4. Session Completion 246 The REPLY packets defined for the packets types in the sections below 247 (Authentication, Authorization and Accounting) contain a status 248 field. The complete set of options for this field depend upon the 249 packet type, but all three REPLY packet types define values 250 representing PASS, ERROR and FAIL, which indicate the last packet of 251 a regular session (one which is not aborted). 253 The server responds with a PASS or a FAIL to indicate that the 254 processing of the request completed and the client can apply the 255 result (PASS or FAIL) to control the execution of the action which 256 prompted the request to be sent to the server. 258 The server responds with an ERROR to indicate that the processing of 259 the request did not complete. The client can not apply the result 260 and it MUST behave as if the server could not be connected to. For 261 example, the client tries alternative methods, if they are available, 262 such as sending the request to a backup server, or using local 263 configuration to determine whether the action which prompted the 264 request should be executed. 266 Refer to the section (Section 4.4.3) on Aborting Authentication 267 Sessions for details on handling additional status options. 269 When the session is complete, then the TCP connection should be 270 handled as follows, according to whether Single Connection Mode was 271 negotiated: 273 If Single Connection Mode was not negotiated, then the connection 274 should be closed 276 If Single Connection Mode was enabled, then the connection SHOULD be 277 left open (see section (Section 3.3) ), but may still be closed after 278 a timeout period to preserve deployment resources 280 If Single Connection Mode was enabled, but an ERROR occurred due to 281 connection issues (such as an incorrect secret, see section 282 (Section 3.7) ), then any further new sessions MUST NOT be accepted 283 on the connection. If there are any sessions that have already been 284 established then they MAY be completed. Once all active sessions are 285 completed then the connection MUST be closed. 287 It is recommended that client implementations provide robust schemes 288 for dealing with servers which cannot be connected to. Options 289 include providing a list of servers for redundancy, and an option for 290 a local fallback configuration if no servers can be reached. Details 291 will be implementation specific. 293 The client should manage connections and handle the case of a server 294 which establishes a connection, but does not respond. The exact 295 behavior is implementation specific. It is recommended that the 296 client should close the connection after a configurable timeout. 298 3.5. Treatment of Enumerated Protocol Values 300 This document describes various enumerated values in the packet 301 header and the headers for specific packet types. For example in the 302 Authentication start packet type, this document defines the action 303 field with three values TAC_PLUS_AUTHEN_LOGIN, TAC_PLUS_AUTHEN_CHPASS 304 and TAC_PLUS_AUTHEN_SENDAUTH. 306 If the server does not implement one of the defined options in a 307 packet that it receives, or it encounters an option that is not 308 listed in this document for a header field, then it should respond 309 with a ERROR and terminate the session. This will allow the client 310 to try a different option. 312 If an error occurs but the type of the incoming packet cannot be 313 determined, a packet with the identical cleartext header but with a 314 sequence number incremented by one and the length set to zero MUST be 315 returned to indicate an error. 317 3.6. Text Encoding 319 All text fields in TACACS+ MUST be printable US-ASCII, excepting 320 special consideration given to user field and data fields used for 321 passwords. 323 To ensure interoperability of current deployments, the TACACS+ client 324 and server MUST handle user fields and those data fields used for 325 passwords as 8-bit octet strings. The deployment operator MUST 326 ensure that consistent character encoding is applied from the end 327 client to the server. The encoding SHOULD be UTF-8, and other 328 encodings outside printable US-ASCII SHOULD be deprecated. 330 3.7. Data Obfuscation 332 The body of packets may be obfuscated. The following sections 333 describe the obfuscation method that is supported in the protocol. 334 In 'The Draft' this process was actually referred to as Encryption, 335 but the algorithm would not meet modern standards, and so will not be 336 termed as encryption in this document. 338 The obfuscation mechanism relies on a secret key, a shared secret 339 value that is known to both the client and the server. This document 340 does not discuss the management and storage of those keys, other than 341 to require that the secret keys MUST remain secret. 343 Server implementations MUST allow a unique secret key to be 344 associated with every client. It is a site-dependent decision as to 345 whether the use of separate keys is appropriate. 347 The flag field may be set as follows: 349 TAC_PLUS_UNENCRYPTED_FLAG = 0x0 351 In this case, the packet body is obfuscated by XOR-ing it byte-wise 352 with a pseudo-random pad. 354 ENCRYPTED {data} = data ^ pseudo_pad 356 The packet body can then be de-obfuscated by XOR-ing it byte-wise 357 with a pseudo random pad. 359 data = ENCRYPTED {data} ^ pseudo_pad 361 The pad is generated by concatenating a series of MD5 hashes (each 16 362 bytes long) and truncating it to the length of the input data. 364 Whenever used in this document, MD5 refers to the "RSA Data Security, 365 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 366 . 368 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 370 The first MD5 hash is generated by concatenating the session_id, the 371 secret key, the version number and the sequence number and then 372 running MD5 over that stream. All of those input values are 373 available in the packet header, except for the secret key which is a 374 shared secret between the TACACS+ client and server. 376 The version number and session_id are used as extracted from the 377 header 379 Subsequent hashes are generated by using the same input stream, but 380 concatenating the previous hash value at the end of the input stream. 382 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 383 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 384 version, seq_no, MD5_n-1} 386 When a server detects that the secret(s) it has configured for the 387 device mismatch, it MUST return ERROR. For details of TCP connection 388 handling on ERROR, refer to section (Section 3.4) 390 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 392 In this case, the entire packet body is in cleartext. Obfuscation 393 and de-obfuscation are null operations. This method should be 394 avoided unless absolutely required for debug purposes, when tooling 395 does not permit de-obfuscation. 397 If deployment is configured for obfuscating a connection then the 398 request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. 400 After a packet body is de-obfuscated, the lengths of the component 401 values in the packet are summed. If the sum is not identical to the 402 cleartext datalength value from the header, the packet MUST be 403 discarded, and an ERROR signaled. For details of TCP connection 404 handling on ERROR, refer to section (Section 3.4) 406 Commonly such failures are seen when the keys are mismatched between 407 the client and the TACACS+ server. 409 3.8. The TACACS+ Packet Header 411 All TACACS+ packets begin with the following 12-byte header. The 412 header describes the remainder of the packet: 414 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 415 +----------------+----------------+----------------+----------------+ 416 |major | minor | | | | 417 |version| version| type | seq_no | flags | 418 +----------------+----------------+----------------+----------------+ 419 | | 420 | session_id | 421 +----------------+----------------+----------------+----------------+ 422 | | 423 | length | 424 +----------------+----------------+----------------+----------------+ 426 major_version 428 This is the major TACACS+ version number. 430 TAC_PLUS_MAJOR_VER := 0xc 432 minor_version 434 The minor TACACS+ version number. 436 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 438 TAC_PLUS_MINOR_VER_ONE := 0x1 440 type 442 This is the packet type. Legal values are: 444 TAC_PLUS_AUTHEN := 0x01 (Authentication) 446 TAC_PLUS_AUTHOR := 0x02 (Authorization) 448 TAC_PLUS_ACCT := 0x03 (Accounting) 450 seq_no 452 This is the sequence number of the current packet. The first packet 453 in a session MUST have the sequence number 1 and each subsequent 454 packet will increment the sequence number by one. Thus clients only 455 send packets containing odd sequence numbers, and TACACS+ servers 456 only send packets containing even sequence numbers. 458 The sequence number must never wrap i.e. if the sequence number 2^8-1 459 is ever reached, that session must terminate and be restarted with a 460 sequence number of 1. 462 flags 464 This field contains various bitmapped flags. 466 The flag bit: 468 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 470 This flag indicates that the sender did not obfuscate the body of the 471 packet. The application of this flag will be covered in the security 472 section (Section 9) . 474 This flag SHOULD be clear in all deployments. Modern network traffic 475 tools support encrypted traffic when configured with the shared 476 secret (see section below), so obfuscated mode can and SHOULD be used 477 even during test. 479 The single-connection flag: 481 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 483 This flag is used to allow a client and server to negotiate Single 484 Connection Mode. 486 session_id 488 The Id for this TACACS+ session. This field does not change for the 489 duration of the TACACS+ session. This number MUST be generated by a 490 cryptographically strong random number generation method. Failure to 491 do so will compromise security of the session. For more details 492 refer to RFC 1750 [RFC1750] 494 length 496 The total length of the packet body (not including the header). 498 3.9. The TACACS+ Packet Body 500 The TACACS+ body types are defined in the packet header. The next 501 sections of this document will address the contents of the different 502 TACACS+ bodies. The following general rules apply to all TACACS+ 503 body types: 505 - To signal that any variable length data fields are unused, their 506 length value is set to zero. Such fields MUST be ignored, and 507 treated as if not present. 509 - the lengths of data and message fields in a packet are specified 510 by their corresponding length fields, (and are not null 511 terminated.) 513 - All length values are unsigned and in network byte order. 515 4. Authentication 517 Authentication is the action of determining who a user (or entity) 518 is. Authentication can take many forms. Traditional authentication 519 employs a name and a fixed password. However, fixed passwords are 520 vulnerable security, so many modern authentication mechanisms utilize 521 "one-time" passwords or a challenge-response query. TACACS+ is 522 designed to support all of these, and be flexible enough to handle 523 any future mechanisms. Authentication generally takes place when the 524 user first logs in to a machine or requests a service of it. 526 Authentication is not mandatory; it is a site-configured option. 527 Some sites do not require it. Others require it only for certain 528 services (see authorization below). Authentication may also take 529 place when a user attempts to gain extra privileges, and must 530 identify himself or herself as someone who possesses the required 531 information (passwords, etc.) for those privileges. 533 4.1. The Authentication START Packet Body 535 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 536 +----------------+----------------+----------------+----------------+ 537 | action | priv_lvl | authen_type | authen_service | 538 +----------------+----------------+----------------+----------------+ 539 | user_len | port_len | rem_addr_len | data_len | 540 +----------------+----------------+----------------+----------------+ 541 | user ... 542 +----------------+----------------+----------------+----------------+ 543 | port ... 544 +----------------+----------------+----------------+----------------+ 545 | rem_addr ... 546 +----------------+----------------+----------------+----------------+ 547 | data... 548 +----------------+----------------+----------------+----------------+ 550 Packet fields are as follows: 552 action 554 This indicates the authentication action. Legal values are listed 555 below. 557 TAC_PLUS_AUTHEN_LOGIN := 0x01 559 TAC_PLUS_AUTHEN_CHPASS := 0x02 561 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 563 priv_lvl 565 This indicates the privilege level that the user is authenticating 566 as. Please refer to the Privilege Level section (Section 8) below. 568 authen_type 570 The type of authentication. Legal values are: 572 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 573 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 575 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 577 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 579 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 581 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 583 authen_service 585 This is the service that is requesting the authentication. Legal 586 values are: 588 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 590 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 592 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 594 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 596 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 598 TAC_PLUS_AUTHEN_SVC_PT := 0x05 600 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 602 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 604 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 606 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 608 The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization 609 application of this field that indicates that no authentication was 610 performed by the device. 612 The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as 613 opposed to ENABLE) to a client device. 615 The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE 616 authen_service, which refers to a service requesting authentication 617 in order to grant the user different privileges. This is comparable 618 to the Unix "su(1)" command, which substitutes the current user's 619 identity with another. An authen_service value of NONE is only to be 620 used when none of the other authen_service values are appropriate. 622 ENABLE may be requested independently, no requirements for previous 623 authentications or authorizations are imposed by the protocol. 625 Other options are included for legacy/backwards compatibility. 627 user, user_len 629 The username is optional in this packet, depending upon the class of 630 authentication. If it is absent, the client MUST set user_len to 0. 631 If included, the user_len indicates the length of the user field, in 632 bytes. 634 port, port_len 636 The printable US-ASCII name of the client port on which the 637 authentication is taking place, and its length in bytes. The value 638 of this field is client specific. (For example, Cisco uses "tty10" 639 to denote the tenth tty line and "Async10" to denote the tenth async 640 interface). The port_len indicates the length of the port field, in 641 bytes. 643 rem_addr, rem_addr_len 645 A printable US-ASCII string indicating the remote location from which 646 the user has connected to the client. It is intended to hold a 647 network address if the user is connected via a network, a caller ID 648 is the user is connected via ISDN or a POTS, or any other remote 649 location information that is available. This field is optional 650 (since the information may not be available). The rem_addr_len 651 indicates the length of the user field, in bytes. 653 data, data_len 655 This field is used to send data appropriate for the action and 656 authen_type. It is described in more detail in the section Common 657 Authentication flows (Section 4.4.2) . The data_len indicates the 658 length of the data field, in bytes. 660 4.2. The Authentication REPLY Packet Body 662 The TACACS+ server sends only one type of authentication packet (a 663 REPLY packet) to the client. 665 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 666 +----------------+----------------+----------------+----------------+ 667 | status | flags | server_msg_len | 668 +----------------+----------------+----------------+----------------+ 669 | data_len | server_msg ... 670 +----------------+----------------+----------------+----------------+ 671 | data ... 672 +----------------+----------------+ 674 status 676 The current status of the authentication. Legal values are: 678 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 680 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 682 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 684 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 686 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 688 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 690 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 692 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 694 flags 696 Bitmapped flags that modify the action to be taken. The following 697 values are defined: 699 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 701 server_msg, server_msg_len 703 A message to be displayed to the user. This field is optional. The 704 printable US-ASCII charset MUST be used. The server_msg_len 705 indicates the length of the server_msg field, in bytes. 707 data, data_len 709 This field holds data that is a part of the authentication exchange 710 and is intended for the client, not the user. Examples of its use 711 are shown in the section Common Authentication flows (Section 4.4.2) 712 . The data_len indicates the length of the data field, in bytes. 714 4.3. The Authentication CONTINUE Packet Body 716 This packet is sent from the client to the server following the 717 receipt of a REPLY packet. 719 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 720 +----------------+----------------+----------------+----------------+ 721 | user_msg len | data_len | 722 +----------------+----------------+----------------+----------------+ 723 | flags | user_msg ... 724 +----------------+----------------+----------------+----------------+ 725 | data ... 726 +----------------+ 728 user_msg, user_msg_len 730 This field is the string that the user entered, or the client 731 provided on behalf of the user, in response to the server_msg from a 732 REPLY packet. The user_len indicates the length of the user field, 733 in bytes. 735 data, data_len 737 This field carries information that is specific to the action and the 738 authen_type for this session. Valid uses of this field are described 739 below. The data_len indicates the length of the data field, in 740 bytes. 742 flags 744 This holds the bitmapped flags that modify the action to be taken. 745 The following values are defined: 747 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 749 4.4. Description of Authentication Process 751 The action, authen_type and authen_service fields (described above) 752 combine to indicate what kind of authentication is to be performed. 753 Every authentication START, REPLY and CONTINUE packet includes a data 754 field. The use of this field is dependent upon the kind of the 755 Authentication. 757 This document defines a core set of authentication flows to be 758 supported by TACACS+. Each authentication flow consists of a START 759 packet. The server responds either with a request for more 760 information (GETDATA, GETUSER or GETPASS) or a termination PASS, 761 FAIL, ERROR or RESTART. The actions and meanings when the server 762 sends a RESTART or ERROR are common and are described further below. 764 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 765 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 766 then authentication continues and the server SHOULD provide 767 server_msg content for the client to prompt the user for more 768 information. The client MUST then return a CONTINUE packet 769 containing the requested information in the user_msg field. 771 The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a 772 request for username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request 773 for password. The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic 774 request for more information to flexibly support future requirements. 776 If the information being requested by the server form the client is 777 sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO 778 flag. When the client queries the user for the information, the 779 response MUST NOT be echoed as it is entered. 781 The data field is only used in the REPLY where explicitly defined 782 below. 784 4.4.1. Version Behaviour 786 The TACACS+ protocol is versioned to allow revisions while 787 maintaining backwards compatibility. The version number is in every 788 packet header. The changes between minor_version 0 and 1 apply only 789 to the authentication process, and all deal with the way that CHAP 790 and PAP authentications are handled. minor_version 1 may only be used 791 for authentication kinds that explicitly call for it in the table 792 below: 794 LOGIN CHPASS SENDAUTH 795 ASCII v0 v0 - 796 PAP v1 - v1 797 CHAP v1 - v1 798 MS-CHAPv1/2 v1 - v1 800 The '-' symbol represents that the option is not valid. 802 All authorisation and accounting and ASCII authentication use 803 minor_version number of 0. 805 PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange 806 is a single START packet from the client and a single REPLY from the 807 server. 809 The removal of SENDPASS was prompted by security concerns, and is no 810 longer considered part of the TACACS+ protocol. 812 4.4.2. Common Authentication Flows 814 This section describes common authentication flows. If the server 815 does not implement an option, it MUST respond with 816 TAC_PLUS_AUTHEN_STATUS_FAIL. 818 4.4.2.1. ASCII Login 820 action = TAC_PLUS_AUTHEN_LOGIN 821 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 822 minor_version = 0x0 824 This is a standard ASCII authentication. The START packet MAY 825 contain the username. If the user does not include the username then 826 the server MUST obtain it from the client with a CONTINUE 827 TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user does not provide a 828 username then the server can send another 829 TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server MUST limit the 830 number of retries that are permitted, recommended limit is three 831 attempts. When the server has the username, it will obtain the 832 password using a continue with TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII 833 login uses the user_msg field for both the username and password. 834 The data fields in both the START and CONTINUE packets are not used 835 for ASCII logins, any content MUST be ignored. The session is 836 composed of a single START followed by zero or more pairs of REPLYs 837 and CONTINUEs, followed by a final REPLY indicating PASS, FAIL or 838 ERROR. 840 4.4.2.2. PAP Login 842 action = TAC_PLUS_AUTHEN_LOGIN 843 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 844 minor_version = 0x1 846 The entire exchange MUST consist of a single START packet and a 847 single REPLY. The START packet MUST contain a username and the data 848 field MUST contain the PAP ASCII password. A PAP authentication only 849 consists of a username and password RFC 1334 [RFC1334] . The REPLY 850 from the server MUST be either a PASS, FAIL or ERROR. 852 4.4.2.3. CHAP login 854 action = TAC_PLUS_AUTHEN_LOGIN 855 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 856 minor_version = 0x1 858 The entire exchange MUST consist of a single START packet and a 859 single REPLY. The START packet MUST contain the username in the user 860 field and the data field is a concatenation of the PPP id, the 861 challenge and the response. 863 The length of the challenge value can be determined from the length 864 of the data field minus the length of the id (always 1 octet) and the 865 length of the response field (always 16 octets). 867 To perform the authentication, the server calculates the PPP hash as 868 defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then 869 compare that value with the response. The MD5 algorithm option is 870 always used. The REPLY from the server MUST be a PASS, FAIL or 871 ERROR. 873 In cases where the client conducts the exchange with the endstation 874 and then sends the resulting materials (challenge and response) to 875 the server, the selection of the challenge and its length are not an 876 aspect of the TACACS+ protocol. However, it is strongly recommended 877 that the client/endstation interaction is configured with a secure 878 challenge. The TACACS+ server can help by rejecting authentications 879 where the challenge is below a minimum length (Minimum recommended is 880 8 bytes). 882 In cases where the TACACS+ Server generates the challenge then it 883 MUST change for every request and MUST be derived from a strong 884 cryptographic source. 886 4.4.2.4. MS-CHAP v1 login 888 action = TAC_PLUS_AUTHEN_LOGIN 889 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 890 minor_version = 0x1 892 The entire exchange MUST consist of a single START packet and a 893 single REPLY. The START packet MUST contain the username in the user 894 field and the data field will be a concatenation of the PPP id, the 895 MS-CHAP challenge and the MS-CHAP response. 897 The length of the challenge value can be determined from the length 898 of the data field minus the length of the id (always 1 octet) and the 899 length of the response field (always 49 octets). 901 To perform the authentication, the server will use a combination of 902 MD4 and DES on the user's secret and the challenge, as defined in RFC 903 2433 [RFC2433] and then compare the resulting value with the 904 response. The REPLY from the server MUST be a PASS or FAIL. 906 For best practices, please refer to RFC 2433 [RFC2433] . The TACACS+ 907 server MUST reject authentications where the challenge deviates from 908 8 bytes as defined in the RFC. 910 4.4.2.5. MS-CHAP v2 login 912 action = TAC_PLUS_AUTHEN_LOGIN 913 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 914 minor_version = 0x1 916 The entire exchange MUST consist of a single START packet and a 917 single REPLY. The START packet MUST contain the username in the user 918 field and the data field will be a concatenation of the PPP id, the 919 MS-CHAP challenge and the MS-CHAP response. 921 The length of the challenge value can be determined from the length 922 of the data field minus the length of the id (always 1 octet) and the 923 length of the response field (always 49 octets). 925 To perform the authentication, the server will use the algorithm 926 specified RFC 2759 [RFC2759] on the user's secret and challenge and 927 then compare the resulting value with the response. The REPLY from 928 the server MUST be a PASS or FAIL. 930 For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] 931 . The TACACS+ server MUST rejects authentications where the challenge 932 deviates from 16 bytes as defined in the RFC. 934 4.4.2.6. Enable Requests 936 action = TAC_PLUS_AUTHEN_LOGIN 937 priv_lvl = implementation dependent 938 authen_type = not used 939 service = TAC_PLUS_AUTHEN_SVC_ENABLE 941 This is an ENABLE request, used to change the current running 942 privilege level of a user. The exchange MAY consist of multiple 943 messages while the server collects the information it requires in 944 order to allow changing the principal's privilege level. This 945 exchange is very similar to an ASCII login (Section 4.4.2.1) . 947 In order to readily distinguish enable requests from other types of 948 request, the value of the authen_service field MUST be set to 949 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 950 set to this value when requesting any other operation. 952 4.4.2.7. ASCII change password request 954 action = TAC_PLUS_AUTHEN_CHPASS 955 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 957 This exchange consists of multiple messages while the server collects 958 the information it requires in order to change the user's password. 959 It is very similar to an ASCII login. The status value 960 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 961 "new" password. It MAY be sent multiple times. When requesting the 962 "old" password, the status value MUST be set to 963 TAC_PLUS_AUTHEN_STATUS_GETDATA. 965 4.4.3. Aborting an Authentication Session 967 The client may prematurely terminate a session by setting the 968 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 969 flag is set, the data portion of the message may contain an ASCII 970 message explaining the reason for the abort. This information will 971 be handled by the server according to the requirements of the 972 deployment. The session is terminated, for more details about 973 session termination, refer to section (Section 3.4) 975 In the case of PALL, FAIL or ERROR, the server can insert a message 976 into server_msg to be displayed to the user. 978 The Draft `The Draft' [TheDraft] defined a mechanism to direct 979 authentication requests to an alternative server. This mechanism is 980 regarded as insecure, is deprecated, and not covered here. The 981 client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as 982 TAC_PLUS_AUTHEN_STATUS_FAIL 984 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 985 indicating that it is experiencing an unrecoverable error and the 986 authentication will proceed as if that host could not be contacted. 987 The data field may contain a message to be printed on an 988 administrative console or log. 990 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 991 authentication sequence is restarted with a new START packet from the 992 client, with new session Id, and seq_no set to 1. This REPLY packet 993 indicates that the current authen_type value (as specified in the 994 START packet) is not acceptable for this session. The client may try 995 an alternative authen_type. 997 If a client does not implement TAC_PLUS_AUTHEN_STATUS_RESTART option, 998 then it MUST process the response as if the status was 999 TAC_PLUS_AUTHEN_STATUS_FAIL. 1001 5. Authorization 1003 In the TACACS+ Protocol, authorization is the action of determining 1004 what a user is allowed to do. Generally authentication precedes 1005 authorization, though it is not mandatory that a client use the same 1006 service for authentication that it will use for authorization. An 1007 authorization request may indicate that the user is not authenticated 1008 (we don't know who they are). In this case it is up to the server to 1009 determine, according to its configuration, if an unauthenticated user 1010 is allowed the services in question. 1012 Authorization does not merely provide yes or no answers, but it may 1013 also customize the service for the particular user. A common use of 1014 authorization is to provision a shell session when a user first logs 1015 into a device to administer it. The TACACS+ server might respond to 1016 the request by allowing the service, but placing a time restriction 1017 on the login shell. For a list of common attributes used in 1018 authorization, see the Authorization Attributes section (Section 7.2) 1019 . 1021 In the TACACS+ protocol an authorization is always a single pair of 1022 messages: a REQUEST from the client followed by a REPLY from the 1023 server. 1025 The authorization REQUEST message contains a fixed set of fields that 1026 indicate how the user was authenticated and a variable set of 1027 arguments that describe the services and options for which 1028 authorization is requested. 1030 The REPLY contains a variable set of response arguments (attribute- 1031 value pairs) that can restrict or modify the client's actions. 1033 5.1. The Authorization REQUEST Packet Body 1034 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 1035 +----------------+----------------+----------------+----------------+ 1036 | authen_method | priv_lvl | authen_type | authen_service | 1037 +----------------+----------------+----------------+----------------+ 1038 | user_len | port_len | rem_addr_len | arg_cnt | 1039 +----------------+----------------+----------------+----------------+ 1040 | arg_1_len | arg_2_len | ... | arg_N_len | 1041 +----------------+----------------+----------------+----------------+ 1042 | user ... 1043 +----------------+----------------+----------------+----------------+ 1044 | port ... 1045 +----------------+----------------+----------------+----------------+ 1046 | rem_addr ... 1047 +----------------+----------------+----------------+----------------+ 1048 | arg_1 ... 1049 +----------------+----------------+----------------+----------------+ 1050 | arg_2 ... 1051 +----------------+----------------+----------------+----------------+ 1052 | ... 1053 +----------------+----------------+----------------+----------------+ 1054 | arg_N ... 1055 +----------------+----------------+----------------+----------------+ 1057 authen_method 1059 This indicates the authentication method used by the client to 1060 acquire the user information. As this information is not always 1061 subject to verification, it is recommended that this field is 1062 ignored. 1064 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1066 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1068 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1070 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1072 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1074 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1076 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1078 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1080 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1081 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1083 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1085 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1086 password associated with the terminal line used to gain access. 1087 LOCAL is a client local user database. ENABLE is a command that 1088 authenticates in order to grant new privileges. TACACSPLUS is, of 1089 course, TACACS+. GUEST is an unqualified guest authentication, such 1090 as an ARAP guest login. RADIUS is the Radius authentication 1091 protocol. RCMD refers to authentication provided via the R-command 1092 protocols from Berkeley Unix. 1094 priv_lvl 1096 This field is used in the same way as the priv_lvl field in 1097 authentication request and is described in the Privilege Level 1098 section (Section 8) below. It indicates the users current privilege 1099 level. 1101 authen_type 1103 This field coresponds to the authen_type field in the authentication 1104 section (Section 4) above. It indicates the type of authentication 1105 that was performed. If this information is not available, then the 1106 client will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. 1107 This value is valid only in authorization and accounting requests. 1109 authen_service 1111 This field is the same as the authen_service field in the 1112 authentication section (Section 4) above. It indicates the service 1113 through which the user authenticated. 1115 user, user_len 1117 This field contains the user's account name. The user_len MUST 1118 indicate the length of the user field, in bytes. 1120 port, port_len 1122 This field matches the port field in the authentication section 1123 (Section 4) above. The port_len indicates the length of the port 1124 field, in bytes. 1126 rem_addr, rem_addr_len 1127 This field matches the rem_addr field in the authentication section 1128 (Section 4) above. The rem_addr_len indicates the length of the port 1129 field, in bytes. 1131 arg_cnt 1133 The number of authorization arguments to follow 1135 arg_1 ... arg_N, arg_1_len .... arg_N_len 1137 The arguments are the primary elements of the authorization 1138 interaction. In the request packet they describe the specifics of 1139 the authorization that is being requested. Each argument is encoded 1140 in the packet as a single arg filed (arg_1... arg_N) with a 1141 corresponding length fields (which indicates the length of each 1142 argument in bytes). 1144 The authorization arguments in both the REQUEST and the REPLY are 1145 attribute-value pairs. The attribute and the value are in a single 1146 printable US-ASCII string and are separated by either a "=" (0X3D) or 1147 a "*" (0X2A). The equals sign indicates a mandatory argument. The 1148 asterisk indicates an optional one. 1150 It is not legal for an attribute name to contain either of the 1151 separators. It is legal for attribute values to contain the 1152 separators. This means that the arguments must be parsed until the 1153 first separator is encountered, all characters in the argument, after 1154 this separator, are interpreted as the argument value. 1156 Optional arguments are ones that may be disregarded by either client 1157 or server. Mandatory arguments require that the receiving side can 1158 handle the attribute, that is: its implementation and configuration 1159 includes the details of how to act on it. If the client receives a 1160 mandatory argument that it cannot handle, it MUST consider the 1161 authorization to have failed. It is legal to send an attribute-value 1162 pair with a zero length value. 1164 Attribute-value strings are not NULL terminated, rather their length 1165 value indicates their end. The maximum length of an attribute-value 1166 string is 255 characters. The minimum is two characters (one name- 1167 value character and the separator) 1169 Though the attributes allow extensibility, a common core set of 1170 authorization attributes SHOULD be supported by clients and servers, 1171 these are listed in the Authorization Attributes (Section 7.2) 1172 section below. 1174 5.2. The Authorization REPLY Packet Body 1176 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 1177 +----------------+----------------+----------------+----------------+ 1178 | status | arg_cnt | server_msg len | 1179 +----------------+----------------+----------------+----------------+ 1180 + data_len | arg_1_len | arg_2_len | 1181 +----------------+----------------+----------------+----------------+ 1182 | ... | arg_N_len | server_msg ... 1183 +----------------+----------------+----------------+----------------+ 1184 | data ... 1185 +----------------+----------------+----------------+----------------+ 1186 | arg_1 ... 1187 +----------------+----------------+----------------+----------------+ 1188 | arg_2 ... 1189 +----------------+----------------+----------------+----------------+ 1190 | ... 1191 +----------------+----------------+----------------+----------------+ 1192 | arg_N ... 1193 +----------------+----------------+----------------+----------------+ 1195 status This field indicates the authorization status 1197 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1199 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1201 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1203 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1205 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1207 server_msg, server_msg_len 1209 This is a printable US-ASCII string that may be presented to the 1210 user. The server_msg_len indicates the length of the server_msg 1211 field, in bytes. 1213 data, data_len 1215 This is a printable US-ASCII string that may be presented on an 1216 administrative display, console or log. The decision to present this 1217 message is client specific. The data_len indicates the length of the 1218 data field, in bytes. 1220 arg_cnt 1221 The number of authorization arguments to follow. 1223 arg_1 ... arg_N, arg_1_len .... arg_N_len 1225 The arguments describe the specifics of the authorization that is 1226 being requested. For details of the content of the args, refer to: 1227 Authorization Attributes (Section 7.2) section below. Each argument 1228 is encoded in the packet as a single arg field (arg_1... arg_N) with 1229 a corresponding length fields (which indicates the length of each 1230 argument in bytes). 1232 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested 1233 authorization MUST be denied. 1235 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1236 arguments specified in the request are authorized and the arguments 1237 in the response MUST be applied according to the rules described 1238 above. 1240 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client 1241 MUST use the authorization attribute-value pairs (if any) in the 1242 response, instead of the authorization attribute-value pairs from the 1243 request. 1245 To approve the authorization with no modifications, the server sets 1246 the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. 1248 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1249 on the server. For the differences between ERROR and FAIL, refer to 1250 section Session Completion (Section 3.4) . None of the arg values 1251 have any relevance if an ERROR is set, and must be ignored. 1253 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1254 arg_cnt MUST be 0. In that case, the actions to be taken and the 1255 contents of the data field are identical to the 1256 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1258 6. Accounting 1260 Accounting is typically the third action after authentication and 1261 authorization. But again, neither authentication nor authorization 1262 is required. Accounting is the action of recording what a user is 1263 doing, and/or has done. Accounting in TACACS+ can serve two 1264 purposes: It may be used as an auditing tool for security services. 1265 It may also be used to account for services used, such as in a 1266 billing environment. To this end, TACACS+ supports three types of 1267 accounting records. Start records indicate that a service is about 1268 to begin. Stop records indicate that a service has just terminated, 1269 and Update records are intermediate notices that indicate that a 1270 service is still being performed. TACACS+ accounting records contain 1271 all the information used in the authorization records, and also 1272 contain accounting specific information such as start and stop times 1273 (when appropriate) and resource usage information. A list of 1274 accounting attributes is defined in the accounting section 1275 (Section 6) . 1277 6.1. The Account REQUEST Packet Body 1279 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 1280 +----------------+----------------+----------------+----------------+ 1281 | flags | authen_method | priv_lvl | authen_type | 1282 +----------------+----------------+----------------+----------------+ 1283 | authen_service | user_len | port_len | rem_addr_len | 1284 +----------------+----------------+----------------+----------------+ 1285 | arg_cnt | arg_1_len | arg_2_len | ... | 1286 +----------------+----------------+----------------+----------------+ 1287 | arg_N_len | user ... 1288 +----------------+----------------+----------------+----------------+ 1289 | port ... 1290 +----------------+----------------+----------------+----------------+ 1291 | rem_addr ... 1292 +----------------+----------------+----------------+----------------+ 1293 | arg_1 ... 1294 +----------------+----------------+----------------+----------------+ 1295 | arg_2 ... 1296 +----------------+----------------+----------------+----------------+ 1297 | ... 1298 +----------------+----------------+----------------+----------------+ 1299 | arg_N ... 1300 +----------------+----------------+----------------+----------------+ 1302 flags 1304 This holds bitmapped flags. 1306 TAC_PLUS_ACCT_FLAG_START := 0x02 1308 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1310 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1312 All other fields are defined in the authorization and authentication 1313 sections above and have the same semantics. They provide details for 1314 the conditions on the client, and authentication context, so that 1315 these details may be logged for accounting purposes. 1317 See section 12 Accounting Attribute-value Pairs for the dictionary of 1318 attributes relevant to accounting. 1320 6.2. The Accounting REPLY Packet Body 1322 The purpose of accounting is to record the action that has occurred 1323 on the client. The server MUST reply with success only when the 1324 accounting request has been recorded. If the server did not record 1325 the accounting request then it MUST reply with ERROR. 1327 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 1328 +----------------+----------------+----------------+----------------+ 1329 | server_msg len | data_len | 1330 +----------------+----------------+----------------+----------------+ 1331 | status | server_msg ... 1332 +----------------+----------------+----------------+----------------+ 1333 | data ... 1334 +----------------+ 1336 status 1338 This is the return status. Values are: 1340 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1342 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1344 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1346 server_msg, server_msg_len 1348 This is a printable US-ASCII string that may be presented to the 1349 user. The server_msg_len indicates the length of the server_msg 1350 field, in bytes. 1352 data, data_len 1354 This is a printable US-ASCII string that may be presented on an 1355 administrative display, console or log. The decision to present this 1356 message is client specific. The data_len indicates the length of the 1357 data field, in bytes. 1359 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1360 to be taken and the contents of the data field are identical to the 1361 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1363 TACACS+ accounting is intended to record various types of events on 1364 clients, for example: login sessions, command entry, and others as 1365 required by the client implementation. These events are collectively 1366 referred to in `The Draft' [TheDraft] as "tasks". 1368 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1369 accounting message. Start messages will only be sent once when a 1370 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1371 a stop record and that the task has terminated. The 1372 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1374 Summary of Accounting Packets 1376 +----------+-------+-------+-------------+-------------------------+ 1377 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1378 +----------+-------+-------+-------------+-------------------------+ 1379 | 0 | 0 | 0 | 0 | INVALID | 1380 | 0 | 0 | 1 | 2 | Start Accounting Record | 1381 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1382 | 0 | 1 | 1 | 6 | INVALID | 1383 | 1 | 0 | 0 | 8 | Watchdog, no update | 1384 | 1 | 0 | 1 | A | Watchdog, with update | 1385 | 1 | 1 | 0 | C | INVALID | 1386 | 1 | 1 | 1 | E | INVALID | 1387 +----------+-------+-------+-------------+-------------------------+ 1389 The START and STOP flags are mutually exclusive. 1391 The WATCHDOG flag is used by the client to communicate ongoing status 1392 of a long-running task. Update records are sent at the client's 1393 discretion. The frequency of the update depends upon the intended 1394 application: A watchdog to provide progress indication will require 1395 higher frequency than a daily keep-alive. When the WATCHDOG flag is 1396 set along with the START flag, it indicates that the update record 1397 provides additional or updated arguments from the original START 1398 record. If the START flag is not set, then this indicates only that 1399 task is still running, and no new information is provided (servers 1400 MUST ignore any arguments). The STOP flag MUST NOT be set in 1401 conjunction with the WATCHDOG flag. 1403 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1404 requests an INVALID option. 1406 7. Attribute-Value Pairs 1408 TACACS+ is intended to be an extensible protocol. The attributes 1409 used in Authorization and Accounting are not limited by this 1410 document. Some attributes are defined below for common use cases, 1411 clients MUST use these attributes when supporting the corresponding 1412 use cases. 1414 7.1. Value Encoding 1416 All attribute values are encoded as printable US-ASCII strings. The 1417 following type representations SHOULD be followed 1419 Numeric 1421 All numeric values in an attribute-value string are provided as 1422 decimal printable US-ASCII numbers, unless otherwise stated. 1424 Boolean 1426 All boolean attributes are encoded as printable US-ASCII with values 1427 "true" or "false". 1429 IP-Address 1431 It is recommended that hosts be specified as a IP address so as to 1432 avoid any ambiguities. IPV4 address are specified as US-ASCII octet 1433 numerics separated by dots ('.'), IPV6 address text representation 1434 defined in RFC 4291. 1436 Date Time 1438 Absolute date/times are specified in seconds since the epoch, 12:00am 1439 Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is 1440 specified. Stardate is canonically inconsistent and so SHOULD NOT be 1441 used. 1443 String 1445 Many values have no specific type representation and so are 1446 interpreted as plain strings. 1448 Empty Values 1450 Attributes may be submitted with no value, in which case they consist 1451 of the name and the mandatory or optional separator. For example, 1452 the attribute "cmd" which has no value is transmitted as a string of 1453 four characters "cmd=" 1455 7.2. Authorization Attributes 1457 service (String) 1459 The primary service. Specifying a service attribute indicates that 1460 this is a request for authorization or accounting of that service. 1462 For example: "shell", "tty-server", "connection", "system" and 1463 "firewall". This attribute MUST always be included. 1465 protocol (String) 1467 the protocol field may be used to indicate a subset of a service. 1469 cmd (String) 1471 a shell (exec) command. This indicates the command name of the 1472 command that is to be run. The "cmd" attribute MUST be specified if 1473 service equals "shell". 1475 Authorization of shell commands is a common use-case for the TACACS+ 1476 protocol. Command Authorization generally takes one of two forms: 1477 session-based and command-based. 1479 For session-based shell authorization, the "cmd" argument will have 1480 an empty value. The client determines which commands are allowed in 1481 a session according to the arguments present in the authorization. 1483 In command-based authorization, the client requests that the server 1484 determine whether a command is allowed by making an authorization 1485 request for each command. The "cmd" argument will have the command 1486 name as its value. 1488 cmd-arg (String) 1490 an argument to a shell (exec) command. This indicates an argument 1491 for the shell command that is to be run. Multiple cmd-arg attributes 1492 may be specified, and they are order dependent. 1494 acl (Numeric) 1496 printable US-ASCII number representing a connection access list. 1497 Applicable only to session-based shell authorization. 1499 inacl (String) 1501 printable US-ASCII identifier for an interface input access list. 1503 outacl (String) 1505 printable US-ASCII identifier for an interface output access list. 1507 addr (IP-Address) 1509 a network address 1510 addr-pool (String) 1512 The identifier of an address pool from which the client can assign an 1513 address. 1515 routing (Boolean) 1517 Specifies whether routing information is to be propagated to, and 1518 accepted from this interface. 1520 route (String) 1522 Indicates a route that is to be applied to this interface. Values 1523 MUST be of the form " []". If a 1524 is not specified, the resulting route is via the 1525 requesting peer. 1527 timeout (Numeric) 1529 an absolute timer for the connection (in minutes). A value of zero 1530 indicates no timeout. 1532 idletime (Numeric) 1534 an idle-timeout for the connection (in minutes). A value of zero 1535 indicates no timeout. 1537 autocmd (String) 1539 an auto-command to run. Applicable only to session-based shell 1540 authorization. 1542 noescape (Boolean) 1544 Prevents user from using an escape character. Applicable only to 1545 session-based shell authorization. 1547 nohangup (Boolean) 1549 Boolean. Do not disconnect after an automatic command. Applicable 1550 only to session-based shell authorization. 1552 priv-lvl (Numeric) 1554 privilege level to be assigned. Please refer to the Privilege Level 1555 section (Section 8) below. 1557 remote_user (String) 1558 remote userid (authen_method must have the value 1559 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1560 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1561 remote_user and remote_host attributes will provide the remote user 1562 and host information to enable rhost style authorization. The 1563 response may request that a privilege level be set for the user. 1565 remote_host (String) 1567 remote host (authen_method must have the value 1568 TAC_PLUS_AUTHEN_METH_RCMD) 1570 7.3. Accounting Attributes 1572 The following attributes are defined for TACACS+ accounting only. 1573 They MUST precede any attribute-value pairs that are defined in the 1574 authorization section (Section 5) above. 1576 task_id (String) 1578 Start and stop records for the same event MUST have matching task_id 1579 attribute values. The client MUST ensure that active task_ids are 1580 not duplicated: a client MUST NOT reuse a task_id a start record 1581 until it has sent a stop record for that task_id. Servers MUST not 1582 make assumptions about the format of a task_id. 1584 start_time (Date Time) 1586 The time the action started (in seconds since the epoch.). 1588 stop_time (Date Time) 1590 The time the action stopped (in seconds since the epoch.) 1592 elapsed_time (Numeric) 1594 The elapsed time in seconds for the action. 1596 timezone (String) 1598 The timezone abbreviation for all timestamps included in this packet. 1600 event (String) 1602 Used only when "service=system". Current values are "net_acct", 1603 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1604 These indicate system-level changes. The flags field SHOULD indicate 1605 whether the service started or stopped. 1607 reason (String) 1609 Accompanies an event attribute. It describes why the event occurred. 1611 bytes (Numeric) 1613 The number of bytes transferred by this action 1615 bytes_in (Numeric) 1617 The number of bytes transferred by this action from the endstation to 1618 the client port 1620 bytes_out (Numeric) 1622 The number of bytes transferred by this action from the client to the 1623 endstation port 1625 paks (Numeric) 1627 The number of packets transferred by this action. 1629 paks_in (Numeric) 1631 The number of input packets transferred by this action from the 1632 endstation to the client port. 1634 paks_out (Numeric) 1636 The number of output packets transferred by this action from the 1637 client port to the endstation. 1639 err_msg (String) 1641 A printable US-ASCII string describing the status of the action. 1643 8. Privilege Levels 1645 The TACACS+ Protocol supports flexible authorization schemes through 1646 the extensible attributes. 1648 One scheme is built into the protocol and has been extensively used 1649 for Session-based shell authorization: Privilege Levels. Privilege 1650 Levels are ordered values from 0 to 15 with each level being a 1651 superset of the next lower value. Configuration and implementation 1652 of the client will map actions (such as the permission to execute of 1653 specific commands) to different privilege levels. Pre-defined values 1654 are: 1656 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1658 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1660 TAC_PLUS_PRIV_LVL_USER := 0x01 1662 TAC_PLUS_PRIV_LVL_MIN := 0x00 1664 A Privilege level can be assigned to a shell (EXEC) session when it 1665 starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will permit 1666 the actions associated with this level to be executed. This 1667 privilege level is returned by the Server in a session-based shell 1668 authorization (when "service" equals "shell" and "cmd" is empty). 1669 When a user required to perform actions that are mapped to a higher 1670 privilege level, then an ENABLE type reauthentication can be 1671 initiated by the client. The client will insert the required 1672 privilege level into the authentication header for enable 1673 authentication request. 1675 The use of Privilege levels to determine session-based access to 1676 commands and resources is not mandatory for clients. Although the 1677 privilege level scheme is widely supported, its lack of flexibility 1678 in requiring a single monotonic hierarchy of permissions means that 1679 other session-based command authorization schemes have evolved, and 1680 so it is no longer mandatory for clients to use it. However, it is 1681 still common enough that it SHOULD be supported by servers. 1683 9. TACACS+ Security Considerations 1685 The original TACACS+ Draft[1] from 1998 did not address all of the 1686 key security concerns which are considered when designing modern 1687 standards. This section addresses known limitations and concerns 1688 which will impact overall security of the protocol and systems where 1689 this protocol is deployed to manage central authentication, 1690 authorization or accounting for network device administration. 1692 Multiple implementations of the protocol described in the draft[1] 1693 have been deployed. As the protocol was never standardised, current 1694 implementations may be incompatible in non-obvious ways, giving rise 1695 to additional security risks about which authors might not be aware 1696 of. This section does not claim to enumerate all possible security 1697 vulnerabilities. 1699 9.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 encrypted which leaves all header 1711 fields open to trivial modification by the man-in-the-middle 1712 attacker. 1714 Invalid or misleading values may be inserted by the man-in-the- 1715 middle attacker in various fields at known offsets to try and 1716 circumvent the authentication or authorization checks even inside 1717 the encrypted body. 1719 While the protocol provides some measure of transport privacy, it is 1720 vulnerable to at least the following attacks: 1722 Brute force attacks exploiting increased efficiency of MD5 digest 1723 computation. 1725 Known plaintext attacks which may decrease the cost of brute force 1726 attack. 1728 Chosen plaintext attacks which may decrease the cost of a brute 1729 force attack. 1731 No forward secrecy. 1733 Even though, to the best knowledge of authors, this method of 1734 encryption wasn't rigorously tested, authors feel that enough 1735 information is available that it is best referred to as "obfuscation" 1736 and not "encryption". 1738 For example, a "session_id" can be replaced by an alternate one, 1739 which could allow an unprivileged administrator to "steal" the 1740 authorization from a session for a privileged administrator. An 1741 attacker could also update the "flags" field to indicate that one or 1742 the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG, 1743 which would subvert the obfuscation mechanism. 1745 For these reasons, users deploying TACACS+ protocol in their 1746 environments MUST limit access to known clients and MUST control the 1747 security of the entire transmission path. Attacks who can guess the 1748 key or otherwise break the obfuscation will gain unrestricted and 1749 undetected access to all TACACS+ traffic. The security risk of such 1750 attack succeeding against a centralised AAA system like TACACS+ 1751 cannot be overstated. 1753 The following parts of this section enumerate only the session- 1754 specific risks which are in addition to general risk associated with 1755 bare obfuscation and lack of integrity checking. 1757 9.2. Security of Authentication Sessions 1759 Authentication sessions SHOULD NOT be used via insecure transport as 1760 the man-in-the-middle attack may completely subvert them. Even CHAP, 1761 which may be considered resistant to password interception, is unsafe 1762 as it does not protect the username from a trivial man-in-the-middle 1763 attack. 1765 Section 4.4.3 permits the redirection of a session to another server 1766 via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this 1767 process, the secret key for a new server can be sent to the client. 1768 This public exchange of secret keys means that once one session is 1769 broken, it may be possible to leverage that key to attacking 1770 connections to other servers. This option MUST NOT be used outside a 1771 secured deployment of protocol clients or outside of secure 1772 transport. 1774 9.3. Security of Authorization Sessions 1776 Authorization sessions MUST be used via secure transport only as it's 1777 trivial to execute a successful man-in-the-middle attacks that 1778 changes well-known plaintext in either requests or responses. 1780 As an example, take the field "authen_method". It's not unusual in 1781 actual deployments to authorize all commands received via the device 1782 local serial port (a console port) as that one is usually considered 1783 secure by virtue of the device located in a physically secure 1784 location. If an administrator would configure the authorization 1785 system to allow all commands entered by the user on a local console 1786 to aid in troubleshooting, that would give all access to all commands 1787 to any attacker that would be able to change the "authen_method" from 1788 TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In 1789 this regard, the obfuscation provided by the protocol itself wouldn't 1790 help much, because: 1792 Lack of integrity means that any byte in the payload may be 1793 changed w/o either side detecting the change. 1795 Known plaintext means that an attacker would know with certainty 1796 which octet is the target of the attack (in this case, 1st octet 1797 after the header). 1799 In combination with known plaintext, the attacker can determine 1800 with certainty the value of the crypto-pad octet used to obfuscate 1801 the original octet. 1803 9.4. Security of Accounting Sessions 1805 Accounting sessions are not directly involved in authentication or 1806 authorizing operations on the device. However, man-in-the-middle 1807 attacker may do any of the following: 1809 Replace accounting data with new valid or garbage which prevents 1810 to provide distraction or hide information related to their 1811 authentication and/or authorization attack attempts. 1813 Try and poison accounting log with entries designed to make 1814 systems behave in unintended ways (which includes TACACS+ server 1815 and any other systems that would manage accounting entries). 1817 In addition to these direct manipulations, different client 1818 implementations pass different fidelity of accounting data. Some 1819 vendors have been observed in the wild that pass sensitive data like 1820 passwords, encryption keys and similar as part of the accounting log. 1821 Due to lack of strong encryption with perfect forward secrecy, this 1822 data may be revealed in future, leading to a security incident. 1824 9.5. TACACS+ Deployment Recommendations 1826 Due to above observations about the TACACS+ protocol, it is critical 1827 to only deploy it using secure transport. A secure transport for 1828 TACACS+ is defined as any means that ensure privacy and integrity of 1829 all data passed between clients and servers. There are multiple 1830 means of achieving this, all of them beyond the scope of this 1831 document. 1833 Symmetric encryption key represents a possible attack vector at the 1834 protocol itself. For this reason, servers SHOULD accept only those 1835 network connection attempts that arrive from known clients. This 1836 limits the exposure and prevents remote brute force attacks from 1837 unknown clients. 1839 Due to the security deficiencies of the protocol, it is critical that 1840 it be deployed in a secure manner. The following recommendations are 1841 made for those deploying and configuring TACACS+ as a solution for 1842 device administration: 1844 Secure the Deployment: TACACS+ MUST BE deployed over networks 1845 which ensure an appropriate privacy and integrity of the 1846 communication. Definition of an appropriate level of privacy and 1847 integrity is organisation-dependent What is appropriate level of 1848 The way this is ensured will depend upon the organisational means: 1849 a dedicated and secure management network where available in 1850 enterprise deployments, or IPsec where dedicated networks are not 1851 available. 1853 Always set a secret key (recommended minimum 14 characters) on the 1854 client and server when configuring the connection between them. 1856 Servers MUST be configured with a list of known clients. Servers 1857 MUST be configured to reject requests from clients not on the 1858 list. A unique secret key SHOULD be configured for every 1859 individual client. 1861 Implementors should consider shared secrets to be sensitive data, 1862 and managed securely. 1864 Restrict to TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type where 1865 possible. Use other options only when unavoidable due to 1866 requirements of identity/password systems. 1868 Servers SHOULD be restricted to requiring TACACS+ authentication 1869 for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS 1870 is used). 1872 Avoid the use of the redirection mechanism. 1873 TAC_PLUS_AUTHEN_STATUS_FOLLOW, specifically avoid the option to 1874 send secret keys in the server list. 1876 Take case when applying extensions to the dictionary of 1877 authorization/accounting arguments. Ensure that the client and 1878 server use of new argument names are consistent. 1880 9.6. TACACS+ Client Implementation Recommendations 1882 When implementing TACACS+ Clients it is recommended: 1884 Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks 1885 that are considered secure. 1887 Ignore redirects to hosts which are outside of the pre-configured 1888 range or list. A client SHOULD ignore any key provided via 1889 TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a 1890 preconfigured key for that host. 1892 If receiving an unknown mandatory authorization attribute, behave 1893 as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. For full 1894 details, refer to (Authorization attributes section). 1896 9.7. TACACS+ Server Implementation Recommendations 1898 When implementing TACACS+ Servers, it is recommended: 1900 Server SHOULD reject all connections which have the 1901 TAC_PLUS_UNENCRYPTED_FLAG with applicable ERROR response for type 1902 of packet. 1904 Servers MUST permit configuration of secret keys per individual 1905 client. Servers SHOULD warn administrators if secret keys are not 1906 unique per client. 1908 On detection of an invalid shared secret: Servers SHOULD NOT 1909 accept any new sessions on a connection, and terminate the 1910 connection on completion of any sessions previously established 1911 with a valid shared secret. 1913 Allow the administrator to mandate : - TAC_PLUS_AUTHEN_TYPE_CHAP 1914 for authen_type - TAC_PLUS_AUTHEN_METH_TACACSPLUS for 1915 authen_method in authorization - Minimum length for shared secrets 1917 9.8. TACACS+ Security and Operational Concerns 1919 This section identifies some of the known security and operational 1920 concerns. It is important to acknowledge that TACACS+ on its own 1921 does not provide modern levels of security, and that it MUST be used 1922 within a secure deployment. 1924 The "encryption" is based upon MD5. In modern terms this can be 1925 regarded merely as "obfuscation". 1927 Only the packet body (not header) is obfuscated. For example, 1928 session_id, flags containing TAC_PLUS_UNENCRYPTED_FLAG is exposed 1929 in cleartext. 1931 Support of insecure authentication protocols such as plaintext, 1932 MS-CHAP. 1934 Difficulty to correlate authentication, authorization, and 1935 accounting requests for a single unit of end client activity. 1937 Potential confusion between clients and servers from different 1938 vendors of the meaning of specific argument attributes. 1940 Potential confusion between clients and servers from different 1941 vendors of the meaning of specific commands. 1943 In summary: It is strongly advised that TACACS+ MUST be used within a 1944 secure deployment. Failure to do so may impact overall network 1945 security. 1947 10. Acknowledgements 1949 The Authors would like to thank the following reviewers whose 1950 comments and contributions made considerable improvements to the 1951 document: Alan DeKok (who provided significant insights and 1952 recommendations on all aspects of documenting the protocol), 1953 Alexander Clouter, Chris Janicki, Tom Petch, Robert Drake 1955 The Authors would also like to thanks the support from the OPSAWG 1956 Chairs and advisors. 1958 11. References 1960 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1961 April 1992. 1963 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1964 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1965 . 1967 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1968 "Randomness Recommendations for Security", RFC 1750, 1969 DOI 10.17487/RFC1750, December 1994, 1970 . 1972 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1973 RFC 2433, DOI 10.17487/RFC2433, October 1998, 1974 . 1976 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1977 RFC 2759, DOI 10.17487/RFC2759, January 2000, 1978 . 1980 [TheDraft] 1981 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 1982 1.78", June 1997, 1983 . 1985 Authors' Addresses 1986 Thorsten Dahm 1987 Google Inc 1988 1600 Amphitheatre Parkway 1989 Mountain View, CA 94043 1990 US 1992 EMail: thorstendlux@google.com 1994 Andrej Ota 1995 Google Inc 1996 1600 Amphitheatre Parkway 1997 Mountain View, CA 94043 1998 US 2000 EMail: aota@google.com 2002 Douglas C. Medway Gash 2003 Cisco Systems, Inc. 2004 170 West Tasman Dr. 2005 San Jose, CA 95134 2006 US 2008 Phone: +44 0208 8244508 2009 EMail: dcmgash@cisco.com 2011 David Carrel 2012 vIPtela, Inc. 2013 1732 North First St. 2014 San Jose, CA 95112 2015 US 2017 EMail: dcarrel@viptela.com 2019 Lol Grant 2021 EMail: lol.grant@gmail.com