idnits 2.17.1 draft-ietf-opsawg-tacacs-08.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 (February 19, 2018) is 2255 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1690 ** 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: August 23, 2018 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 February 19, 2018 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-08 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 August 23, 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 originally conceived 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 have 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 authroization 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 try 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 implmentation 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 (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. An authen_service value of NONE is only 619 to be used when none of the other authen_service values are 620 appropriate. ENABLE may be requested independently, no requirements 621 for previous authentications or authorizations are imposed by the 622 protocol. 624 Other options are included for legacy/backwards compatibility. 626 user, user_len 628 The username is optional in this packet, depending upon the class of 629 authentication. If it is absent, the client MUST set user_len to 0. 630 If included, the user_len indicates the length of the user field, in 631 bytes. 633 port, port_len 635 The printable US-ASCII name of the client port on which the 636 authentication is taking place, and its length in bytes. The value 637 of this field is client specific. (For example, Cisco uses "tty10" 638 to denote the tenth tty line and "Async10" to denote the tenth async 639 interface). The port_len indicates the length of the port field, in 640 bytes. 642 rem_addr, rem_addr_len 644 A printable US-ASCII string indicating the remote location from which 645 the user has connected to the client. It is intended to hold a 646 network address if the user is connected via a network, a caller ID 647 is the user is connected via ISDN or a POTS, or any other remote 648 location information that is available. This field is optional 649 (since the information may not be available). The rem_addr_len 650 indicates the length of the user field, in bytes. 652 data, data_len 654 This field is used to send data appropriate for the action and 655 authen_type. It is described in more detail in the section Common 656 Authentication flows (Section 4.4.2) . The data_len indicates the 657 length of the data field, in bytes. 659 4.2. The Authentication REPLY Packet Body 661 The TACACS+ server sends only one type of authentication packet (a 662 REPLY packet) to the client. 664 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 665 +----------------+----------------+----------------+----------------+ 666 | status | flags | server_msg_len | 667 +----------------+----------------+----------------+----------------+ 668 | data_len | server_msg ... 669 +----------------+----------------+----------------+----------------+ 670 | data ... 671 +----------------+----------------+ 673 status 675 The current status of the authentication. Legal values are: 677 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 679 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 681 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 683 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 685 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 687 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 689 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 691 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 693 flags 695 Bitmapped flags that modify the action to be taken. The following 696 values are defined: 698 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 700 server_msg, server_msg_len 702 A message to be displayed to the user. This field is optional. The 703 printable US-ASCII charset MUST be used. The server_msg_len 704 indicates the length of the server_msg field, in bytes. 706 data, data_len 708 This field holds data that is a part of the authentication exchange 709 and is intended for the client, not the user. Examples of its use 710 are shown in the section Common Authentication flows (Section 4.4.2) 711 . The data_len indicates the length of the data field, in bytes. 713 4.3. The Authentication CONTINUE Packet Body 715 This packet is sent from the client to the server following the 716 receipt of a REPLY packet. 718 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 719 +----------------+----------------+----------------+----------------+ 720 | user_msg len | data_len | 721 +----------------+----------------+----------------+----------------+ 722 | flags | user_msg ... 723 +----------------+----------------+----------------+----------------+ 724 | data ... 725 +----------------+ 727 user_msg, user_msg_len 729 This field is the string that the user entered, or the client 730 provided on behalf of the user, in response to the server_msg from a 731 REPLY packet. The user_len indicates the length of the user field, 732 in bytes. 734 data, data_len 736 This field carries information that is specific to the action and the 737 authen_type for this session. Valid uses of this field are described 738 below. The data_len indicates the length of the data field, in 739 bytes. 741 flags 743 This holds the bitmapped flags that modify the action to be taken. 744 The following values are defined: 746 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 748 4.4. Description of Authentication Process 750 The action, authen_type and authen_service fields (described above) 751 combine to indicate what kind of authentication is to be performed. 752 Every authentication START, REPLY and CONTINUE packet includes a data 753 field. The use of this field is dependent upon the kind of the 754 Authentication. 756 This document defines a core set of authentication flows to be 757 supported by TACACS+. Each authentication flow consists of a START 758 packet. The server responds either with a request for more 759 information (GETDATA, GETUSER or GETPASS) or a termination PASS, 760 FAIL, ERROR or RESTART. The actions and meanings when the server 761 sends a RESTART or ERROR are common and are described further below. 763 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 764 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 765 then authentication continues and the server SHOULD provide 766 server_msg content for the client to prompt the user for more 767 information. The client MUST then return a CONTINUE packet 768 containing the requested information in the user_msg field. 770 The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a 771 request for username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request 772 for password. The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic 773 request for more information to flexibly support future requirements. 775 If the information being requested by the server form the client is 776 sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO 777 flag. When the client queries the user for the information, the 778 response MUST NOT be echoed as it is entered. 780 The data field is only used in the REPLY where explicitly defined 781 below. 783 4.4.1. Version Behaviour 785 The TACACS+ protocol is versioned to allow revisions while 786 maintaining backwards compatibility. The version number is in every 787 packet header. The changes between minor_version 0 and 1 apply only 788 to the authentication process, and all deal with the way that CHAP 789 and PAP authentications are handled. minor_version 1 may only be used 790 for authentication kinds that explicitly call for it in the table 791 below: 793 LOGIN CHPASS SENDAUTH 794 ASCII v0 v0 - 795 PAP v1 - v1 796 CHAP v1 - v1 797 MS-CHAPv1/2 v1 - v1 799 The '-' symbol represents that the option is not valid. 801 All authorisation and accounting and ASCII authentication use 802 minor_version number of 0. 804 PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange 805 is a single START packet from the client and a single REPLY from the 806 server. 808 The removal of SENDPASS was prompted by security concerns, and is no 809 longer considered part of the TACACS+ protocol. 811 4.4.2. Common Authentication Flows 813 This section describes common authentication flows. If the server 814 does not implement an option, it MUST respond with 815 TAC_PLUS_AUTHEN_STATUS_FAIL. 817 4.4.2.1. ASCII Login 819 action = TAC_PLUS_AUTHEN_LOGIN 820 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 821 minor_version = 0x0 823 This is a standard ASCII authentication. The START packet MAY 824 contain the username. If the user does not include the username then 825 the server MUST obtain it from the client with a CONTINUE 826 TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user does not provide a 827 username then the server can send another 828 TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server MUST limit the 829 number of retries that are permitted, recommended limit is three 830 attempts. When the server has the username, it will obtain the 831 password using a continue with TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII 832 login uses the user_msg field for both the username and password. 833 The data fields in both the START and CONTINUE packets are not used 834 for ASCII logins, any content MUST be ignored. The session is 835 composed of a single START followed by zero or more pairs of REPLYs 836 and CONTINUEs, followed by a final REPLY indicating PASS, FAIL or 837 ERROR. 839 4.4.2.2. PAP Login 841 action = TAC_PLUS_AUTHEN_LOGIN 842 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 843 minor_version = 0x1 845 The entire exchange MUST consist of a single START packet and a 846 single REPLY. The START packet MUST contain a username and the data 847 field MUST contain the PAP ASCII password. A PAP authentication only 848 consists of a username and password RFC 1334 [RFC1334] . The REPLY 849 from the server MUST be either a PASS, FAIL or ERROR. 851 4.4.2.3. CHAP login 853 action = TAC_PLUS_AUTHEN_LOGIN 854 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 855 minor_version = 0x1 857 The entire exchange MUST consist of a single START packet and a 858 single REPLY. The START packet MUST contain the username in the user 859 field and the data field is a concatenation of the PPP id, the 860 challenge and the response. 862 The length of the challenge value can be determined from the length 863 of the data field minus the length of the id (always 1 octet) and the 864 length of the response field (always 16 octets). 866 To perform the authentication, the server calculates the PPP hash as 867 defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then 868 compare that value with the response. The MD5 algorithm option is 869 alays used. The REPLY from the server MUST be a PASS, FAIL or ERROR. 871 In cases where the client conducts the exchange with the endstation 872 and then sends the resulting materials (challenge and responsee) to 873 the server, the selection of the challenge and its length are not an 874 aspect of the TACACS+ protocol. However, it is strongly recommended 875 that the client/endstation interaction is configured with a secure 876 challenge. The TACACS+ server can help by rejecting authentications 877 where the challenge is below a minimum length (Minimum recommended is 878 8 bytes). 880 In cases where the TACACS+ Server generates the challenge then it 881 MUST change for every request and MUST be derived from a strong 882 cryptographic source. 884 4.4.2.4. MS-CHAP v1 login 886 action = TAC_PLUS_AUTHEN_LOGIN 887 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 888 minor_version = 0x1 890 The entire exchange MUST consist of a single START packet and a 891 single REPLY. The START packet MUST contain the username in the user 892 field and the data field will be a concatenation of the PPP id, the 893 MS-CHAP challenge and the MS-CHAP response. 895 The length of the challenge value can be determined from the length 896 of the data field minus the length of the id (always 1 octet) and the 897 length of the response field (always 49 octets). 899 To perform the authentication, the server will use a combination of 900 MD4 and DES on the user's secret and the challenge, as defined in RFC 901 2433 [RFC2433] and then compare the resulting value with the 902 response. The REPLY from the server MUST be a PASS or FAIL. 904 For best practices, please refer to RFC 2433 [RFC2433] . The TACACS+ 905 server MUST rejects authentications where the challenge deviates from 906 8 bytes as defined in the RFC. 908 4.4.2.5. MS-CHAP v2 login 910 action = TAC_PLUS_AUTHEN_LOGIN 911 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 912 minor_version = 0x1 914 The entire exchange MUST consist of a single START packet and a 915 single REPLY. The START packet MUST contain the username in the user 916 field and the data field will be a concatenation of the PPP id, the 917 MS-CHAP challenge and the MS-CHAP response. 919 The length of the challenge value can be determined from the length 920 of the data field minus the length of the id (always 1 octet) and the 921 length of the response field (always 49 octets). 923 To perform the authentication, the server will use the algorithm 924 specified RFC 2759 [RFC2759] on the user's secret and challenge and 925 then compare the resulting value with the response. The REPLY from 926 the server MUST be a PASS or FAIL. 928 For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] 929 . The TACACS+ server MUST rejects authentications where the challenge 930 deviates from 16 bytes as defined in the RFC. 932 4.4.2.6. Enable Requests 934 action = TAC_PLUS_AUTHEN_LOGIN 935 priv_lvl = implementation dependent 936 authen_type = not used 937 service = TAC_PLUS_AUTHEN_SVC_ENABLE 939 This is an ENABLE request, used to change the current running 940 privilege level of a user. The exchange MAY consist of multiple 941 messages while the server collects the information it requires in 942 order to allow changing the principal's privilege level. This 943 exchange is very similar to an ASCII login (Section 4.4.2.1) . 945 In order to readily distinguish enable requests from other types of 946 request, the value of the authen_service field MUST be set to 947 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 948 set to this value when requesting any other operation. 950 4.4.2.7. ASCII change password request 952 action = TAC_PLUS_AUTHEN_CHPASS 953 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 955 This exchange consists of multiple messages while the server collects 956 the information it requires in order to change the user's password. 957 It is very similar to an ASCII login. The status value 958 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 959 "new" password. It MAY be sent multiple times. When requesting the 960 "old" password, the status value MUST be set to 961 TAC_PLUS_AUTHEN_STATUS_GETDATA. 963 4.4.3. Aborting an Authentication Session 965 The client may prematurely terminate a session by setting the 966 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 967 flag is set, the data portion of the message may contain an ASCII 968 message explaining the reason for the abort. This information will 969 be handled by the server according to the requirements of the 970 deployment. The session is terminated, for more details about 971 session temrination, oplease refer to section (Section 3.4) 973 In the case of PALL, FAIL or ERROR, the server can insert a message 974 into server_msg to be displayed to the user. 976 The Draft `The Draft' [TheDraft] defined a mechanism to direct 977 authentication requests to an alternative server. This mechanism is 978 regarded as insecure, is deprecated, and not covered here. The 979 client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as 980 TAC_PLUS_AUTHEN_STATUS_FAIL 982 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 983 indicating that it is experiencing an unrecoverable error and the 984 authentication will proceed as if that host could not be contacted. 985 The data field may contain a message to be printed on an 986 administrative console or log. 988 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 989 authentication sequence is restarted with a new START packet from the 990 client, with new session Id, and seq_no set to 1. This REPLY packet 991 indicates that the current authen_type value (as specified in the 992 START packet) is not acceptable for this session. The client may try 993 an alternative authen_type. 995 If a client does not implement TAC_PLUS_AUTHEN_STATUS_RESTART option, 996 then it MUST process the response as if the status was 997 TAC_PLUS_AUTHEN_STATUS_FAIL. 999 5. Authorization 1001 In the TACACS+ Protocol, authorization is the action of determining 1002 what a user is allowed to do. Generally authentication precedes 1003 authorization, though it is not mandatory that a client use the same 1004 service for authentication that it will use for authorization. An 1005 authorization request may indicate that the user is not authenticated 1006 (we don't know who they are). In this case it is up to the server to 1007 determine, according to its configuration, if an unauthenticated user 1008 is allowed the services in question. 1010 Authorization does not merely provide yes or no answers, but it may 1011 also customize the service for the particular user. A common use of 1012 authorization is to provision a shell session when a user first logs 1013 in to a device to administer it. The TACACS+ server might respond to 1014 the request by allowing the service, but placing a time restriction 1015 on the login shell. For a list of common attributes used in 1016 authorization, see the Authorization Attributes section (Section 7.2) 1017 . 1019 In the TACACS+ protocol an authorization is always a single pair of 1020 messages: a REQUEST from the client followed by a REPLY from the 1021 server. 1023 The authorization REQUEST message contains a fixed set of fields that 1024 indicate how the user was authenticated and a variable set of 1025 arguments that describe the services and options for which 1026 authorization is requested. 1028 The REPLY contains a variable set of response arguments (attribute- 1029 value pairs) that can restrict or modify the clients actions. 1031 5.1. The Authorization REQUEST Packet Body 1032 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 1033 +----------------+----------------+----------------+----------------+ 1034 | authen_method | priv_lvl | authen_type | authen_service | 1035 +----------------+----------------+----------------+----------------+ 1036 | user_len | port_len | rem_addr_len | arg_cnt | 1037 +----------------+----------------+----------------+----------------+ 1038 | arg_1_len | arg_2_len | ... | arg_N_len | 1039 +----------------+----------------+----------------+----------------+ 1040 | user ... 1041 +----------------+----------------+----------------+----------------+ 1042 | port ... 1043 +----------------+----------------+----------------+----------------+ 1044 | rem_addr ... 1045 +----------------+----------------+----------------+----------------+ 1046 | arg_1 ... 1047 +----------------+----------------+----------------+----------------+ 1048 | arg_2 ... 1049 +----------------+----------------+----------------+----------------+ 1050 | ... 1051 +----------------+----------------+----------------+----------------+ 1052 | arg_N ... 1053 +----------------+----------------+----------------+----------------+ 1055 authen_method 1057 This indicates the authentication method used by the client to 1058 acquire the user information. As this information is not always 1059 subject to verification, it is recommended that this field is 1060 ignored. 1062 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1064 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1066 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1068 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1070 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1072 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1074 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1076 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1078 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1079 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1081 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1083 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1084 password associated with the terminal line used to gain access. 1085 LOCAL is a client local user database. ENABLE is a command that 1086 authenticates in order to grant new privileges. TACACSPLUS is, of 1087 course, TACACS+. GUEST is an unqualified guest authentication, such 1088 as an ARAP guest login. RADIUS is the Radius authentication 1089 protocol. RCMD refers to authentication provided via the R-command 1090 protocols from Berkeley Unix. 1092 priv_lvl 1094 This field is used in the same way as the priv_lvl field in 1095 authentication request and is described in the Privilege Level 1096 section (Section 8) below. It indicates the users current privilege 1097 level. 1099 authen_type 1101 This field corrsponds to the authen_type field in the authentication 1102 section (Section 4) above. It indicates the type of authentication 1103 that was performed. If this information is not available, then the 1104 client will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. 1105 This value is valid only in authorization and accounting requests. 1107 authen_service 1109 This field is the same as the authen_service field in the 1110 authentication section (Section 4) above. It indicates the service 1111 through which the user authenticated. 1113 user, user_len 1115 This field contains the user's account name. The user_len MUST 1116 indicate the length of the user field, in bytes. 1118 port, port_len 1120 This field matches the port field in the authentication section 1121 (Section 4) above. The port_len indicates the length of the port 1122 field, in bytes. 1124 rem_addr, rem_addr_len 1125 This field matches the rem_addr field in the authentication section 1126 (Section 4) above. The rem_addr_len indicates the length of the port 1127 field, in bytes. 1129 arg_cnt 1131 The number of authorization arguments to follow 1133 arg_1 ... arg_N, arg_1_len .... arg_N_len 1135 The arguments are the primary elements of the authorization 1136 interaction. In the request packet they describe the specifics of 1137 the authorization that is being requested. Each argument is encoded 1138 in the packet as a single arg filed (arg_1... arg_N) with a 1139 corresponding length fields (which indicates the length of each 1140 argument in bytes). 1142 The authorization arguments in both the REQUEST and the REPLY are 1143 attribute-value pairs. The attribute and the value are in a single 1144 printable US-ASCII string and are separated by either a "=" (0X3D) or 1145 a "*" (0X2A). The equals sign indicates a mandatory argument. The 1146 asterisk indicates an optional one. 1148 It is not legal for an attribute name to contain either of the 1149 separators. It is legal for attribute values to contain the 1150 separators. This means that the arguments must be parsed until the 1151 first separator is encountered, all characters in the argument, after 1152 this separator, are interpreted as the argument value. 1154 Optional arguments are ones that may be disregarded by either client 1155 or server. Mandatory arguments require that the receiving side can 1156 handle the attribute, that is: its implementation and configuration 1157 includes the details of how to act on it. If the client receives a 1158 mandatory argument that it cannot handle, it MUST consider the 1159 authorization to have failed. It is legal to send an attribute-value 1160 pair with a zero length value. 1162 Attribute-value strings are not NULL terminated, rather their length 1163 value indicates their end. The maximum length of an attribute-value 1164 string is 255 characters. The minimum is two characters (one name 1165 value character and the separator) 1167 Though the attributes allow extensibility, a common core set of 1168 authorization attributes SHOULD be supported by clients and servers, 1169 these are listed in the Authorization Attributes (Section 7.2) 1170 section below. 1172 5.2. The Authorization REPLY Packet Body 1174 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 1175 +----------------+----------------+----------------+----------------+ 1176 | status | arg_cnt | server_msg len | 1177 +----------------+----------------+----------------+----------------+ 1178 + data_len | arg_1_len | arg_2_len | 1179 +----------------+----------------+----------------+----------------+ 1180 | ... | arg_N_len | server_msg ... 1181 +----------------+----------------+----------------+----------------+ 1182 | data ... 1183 +----------------+----------------+----------------+----------------+ 1184 | arg_1 ... 1185 +----------------+----------------+----------------+----------------+ 1186 | arg_2 ... 1187 +----------------+----------------+----------------+----------------+ 1188 | ... 1189 +----------------+----------------+----------------+----------------+ 1190 | arg_N ... 1191 +----------------+----------------+----------------+----------------+ 1193 status This field indicates the authorization status 1195 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1197 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1199 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1201 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1203 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1205 server_msg, server_msg_len 1207 This is a printable US-ASCII string that may be presented to the 1208 user. The server_msg_len indicates the length of the server_msg 1209 field, in bytes. 1211 data, data_len 1213 This is a printable US-ASCII string that may be presented on an 1214 administrative display, console or log. The decision to present this 1215 message is client specific. The data_len indicates the length of the 1216 data field, in bytes. 1218 arg_cnt 1219 The number of authorization arguments to follow. 1221 arg_1 ... arg_N, arg_1_len .... arg_N_len 1223 The arguments describe the specifics of the authorization that is 1224 being requested. For details of the content of the args, refer to: 1225 Authorization Attributes (Section 7.2) section below. Each argument 1226 is encoded in the packet as a single arg field (arg_1... arg_N) with 1227 a corresponding length fields (which indicates the length of each 1228 argument in bytes). 1230 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested 1231 authorization MUST be denied. 1233 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1234 arguments specified in the request are authorized and the arguments 1235 in the response MUST be applied according to the rules described 1236 above. 1238 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client 1239 MUST use the authorization attribute-value pairs (if any) in the 1240 response, instead of the authorization attribute-value pairs from the 1241 request. 1243 To approve the authorization with no modifications, the server sets 1244 the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. 1246 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1247 on the server. For the differences between ERROR and FAIL, refer to 1248 section Session Completion (Section 3.4) . None of the arg values 1249 have any relevance if an ERROR is set, and must be ignored. 1251 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1252 arg_cnt MUST be 0. In that case, the actions to be taken and the 1253 contents of the data field are identical to the 1254 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1256 6. Accounting 1258 Accounting is typically the third action after authentication and 1259 authorization. But again, neither authentication nor authorization 1260 is required. Accounting is the action of recording what a user is 1261 doing, and/or has done. Accounting in TACACS+ can serve two 1262 purposes: It may be used as an auditing tool for security services. 1263 It may also be used to account for services used, such as in a 1264 billing environment. To this end, TACACS+ supports three types of 1265 accounting records. Start records indicate that a service is about 1266 to begin. Stop records indicate that a service has just terminated, 1267 and Update records are intermediate notices that indicate that a 1268 service is still being performed. TACACS+ accounting records contain 1269 all the information used in the authorization records, and also 1270 contain accounting specific information such as start and stop times 1271 (when appropriate) and resource usage information. A list of 1272 accounting attributes is defined in the accounting section 1273 (Section 6) . 1275 6.1. The Account REQUEST Packet Body 1277 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 1278 +----------------+----------------+----------------+----------------+ 1279 | flags | authen_method | priv_lvl | authen_type | 1280 +----------------+----------------+----------------+----------------+ 1281 | authen_service | user_len | port_len | rem_addr_len | 1282 +----------------+----------------+----------------+----------------+ 1283 | arg_cnt | arg_1_len | arg_2_len | ... | 1284 +----------------+----------------+----------------+----------------+ 1285 | arg_N_len | user ... 1286 +----------------+----------------+----------------+----------------+ 1287 | port ... 1288 +----------------+----------------+----------------+----------------+ 1289 | rem_addr ... 1290 +----------------+----------------+----------------+----------------+ 1291 | arg_1 ... 1292 +----------------+----------------+----------------+----------------+ 1293 | arg_2 ... 1294 +----------------+----------------+----------------+----------------+ 1295 | ... 1296 +----------------+----------------+----------------+----------------+ 1297 | arg_N ... 1298 +----------------+----------------+----------------+----------------+ 1300 flags 1302 This holds bitmapped flags. 1304 TAC_PLUS_ACCT_FLAG_START := 0x02 1306 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1308 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1310 All other fields are defined in the authorization and authentication 1311 sections above and have the same semantics. They provide details for 1312 the conditions on the client, and authentication context, so that 1313 these details may be logged for accounting purposes. 1315 See section 12 Accounting Attribute-value Pairs for the dictionary of 1316 attributes relevant to accounting. 1318 6.2. The Accounting REPLY Packet Body 1320 The purpose of accounting is to record the action that has occurred 1321 on the client. The server MUST reply with success only when the 1322 accounting request has been recorded. If the server did not record 1323 the accounting request then it MUST reply with ERROR. 1325 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 1326 +----------------+----------------+----------------+----------------+ 1327 | server_msg len | data_len | 1328 +----------------+----------------+----------------+----------------+ 1329 | status | server_msg ... 1330 +----------------+----------------+----------------+----------------+ 1331 | data ... 1332 +----------------+ 1334 status 1336 This is the return status. Values are: 1338 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1340 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1342 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1344 server_msg, server_msg_len 1346 This is a printable US-ASCII string that may be presented to the 1347 user. The server_msg_len indicates the length of the server_msg 1348 field, in bytes. 1350 data, data_len 1352 This is a printable US-ASCII string that may be presented on an 1353 administrative display, console or log. The decision to present this 1354 message is client specific. The data_len indicates the length of the 1355 data field, in bytes. 1357 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1358 to be taken and the contents of the data field are identical to the 1359 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1361 TACACS+ accounting is intended to record various types of events on 1362 clients, for example: login sessions, command entry, and others as 1363 required by the client implementation. These events are collectively 1364 referred to in `The Draft' [TheDraft] as "tasks". 1366 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1367 accounting message. Start messages will only be sent once when a 1368 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1369 a stop record and that the task has terminated. The 1370 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1372 Summary of Accounting Packets 1374 +----------+-------+-------+-------------+-------------------------+ 1375 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1376 +----------+-------+-------+-------------+-------------------------+ 1377 | 0 | 0 | 0 | 0 | INVALID | 1378 | 0 | 0 | 1 | 2 | Start Accounting Record | 1379 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1380 | 0 | 1 | 1 | 6 | INVALID | 1381 | 1 | 0 | 0 | 8 | Watchdog, no update | 1382 | 1 | 0 | 1 | A | Watchdog, with update | 1383 | 1 | 1 | 0 | C | INVALID | 1384 | 1 | 1 | 1 | E | INVALID | 1385 +----------+-------+-------+-------------+-------------------------+ 1387 The START and STOP flags are mutually exclusive. 1389 The WATCHDOG flag is used by the client to communicate ongoing status 1390 of a long running task. Update records are sent at the client's 1391 discretion. The frequency of the update depends upon the intended 1392 application: A watchdog to provide progress indication will require 1393 higher frequency than a daily keep-alive. When the WATCHDOG flag is 1394 set along with the START flag, it indicates that the update record 1395 provides additional or updated arguments from the original START 1396 record. If the START flag is not set, then this indicates only that 1397 task is still running, and no new information is provided (servers 1398 MUST ignore any arguments). The STOP flag MUST NOT be set in 1399 conjunction with the WATCHDOG flag. 1401 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1402 requests an INVALID option. 1404 7. Attribute-Value Pairs 1406 TACACS+ is intended to be an extensible protocol. The attributes 1407 used in Authorization and Accounting are not limited by this 1408 document. Some attributes are defined below for common use cases, 1409 clients MUST use these attributes when supporting the corresponding 1410 use cases. 1412 7.1. Value Encoding 1414 All attribute values are encoded as printable US-ASCII strings. The 1415 following type representations SHOULD be followed 1417 Numeric 1419 All numeric values in an attribute-value string are provided as 1420 decimal printable US-ASCII numbers, unless otherwise stated. 1422 Boolean 1424 All boolean attributes are encoded as printable US-ASCII with values 1425 "true" or "false". 1427 IP-Address 1429 It is recommended that hosts be specified as a IP address so as to 1430 avoid any ambiguities. IPV4 address are specified as US-ASCII octet 1431 numerics separated by dots ('.'), IPV6 address text representation 1432 defined in RFC 4291. 1434 Date Time 1436 Absolute date/times are specified in seconds since the epoch, 12:00am 1437 Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is 1438 specified. Stardate is canonically inconsistent and so SHOULD NOT be 1439 used. 1441 String 1443 Many values have no specific type representation and so are 1444 interpreted as plain strings. 1446 Empty Values 1448 Attributes may be submitted with no value, in which case they consist 1449 of the name and the mandatory or optional separator. For example, 1450 the attribute "cmd" which has no value is transmitted as a string of 1451 four characters "cmd=" 1453 7.2. Authorization Attributes 1455 service (String) 1457 The primary service. Specifying a service attribute indicates that 1458 this is a request for authorization or accounting of that service. 1460 For example: "shell", "tty-server", "connection", "system" and 1461 "firewall". This attribute MUST always be included. 1463 protocol (String) 1465 the protocol field may be used to indicate a subset of a service. 1467 cmd (String) 1469 a shell (exec) command. This indicates the command name of the 1470 command that is to be run. The "cmd" attribute MUST be specified if 1471 service equals "shell". 1473 Authorization of shell commands is a common use-case for the TACACS+ 1474 protocol. Command Authorization generally takes one of two forms: 1475 session-based and command-based. 1477 For session-based shell authorization, the "cmd" argument will have 1478 an empty value. The client determines which commands are allowed in 1479 a session according to the arguments present in the authorization. 1481 In command-based authorization, the client requests that the server 1482 determine whether a command is allowed by making an authorization 1483 request for each command. The "cmd" argument will have the command 1484 name as its value. 1486 cmd-arg (String) 1488 an argument to a shell (exec) command. This indicates an argument 1489 for the shell command that is to be run. Multiple cmd-arg attributes 1490 may be specified, and they are order dependent. 1492 acl (Numeric) 1494 printable US-ASCII number representing a connection access list. 1495 Applicable only to session-based shell authorization. 1497 inacl (String) 1499 printable US-ASCII identifier for an interface input access list. 1501 outacl (String) 1503 printable US-ASCII identifier for an interface output access list. 1505 addr (IP-Address) 1507 a network address 1508 addr-pool (String) 1510 The identifier of an address pool from which the client can assign an 1511 address. 1513 routing (Boolean) 1515 Specifies whether routing information is to be propagated to, and 1516 accepted from this interface. 1518 route (String) 1520 Indicates a route that is to be applied to this interface. Values 1521 MUST be of the form " []". If a 1522 is not specified, the resulting route is via the 1523 requesting peer. 1525 timeout (Numeric) 1527 an absolute timer for the connection (in minutes). A value of zero 1528 indicates no timeout. 1530 idletime (Numeric) 1532 an idle-timeout for the connection (in minutes). A value of zero 1533 indicates no timeout. 1535 autocmd (String) 1537 an auto-command to run. Applicable only to session-based shell 1538 authorization. 1540 noescape (Boolean) 1542 Prevents user from using an escape character. Applicable only to 1543 session-based shell authorization. 1545 nohangup (Boolean) 1547 Boolean. Do not disconnect after an automatic command. Applicable 1548 only to session-based shell authorization.y. 1550 priv-lvl (Numeric) 1552 privilege level to be assigned. Please refer to the Privilege Level 1553 section (Section 8) below. 1555 remote_user (String) 1556 remote userid (authen_method must have the value 1557 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1558 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1559 remote_user and remote_host attributes will provide the remote user 1560 and host information to enable rhost style authorization. The 1561 response may request that a privilege level be set for the user. 1563 remote_host (String) 1565 remote host (authen_method must have the value 1566 TAC_PLUS_AUTHEN_METH_RCMD) 1568 7.3. Accounting Attributes 1570 The following attributes are defined for TACACS+ accounting only. 1571 They MUST precede any attribute-value pairs that are defined in the 1572 authorization section (Section 5) above. 1574 task_id (String) 1576 Start and stop records for the same event MUST have matching task_id 1577 attribute values. The client MUST ensure that active task_ids are 1578 not duplicated: a client MUST NOT reuse a task_id a start record 1579 until it has sent a stop record for that task_id. Servers MUST not 1580 make assumptions about the format of a task_id. 1582 start_time (Date Time) 1584 The time the action started (in seconds since the epoch.). 1586 stop_time (Date Time) 1588 The time the action stopped (in seconds since the epoch.) 1590 elapsed_time (Numeric) 1592 The elapsed time in seconds for the action. 1594 timezone (String) 1596 The timezone abbreviation for all timestamps included in this packet. 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". 1602 These indicate system level changes. The flags field SHOULD indicate 1603 whether the service started or stopped. 1605 reason (String) 1607 Accompanies an event attribute. It describes why the event occurred. 1609 bytes (Numeric) 1611 The number of bytes transferred by this action 1613 bytes_in (Numeric) 1615 The number of bytes transferred by this action from the endstation to 1616 the client port 1618 bytes_out (Numeric) 1620 The number of bytes transferred by this action from the client to the 1621 endstation port 1623 paks (Numeric) 1625 The number of packets transferred by this action. 1627 paks_in (Numeric) 1629 The number of input packets transferred by this action from the 1630 endstation to the client port. 1632 paks_out (Numeric) 1634 The number of output packets transferred by this action from the 1635 client port to the endstation. 1637 err_msg (String) 1639 A printable US-ASCII string describing the status of the action. 1641 8. Privilege Levels 1643 The TACACS+ Protocol supports flexible authorization schemes through 1644 the extensible attributes. 1646 One scheme is built in to the protocol and has been extensively used 1647 for Session-based shell authorization: Privilege Levels. Privilege 1648 Levels are ordered values from 0 to 15 with each level being a 1649 superset of the next lower value. Configuration and implementation 1650 of the client will map actions ()such as the permission to execute of 1651 specific commands) to different privilege levels. Pre-defined values 1652 are: 1654 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1656 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1658 TAC_PLUS_PRIV_LVL_USER := 0x01 1660 TAC_PLUS_PRIV_LVL_MIN := 0x00 1662 A Privilege level can be assigned to a shell (EXEC) session when it 1663 starts starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will 1664 permit the actions associated with this level to be executed. This 1665 privilege level is returned by the Server in a session-based shell 1666 authorization (when "service" equals "shell" and "cmd" is empty). 1667 When a user required to perform actions that are mapped to a higher 1668 privilege level, then an ENABLE type reuthentication can be initiated 1669 by the client, in a way similar to su in unix. The client will 1670 insert the required privilege level into the authentication header 1671 for enable authentication request. 1673 The use of Privilege levels to determine session-based access to 1674 commands and resources is not mandatory for clients. Although the 1675 privilege level scheme is widely supported, its lack of flexibility 1676 in requiring a single monotonic hierarchy of permissions means that 1677 other session-based command authorization schemes have evolved, and 1678 so it is no longer mandatory for clients to use it. However, it is 1679 still common enough that it SHOULD be supported by servers. 1681 9. TACACS+ Security Considerations 1683 The original TACACS+ Draft[1] from 1998 did not address all of the 1684 key security concerns which are considered when designing modern 1685 standards. This section addresses known limitations and concerns 1686 which will impact overall security of the protocol and systems where 1687 this protocol is deployed to manage central authentication, 1688 authorization or accounting for network device administration. 1690 Multiple implementations of the protocol described in the draft[1] 1691 have been deployed. As the protocol was never standardised, current 1692 implementations may be incompatible in non-obvious ways, giving rise 1693 to additional security risks about which authors might not be aware 1694 of. This section does not claim to enumerate all possible security 1695 vulnerabilities. 1697 9.1. General Security of The Protocol 1699 TACACS+ protocol does not include a security mechanism that would 1700 meet modern day requirements. Support for MD5-based crypto pad 1701 encryption fails to provide any kind of transport integrity, which 1702 presents at least the following risks: 1704 Accounting information may be modified by the man-in-the-middle 1705 attacker, making such logs unsuitable and untrustable for auditing 1706 purposes. 1708 Only the body of the request is encrypted which leaves all header 1709 fields open to trivial modification by the man-in-the-middle 1710 attacker. 1712 Invalid or misleading values may be inserted by the man-in-the- 1713 middle attacker in various fields at known offsets to try and 1714 circumvent the authentication or authorization checks even inside 1715 the encrypted body. 1717 While the protocol provides some measure of transport privacy, it is 1718 vulnerable to at least the following attacks: 1720 Brute force attacks exploiting increased efficiency of MD5 digest 1721 computation. 1723 Known plaintext attacks which may decrease the cost of brute force 1724 attack. 1726 Chosen plaintext attacks which may decrease the cost of a brute 1727 force attack. 1729 No forward secrecy. 1731 Even though, to the best knowledge of authors, this method of 1732 encryption wasn't rigorously tested, authors feel that enough 1733 information is available that it is best referred to as "obfuscation" 1734 and not "encryption". 1736 For example, a "session_id" can be replaced by an alternate one, 1737 which could allow an unprivileged administrator to "steal" the 1738 authorization from a session for a privileged administrator. An 1739 attacker could also update the "flags" field to indicate that one or 1740 the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG, 1741 which would subvert the obfuscation mechanism. 1743 For this reasons, users deploying TACACS+ protocol in their 1744 environments MUST limit access to known clients and MUST control the 1745 security of the entire transmission path. Attacks who can guess the 1746 key or otherwise break the obfuscation will gain unrestricted and 1747 undetected access to all TACACS+ traffic. The security risk of such 1748 attack succeeding against a centralised AAA system like TACACS+ 1749 cannot be overstated. 1751 The following parts of this section enumerate only the session- 1752 specific risks which are in addition to general risk associated with 1753 bare obfuscation and lack of integrity checking. 1755 9.2. Security of Authentication Sessions 1757 Authentication sessions SHOULD NOT be used via unsecure transport as 1758 the man-in-the-middle attack may completely subvert them. Even CHAP, 1759 which may me considered resistant to password interception, is unsafe 1760 as it does not protect the username from a trivial man-in-the-middle 1761 attack. 1763 Section 4.4.3 permits the redirection of a session to another server 1764 via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this 1765 process, the secret key for a new server can be sent to the client. 1766 This public exchange of secret keys means that once one session is 1767 broken, it may be possible to leverage that key to attacking 1768 connections to other servers. This option MUST NOT be used outside a 1769 secured deployment of protocol clients or outside of secure 1770 transport. 1772 9.3. Security of Authorization Sessions 1774 Authorization sessions MUST be used via secure transport only as it's 1775 trivial to execute a successful man-in-the-middle attacks that 1776 changes well-known plaintext in either requests or responses. 1778 As an example, take the field "authen_method". It's not unusual in 1779 actual deployments to authorize all commands received via the device 1780 local serial port (a console port) as that one is usually considered 1781 secure by virtue of the device located in a physically secure 1782 location. If an administrator would configure the authorization 1783 system to allow all commands entered by the user on a local console 1784 to aid in troubleshooting, that would give all access to all commands 1785 to any attacker that would be able to change the "authen_method" from 1786 TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In 1787 this regard, the obfuscation provided by the protocol itself wouldn't 1788 help much, because: 1790 Lack of integrity means that any byte in the payload may be 1791 changed w/o either side detecting the change. 1793 Known plaintext means that an attacker would know with certainty 1794 which octet is the target of the attack (in this case, 1st octet 1795 after the header). 1797 In combination with known plaintext, the attacker can determine 1798 with certainty the value of the crypto-pad octet used to obfuscate 1799 the original octet. 1801 9.4. Security of Accounting Sessions 1803 Accounting sessions are not directly involved in authentication or 1804 authorizing operations on the device. However, man-in-the-middle 1805 attacker may do any of the following: 1807 Replace accounting data with new valid or garbage which prevents 1808 to provide distraction or hide information related to their 1809 authentication and/or authorization attack attempts. 1811 Try and poison accounting log with entries designed to make 1812 systems behave in unintended ways (which includes TACACS+ server 1813 and any other systems that would manage accounting entries). 1815 In addition to these direct manipulations, different client 1816 implementations pass different fidelity of accounting data. Some 1817 vendors have been observed in the wild that pass sensitive data like 1818 passwords, encryption keys and similar as part of the accounting log. 1819 Due to lack of strong encryption with perfect forward secrecy, this 1820 data may be revealed in future, leading to a security incident. 1822 9.5. TACACS+ Deployment Recommendations 1824 Due to above observations about the TACACS+ protocol, it is critical 1825 to only deploy it using secure transport. A secure transport for 1826 TACACS+ is defined as any means that ensure privacy and integrity of 1827 all data passed between clients and servers. There are multiple 1828 means of achieving this, all of them beyond the scope of this 1829 document. 1831 Symmetric encryption key represents a possible attack vector at the 1832 protocol itself. For this reason, servers SHOULD accept only those 1833 network connection attempts that arrive from known clients. This 1834 limits the exposure and prevents remote brute force attacks from 1835 unknown clients. 1837 Due to the security deficiencies of the protocol, it is critical that 1838 it be deployed in a secure manner. The following recommendations are 1839 made for those deploying and configuring TACACS+ as a solution for 1840 device administration: 1842 Secure the Deployment: TACACS+ MUST BE deployed over networks 1843 which ensure an appropriate privacy and integrity of the 1844 communication. Definition of an appropriate level of privacy and 1845 integrity is organisation-dependent What is apropriate level of 1846 The way this is ensured will depend upon the organisational means: 1847 a dedicated and secure management network where available in 1848 enterprise deployments, or IPsec where dedicated networks are not 1849 available. 1851 Always set a secret key (recommended minimum 14 characters) on the 1852 client and server when configuring the connection between them. 1854 Servers MUST be configured with a list of known clients. Servers 1855 MUST be configured to reject requests from clients not on the 1856 list. A unique secret key SHOULD be configured for every 1857 individual client. 1859 Implementors should consider shared secrets to be sensitive data, 1860 and managed securely. 1862 Restrict to TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type where 1863 possible. Use other options only when unavoidable due to 1864 requirements of identity/password systems. 1866 Servers SHOULD be restricted to requiring TACACS+ authentication 1867 for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS 1868 is used). 1870 Avoid the use of the redirection mechanism. 1871 TAC_PLUS_AUTHEN_STATUS_FOLLOW, specifically avoid the option to 1872 send send secret keys in the server list. 1874 Take case when applying extensions to the dictionary of 1875 authorization/accounting arguments. Ensure that the client and 1876 server use of new argument names are consistent. 1878 9.6. TACACS+ Client Implementation Recommendations 1880 When implementing TACACS+ Clients it is recommended: 1882 Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks 1883 that are considered secure. 1885 Ignore redirects to hosts which are outside of the pre-configured 1886 range or list. A client SHOULD ignore any key provided via 1887 TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a 1888 preconfigured key for that host. 1890 If receiving an unknown mandatory authorization attribute, behave 1891 as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. For full 1892 details, refer to (Authorization attributes section). 1894 9.7. TACACS+ Server Implementation Recommendations 1896 When implementing TACACS+ Servers, it is recommended: 1898 Server SHOULD reject all connections which have the 1899 TAC_PLUS_UNENCRYPTED_FLAG with applicable ERROR response for type 1900 of packet. 1902 Servers MUST permit configuration of secret keys per individual 1903 client. Servers SHOULD warn administrators if secret keys are not 1904 unique per client. 1906 On detection of an invalid shared secret: Servers SHOULD NOT 1907 accept any new sessions on a connection, and terminate the 1908 connection on completion of any sessions previously established 1909 with a valid shared secret. 1911 Allow the administrator to mandate : - TAC_PLUS_AUTHEN_TYPE_CHAP 1912 for authen_type - TAC_PLUS_AUTHEN_METH_TACACSPLUS for 1913 authen_method in authorization - Minimum length for shared secrets 1915 9.8. TACACS+ Security and Operational Concerns 1917 This section identifies some of the known security and operational 1918 concerns. It is important to acknowledge that TACACS+ on its own 1919 does not provide modern levels of security, and that it MUST be used 1920 within a secure deployment. 1922 The "encryption" is based upon MD5. In modern terms this can be 1923 regarded merely as "obfuscation". 1925 Only the packet body (not header) is obfuscated. For example, 1926 session_id, flags containing TAC_PLUS_UNENCRYPTED_FLAG is exposed 1927 in cleartext. 1929 Support of insecure authentication protocols such as plaintext, 1930 MS-CHAP. 1932 Difficulty to correlate authentication, authorization, and 1933 accounting requests for a single unit of end client activity. 1935 Potential confusion between clients and servers from different 1936 vendors of the meaning of specific argument attributes. 1938 Potential confusion between clients and servers from different 1939 vendors of the meaning of specific commands. 1941 In summary: It is strongly advised that TACACS+ MUST be used within a 1942 secure deployment. Failure to do so may impact overall network 1943 security. 1945 10. Acknowledgements 1947 The Authors would like to thank the following reviewers whose 1948 comments and contributions made considerable improvements to the 1949 document: Alan DeKok (who provided significant insights and 1950 recommendations on all aspects of documenting the protocol), 1951 Alexander Clouter, Chris Janicki, Tom Petch, Robert Drake 1953 The Authors would also like to thanks the support from the OPSAWG 1954 Chairs and advisors. 1956 11. References 1958 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1959 April 1992. 1961 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1962 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1963 . 1965 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1966 "Randomness Recommendations for Security", RFC 1750, 1967 DOI 10.17487/RFC1750, December 1994, 1968 . 1970 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1971 RFC 2433, DOI 10.17487/RFC2433, October 1998, 1972 . 1974 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1975 RFC 2759, DOI 10.17487/RFC2759, January 2000, 1976 . 1978 [TheDraft] 1979 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 1980 1.78", June 1997, 1981 . 1983 Authors' Addresses 1984 Thorsten Dahm 1985 Google Inc 1986 1600 Amphitheatre Parkway 1987 Mountain View, CA 94043 1988 US 1990 EMail: thorstendlux@google.com 1992 Andrej Ota 1993 Google Inc 1994 1600 Amphitheatre Parkway 1995 Mountain View, CA 94043 1996 US 1998 EMail: aota@google.com 2000 Douglas C. Medway Gash 2001 Cisco Systems, Inc. 2002 170 West Tasman Dr. 2003 San Jose, CA 95134 2004 US 2006 Phone: +44 0208 8244508 2007 EMail: dcmgash@cisco.com 2009 David Carrel 2010 vIPtela, Inc. 2011 1732 North First St. 2012 San Jose, CA 95112 2013 US 2015 EMail: dcarrel@viptela.com 2017 Lol Grant 2019 EMail: lol.grant@gmail.com