idnits 2.17.1 draft-ietf-opsawg-tacacs-13.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 27, 2019) is 1850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations T. Dahm 3 Internet-Draft A. Ota 4 Intended status: Informational Google Inc 5 Expires: September 28, 2019 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 March 27, 2019 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-13 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 28, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 71 4. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 5 72 4.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.3. Single Connection Mode . . . . . . . . . . . . . . . . . 5 75 4.4. Session Completion . . . . . . . . . . . . . . . . . . . 6 76 4.5. Treatment of Enumerated Protocol Values . . . . . . . . . 7 77 4.6. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 7 78 4.7. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 8 79 4.8. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 9 80 4.9. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 11 81 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 12 82 5.1. The Authentication START Packet Body . . . . . . . . . . 12 83 5.2. The Authentication REPLY Packet Body . . . . . . . . . . 15 84 5.3. The Authentication CONTINUE Packet Body . . . . . . . . . 16 85 5.4. Description of Authentication Process . . . . . . . . . . 17 86 5.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 87 5.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 88 5.4.3. Aborting an Authentication Session . . . . . . . . . 21 89 6. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 90 6.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23 91 6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 92 7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 94 7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 95 8. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 96 8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 97 8.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 98 8.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 99 9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 101 10.1. General Security of the Protocol . . . . . . . . . . . . 37 102 10.2. Security of Authentication Sessions . . . . . . . . . . 38 103 10.3. Security of Authorization Sessions . . . . . . . . . . . 38 104 10.4. Security of Accounting Sessions . . . . . . . . . . . . 39 105 10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39 106 10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39 107 10.5.2. Connections and Obfuscation . . . . . . . . . . . . 40 108 10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41 109 10.5.4. Authorization . . . . . . . . . . . . . . . . . . . 41 110 10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 42 111 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 112 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 43 115 13.2. Informative References . . . . . . . . . . . . . . . . . 43 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 118 1. Introduction 120 Terminal Access Controller Access-Control System Plus (TACACS+) was 121 conceived initially as a general Authentication, Authorization and 122 Accounting protocol. It is primarily used today for Device 123 Administration: authenticating access to network devices, providing 124 central authorization of operations, and audit of those operations. 126 A wide range of TACACS+ clients and servers are already deployed in 127 the field. The TACACS+ protocol they are based on is defined in a 128 draft document that was originally intended for IETF publication. 129 This document is known as `The Draft' [TheDraft] . 131 It is intended that all implementations which conform to this 132 document will conform to `The Draft'. However, attention is drawn to 133 the following specific adjustments of the protocol specification from 134 'The Draft': 136 This document officially removes SENDPASS for security reasons. 138 The normative description of Legacy features such as ARAP and 139 outbound authentication has been removed, however, the required 140 enumerations are kept. 142 The Support for forwarding to an alternative daemon 143 (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated. 145 The TACACS+ protocol separates the functions of Authentication, 146 Authorization and Accounting. It allows for arbitrary length and 147 content authentication exchanges, to support future authentication 148 mechanisms. It is extensible to provide for site customization and 149 future development features, and it uses TCP to ensure reliable 150 delivery. The protocol allows the TACACS+ client to request very 151 fine-grained access control and allows the server to respond to each 152 component of that request. 154 The separation of authentication, authorization and accounting was a 155 key element of the design of TACACS+ protocol. Essentially it makes 156 TACACS+ a suite of three protocols. This document will address each 157 one in separate sections. Although TACACS+ defines all three, an 158 implementation or configuration is not required to employ all three. 159 Separating the elements is useful for Device Administration use case, 160 specifically, for authorization of individual commands in a session. 161 Note that there is no provision made at the protocol level for 162 association of an authentication to each authorization request. 164 2. Conventions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 RFC2119 169 [RFC2119]. 171 3. Technical Definitions 173 This section provides a few basic definitions that are applicable to 174 this document 176 Client 178 The client is any device, (often a Network Access Server) that 179 provides access services. The clients usually provide a character 180 mode front end and then allow the user to telnet or rlogin to another 181 host. 183 Server 185 The server receives TACACS+ protocol requests, and replies according 186 to its business model, in accordance with the flows defined in this 187 document. 189 Packet 191 All uses of the word packet in this document refer to TACACS+ 192 protocol packets unless explicitly noted otherwise. 194 4. TACACS+ Connections and Sessions 196 4.1. Connection 198 TACACS+ uses TCP for its transport. Server port 49 is allocated for 199 TACACS+ traffic. 201 4.2. Session 203 The concept of a session is used throughout this document. A TACACS+ 204 session is a single authentication sequence, a single authorization 205 exchange, or a single accounting exchange. 207 An accounting and authorization session will consist of a single pair 208 of packets (the request and its reply). An authentication session 209 may involve an arbitrary number of packets being exchanged. The 210 session is an operational concept that is maintained between the 211 TACACS+ client and server. It does not necessarily correspond to a 212 given user or user action. 214 4.3. Single Connection Mode 216 Single Connection Mode is intended to improve performance by allowing 217 a client to multiplex multiple session on a single TCP connection. 219 The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by 220 the client and server to negotiate the use of Single Connect Mode. 222 The client sets this flag, to indicate that it supports multiplexing 223 TACACS+ sessions over a single TCP connection. The client MUST NOT 224 send a second packet on a connection until single-connect status has 225 been established. 227 To indicate it will support Single Connection Mode, the server sets 228 this flag in the first reply packet in response to the first request 229 from a client. The server may set this flag even if the client does 230 not set it, but the client may ignore the flag and close the 231 connection after the session completes. 233 The flag is only relevant for the first two packets on a connection, 234 to allow the client and server to establish Single Connection Mode. 235 No provision is made for changing Single Connection Mode after the 236 first two packets: the client and server MUST ignore the flag after 237 the second packet on a connection. 239 If single Connection Mode has not been established in the first two 240 packets of a TCP connection, then both the client and the server 241 close the connection at the end of the first session. 243 The client negotiates Single Connection Mode to improve efficiency. 244 The server may refuse to allow Single Connection Mode for the client. 245 For example, it may not be appropriate to allocate a long-lasting TCP 246 connection to a specific client in some deployments. Even if the 247 server is configured to permit single Connection Mode for a specific 248 client, the server may close the connection. For example: a server 249 may be configured to time out a Single Connection Mode TCP Connection 250 after a specific period of inactivity to preserve its resources. The 251 client MUST accommodate such closures on a TCP session even after 252 Single Connection Mode has been established. 254 4.4. Session Completion 256 The REPLY packets defined for the packets types in the sections below 257 (Authentication, Authorization and Accounting) contain a status 258 field. The complete set of options for this field depend upon the 259 packet type, but all three REPLY packet types define values 260 representing PASS, ERROR and FAIL, which indicate the last packet of 261 a regular session (one which is not aborted). 263 The server responds with a PASS or a FAIL to indicate that the 264 processing of the request completed and the client can apply the 265 result (PASS or FAIL) to control the execution of the action which 266 prompted the request to be sent to the server. 268 The server responds with an ERROR to indicate that the processing of 269 the request did not complete. The client can not apply the result 270 and it MUST behave as if the server could not be connected to. For 271 example, the client tries alternative methods, if they are available, 272 such as sending the request to a backup server, or using local 273 configuration to determine whether the action which prompted the 274 request should be executed. 276 Refer to the section (Section 5.4.3) on Aborting Authentication 277 Sessions for details on handling additional status options. 279 When the session is complete, then the TCP connection should be 280 handled as follows, according to whether Single Connection Mode was 281 negotiated: 283 If Single Connection Mode was not negotiated, then the connection 284 should be closed 286 If Single Connection Mode was enabled, then the connection SHOULD be 287 left open (see section (Section 4.3) ), but may still be closed after 288 a timeout period to preserve deployment resources 289 If Single Connection Mode was enabled, but an ERROR occurred due to 290 connection issues (such as an incorrect secret, see section 291 (Section 4.7) ), then any further new sessions MUST NOT be accepted 292 on the connection. If there are any sessions that have already been 293 established then they MAY be completed. Once all active sessions are 294 completed then the connection MUST be closed. 296 It is recommended that client implementations provide robust schemes 297 for dealing with servers which cannot be connected to. Options 298 include providing a list of servers for redundancy, and an option for 299 a local fallback configuration if no servers can be reached. Details 300 will be implementation specific. 302 The client should manage connections and handle the case of a server 303 which establishes a connection, but does not respond. The exact 304 behavior is implementation specific. It is recommended that the 305 client should close the connection after a configurable timeout. 307 4.5. Treatment of Enumerated Protocol Values 309 This document describes various enumerated values in the packet 310 header and the headers for specific packet types. For example in the 311 Authentication start packet type, this document defines the action 312 field with three values TAC_PLUS_AUTHEN_LOGIN, TAC_PLUS_AUTHEN_CHPASS 313 and TAC_PLUS_AUTHEN_SENDAUTH. 315 If the server does not implement one of the defined options in a 316 packet that it receives, or it encounters an option that is not 317 listed in this document for a header field, then it should respond 318 with a ERROR and terminate the session. This will allow the client 319 to try a different option. 321 If an error occurs but the type of the incoming packet cannot be 322 determined, a packet with the identical cleartext header but with a 323 sequence number incremented by one and the length set to zero MUST be 324 returned to indicate an error. 326 4.6. Text Encoding 328 All text fields in TACACS+ MUST be printable US-ASCII, excepting 329 special consideration given to user field and data fields used for 330 passwords. 332 To ensure interoperability of current deployments, the TACACS+ client 333 and server MUST handle user fields and those data fields used for 334 passwords as 8-bit octet strings. The deployment operator MUST 335 ensure that consistent character encoding is applied from the end 336 client to the server. The encoding SHOULD be UTF-8, and other 337 encodings outside printable US-ASCII SHOULD be deprecated. 339 4.7. Data Obfuscation 341 The body of packets may be obfuscated. The following sections 342 describe the obfuscation method that is supported in the protocol. 343 In 'The Draft' this process was actually referred to as Encryption, 344 but the algorithm would not meet modern standards, and so will not be 345 termed as encryption in this document. 347 The obfuscation mechanism relies on a secret key, a shared secret 348 value that is known to both the client and the server. The secret 349 keys MUST remain secret. 351 Server implementations MUST allow a unique secret key to be 352 associated with every client. It is a site-dependent decision as to 353 whether the use of separate keys is appropriate. 355 The flag field may be set as follows: 357 TAC_PLUS_UNENCRYPTED_FLAG = 0x0 359 In this case, the packet body is obfuscated by XOR-ing it byte-wise 360 with a pseudo-random pad. 362 ENCRYPTED {data} = data ^ pseudo_pad 364 The packet body can then be de-obfuscated by XOR-ing it byte-wise 365 with a pseudo random pad. 367 data = ENCRYPTED {data} ^ pseudo_pad 369 The pad is generated by concatenating a series of MD5 hashes (each 16 370 bytes long) and truncating it to the length of the input data. 372 Whenever used in this document, MD5 refers to the "RSA Data Security, 373 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 374 . 376 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 378 The first MD5 hash is generated by concatenating the session_id, the 379 secret key, the version number and the sequence number and then 380 running MD5 over that stream. All of those input values are 381 available in the packet header, except for the secret key which is a 382 shared secret between the TACACS+ client and server. 384 The version number and session_id are used as extracted from the 385 header 387 Subsequent hashes are generated by using the same input stream, but 388 concatenating the previous hash value at the end of the input stream. 390 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 391 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 392 version, seq_no, MD5_n-1} 394 When a server detects that the secret(s) it has configured for the 395 device mismatch, it MUST return ERROR. For details of TCP connection 396 handling on ERROR, refer to section (Section 4.4) 398 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 400 In this case, the entire packet body is in cleartext. Obfuscation 401 and de-obfuscation are null operations. This method should be 402 avoided unless absolutely required for debug purposes, when tooling 403 does not permit de-obfuscation. 405 If deployment is configured for obfuscating a connection then the 406 request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. 408 After a packet body is de-obfuscated, the lengths of the component 409 values in the packet are summed. If the sum is not identical to the 410 cleartext datalength value from the header, the packet MUST be 411 discarded, and an ERROR signaled. For details of TCP connection 412 handling on ERROR, refer to section (Section 4.4) 414 Commonly such failures are seen when the keys are mismatched between 415 the client and the TACACS+ server. 417 4.8. The TACACS+ Packet Header 419 All TACACS+ packets begin with the following 12-byte header. The 420 header describes the remainder of the packet: 422 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 423 +----------------+----------------+----------------+----------------+ 424 |major | minor | | | | 425 |version| version| type | seq_no | flags | 426 +----------------+----------------+----------------+----------------+ 427 | | 428 | session_id | 429 +----------------+----------------+----------------+----------------+ 430 | | 431 | length | 432 +----------------+----------------+----------------+----------------+ 434 major_version 436 This is the major TACACS+ version number. 438 TAC_PLUS_MAJOR_VER := 0xc 440 minor_version 442 The minor TACACS+ version number. 444 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 446 TAC_PLUS_MINOR_VER_ONE := 0x1 448 type 450 This is the packet type. Legal values are: 452 TAC_PLUS_AUTHEN := 0x01 (Authentication) 454 TAC_PLUS_AUTHOR := 0x02 (Authorization) 456 TAC_PLUS_ACCT := 0x03 (Accounting) 458 seq_no 460 This is the sequence number of the current packet. The first packet 461 in a session MUST have the sequence number 1 and each subsequent 462 packet will increment the sequence number by one. Thus clients only 463 send packets containing odd sequence numbers, and TACACS+ servers 464 only send packets containing even sequence numbers. 466 The sequence number must never wrap i.e. if the sequence number 2^8-1 467 is ever reached, that session must terminate and be restarted with a 468 sequence number of 1. 470 flags 472 This field contains various bitmapped flags. 474 The flag bit: 476 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 478 This flag indicates that the sender did not obfuscate the body of the 479 packet. The application of this flag will be covered in the security 480 section (Section 10) . 482 This flag SHOULD be clear in all deployments. Modern network traffic 483 tools support encrypted traffic when configured with the shared 484 secret (see section below), so obfuscated mode can and SHOULD be used 485 even during test. 487 The single-connection flag: 489 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 491 This flag is used to allow a client and server to negotiate Single 492 Connection Mode. 494 session_id 496 The Id for this TACACS+ session. This field does not change for the 497 duration of the TACACS+ session. This number MUST be generated by a 498 cryptographically strong random number generation method. Failure to 499 do so will compromise security of the session. For more details 500 refer to RFC 4086 [RFC4086] 502 length 504 The total length of the packet body (not including the header). 506 4.9. The TACACS+ Packet Body 508 The TACACS+ body types are defined in the packet header. The next 509 sections of this document will address the contents of the different 510 TACACS+ bodies. The following general rules apply to all TACACS+ 511 body types: 513 - To signal that any variable length data fields are unused, their 514 length value is set to zero. Such fields MUST be ignored, and 515 treated as if not present. 517 - the lengths of data and message fields in a packet are specified 518 by their corresponding length fields, (and are not null 519 terminated.) 521 - All length values are unsigned and in network byte order. 523 5. Authentication 525 Authentication is the action of determining who a user (or entity) 526 is. Authentication can take many forms. Traditional authentication 527 employs a name and a fixed password. However, fixed passwords are 528 vulnerable security, so many modern authentication mechanisms utilize 529 "one-time" passwords or a challenge-response query. TACACS+ is 530 designed to support all of these, and be flexible enough to handle 531 any future mechanisms. Authentication generally takes place when the 532 user first logs in to a machine or requests a service of it. 534 Authentication is not mandatory; it is a site-configured option. 535 Some sites do not require it. Others require it only for certain 536 services (see authorization below). Authentication may also take 537 place when a user attempts to gain extra privileges, and must 538 identify himself or herself as someone who possesses the required 539 information (passwords, etc.) for those privileges. 541 5.1. The Authentication START Packet Body 543 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 544 +----------------+----------------+----------------+----------------+ 545 | action | priv_lvl | authen_type | authen_service | 546 +----------------+----------------+----------------+----------------+ 547 | user_len | port_len | rem_addr_len | data_len | 548 +----------------+----------------+----------------+----------------+ 549 | user ... 550 +----------------+----------------+----------------+----------------+ 551 | port ... 552 +----------------+----------------+----------------+----------------+ 553 | rem_addr ... 554 +----------------+----------------+----------------+----------------+ 555 | data... 556 +----------------+----------------+----------------+----------------+ 558 Packet fields are as follows: 560 action 562 This indicates the authentication action. Legal values are listed 563 below. 565 TAC_PLUS_AUTHEN_LOGIN := 0x01 567 TAC_PLUS_AUTHEN_CHPASS := 0x02 569 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 571 priv_lvl 573 This indicates the privilege level that the user is authenticating 574 as. Please refer to the Privilege Level section (Section 9) below. 576 authen_type 578 The type of authentication. Legal values are: 580 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 582 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 584 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 586 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 588 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 590 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 592 authen_service 594 This is the service that is requesting the authentication. Legal 595 values are: 597 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 599 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 601 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 603 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 605 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 607 TAC_PLUS_AUTHEN_SVC_PT := 0x05 609 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 611 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 612 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 614 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 616 The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization 617 application of this field that indicates that no authentication was 618 performed by the device. 620 The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as 621 opposed to ENABLE) to a client device. 623 The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE 624 authen_service, which refers to a service requesting authentication 625 in order to grant the user different privileges. This is comparable 626 to the Unix "su(1)" command, which substitutes the current user's 627 identity with another. An authen_service value of NONE is only to be 628 used when none of the other authen_service values are appropriate. 629 ENABLE may be requested independently, no requirements for previous 630 authentications or authorizations are imposed by the protocol. 632 Other options are included for legacy/backwards compatibility. 634 user, user_len 636 The username is optional in this packet, depending upon the class of 637 authentication. If it is absent, the client MUST set user_len to 0. 638 If included, the user_len indicates the length of the user field, in 639 bytes. 641 port, port_len 643 The printable US-ASCII name of the client port on which the 644 authentication is taking place, and its length in bytes. The value 645 of this field is client specific. (For example, Cisco uses "tty10" 646 to denote the tenth tty line and "Async10" to denote the tenth async 647 interface). The port_len indicates the length of the port field, in 648 bytes. 650 rem_addr, rem_addr_len 652 A printable US-ASCII string indicating the remote location from which 653 the user has connected to the client. It is intended to hold a 654 network address if the user is connected via a network, a caller ID 655 is the user is connected via ISDN or a POTS, or any other remote 656 location information that is available. This field is optional 657 (since the information may not be available). The rem_addr_len 658 indicates the length of the user field, in bytes. 660 data, data_len 662 This field is used to send data appropriate for the action and 663 authen_type. It is described in more detail in the section Common 664 Authentication flows (Section 5.4.2) . The data_len indicates the 665 length of the data field, in bytes. 667 5.2. The Authentication REPLY Packet Body 669 The TACACS+ server sends only one type of authentication packet (a 670 REPLY packet) to the client. 672 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 673 +----------------+----------------+----------------+----------------+ 674 | status | flags | server_msg_len | 675 +----------------+----------------+----------------+----------------+ 676 | data_len | server_msg ... 677 +----------------+----------------+----------------+----------------+ 678 | data ... 679 +----------------+----------------+ 681 status 683 The current status of the authentication. Legal values are: 685 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 687 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 689 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 691 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 693 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 695 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 697 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 699 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 701 flags 703 Bitmapped flags that modify the action to be taken. The following 704 values are defined: 706 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 708 server_msg, server_msg_len 710 A message to be displayed to the user. This field is optional. The 711 printable US-ASCII charset MUST be used. The server_msg_len 712 indicates the length of the server_msg field, in bytes. 714 data, data_len 716 This field holds data that is a part of the authentication exchange 717 and is intended for the client, not the user. Examples of its use 718 are shown in the section Common Authentication flows (Section 5.4.2) 719 . The data_len indicates the length of the data field, in bytes. 721 5.3. The Authentication CONTINUE Packet Body 723 This packet is sent from the client to the server following the 724 receipt of a REPLY packet. 726 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 727 +----------------+----------------+----------------+----------------+ 728 | user_msg len | data_len | 729 +----------------+----------------+----------------+----------------+ 730 | flags | user_msg ... 731 +----------------+----------------+----------------+----------------+ 732 | data ... 733 +----------------+ 735 user_msg, user_msg_len 737 This field is the string that the user entered, or the client 738 provided on behalf of the user, in response to the server_msg from a 739 REPLY packet. The user_len indicates the length of the user field, 740 in bytes. 742 data, data_len 744 This field carries information that is specific to the action and the 745 authen_type for this session. Valid uses of this field are described 746 below. The data_len indicates the length of the data field, in 747 bytes. 749 flags 751 This holds the bitmapped flags that modify the action to be taken. 752 The following values are defined: 754 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 756 5.4. Description of Authentication Process 758 The action, authen_type and authen_service fields (described above) 759 combine to indicate what kind of authentication is to be performed. 760 Every authentication START, REPLY and CONTINUE packet includes a data 761 field. The use of this field is dependent upon the kind of the 762 Authentication. 764 This document defines a core set of authentication flows to be 765 supported by TACACS+. Each authentication flow consists of a START 766 packet. The server responds either with a request for more 767 information (GETDATA, GETUSER or GETPASS) or a termination PASS, 768 FAIL, ERROR or RESTART. The actions and meanings when the server 769 sends a RESTART or ERROR are common and are described further below. 771 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 772 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 773 then authentication continues and the server SHOULD provide 774 server_msg content for the client to prompt the user for more 775 information. The client MUST then return a CONTINUE packet 776 containing the requested information in the user_msg field. 778 The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a 779 request for username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request 780 for password. The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic 781 request for more information to flexibly support future requirements. 783 If the information being requested by the server form the client is 784 sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO 785 flag. When the client queries the user for the information, the 786 response MUST NOT be echoed as it is entered. 788 The data field is only used in the REPLY where explicitly defined 789 below. 791 5.4.1. Version Behaviour 793 The TACACS+ protocol is versioned to allow revisions while 794 maintaining backwards compatibility. The version number is in every 795 packet header. The changes between minor_version 0 and 1 apply only 796 to the authentication process, and all deal with the way that CHAP 797 and PAP authentications are handled. minor_version 1 may only be used 798 for authentication kinds that explicitly call for it in the table 799 below: 801 LOGIN CHPASS SENDAUTH 802 ASCII v0 v0 - 803 PAP v1 - v1 804 CHAP v1 - v1 805 MS-CHAPv1/2 v1 - v1 807 The '-' symbol represents that the option is not valid. 809 All authorisation and accounting and ASCII authentication use 810 minor_version number of 0. 812 PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange 813 is a single START packet from the client and a single REPLY from the 814 server. 816 The removal of SENDPASS was prompted by security concerns, and is no 817 longer considered part of the TACACS+ protocol. 819 5.4.2. Common Authentication Flows 821 This section describes common authentication flows. If the server 822 does not implement an option, it MUST respond with 823 TAC_PLUS_AUTHEN_STATUS_FAIL. 825 5.4.2.1. ASCII Login 827 action = TAC_PLUS_AUTHEN_LOGIN 828 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 829 minor_version = 0x0 831 This is a standard ASCII authentication. The START packet MAY 832 contain the username. If the user does not include the username then 833 the server MUST obtain it from the client with a CONTINUE 834 TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user does not provide a 835 username then the server can send another 836 TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server MUST limit the 837 number of retries that are permitted, recommended limit is three 838 attempts. When the server has the username, it will obtain the 839 password using a continue with TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII 840 login uses the user_msg field for both the username and password. 841 The data fields in both the START and CONTINUE packets are not used 842 for ASCII logins, any content MUST be ignored. The session is 843 composed of a single START followed by zero or more pairs of REPLYs 844 and CONTINUEs, followed by a final REPLY indicating PASS, FAIL or 845 ERROR. 847 5.4.2.2. PAP Login 849 action = TAC_PLUS_AUTHEN_LOGIN 850 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 851 minor_version = 0x1 853 The entire exchange MUST consist of a single START packet and a 854 single REPLY. The START packet MUST contain a username and the data 855 field MUST contain the PAP ASCII password. A PAP authentication only 856 consists of a username and password RFC 1334 [RFC1334] . The REPLY 857 from the server MUST be either a PASS, FAIL or ERROR. 859 5.4.2.3. CHAP login 861 action = TAC_PLUS_AUTHEN_LOGIN 862 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 863 minor_version = 0x1 865 The entire exchange MUST consist of a single START packet and a 866 single REPLY. The START packet MUST contain the username in the user 867 field and the data field is a concatenation of the PPP id, the 868 challenge and the response. 870 The length of the challenge value can be determined from the length 871 of the data field minus the length of the id (always 1 octet) and the 872 length of the response field (always 16 octets). 874 To perform the authentication, the server calculates the PPP hash as 875 defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then 876 compare that value with the response. The MD5 algorithm option is 877 always used. The REPLY from the server MUST be a PASS, FAIL or 878 ERROR. 880 The selection of the challenge and its length are not an aspect of 881 the TACACS+ protocol. However, it is strongly recommended that the 882 client/endstation interaction is configured with a secure challenge. 883 The TACACS+ server can help by rejecting authentications where the 884 challenge is below a minimum length (Minimum recommended is 8 bytes). 886 5.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 5.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 5.4.2.6. Enable Requests 935 action = TAC_PLUS_AUTHEN_LOGIN 936 priv_lvl = implementation dependent 937 authen_type = not used 938 service = TAC_PLUS_AUTHEN_SVC_ENABLE 940 This is an ENABLE request, used to change the current running 941 privilege level of a user. The exchange MAY consist of multiple 942 messages while the server collects the information it requires in 943 order to allow changing the principal's privilege level. This 944 exchange is very similar to an ASCII login (Section 5.4.2.1) . 946 In order to readily distinguish enable requests from other types of 947 request, the value of the authen_service field MUST be set to 948 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 949 set to this value when requesting any other operation. 951 5.4.2.7. ASCII change password request 953 action = TAC_PLUS_AUTHEN_CHPASS 954 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 956 This exchange consists of multiple messages while the server collects 957 the information it requires in order to change the user's password. 958 It is very similar to an ASCII login. The status value 959 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 960 "new" password. It MAY be sent multiple times. When requesting the 961 "old" password, the status value MUST be set to 962 TAC_PLUS_AUTHEN_STATUS_GETDATA. 964 5.4.3. Aborting an Authentication Session 966 The client may prematurely terminate a session by setting the 967 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 968 flag is set, the data portion of the message may contain an ASCII 969 message explaining the reason for the abort. This information will 970 be handled by the server according to the requirements of the 971 deployment. The session is terminated, for more details about 972 session termination, refer to section (Section 4.4) 974 In cases of PASS, FAIL or ERROR, the server can insert a message into 975 server_msg to be displayed to the user. 977 The Draft `The Draft' [TheDraft] defined a mechanism to direct 978 authentication requests to an alternative server. This mechanism is 979 regarded as insecure, is deprecated, and not covered here. The 980 client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as 981 TAC_PLUS_AUTHEN_STATUS_FAIL 983 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 984 indicating that it is experiencing an unrecoverable error and the 985 authentication will proceed as if that host could not be contacted. 986 The data field may contain a message to be printed on an 987 administrative console or log. 989 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 990 authentication sequence is restarted with a new START packet from the 991 client, with new session Id, and seq_no set to 1. This REPLY packet 992 indicates that the current authen_type value (as specified in the 993 START packet) is not acceptable for this session. The client may try 994 an alternative authen_type. 996 If a client does not implement TAC_PLUS_AUTHEN_STATUS_RESTART option, 997 then it MUST process the response as if the status was 998 TAC_PLUS_AUTHEN_STATUS_FAIL. 1000 6. Authorization 1002 In the TACACS+ Protocol, authorization is the action of determining 1003 what a user is allowed to do. Generally authentication precedes 1004 authorization, though it is not mandatory that a client use the same 1005 service for authentication that it will use for authorization. An 1006 authorization request may indicate that the user is not authenticated 1007 (we don't know who they are). In this case it is up to the server to 1008 determine, according to its configuration, if an unauthenticated user 1009 is allowed the services in question. 1011 Authorization does not merely provide yes or no answers, but it may 1012 also customize the service for the particular user. A common use of 1013 authorization is to provision a shell session when a user first logs 1014 into a device to administer it. The TACACS+ server might respond to 1015 the request by allowing the service, but placing a time restriction 1016 on the login shell. For a list of common attributes used in 1017 authorization, see the Authorization Attributes section (Section 8.2) 1018 . 1020 In the TACACS+ protocol an authorization is always a single pair of 1021 messages: a REQUEST from the client followed by a REPLY from the 1022 server. 1024 The authorization REQUEST message contains a fixed set of fields that 1025 indicate how the user was authenticated and a variable set of 1026 arguments that describe the services and options for which 1027 authorization is requested. 1029 The REPLY contains a variable set of response arguments (attribute- 1030 value pairs) that can restrict or modify the client's actions. 1032 6.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 1077 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1079 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 9) 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 5) 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 5) 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 5) above. The port_len indicates the length of the port 1124 field, in bytes. 1126 rem_addr, rem_addr_len 1128 This field matches the rem_addr field in the authentication section 1129 (Section 5) above. The rem_addr_len indicates the length of the port 1130 field, in bytes. 1132 arg_cnt 1134 The number of authorization arguments to follow 1136 arg_1 ... arg_N, arg_1_len .... arg_N_len 1138 The arguments are the primary elements of the authorization 1139 interaction. In the request packet they describe the specifics of 1140 the authorization that is being requested. Each argument is encoded 1141 in the packet as a single arg filed (arg_1... arg_N) with a 1142 corresponding length fields (which indicates the length of each 1143 argument in bytes). 1145 The authorization arguments in both the REQUEST and the REPLY are 1146 attribute-value pairs. The attribute and the value are in a single 1147 printable US-ASCII string and are separated by either a "=" (0X3D) or 1148 a "*" (0X2A). The equals sign indicates a mandatory argument. The 1149 asterisk indicates an optional one. 1151 It is not legal for an attribute name to contain either of the 1152 separators. It is legal for attribute values to contain the 1153 separators. This means that the arguments must be parsed until the 1154 first separator is encountered, all characters in the argument, after 1155 this separator, are interpreted as the argument value. 1157 Optional arguments are ones that may be disregarded by either client 1158 or server. Mandatory arguments require that the receiving side can 1159 handle the attribute, that is: its implementation and configuration 1160 includes the details of how to act on it. If the client receives a 1161 mandatory argument that it cannot handle, it MUST consider the 1162 authorization to have failed. It is legal to send an attribute-value 1163 pair with a zero length value. 1165 Attribute-value strings are not NULL terminated, rather their length 1166 value indicates their end. The maximum length of an attribute-value 1167 string is 255 characters. The minimum is two characters (one name- 1168 value character and the separator) 1170 Though the attributes allow extensibility, a common core set of 1171 authorization attributes SHOULD be supported by clients and servers, 1172 these are listed in the Authorization Attributes (Section 8.2) 1173 section below. 1175 6.2. The Authorization REPLY Packet Body 1177 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 1178 +----------------+----------------+----------------+----------------+ 1179 | status | arg_cnt | server_msg len | 1180 +----------------+----------------+----------------+----------------+ 1181 + data_len | arg_1_len | arg_2_len | 1182 +----------------+----------------+----------------+----------------+ 1183 | ... | arg_N_len | server_msg ... 1184 +----------------+----------------+----------------+----------------+ 1185 | data ... 1186 +----------------+----------------+----------------+----------------+ 1187 | arg_1 ... 1188 +----------------+----------------+----------------+----------------+ 1189 | arg_2 ... 1190 +----------------+----------------+----------------+----------------+ 1191 | ... 1192 +----------------+----------------+----------------+----------------+ 1193 | arg_N ... 1194 +----------------+----------------+----------------+----------------+ 1196 status This field indicates the authorization status 1198 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1200 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1202 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1204 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1206 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1208 server_msg, server_msg_len 1210 This is a printable US-ASCII string that may be presented to the 1211 user. The server_msg_len indicates the length of the server_msg 1212 field, in bytes. 1214 data, data_len 1216 This is a printable US-ASCII string that may be presented on an 1217 administrative display, console or log. The decision to present this 1218 message is client specific. The data_len indicates the length of the 1219 data field, in bytes. 1221 arg_cnt 1222 The number of authorization arguments to follow. 1224 arg_1 ... arg_N, arg_1_len .... arg_N_len 1226 The arguments describe the specifics of the authorization that is 1227 being requested. For details of the content of the args, refer to: 1228 Authorization Attributes (Section 8.2) section below. Each argument 1229 is encoded in the packet as a single arg field (arg_1... arg_N) with 1230 a corresponding length fields (which indicates the length of each 1231 argument in bytes). 1233 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested 1234 authorization MUST be denied. 1236 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1237 arguments specified in the request are authorized and the arguments 1238 in the response MUST be applied according to the rules described 1239 above. 1241 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client 1242 MUST use the authorization attribute-value pairs (if any) in the 1243 response, instead of the authorization attribute-value pairs from the 1244 request. 1246 To approve the authorization with no modifications, the server sets 1247 the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. 1249 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1250 on the server. For the differences between ERROR and FAIL, refer to 1251 section Session Completion (Section 4.4) . None of the arg values 1252 have any relevance if an ERROR is set, and must be ignored. 1254 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1255 arg_cnt MUST be 0. In that case, the actions to be taken and the 1256 contents of the data field are identical to the 1257 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1259 7. Accounting 1261 Accounting is typically the third action after authentication and 1262 authorization. But again, neither authentication nor authorization 1263 is required. Accounting is the action of recording what a user is 1264 doing, and/or has done. Accounting in TACACS+ can serve two 1265 purposes: It may be used as an auditing tool for security services. 1266 It may also be used to account for services used, such as in a 1267 billing environment. To this end, TACACS+ supports three types of 1268 accounting records. Start records indicate that a service is about 1269 to begin. Stop records indicate that a service has just terminated, 1270 and Update records are intermediate notices that indicate that a 1271 service is still being performed. TACACS+ accounting records contain 1272 all the information used in the authorization records, and also 1273 contain accounting specific information such as start and stop times 1274 (when appropriate) and resource usage information. A list of 1275 accounting attributes is defined in the accounting section 1276 (Section 7) . 1278 7.1. The Account REQUEST Packet Body 1280 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 1281 +----------------+----------------+----------------+----------------+ 1282 | flags | authen_method | priv_lvl | authen_type | 1283 +----------------+----------------+----------------+----------------+ 1284 | authen_service | user_len | port_len | rem_addr_len | 1285 +----------------+----------------+----------------+----------------+ 1286 | arg_cnt | arg_1_len | arg_2_len | ... | 1287 +----------------+----------------+----------------+----------------+ 1288 | arg_N_len | user ... 1289 +----------------+----------------+----------------+----------------+ 1290 | port ... 1291 +----------------+----------------+----------------+----------------+ 1292 | rem_addr ... 1293 +----------------+----------------+----------------+----------------+ 1294 | arg_1 ... 1295 +----------------+----------------+----------------+----------------+ 1296 | arg_2 ... 1297 +----------------+----------------+----------------+----------------+ 1298 | ... 1299 +----------------+----------------+----------------+----------------+ 1300 | arg_N ... 1301 +----------------+----------------+----------------+----------------+ 1303 flags 1305 This holds bitmapped flags. 1307 TAC_PLUS_ACCT_FLAG_START := 0x02 1309 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1311 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1313 All other fields are defined in the authorization and authentication 1314 sections above and have the same semantics. They provide details for 1315 the conditions on the client, and authentication context, so that 1316 these details may be logged for accounting purposes. 1318 See section 12 Accounting Attribute-value Pairs for the dictionary of 1319 attributes relevant to accounting. 1321 7.2. The Accounting REPLY Packet Body 1323 The purpose of accounting is to record the action that has occurred 1324 on the client. The server MUST reply with success only when the 1325 accounting request has been recorded. If the server did not record 1326 the accounting request then it MUST reply with ERROR. 1328 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 1329 +----------------+----------------+----------------+----------------+ 1330 | server_msg len | data_len | 1331 +----------------+----------------+----------------+----------------+ 1332 | status | server_msg ... 1333 +----------------+----------------+----------------+----------------+ 1334 | data ... 1335 +----------------+ 1337 status 1339 This is the return status. Values are: 1341 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1343 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1345 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1347 server_msg, server_msg_len 1349 This is a printable US-ASCII string that may be presented to the 1350 user. The server_msg_len indicates the length of the server_msg 1351 field, in bytes. 1353 data, data_len 1355 This is a printable US-ASCII string that may be presented on an 1356 administrative display, console or log. The decision to present this 1357 message is client specific. The data_len indicates the length of the 1358 data field, in bytes. 1360 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1361 to be taken and the contents of the data field are identical to the 1362 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1364 TACACS+ accounting is intended to record various types of events on 1365 clients, for example: login sessions, command entry, and others as 1366 required by the client implementation. These events are collectively 1367 referred to in `The Draft' [TheDraft] as "tasks". 1369 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1370 accounting message. Start messages will only be sent once when a 1371 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1372 a stop record and that the task has terminated. The 1373 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1375 Summary of Accounting Packets 1377 +----------+-------+-------+-------------+-------------------------+ 1378 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1379 +----------+-------+-------+-------------+-------------------------+ 1380 | 0 | 0 | 0 | 0 | INVALID | 1381 | 0 | 0 | 1 | 2 | Start Accounting Record | 1382 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1383 | 0 | 1 | 1 | 6 | INVALID | 1384 | 1 | 0 | 0 | 8 | Watchdog, no update | 1385 | 1 | 0 | 1 | A | Watchdog, with update | 1386 | 1 | 1 | 0 | C | INVALID | 1387 | 1 | 1 | 1 | E | INVALID | 1388 +----------+-------+-------+-------------+-------------------------+ 1390 The START and STOP flags are mutually exclusive. 1392 The WATCHDOG flag is used by the client to communicate ongoing status 1393 of a long-running task. Update records are sent at the client's 1394 discretion. The frequency of the update depends upon the intended 1395 application: A watchdog to provide progress indication will require 1396 higher frequency than a daily keep-alive. When the WATCHDOG flag is 1397 set along with the START flag, it indicates that the update record 1398 provides additional or updated arguments from the original START 1399 record. If the START flag is not set, then this indicates only that 1400 task is still running, and no new information is provided (servers 1401 MUST ignore any arguments). The STOP flag MUST NOT be set in 1402 conjunction with the WATCHDOG flag. 1404 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1405 requests an INVALID option. 1407 8. Attribute-Value Pairs 1409 TACACS+ is intended to be an extensible protocol. The attributes 1410 used in Authorization and Accounting are not limited by this 1411 document. Some attributes are defined below for common use cases, 1412 clients MUST use these attributes when supporting the corresponding 1413 use cases. 1415 8.1. Value Encoding 1417 All attribute values are encoded as printable US-ASCII strings. The 1418 following type representations SHOULD be followed 1420 Numeric 1422 All numeric values in an attribute-value string are provided as 1423 decimal printable US-ASCII numbers, unless otherwise stated. 1425 Boolean 1427 All boolean attributes are encoded as printable US-ASCII with values 1428 "true" or "false". 1430 IP-Address 1432 It is recommended that hosts be specified as a IP address so as to 1433 avoid any ambiguities. IPV4 address are specified as US-ASCII octet 1434 numerics separated by dots ('.'), IPV6 address text representation 1435 defined in RFC 4291 [RFC4291] 1437 Date Time 1439 Absolute date/times are specified in seconds since the epoch, 12:00am 1440 Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is 1441 specified. Stardate is canonically inconsistent and so SHOULD NOT be 1442 used. 1444 String 1446 Many values have no specific type representation and so are 1447 interpreted as plain strings. 1449 Empty Values 1451 Attributes may be submitted with no value, in which case they consist 1452 of the name and the mandatory or optional separator. For example, 1453 the attribute "cmd" which has no value is transmitted as a string of 1454 four characters "cmd=" 1456 8.2. Authorization Attributes 1458 service (String) 1460 The primary service. Specifying a service attribute indicates that 1461 this is a request for authorization or accounting of that service. 1463 For example: "shell", "tty-server", "connection", "system" and 1464 "firewall". This attribute MUST always be included. 1466 protocol (String) 1468 the protocol field may be used to indicate a subset of a service. 1470 cmd (String) 1472 a shell (exec) command. This indicates the command name of the 1473 command that is to be run. The "cmd" attribute MUST be specified if 1474 service equals "shell". 1476 Authorization of shell commands is a common use-case for the TACACS+ 1477 protocol. Command Authorization generally takes one of two forms: 1478 session-based and command-based. 1480 For session-based shell authorization, the "cmd" argument will have 1481 an empty value. The client determines which commands are allowed in 1482 a session according to the arguments present in the authorization. 1484 In command-based authorization, the client requests that the server 1485 determine whether a command is allowed by making an authorization 1486 request for each command. The "cmd" argument will have the command 1487 name as its value. 1489 cmd-arg (String) 1491 an argument to a shell (exec) command. This indicates an argument 1492 for the shell command that is to be run. Multiple cmd-arg attributes 1493 may be specified, and they are order dependent. 1495 acl (Numeric) 1497 printable US-ASCII number representing a connection access list. 1498 Applicable only to session-based shell authorization. 1500 inacl (String) 1502 printable US-ASCII identifier for an interface input access list. 1504 outacl (String) 1506 printable US-ASCII identifier for an interface output access list. 1508 addr (IP-Address) 1510 a network address 1511 addr-pool (String) 1513 The identifier of an address pool from which the client can assign an 1514 address. 1516 routing (Boolean) 1518 Specifies whether routing information is to be propagated to, and 1519 accepted from this interface. 1521 route (String) 1523 Indicates an IPv4 route that is to be applied to this interface. 1524 Values MUST be of the form " []". 1525 If a is not specified, the resulting route is via the 1526 requesting peer. 1528 timeout (Numeric) 1530 an absolute timer for the connection (in minutes). A value of zero 1531 indicates no timeout. 1533 idletime (Numeric) 1535 an idle-timeout for the connection (in minutes). A value of zero 1536 indicates no timeout. 1538 autocmd (String) 1540 an auto-command to run. Applicable only to session-based shell 1541 authorization. 1543 noescape (Boolean) 1545 Prevents user from using an escape character. Applicable only to 1546 session-based shell authorization. 1548 nohangup (Boolean) 1550 Boolean. Do not disconnect after an automatic command. Applicable 1551 only to session-based shell authorization. 1553 priv-lvl (Numeric) 1555 privilege level to be assigned. Please refer to the Privilege Level 1556 section (Section 9) below. 1558 remote_user (String) 1559 remote userid (authen_method must have the value 1560 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1561 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1562 remote_user and remote_host attributes will provide the remote user 1563 and host information to enable rhost style authorization. The 1564 response may request that a privilege level be set for the user. 1566 remote_host (String) 1568 remote host (authen_method must have the value 1569 TAC_PLUS_AUTHEN_METH_RCMD) 1571 8.3. Accounting Attributes 1573 The following attributes are defined for TACACS+ accounting only. 1574 They MUST precede any attribute-value pairs that are defined in the 1575 authorization section (Section 6) above. 1577 task_id (String) 1579 Start and stop records for the same event MUST have matching task_id 1580 attribute values. The client MUST ensure that active task_ids are 1581 not duplicated: a client MUST NOT reuse a task_id a start record 1582 until it has sent a stop record for that task_id. Servers MUST NOT 1583 make assumptions about the format of a task_id. 1585 start_time (Date Time) 1587 The time the action started (in seconds since the epoch.). 1589 stop_time (Date Time) 1591 The time the action stopped (in seconds since the epoch.) 1593 elapsed_time (Numeric) 1595 The elapsed time in seconds for the action. 1597 timezone (String) 1599 The timezone abbreviation for all timestamps included in this packet. 1600 A database of timezones is maintained here: TZDB [TZDB] 1602 event (String) 1604 Used only when "service=system". Current values are "net_acct", 1605 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1607 These indicate system-level changes. The flags field SHOULD indicate 1608 whether the service started or stopped. 1610 reason (String) 1612 Accompanies an event attribute. It describes why the event occurred. 1614 bytes (Numeric) 1616 The number of bytes transferred by this action 1618 bytes_in (Numeric) 1620 The number of bytes transferred by this action from the endstation to 1621 the client port 1623 bytes_out (Numeric) 1625 The number of bytes transferred by this action from the client to the 1626 endstation port 1628 paks (Numeric) 1630 The number of packets transferred by this action. 1632 paks_in (Numeric) 1634 The number of input packets transferred by this action from the 1635 endstation to the client port. 1637 paks_out (Numeric) 1639 The number of output packets transferred by this action from the 1640 client port to the endstation. 1642 err_msg (String) 1644 A printable US-ASCII string describing the status of the action. 1646 9. Privilege Levels 1648 The TACACS+ Protocol supports flexible authorization schemes through 1649 the extensible attributes. 1651 One scheme is built into the protocol and has been extensively used 1652 for Session-based shell authorization: Privilege Levels. Privilege 1653 Levels are ordered values from 0 to 15 with each level being a 1654 superset of the next lower value. Configuration and implementation 1655 of the client will map actions (such as the permission to execute of 1656 specific commands) to different privilege levels. Pre-defined values 1657 are: 1659 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1661 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1663 TAC_PLUS_PRIV_LVL_USER := 0x01 1665 TAC_PLUS_PRIV_LVL_MIN := 0x00 1667 A Privilege level can be assigned to a shell (EXEC) session when it 1668 starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will permit 1669 the actions associated with this level to be executed. This 1670 privilege level is returned by the Server in a session-based shell 1671 authorization (when "service" equals "shell" and "cmd" is empty). 1672 When a user required to perform actions that are mapped to a higher 1673 privilege level, then an ENABLE type reauthentication can be 1674 initiated by the client. The client will insert the required 1675 privilege level into the authentication header for enable 1676 authentication request. 1678 The use of Privilege levels to determine session-based access to 1679 commands and resources is not mandatory for clients. Although the 1680 privilege level scheme is widely supported, its lack of flexibility 1681 in requiring a single monotonic hierarchy of permissions means that 1682 other session-based command authorization schemes have evolved, and 1683 so it is no longer mandatory for clients to use it. However, it is 1684 still common enough that it SHOULD be supported by servers. 1686 10. Security Considerations 1688 The original TACACS+ Draft `The Draft' [TheDraft] from 1998 did not 1689 address all of the key security concerns which are considered when 1690 designing modern standards. This section addresses known limitations 1691 and concerns which will impact overall security of the protocol and 1692 systems where this protocol is deployed to manage central 1693 authentication, authorization or accounting for network device 1694 administration. 1696 Multiple implementations of the protocol described in the original 1697 TACACS+ Draft `The Draft' [TheDraft] have been deployed. As the 1698 protocol was never standardized, current implementations may be 1699 incompatible in non-obvious ways, giving rise to additional security 1700 risks. This section does not claim to enumerate all possible 1701 security vulnerabilities. 1703 10.1. General Security of the Protocol 1705 TACACS+ protocol does not include a security mechanism that would 1706 meet modern-day requirements. Support for MD5-based crypto pad 1707 encryption fails to provide any kind of transport integrity, which 1708 presents at least the following risks: 1710 Accounting information may be modified by the man-in-the-middle 1711 attacker, making such logs unsuitable and untrustable for auditing 1712 purposes. 1714 Only the body of the request is obfuscated which leaves all header 1715 fields open to trivial modification by the man-in-the-middle 1716 attacker. For this reason, deployments SHOULD NOT use connections 1717 with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the Best Practices 1718 section (Section 10.5) . 1720 Invalid or misleading values may be inserted by the man-in-the- 1721 middle attacker in various fields at known offsets to try and 1722 circumvent the authentication or authorization checks even inside 1723 the obfuscated body. 1725 While the protocol provides some measure of transport privacy, it is 1726 vulnerable to at least the following attacks: 1728 Brute force attacks exploiting increased efficiency of MD5 digest 1729 computation. 1731 Known plaintext attacks which may decrease the cost of brute force 1732 attack. 1734 Chosen plaintext attacks which may decrease the cost of a brute 1735 force attack. 1737 No forward secrecy. 1739 Even though, to the best knowledge of authors, this method of 1740 encryption wasn't rigorously tested, enough information is available 1741 that it is best referred to as "obfuscation" and not "encryption". 1743 For these 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. Attackers who can guess 1746 the key or otherwise break the obfuscation will gain unrestricted and 1747 undetected access to all TACACS+ traffic. Ensuring that a 1748 centralized AAA system like TACACS+ is deployed on a secured 1749 transport is essential to managing the security risk of such an 1750 attack. 1752 The following parts of this section enumerate only the session- 1753 specific risks which are in addition to general risk associated with 1754 bare obfuscation and lack of integrity checking. 1756 10.2. Security of Authentication Sessions 1758 Authentication sessions SHOULD be used via a secure transport (see 1759 Best Practices section (Section 10.5) ) as the man-in-the-middle 1760 attack may completely subvert them. Even CHAP, which may be 1761 considered resistant to password interception, is unsafe as it does 1762 not protect the username from a trivial man-in-the-middle attack. 1764 This document deprecates the redirection mechanism using the 1765 TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the 1766 original draft. As part of this process, the secret key for a new 1767 server was sent to the client. This public exchange of secret keys 1768 means that once one session is broken, it may be possible to leverage 1769 that key to attacking connections to other servers. This mechanism 1770 SHOULD NOT be used in modern deployments. It MUST NOT be used 1771 outside a secured deployment. 1773 10.3. Security of Authorization Sessions 1775 Authorization sessions SHOULD be used via a secure transport (see 1776 Best Practices section (Section 10.5) ) as it's trivial to execute a 1777 successful man-in-the-middle attacks that changes well-known 1778 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 without 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 10.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 10.5. TACACS+ Best Practices 1826 With respect to the observations about the security issues described 1827 above, a network administrator MUST NOT rely on the obfuscation of 1828 the TACACS+ protocol and TACACS+ MUST be deployed over networks which 1829 ensure privacy and integrity of the communication. TACACS+ MUST be 1830 used within a secure deployment. Failure to do so will impact 1831 overall network security. 1833 TACACS+ SHOULD be deployed over a network which is separated from 1834 other traffic. 1836 The following recommendations impose restrictions on how the protocol 1837 is applied. These restrictions were not imposed in the original 1838 draft. New implementations, and upgrades of current implementations, 1839 MUST implement these recommendations. 1841 10.5.1. Shared Secrets 1843 TACACS+ servers and clients MUST treat shared secrets as sensitive 1844 data to be managed securely, as would be expected for other sensitive 1845 data such as identity credential information. TACACS+ servers MUST 1846 NOT leak sensitive data. For example, TACACS+ servers should not 1847 expose shared secrets in logs. 1849 TACACS+ servers MUST allow a dedicated secret key to be defined for 1850 each client. 1852 TACACS+ servers SHOULD warn administrators if secret keys are not 1853 unique per client. 1855 TACACS+ server administrators SHOULD always define a secret for each 1856 client. 1858 TACACS+ servers and clients MUST support shared keys that are at 1859 least 32 characters long. 1861 TACACS+ servers MUST support policy to define minimum complexity for 1862 shared keys. 1864 TACACS+ clients SHOULD NOT allow servers to be configured without 1865 shared secret key, or shared key that is less than 16 characters 1866 long. 1868 TACACS+ server administrators SHOULD configure secret keys of minimum 1869 16 characters length. 1871 TACACS+ server administrators SHOULD change secret keys at regular 1872 intervals. 1874 10.5.2. Connections and Obfuscation 1876 TACACS+ servers MUST allow the definition of individual clients. The 1877 servers MUST only accept network connection attempts from these 1878 defined, known clients. 1880 TACACS+ servers MUST reject connections with 1881 TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on 1882 the server for the client requesting the connection. 1884 If an invalid shared secret is detected when processing packets for a 1885 client, TACACS+ servers MUST NOT accept any new sessions on that 1886 connection. TACACS+ servers MUST terminate the connection on 1887 completion of any sessions that were previously established with a 1888 valid shared secret on that connection. 1890 TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG when a secret 1891 is defined. Clients MUST be implemented in a way that requires 1892 explicit configuration to enable the use of 1893 TAC_PLUS_UNENCRYPTED_FLAG. 1895 When a TACACS+ client receives responses from servers where: 1897 the response packet was received from the server configured with 1898 shared key, but the packet jas TAC_PLUS_UNENCRYPTED_FLAG set. 1900 the response packet was received from the server configured not to 1901 use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not 1902 set. 1904 then the TACACS+ client MUST close TCP session, and process the 1905 response in the same way that a TAC_PLUS_AUTHEN_STATUS_FAIL 1906 (authentication sessions) or TAC_PLUS_AUTHOR_STATUS_FAIL 1907 (authorization sessions) was received. 1909 10.5.3. Authentication 1911 To help TACACS+ administraots select the stronger authentication 1912 options, TACACS+ servers MUST allow the administrator to configure 1913 the server to only accept challenge/response options for 1914 authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or 1915 TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for 1916 authen_type). 1918 TACACS+ server administrators SHOULD enable the option mentioned in 1919 the previous paragraph. TACACS+ Server deployments SHOULD ONLY 1920 enable other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or 1921 TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of 1922 identity/password systems. 1924 TACACS+ server administrators SHOULD NOT allow the same credentials 1925 to be applied in challenge-based (TAC_PLUS_AUTHEN_TYPE_CHAP or 1926 TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non 1927 challenge-based authen_type options as the insecurity of the latter 1928 will compromise the security of the former. 1930 TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options 1931 mentioned in the original draft SHOULD NOT be used, due to their 1932 security implications. TACACS+ servers SHOULD NOT implement them. 1933 If they must be implemented, the servers MUST default to the options 1934 being disabled and MUST warn the administrator that these options are 1935 not secure. 1937 10.5.4. Authorization 1939 The authorization and accounting features are intended to provide 1940 extensibility and flexibility. There is a base dictionary defined in 1941 this document, but it may be extended in deployments by using new 1942 attribute names. The cost of the flexibility is that administrators 1943 and implementors MUST ensure that the attribute and value pairs 1944 shared between the clients and servers have consistent 1945 interpretation. 1947 TACACS+ clients that receive an unrecognised mandatory attribute MUST 1948 evaluate server response as if they received 1949 TAC_PLUS_AUTHOR_STATUS_FAIL. 1951 10.5.5. Redirection Mechanism 1953 The original draft described a redirection mechanism 1954 (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to 1955 secure. The option to send secret keys in the server list is 1956 particularly insecure, as it can reveal client shared secrets. 1958 TACACS+ servers SHOULD deprecate the redirection mechanism. 1960 If the redirection mechanism is implemented then TACACS+ servers MUST 1961 disable it by default, and MUST warn TACACS+ server administrators 1962 that it must only be enabled within a secure deployment due to the 1963 risks of revealing shared secrets. 1965 TACACS+ clients SHOULD deprecate this feature by treating 1966 TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. 1968 11. IANA Considerations 1970 This informational document describes TACACS+ protocol and its common 1971 deployments. There is no further consideration required from IANA. 1973 12. Acknowledgements 1975 The authors would like to thank the following reviewers whose 1976 comments and contributions made considerable improvements to the 1977 document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch, 1978 Robert Drake, among many others. 1980 The authors would particularly like to thank Alan DeKok, who provided 1981 significant insights and recommendations on all aspects of the 1982 document and the protocol. Alan DeKok has dedicated considerable 1983 time and effort to help improve the document, identifying weaknesses 1984 and providing remediation. 1986 The authors would also like to thanks the support from the OPSAWG 1987 Chairs and advisors. 1989 13. References 1991 13.1. Normative References 1993 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1994 April 1992. 1996 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1997 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1998 . 2000 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2001 Requirement Levels", BCP 14, RFC 2119, 2002 DOI 10.17487/RFC2119, March 1997, 2003 . 2005 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 2006 RFC 2433, DOI 10.17487/RFC2433, October 1998, 2007 . 2009 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 2010 RFC 2759, DOI 10.17487/RFC2759, January 2000, 2011 . 2013 [RFC4086] Eastlake 3rd, D., Crocker, S., and J. Schiller, 2014 "Randomness Requirements for Security", RFC 4086, 2015 DOI 10.17487/RFC4086, June 2005, 2016 . 2018 13.2. Informative References 2020 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2021 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2022 2006, . 2024 [TheDraft] 2025 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 2026 1.78", June 1997, 2027 . 2029 [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and 2030 Daylight Saving Time Data", 1987, 2031 . 2033 Authors' Addresses 2035 Thorsten Dahm 2036 Google Inc 2037 1600 Amphitheatre Parkway 2038 Mountain View, CA 94043 2039 US 2041 EMail: thorstendlux@google.com 2043 Andrej Ota 2044 Google Inc 2045 1600 Amphitheatre Parkway 2046 Mountain View, CA 94043 2047 US 2049 EMail: andrej@ota.si 2051 Douglas C. Medway Gash 2052 Cisco Systems, Inc. 2053 170 West Tasman Dr. 2054 San Jose, CA 95134 2055 US 2057 EMail: dcmgash@cisco.com 2059 David Carrel 2060 vIPtela, Inc. 2061 1732 North First St. 2062 San Jose, CA 95112 2063 US 2065 EMail: dcarrel@viptela.com 2067 Lol Grant 2069 EMail: lol.grant@gmail.com