idnits 2.17.1 draft-ietf-opsawg-tacacs-11.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 215: '...e TCP connection. The client MUST NOT...' RFC 2119 keyword, line 228: '...lient and server MUST ignore the flag ...' RFC 2119 keyword, line 243: '... client MUST accommodate such closur...' RFC 2119 keyword, line 262: '... and it MUST behave as if the server...' RFC 2119 keyword, line 278: '...enabled, then the connection SHOULD be...' (116 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 'MUST not' in this paragraph: TACACS+ servers and clients MUST treat shared secrets as sensitive data to be managed securely, as would be expected for other sensitive data such as identity credential information. TACACS+ servers MUST not leak sensitive data. For example, TACACS+ servers should not expose shared secrets in logs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft SHOULD not be used, due to their security implications. TACACS+ servers SHOULD NOT implement them. If they must be implemented, the servers MUST default to the options being disabled and MUST warn the administrator that these options are not secure. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 12, 2018) is 2051 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1687 ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) Summary: 6 errors (**), 0 flaws (~~), 5 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: March 16, 2019 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 September 12, 2018 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-11 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 March 16, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. 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+ Best Practices . . . . . . . . . . . . . . . . . 39 105 9.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39 106 9.5.2. Connections and Obfuscation . . . . . . . . . . . . . 40 107 9.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41 108 9.5.4. Authorization . . . . . . . . . . . . . . . . . . . . 41 109 9.5.5. Redirection Mechanism . . . . . . . . . . . . . . . . 42 110 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 114 1. Introduction 116 Terminal Access Controller Access-Control System Plus (TACACS+) was 117 conceived initially as a general Authentication, Authorization and 118 Accounting protocol. It is primarily used today for Device 119 Administration: authenticating access to network devices, providing 120 central authorization of operations, and audit of those operations. 122 A wide range of TACACS+ clients and servers are already deployed in 123 the field. The TACACS+ protocol they are based on is defined in a 124 draft document that was originally intended for IETF publication. 125 This document is known as `The Draft' [TheDraft] . 127 It is intended that all implementations which conform to this 128 document will conform to `The Draft'. However, attention is drawn to 129 the following specific adjustments of the protocol specification from 130 'The Draft': 132 This document officially removes SENDPASS for security reasons. 134 The normative description of Legacy features such as ARAP and 135 outbound authentication has been removed, however, the required 136 enumerations are kept. 138 The Support for forwarding to an alternative daemon 139 (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated. 141 The TACACS+ protocol separates the functions of Authentication, 142 Authorization and Accounting. It allows for arbitrary length and 143 content authentication exchanges, to support future authentication 144 mechanisms. It is extensible to provide for site customization and 145 future development features, and it uses TCP to ensure reliable 146 delivery. The protocol allows the TACACS+ client to request very 147 fine-grained access control and allows the server to respond to each 148 component of that request. 150 The separation of authentication, authorization and accounting was a 151 key element of the design of TACACS+ protocol. Essentially it makes 152 TACACS+ a suite of three protocols. This document will address each 153 one in separate sections. Although TACACS+ defines all three, but an 154 implementation or configuration is not required to employ all three. 155 Separating the elements is useful for Device Administration use case, 156 specifically, for authorization of individual commands in a session. 157 Note that there is no provision made at the protocol level for 158 association of an authentication to each authorization request. 160 This document restricts itself to a description of the protocol that 161 is used by TACACS+. It does not cover deployment or best practices. 163 2. Technical Definitions 165 This section provides a few basic definitions that are applicable to 166 this document 168 Client 170 The client is any device, (often a Network Access Server) that 171 provides access services. The clients usually provide a character 172 mode front end and then allow the user to telnet or rlogin to another 173 host. 175 Server 177 The server receives TACACS+ protocol requests, and replies according 178 to its business model, in accordance with the flows defined in this 179 document. 181 Packet 183 All uses of the word packet in this document refer to TACACS+ 184 protocol packets unless explicitly noted otherwise. 186 3. TACACS+ Connections and Sessions 188 3.1. Connection 190 TACACS+ uses TCP for its transport. Server port 49 is allocated for 191 TACACS+ traffic. 193 3.2. Session 195 The concept of a session is used throughout this document. A TACACS+ 196 session is a single authentication sequence, a single authorization 197 exchange, or a single accounting exchange. 199 An accounting and authorization session will consist of a single pair 200 of packets (the request and its reply). An authentication session 201 may involve an arbitrary number of packets being exchanged. The 202 session is an operational concept that is maintained between the 203 TACACS+ client and server. It does not necessarily correspond to a 204 given user or user action. 206 3.3. Single Connection Mode 208 Single Connection Mode is intended to improve performance by allowing 209 a client to multiplex multiple session on a single TCP connection. 211 The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by 212 the client and server to negotiate the use of Single Connect Mode. 214 The client sets this flag, to indicate that it supports multiplexing 215 TACACS+ sessions over a single TCP connection. The client MUST NOT 216 send a second packet on a connection until single-connect status has 217 been established. 219 To indicate it will support Single Connection Mode, the server sets 220 this flag in the first reply packet in response to the first request 221 from a client. The server may set this flag even if the client does 222 not set it, but the client may ignore the flag and close the 223 connection after the session completes. 225 The flag is only relevant for the first two packets on a connection, 226 to allow the client and server to establish Single Connection Mode. 227 No provision is made for changing Single Connection Mode after the 228 first two packets: the client and server MUST ignore the flag after 229 the second packet on a connection. 231 If single Connection Mode has not been established in the first two 232 packets of a TCP connection, then both the client and the server 233 close the connection at the end of the first session. 235 The client negotiates Single Connection Mode to improve efficiency. 236 The server may refuse to allow Single Connection Mode for the client. 237 For example, it may not be appropriate to allocate a long-lasting TCP 238 connection to a specific client in some deployments. Even if the 239 server is configured to permit single Connection Mode for a specific 240 client, the server may close the connection. For example: a server 241 may be configured to time out a Single Connection Mode TCP Connection 242 after a specific period of inactivity to preserve its resources. The 243 client MUST accommodate such closures on a TCP session even after 244 Single Connection Mode has been established. 246 3.4. Session Completion 248 The REPLY packets defined for the packets types in the sections below 249 (Authentication, Authorization and Accounting) contain a status 250 field. The complete set of options for this field depend upon the 251 packet type, but all three REPLY packet types define values 252 representing PASS, ERROR and FAIL, which indicate the last packet of 253 a regular session (one which is not aborted). 255 The server responds with a PASS or a FAIL to indicate that the 256 processing of the request completed and the client can apply the 257 result (PASS or FAIL) to control the execution of the action which 258 prompted the request to be sent to the server. 260 The server responds with an ERROR to indicate that the processing of 261 the request did not complete. The client can not apply the result 262 and it MUST behave as if the server could not be connected to. For 263 example, the client tries alternative methods, if they are available, 264 such as sending the request to a backup server, or using local 265 configuration to determine whether the action which prompted the 266 request should be executed. 268 Refer to the section (Section 4.4.3) on Aborting Authentication 269 Sessions for details on handling additional status options. 271 When the session is complete, then the TCP connection should be 272 handled as follows, according to whether Single Connection Mode was 273 negotiated: 275 If Single Connection Mode was not negotiated, then the connection 276 should be closed 278 If Single Connection Mode was enabled, then the connection SHOULD be 279 left open (see section (Section 3.3) ), but may still be closed after 280 a timeout period to preserve deployment resources 282 If Single Connection Mode was enabled, but an ERROR occurred due to 283 connection issues (such as an incorrect secret, see section 284 (Section 3.7) ), then any further new sessions MUST NOT be accepted 285 on the connection. If there are any sessions that have already been 286 established then they MAY be completed. Once all active sessions are 287 completed then the connection MUST be closed. 289 It is recommended that client implementations provide robust schemes 290 for dealing with servers which cannot be connected to. Options 291 include providing a list of servers for redundancy, and an option for 292 a local fallback configuration if no servers can be reached. Details 293 will be implementation specific. 295 The client should manage connections and handle the case of a server 296 which establishes a connection, but does not respond. The exact 297 behavior is implementation specific. It is recommended that the 298 client should close the connection after a configurable timeout. 300 3.5. Treatment of Enumerated Protocol Values 302 This document describes various enumerated values in the packet 303 header and the headers for specific packet types. For example in the 304 Authentication start packet type, this document defines the action 305 field with three values TAC_PLUS_AUTHEN_LOGIN, TAC_PLUS_AUTHEN_CHPASS 306 and TAC_PLUS_AUTHEN_SENDAUTH. 308 If the server does not implement one of the defined options in a 309 packet that it receives, or it encounters an option that is not 310 listed in this document for a header field, then it should respond 311 with a ERROR and terminate the session. This will allow the client 312 to try a different option. 314 If an error occurs but the type of the incoming packet cannot be 315 determined, a packet with the identical cleartext header but with a 316 sequence number incremented by one and the length set to zero MUST be 317 returned to indicate an error. 319 3.6. Text Encoding 321 All text fields in TACACS+ MUST be printable US-ASCII, excepting 322 special consideration given to user field and data fields used for 323 passwords. 325 To ensure interoperability of current deployments, the TACACS+ client 326 and server MUST handle user fields and those data fields used for 327 passwords as 8-bit octet strings. The deployment operator MUST 328 ensure that consistent character encoding is applied from the end 329 client to the server. The encoding SHOULD be UTF-8, and other 330 encodings outside printable US-ASCII SHOULD be deprecated. 332 3.7. Data Obfuscation 334 The body of packets may be obfuscated. The following sections 335 describe the obfuscation method that is supported in the protocol. 336 In 'The Draft' this process was actually referred to as Encryption, 337 but the algorithm would not meet modern standards, and so will not be 338 termed as encryption in this document. 340 The obfuscation mechanism relies on a secret key, a shared secret 341 value that is known to both the client and the server. This document 342 does not discuss the management and storage of those keys, other than 343 to require that the secret keys MUST remain secret. 345 Server implementations MUST allow a unique secret key to be 346 associated with every client. It is a site-dependent decision as to 347 whether the use of separate keys is appropriate. 349 The flag field may be set as follows: 351 TAC_PLUS_UNENCRYPTED_FLAG = 0x0 353 In this case, the packet body is obfuscated by XOR-ing it byte-wise 354 with a pseudo-random pad. 356 ENCRYPTED {data} = data ^ pseudo_pad 358 The packet body can then be de-obfuscated by XOR-ing it byte-wise 359 with a pseudo random pad. 361 data = ENCRYPTED {data} ^ pseudo_pad 363 The pad is generated by concatenating a series of MD5 hashes (each 16 364 bytes long) and truncating it to the length of the input data. 366 Whenever used in this document, MD5 refers to the "RSA Data Security, 367 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 368 . 370 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 372 The first MD5 hash is generated by concatenating the session_id, the 373 secret key, the version number and the sequence number and then 374 running MD5 over that stream. All of those input values are 375 available in the packet header, except for the secret key which is a 376 shared secret between the TACACS+ client and server. 378 The version number and session_id are used as extracted from the 379 header 381 Subsequent hashes are generated by using the same input stream, but 382 concatenating the previous hash value at the end of the input stream. 384 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 385 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 386 version, seq_no, MD5_n-1} 388 When a server detects that the secret(s) it has configured for the 389 device mismatch, it MUST return ERROR. For details of TCP connection 390 handling on ERROR, refer to section (Section 3.4) 392 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 394 In this case, the entire packet body is in cleartext. Obfuscation 395 and de-obfuscation are null operations. This method should be 396 avoided unless absolutely required for debug purposes, when tooling 397 does not permit de-obfuscation. 399 If deployment is configured for obfuscating a connection then the 400 request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. 402 After a packet body is de-obfuscated, the lengths of the component 403 values in the packet are summed. If the sum is not identical to the 404 cleartext datalength value from the header, the packet MUST be 405 discarded, and an ERROR signaled. For details of TCP connection 406 handling on ERROR, refer to section (Section 3.4) 408 Commonly such failures are seen when the keys are mismatched between 409 the client and the TACACS+ server. 411 3.8. The TACACS+ Packet Header 413 All TACACS+ packets begin with the following 12-byte header. The 414 header describes the remainder of the packet: 416 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 417 +----------------+----------------+----------------+----------------+ 418 |major | minor | | | | 419 |version| version| type | seq_no | flags | 420 +----------------+----------------+----------------+----------------+ 421 | | 422 | session_id | 423 +----------------+----------------+----------------+----------------+ 424 | | 425 | length | 426 +----------------+----------------+----------------+----------------+ 428 major_version 430 This is the major TACACS+ version number. 432 TAC_PLUS_MAJOR_VER := 0xc 434 minor_version 436 The minor TACACS+ version number. 438 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 440 TAC_PLUS_MINOR_VER_ONE := 0x1 442 type 444 This is the packet type. Legal values are: 446 TAC_PLUS_AUTHEN := 0x01 (Authentication) 448 TAC_PLUS_AUTHOR := 0x02 (Authorization) 450 TAC_PLUS_ACCT := 0x03 (Accounting) 452 seq_no 454 This is the sequence number of the current packet. The first packet 455 in a session MUST have the sequence number 1 and each subsequent 456 packet will increment the sequence number by one. Thus clients only 457 send packets containing odd sequence numbers, and TACACS+ servers 458 only send packets containing even sequence numbers. 460 The sequence number must never wrap i.e. if the sequence number 2^8-1 461 is ever reached, that session must terminate and be restarted with a 462 sequence number of 1. 464 flags 466 This field contains various bitmapped flags. 468 The flag bit: 470 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 472 This flag indicates that the sender did not obfuscate the body of the 473 packet. The application of this flag will be covered in the security 474 section (Section 9) . 476 This flag SHOULD be clear in all deployments. Modern network traffic 477 tools support encrypted traffic when configured with the shared 478 secret (see section below), so obfuscated mode can and SHOULD be used 479 even during test. 481 The single-connection flag: 483 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 485 This flag is used to allow a client and server to negotiate Single 486 Connection Mode. 488 session_id 490 The Id for this TACACS+ session. This field does not change for the 491 duration of the TACACS+ session. This number MUST be generated by a 492 cryptographically strong random number generation method. Failure to 493 do so will compromise security of the session. For more details 494 refer to RFC 1750 [RFC1750] 496 length 498 The total length of the packet body (not including the header). 500 3.9. The TACACS+ Packet Body 502 The TACACS+ body types are defined in the packet header. The next 503 sections of this document will address the contents of the different 504 TACACS+ bodies. The following general rules apply to all TACACS+ 505 body types: 507 - To signal that any variable length data fields are unused, their 508 length value is set to zero. Such fields MUST be ignored, and 509 treated as if not present. 511 - the lengths of data and message fields in a packet are specified 512 by their corresponding length fields, (and are not null 513 terminated.) 515 - All length values are unsigned and in network byte order. 517 4. Authentication 519 Authentication is the action of determining who a user (or entity) 520 is. Authentication can take many forms. Traditional authentication 521 employs a name and a fixed password. However, fixed passwords are 522 vulnerable security, so many modern authentication mechanisms utilize 523 "one-time" passwords or a challenge-response query. TACACS+ is 524 designed to support all of these, and be flexible enough to handle 525 any future mechanisms. Authentication generally takes place when the 526 user first logs in to a machine or requests a service of it. 528 Authentication is not mandatory; it is a site-configured option. 529 Some sites do not require it. Others require it only for certain 530 services (see authorization below). Authentication may also take 531 place when a user attempts to gain extra privileges, and must 532 identify himself or herself as someone who possesses the required 533 information (passwords, etc.) for those privileges. 535 4.1. The Authentication START Packet Body 537 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 538 +----------------+----------------+----------------+----------------+ 539 | action | priv_lvl | authen_type | authen_service | 540 +----------------+----------------+----------------+----------------+ 541 | user_len | port_len | rem_addr_len | data_len | 542 +----------------+----------------+----------------+----------------+ 543 | user ... 544 +----------------+----------------+----------------+----------------+ 545 | port ... 546 +----------------+----------------+----------------+----------------+ 547 | rem_addr ... 548 +----------------+----------------+----------------+----------------+ 549 | data... 550 +----------------+----------------+----------------+----------------+ 552 Packet fields are as follows: 554 action 556 This indicates the authentication action. Legal values are listed 557 below. 559 TAC_PLUS_AUTHEN_LOGIN := 0x01 561 TAC_PLUS_AUTHEN_CHPASS := 0x02 563 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 565 priv_lvl 567 This indicates the privilege level that the user is authenticating 568 as. Please refer to the Privilege Level section (Section 8) below. 570 authen_type 572 The type of authentication. Legal values are: 574 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 575 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 577 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 579 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 581 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 583 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 585 authen_service 587 This is the service that is requesting the authentication. Legal 588 values are: 590 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 592 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 594 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 596 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 598 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 600 TAC_PLUS_AUTHEN_SVC_PT := 0x05 602 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 604 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 606 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 608 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 610 The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization 611 application of this field that indicates that no authentication was 612 performed by the device. 614 The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as 615 opposed to ENABLE) to a client device. 617 The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE 618 authen_service, which refers to a service requesting authentication 619 in order to grant the user different privileges. This is comparable 620 to the Unix "su(1)" command, which substitutes the current user's 621 identity with another. An authen_service value of NONE is only to be 622 used when none of the other authen_service values are appropriate. 624 ENABLE may be requested independently, no requirements for previous 625 authentications or authorizations are imposed by the protocol. 627 Other options are included for legacy/backwards compatibility. 629 user, user_len 631 The username is optional in this packet, depending upon the class of 632 authentication. If it is absent, the client MUST set user_len to 0. 633 If included, the user_len indicates the length of the user field, in 634 bytes. 636 port, port_len 638 The printable US-ASCII name of the client port on which the 639 authentication is taking place, and its length in bytes. The value 640 of this field is client specific. (For example, Cisco uses "tty10" 641 to denote the tenth tty line and "Async10" to denote the tenth async 642 interface). The port_len indicates the length of the port field, in 643 bytes. 645 rem_addr, rem_addr_len 647 A printable US-ASCII string indicating the remote location from which 648 the user has connected to the client. It is intended to hold a 649 network address if the user is connected via a network, a caller ID 650 is the user is connected via ISDN or a POTS, or any other remote 651 location information that is available. This field is optional 652 (since the information may not be available). The rem_addr_len 653 indicates the length of the user field, in bytes. 655 data, data_len 657 This field is used to send data appropriate for the action and 658 authen_type. It is described in more detail in the section Common 659 Authentication flows (Section 4.4.2) . The data_len indicates the 660 length of the data field, in bytes. 662 4.2. The Authentication REPLY Packet Body 664 The TACACS+ server sends only one type of authentication packet (a 665 REPLY packet) to the client. 667 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 668 +----------------+----------------+----------------+----------------+ 669 | status | flags | server_msg_len | 670 +----------------+----------------+----------------+----------------+ 671 | data_len | server_msg ... 672 +----------------+----------------+----------------+----------------+ 673 | data ... 674 +----------------+----------------+ 676 status 678 The current status of the authentication. Legal values are: 680 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 682 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 684 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 686 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 688 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 690 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 692 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 694 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 696 flags 698 Bitmapped flags that modify the action to be taken. The following 699 values are defined: 701 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 703 server_msg, server_msg_len 705 A message to be displayed to the user. This field is optional. The 706 printable US-ASCII charset MUST be used. The server_msg_len 707 indicates the length of the server_msg field, in bytes. 709 data, data_len 711 This field holds data that is a part of the authentication exchange 712 and is intended for the client, not the user. Examples of its use 713 are shown in the section Common Authentication flows (Section 4.4.2) 714 . The data_len indicates the length of the data field, in bytes. 716 4.3. The Authentication CONTINUE Packet Body 718 This packet is sent from the client to the server following the 719 receipt of a REPLY packet. 721 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 722 +----------------+----------------+----------------+----------------+ 723 | user_msg len | data_len | 724 +----------------+----------------+----------------+----------------+ 725 | flags | user_msg ... 726 +----------------+----------------+----------------+----------------+ 727 | data ... 728 +----------------+ 730 user_msg, user_msg_len 732 This field is the string that the user entered, or the client 733 provided on behalf of the user, in response to the server_msg from a 734 REPLY packet. The user_len indicates the length of the user field, 735 in bytes. 737 data, data_len 739 This field carries information that is specific to the action and the 740 authen_type for this session. Valid uses of this field are described 741 below. The data_len indicates the length of the data field, in 742 bytes. 744 flags 746 This holds the bitmapped flags that modify the action to be taken. 747 The following values are defined: 749 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 751 4.4. Description of Authentication Process 753 The action, authen_type and authen_service fields (described above) 754 combine to indicate what kind of authentication is to be performed. 755 Every authentication START, REPLY and CONTINUE packet includes a data 756 field. The use of this field is dependent upon the kind of the 757 Authentication. 759 This document defines a core set of authentication flows to be 760 supported by TACACS+. Each authentication flow consists of a START 761 packet. The server responds either with a request for more 762 information (GETDATA, GETUSER or GETPASS) or a termination PASS, 763 FAIL, ERROR or RESTART. The actions and meanings when the server 764 sends a RESTART or ERROR are common and are described further below. 766 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 767 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 768 then authentication continues and the server SHOULD provide 769 server_msg content for the client to prompt the user for more 770 information. The client MUST then return a CONTINUE packet 771 containing the requested information in the user_msg field. 773 The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a 774 request for username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request 775 for password. The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic 776 request for more information to flexibly support future requirements. 778 If the information being requested by the server form the client is 779 sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO 780 flag. When the client queries the user for the information, the 781 response MUST NOT be echoed as it is entered. 783 The data field is only used in the REPLY where explicitly defined 784 below. 786 4.4.1. Version Behaviour 788 The TACACS+ protocol is versioned to allow revisions while 789 maintaining backwards compatibility. The version number is in every 790 packet header. The changes between minor_version 0 and 1 apply only 791 to the authentication process, and all deal with the way that CHAP 792 and PAP authentications are handled. minor_version 1 may only be used 793 for authentication kinds that explicitly call for it in the table 794 below: 796 LOGIN CHPASS SENDAUTH 797 ASCII v0 v0 - 798 PAP v1 - v1 799 CHAP v1 - v1 800 MS-CHAPv1/2 v1 - v1 802 The '-' symbol represents that the option is not valid. 804 All authorisation and accounting and ASCII authentication use 805 minor_version number of 0. 807 PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange 808 is a single START packet from the client and a single REPLY from the 809 server. 811 The removal of SENDPASS was prompted by security concerns, and is no 812 longer considered part of the TACACS+ protocol. 814 4.4.2. Common Authentication Flows 816 This section describes common authentication flows. If the server 817 does not implement an option, it MUST respond with 818 TAC_PLUS_AUTHEN_STATUS_FAIL. 820 4.4.2.1. ASCII Login 822 action = TAC_PLUS_AUTHEN_LOGIN 823 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 824 minor_version = 0x0 826 This is a standard ASCII authentication. The START packet MAY 827 contain the username. If the user does not include the username then 828 the server MUST obtain it from the client with a CONTINUE 829 TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user does not provide a 830 username then the server can send another 831 TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server MUST limit the 832 number of retries that are permitted, recommended limit is three 833 attempts. When the server has the username, it will obtain the 834 password using a continue with TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII 835 login uses the user_msg field for both the username and password. 836 The data fields in both the START and CONTINUE packets are not used 837 for ASCII logins, any content MUST be ignored. The session is 838 composed of a single START followed by zero or more pairs of REPLYs 839 and CONTINUEs, followed by a final REPLY indicating PASS, FAIL or 840 ERROR. 842 4.4.2.2. PAP Login 844 action = TAC_PLUS_AUTHEN_LOGIN 845 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 846 minor_version = 0x1 848 The entire exchange MUST consist of a single START packet and a 849 single REPLY. The START packet MUST contain a username and the data 850 field MUST contain the PAP ASCII password. A PAP authentication only 851 consists of a username and password RFC 1334 [RFC1334] . The REPLY 852 from the server MUST be either a PASS, FAIL or ERROR. 854 4.4.2.3. CHAP login 856 action = TAC_PLUS_AUTHEN_LOGIN 857 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 858 minor_version = 0x1 860 The entire exchange MUST consist of a single START packet and a 861 single REPLY. The START packet MUST contain the username in the user 862 field and the data field is a concatenation of the PPP id, the 863 challenge and the response. 865 The length of the challenge value can be determined from the length 866 of the data field minus the length of the id (always 1 octet) and the 867 length of the response field (always 16 octets). 869 To perform the authentication, the server calculates the PPP hash as 870 defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then 871 compare that value with the response. The MD5 algorithm option is 872 always used. The REPLY from the server MUST be a PASS, FAIL or 873 ERROR. 875 The selection of the challenge and its length are not an aspect of 876 the TACACS+ protocol. However, it is strongly recommended that the 877 client/endstation interaction is configured with a secure challenge. 878 The TACACS+ server can help by rejecting authentications where the 879 challenge is below a minimum length (Minimum recommended is 8 bytes). 881 4.4.2.4. MS-CHAP v1 login 883 action = TAC_PLUS_AUTHEN_LOGIN 884 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 885 minor_version = 0x1 887 The entire exchange MUST consist of a single START packet and a 888 single REPLY. The START packet MUST contain the username in the user 889 field and the data field will be a concatenation of the PPP id, the 890 MS-CHAP challenge and the MS-CHAP response. 892 The length of the challenge value can be determined from the length 893 of the data field minus the length of the id (always 1 octet) and the 894 length of the response field (always 49 octets). 896 To perform the authentication, the server will use a combination of 897 MD4 and DES on the user's secret and the challenge, as defined in RFC 898 2433 [RFC2433] and then compare the resulting value with the 899 response. The REPLY from the server MUST be a PASS or FAIL. 901 For best practices, please refer to RFC 2433 [RFC2433] . The TACACS+ 902 server MUST reject authentications where the challenge deviates from 903 8 bytes as defined in the RFC. 905 4.4.2.5. MS-CHAP v2 login 907 action = TAC_PLUS_AUTHEN_LOGIN 908 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 909 minor_version = 0x1 911 The entire exchange MUST consist of a single START packet and a 912 single REPLY. The START packet MUST contain the username in the user 913 field and the data field will be a concatenation of the PPP id, the 914 MS-CHAP challenge and the MS-CHAP response. 916 The length of the challenge value can be determined from the length 917 of the data field minus the length of the id (always 1 octet) and the 918 length of the response field (always 49 octets). 920 To perform the authentication, the server will use the algorithm 921 specified RFC 2759 [RFC2759] on the user's secret and challenge and 922 then compare the resulting value with the response. The REPLY from 923 the server MUST be a PASS or FAIL. 925 For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] 926 . The TACACS+ server MUST rejects authentications where the challenge 927 deviates from 16 bytes as defined in the RFC. 929 4.4.2.6. Enable Requests 931 action = TAC_PLUS_AUTHEN_LOGIN 932 priv_lvl = implementation dependent 933 authen_type = not used 934 service = TAC_PLUS_AUTHEN_SVC_ENABLE 936 This is an ENABLE request, used to change the current running 937 privilege level of a user. The exchange MAY consist of multiple 938 messages while the server collects the information it requires in 939 order to allow changing the principal's privilege level. This 940 exchange is very similar to an ASCII login (Section 4.4.2.1) . 942 In order to readily distinguish enable requests from other types of 943 request, the value of the authen_service field MUST be set to 944 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 945 set to this value when requesting any other operation. 947 4.4.2.7. ASCII change password request 949 action = TAC_PLUS_AUTHEN_CHPASS 950 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 952 This exchange consists of multiple messages while the server collects 953 the information it requires in order to change the user's password. 954 It is very similar to an ASCII login. The status value 955 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 956 "new" password. It MAY be sent multiple times. When requesting the 957 "old" password, the status value MUST be set to 958 TAC_PLUS_AUTHEN_STATUS_GETDATA. 960 4.4.3. Aborting an Authentication Session 962 The client may prematurely terminate a session by setting the 963 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 964 flag is set, the data portion of the message may contain an ASCII 965 message explaining the reason for the abort. This information will 966 be handled by the server according to the requirements of the 967 deployment. The session is terminated, for more details about 968 session termination, refer to section (Section 3.4) 970 In the case of PALL, FAIL or ERROR, the server can insert a message 971 into server_msg to be displayed to the user. 973 The Draft `The Draft' [TheDraft] defined a mechanism to direct 974 authentication requests to an alternative server. This mechanism is 975 regarded as insecure, is deprecated, and not covered here. The 976 client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as 977 TAC_PLUS_AUTHEN_STATUS_FAIL 979 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 980 indicating that it is experiencing an unrecoverable error and the 981 authentication will proceed as if that host could not be contacted. 982 The data field may contain a message to be printed on an 983 administrative console or log. 985 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 986 authentication sequence is restarted with a new START packet from the 987 client, with new session Id, and seq_no set to 1. This REPLY packet 988 indicates that the current authen_type value (as specified in the 989 START packet) is not acceptable for this session. The client may try 990 an alternative authen_type. 992 If a client does not implement TAC_PLUS_AUTHEN_STATUS_RESTART option, 993 then it MUST process the response as if the status was 994 TAC_PLUS_AUTHEN_STATUS_FAIL. 996 5. Authorization 998 In the TACACS+ Protocol, authorization is the action of determining 999 what a user is allowed to do. Generally authentication precedes 1000 authorization, though it is not mandatory that a client use the same 1001 service for authentication that it will use for authorization. An 1002 authorization request may indicate that the user is not authenticated 1003 (we don't know who they are). In this case it is up to the server to 1004 determine, according to its configuration, if an unauthenticated user 1005 is allowed the services in question. 1007 Authorization does not merely provide yes or no answers, but it may 1008 also customize the service for the particular user. A common use of 1009 authorization is to provision a shell session when a user first logs 1010 into a device to administer it. The TACACS+ server might respond to 1011 the request by allowing the service, but placing a time restriction 1012 on the login shell. For a list of common attributes used in 1013 authorization, see the Authorization Attributes section (Section 7.2) 1014 . 1016 In the TACACS+ protocol an authorization is always a single pair of 1017 messages: a REQUEST from the client followed by a REPLY from the 1018 server. 1020 The authorization REQUEST message contains a fixed set of fields that 1021 indicate how the user was authenticated and a variable set of 1022 arguments that describe the services and options for which 1023 authorization is requested. 1025 The REPLY contains a variable set of response arguments (attribute- 1026 value pairs) that can restrict or modify the client's actions. 1028 5.1. The Authorization REQUEST Packet Body 1029 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 1030 +----------------+----------------+----------------+----------------+ 1031 | authen_method | priv_lvl | authen_type | authen_service | 1032 +----------------+----------------+----------------+----------------+ 1033 | user_len | port_len | rem_addr_len | arg_cnt | 1034 +----------------+----------------+----------------+----------------+ 1035 | arg_1_len | arg_2_len | ... | arg_N_len | 1036 +----------------+----------------+----------------+----------------+ 1037 | user ... 1038 +----------------+----------------+----------------+----------------+ 1039 | port ... 1040 +----------------+----------------+----------------+----------------+ 1041 | rem_addr ... 1042 +----------------+----------------+----------------+----------------+ 1043 | arg_1 ... 1044 +----------------+----------------+----------------+----------------+ 1045 | arg_2 ... 1046 +----------------+----------------+----------------+----------------+ 1047 | ... 1048 +----------------+----------------+----------------+----------------+ 1049 | arg_N ... 1050 +----------------+----------------+----------------+----------------+ 1052 authen_method 1054 This indicates the authentication method used by the client to 1055 acquire the user information. As this information is not always 1056 subject to verification, it is recommended that this field is 1057 ignored. 1059 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1061 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1063 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1065 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1067 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1069 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1071 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1073 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1075 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1076 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1078 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1080 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1081 password associated with the terminal line used to gain access. 1082 LOCAL is a client local user database. ENABLE is a command that 1083 authenticates in order to grant new privileges. TACACSPLUS is, of 1084 course, TACACS+. GUEST is an unqualified guest authentication, such 1085 as an ARAP guest login. RADIUS is the Radius authentication 1086 protocol. RCMD refers to authentication provided via the R-command 1087 protocols from Berkeley Unix. 1089 priv_lvl 1091 This field is used in the same way as the priv_lvl field in 1092 authentication request and is described in the Privilege Level 1093 section (Section 8) below. It indicates the users current privilege 1094 level. 1096 authen_type 1098 This field coresponds to the authen_type field in the authentication 1099 section (Section 4) above. It indicates the type of authentication 1100 that was performed. If this information is not available, then the 1101 client will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. 1102 This value is valid only in authorization and accounting requests. 1104 authen_service 1106 This field is the same as the authen_service field in the 1107 authentication section (Section 4) above. It indicates the service 1108 through which the user authenticated. 1110 user, user_len 1112 This field contains the user's account name. The user_len MUST 1113 indicate the length of the user field, in bytes. 1115 port, port_len 1117 This field matches the port field in the authentication section 1118 (Section 4) above. The port_len indicates the length of the port 1119 field, in bytes. 1121 rem_addr, rem_addr_len 1122 This field matches the rem_addr field in the authentication section 1123 (Section 4) above. The rem_addr_len indicates the length of the port 1124 field, in bytes. 1126 arg_cnt 1128 The number of authorization arguments to follow 1130 arg_1 ... arg_N, arg_1_len .... arg_N_len 1132 The arguments are the primary elements of the authorization 1133 interaction. In the request packet they describe the specifics of 1134 the authorization that is being requested. Each argument is encoded 1135 in the packet as a single arg filed (arg_1... arg_N) with a 1136 corresponding length fields (which indicates the length of each 1137 argument in bytes). 1139 The authorization arguments in both the REQUEST and the REPLY are 1140 attribute-value pairs. The attribute and the value are in a single 1141 printable US-ASCII string and are separated by either a "=" (0X3D) or 1142 a "*" (0X2A). The equals sign indicates a mandatory argument. The 1143 asterisk indicates an optional one. 1145 It is not legal for an attribute name to contain either of the 1146 separators. It is legal for attribute values to contain the 1147 separators. This means that the arguments must be parsed until the 1148 first separator is encountered, all characters in the argument, after 1149 this separator, are interpreted as the argument value. 1151 Optional arguments are ones that may be disregarded by either client 1152 or server. Mandatory arguments require that the receiving side can 1153 handle the attribute, that is: its implementation and configuration 1154 includes the details of how to act on it. If the client receives a 1155 mandatory argument that it cannot handle, it MUST consider the 1156 authorization to have failed. It is legal to send an attribute-value 1157 pair with a zero length value. 1159 Attribute-value strings are not NULL terminated, rather their length 1160 value indicates their end. The maximum length of an attribute-value 1161 string is 255 characters. The minimum is two characters (one name- 1162 value character and the separator) 1164 Though the attributes allow extensibility, a common core set of 1165 authorization attributes SHOULD be supported by clients and servers, 1166 these are listed in the Authorization Attributes (Section 7.2) 1167 section below. 1169 5.2. The Authorization REPLY Packet Body 1171 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 1172 +----------------+----------------+----------------+----------------+ 1173 | status | arg_cnt | server_msg len | 1174 +----------------+----------------+----------------+----------------+ 1175 + data_len | arg_1_len | arg_2_len | 1176 +----------------+----------------+----------------+----------------+ 1177 | ... | arg_N_len | server_msg ... 1178 +----------------+----------------+----------------+----------------+ 1179 | data ... 1180 +----------------+----------------+----------------+----------------+ 1181 | arg_1 ... 1182 +----------------+----------------+----------------+----------------+ 1183 | arg_2 ... 1184 +----------------+----------------+----------------+----------------+ 1185 | ... 1186 +----------------+----------------+----------------+----------------+ 1187 | arg_N ... 1188 +----------------+----------------+----------------+----------------+ 1190 status This field indicates the authorization status 1192 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1194 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1196 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1198 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1200 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1202 server_msg, server_msg_len 1204 This is a printable US-ASCII string that may be presented to the 1205 user. The server_msg_len indicates the length of the server_msg 1206 field, in bytes. 1208 data, data_len 1210 This is a printable US-ASCII string that may be presented on an 1211 administrative display, console or log. The decision to present this 1212 message is client specific. The data_len indicates the length of the 1213 data field, in bytes. 1215 arg_cnt 1216 The number of authorization arguments to follow. 1218 arg_1 ... arg_N, arg_1_len .... arg_N_len 1220 The arguments describe the specifics of the authorization that is 1221 being requested. For details of the content of the args, refer to: 1222 Authorization Attributes (Section 7.2) section below. Each argument 1223 is encoded in the packet as a single arg field (arg_1... arg_N) with 1224 a corresponding length fields (which indicates the length of each 1225 argument in bytes). 1227 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested 1228 authorization MUST be denied. 1230 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1231 arguments specified in the request are authorized and the arguments 1232 in the response MUST be applied according to the rules described 1233 above. 1235 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client 1236 MUST use the authorization attribute-value pairs (if any) in the 1237 response, instead of the authorization attribute-value pairs from the 1238 request. 1240 To approve the authorization with no modifications, the server sets 1241 the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. 1243 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1244 on the server. For the differences between ERROR and FAIL, refer to 1245 section Session Completion (Section 3.4) . None of the arg values 1246 have any relevance if an ERROR is set, and must be ignored. 1248 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1249 arg_cnt MUST be 0. In that case, the actions to be taken and the 1250 contents of the data field are identical to the 1251 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1253 6. Accounting 1255 Accounting is typically the third action after authentication and 1256 authorization. But again, neither authentication nor authorization 1257 is required. Accounting is the action of recording what a user is 1258 doing, and/or has done. Accounting in TACACS+ can serve two 1259 purposes: It may be used as an auditing tool for security services. 1260 It may also be used to account for services used, such as in a 1261 billing environment. To this end, TACACS+ supports three types of 1262 accounting records. Start records indicate that a service is about 1263 to begin. Stop records indicate that a service has just terminated, 1264 and Update records are intermediate notices that indicate that a 1265 service is still being performed. TACACS+ accounting records contain 1266 all the information used in the authorization records, and also 1267 contain accounting specific information such as start and stop times 1268 (when appropriate) and resource usage information. A list of 1269 accounting attributes is defined in the accounting section 1270 (Section 6) . 1272 6.1. The Account REQUEST Packet Body 1274 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 1275 +----------------+----------------+----------------+----------------+ 1276 | flags | authen_method | priv_lvl | authen_type | 1277 +----------------+----------------+----------------+----------------+ 1278 | authen_service | user_len | port_len | rem_addr_len | 1279 +----------------+----------------+----------------+----------------+ 1280 | arg_cnt | arg_1_len | arg_2_len | ... | 1281 +----------------+----------------+----------------+----------------+ 1282 | arg_N_len | user ... 1283 +----------------+----------------+----------------+----------------+ 1284 | port ... 1285 +----------------+----------------+----------------+----------------+ 1286 | rem_addr ... 1287 +----------------+----------------+----------------+----------------+ 1288 | arg_1 ... 1289 +----------------+----------------+----------------+----------------+ 1290 | arg_2 ... 1291 +----------------+----------------+----------------+----------------+ 1292 | ... 1293 +----------------+----------------+----------------+----------------+ 1294 | arg_N ... 1295 +----------------+----------------+----------------+----------------+ 1297 flags 1299 This holds bitmapped flags. 1301 TAC_PLUS_ACCT_FLAG_START := 0x02 1303 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1305 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1307 All other fields are defined in the authorization and authentication 1308 sections above and have the same semantics. They provide details for 1309 the conditions on the client, and authentication context, so that 1310 these details may be logged for accounting purposes. 1312 See section 12 Accounting Attribute-value Pairs for the dictionary of 1313 attributes relevant to accounting. 1315 6.2. The Accounting REPLY Packet Body 1317 The purpose of accounting is to record the action that has occurred 1318 on the client. The server MUST reply with success only when the 1319 accounting request has been recorded. If the server did not record 1320 the accounting request then it MUST reply with ERROR. 1322 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 1323 +----------------+----------------+----------------+----------------+ 1324 | server_msg len | data_len | 1325 +----------------+----------------+----------------+----------------+ 1326 | status | server_msg ... 1327 +----------------+----------------+----------------+----------------+ 1328 | data ... 1329 +----------------+ 1331 status 1333 This is the return status. Values are: 1335 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1337 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1339 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1341 server_msg, server_msg_len 1343 This is a printable US-ASCII string that may be presented to the 1344 user. The server_msg_len indicates the length of the server_msg 1345 field, in bytes. 1347 data, data_len 1349 This is a printable US-ASCII string that may be presented on an 1350 administrative display, console or log. The decision to present this 1351 message is client specific. The data_len indicates the length of the 1352 data field, in bytes. 1354 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1355 to be taken and the contents of the data field are identical to the 1356 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1358 TACACS+ accounting is intended to record various types of events on 1359 clients, for example: login sessions, command entry, and others as 1360 required by the client implementation. These events are collectively 1361 referred to in `The Draft' [TheDraft] as "tasks". 1363 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1364 accounting message. Start messages will only be sent once when a 1365 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1366 a stop record and that the task has terminated. The 1367 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1369 Summary of Accounting Packets 1371 +----------+-------+-------+-------------+-------------------------+ 1372 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1373 +----------+-------+-------+-------------+-------------------------+ 1374 | 0 | 0 | 0 | 0 | INVALID | 1375 | 0 | 0 | 1 | 2 | Start Accounting Record | 1376 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1377 | 0 | 1 | 1 | 6 | INVALID | 1378 | 1 | 0 | 0 | 8 | Watchdog, no update | 1379 | 1 | 0 | 1 | A | Watchdog, with update | 1380 | 1 | 1 | 0 | C | INVALID | 1381 | 1 | 1 | 1 | E | INVALID | 1382 +----------+-------+-------+-------------+-------------------------+ 1384 The START and STOP flags are mutually exclusive. 1386 The WATCHDOG flag is used by the client to communicate ongoing status 1387 of a long-running task. Update records are sent at the client's 1388 discretion. The frequency of the update depends upon the intended 1389 application: A watchdog to provide progress indication will require 1390 higher frequency than a daily keep-alive. When the WATCHDOG flag is 1391 set along with the START flag, it indicates that the update record 1392 provides additional or updated arguments from the original START 1393 record. If the START flag is not set, then this indicates only that 1394 task is still running, and no new information is provided (servers 1395 MUST ignore any arguments). The STOP flag MUST NOT be set in 1396 conjunction with the WATCHDOG flag. 1398 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1399 requests an INVALID option. 1401 7. Attribute-Value Pairs 1403 TACACS+ is intended to be an extensible protocol. The attributes 1404 used in Authorization and Accounting are not limited by this 1405 document. Some attributes are defined below for common use cases, 1406 clients MUST use these attributes when supporting the corresponding 1407 use cases. 1409 7.1. Value Encoding 1411 All attribute values are encoded as printable US-ASCII strings. The 1412 following type representations SHOULD be followed 1414 Numeric 1416 All numeric values in an attribute-value string are provided as 1417 decimal printable US-ASCII numbers, unless otherwise stated. 1419 Boolean 1421 All boolean attributes are encoded as printable US-ASCII with values 1422 "true" or "false". 1424 IP-Address 1426 It is recommended that hosts be specified as a IP address so as to 1427 avoid any ambiguities. IPV4 address are specified as US-ASCII octet 1428 numerics separated by dots ('.'), IPV6 address text representation 1429 defined in RFC 4291. 1431 Date Time 1433 Absolute date/times are specified in seconds since the epoch, 12:00am 1434 Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is 1435 specified. Stardate is canonically inconsistent and so SHOULD NOT be 1436 used. 1438 String 1440 Many values have no specific type representation and so are 1441 interpreted as plain strings. 1443 Empty Values 1445 Attributes may be submitted with no value, in which case they consist 1446 of the name and the mandatory or optional separator. For example, 1447 the attribute "cmd" which has no value is transmitted as a string of 1448 four characters "cmd=" 1450 7.2. Authorization Attributes 1452 service (String) 1454 The primary service. Specifying a service attribute indicates that 1455 this is a request for authorization or accounting of that service. 1457 For example: "shell", "tty-server", "connection", "system" and 1458 "firewall". This attribute MUST always be included. 1460 protocol (String) 1462 the protocol field may be used to indicate a subset of a service. 1464 cmd (String) 1466 a shell (exec) command. This indicates the command name of the 1467 command that is to be run. The "cmd" attribute MUST be specified if 1468 service equals "shell". 1470 Authorization of shell commands is a common use-case for the TACACS+ 1471 protocol. Command Authorization generally takes one of two forms: 1472 session-based and command-based. 1474 For session-based shell authorization, the "cmd" argument will have 1475 an empty value. The client determines which commands are allowed in 1476 a session according to the arguments present in the authorization. 1478 In command-based authorization, the client requests that the server 1479 determine whether a command is allowed by making an authorization 1480 request for each command. The "cmd" argument will have the command 1481 name as its value. 1483 cmd-arg (String) 1485 an argument to a shell (exec) command. This indicates an argument 1486 for the shell command that is to be run. Multiple cmd-arg attributes 1487 may be specified, and they are order dependent. 1489 acl (Numeric) 1491 printable US-ASCII number representing a connection access list. 1492 Applicable only to session-based shell authorization. 1494 inacl (String) 1496 printable US-ASCII identifier for an interface input access list. 1498 outacl (String) 1500 printable US-ASCII identifier for an interface output access list. 1502 addr (IP-Address) 1504 a network address 1505 addr-pool (String) 1507 The identifier of an address pool from which the client can assign an 1508 address. 1510 routing (Boolean) 1512 Specifies whether routing information is to be propagated to, and 1513 accepted from this interface. 1515 route (String) 1517 Indicates a route that is to be applied to this interface. Values 1518 MUST be of the form " []". If a 1519 is not specified, the resulting route is via the 1520 requesting peer. 1522 timeout (Numeric) 1524 an absolute timer for the connection (in minutes). A value of zero 1525 indicates no timeout. 1527 idletime (Numeric) 1529 an idle-timeout for the connection (in minutes). A value of zero 1530 indicates no timeout. 1532 autocmd (String) 1534 an auto-command to run. Applicable only to session-based shell 1535 authorization. 1537 noescape (Boolean) 1539 Prevents user from using an escape character. Applicable only to 1540 session-based shell authorization. 1542 nohangup (Boolean) 1544 Boolean. Do not disconnect after an automatic command. Applicable 1545 only to session-based shell authorization. 1547 priv-lvl (Numeric) 1549 privilege level to be assigned. Please refer to the Privilege Level 1550 section (Section 8) below. 1552 remote_user (String) 1553 remote userid (authen_method must have the value 1554 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1555 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1556 remote_user and remote_host attributes will provide the remote user 1557 and host information to enable rhost style authorization. The 1558 response may request that a privilege level be set for the user. 1560 remote_host (String) 1562 remote host (authen_method must have the value 1563 TAC_PLUS_AUTHEN_METH_RCMD) 1565 7.3. Accounting Attributes 1567 The following attributes are defined for TACACS+ accounting only. 1568 They MUST precede any attribute-value pairs that are defined in the 1569 authorization section (Section 5) above. 1571 task_id (String) 1573 Start and stop records for the same event MUST have matching task_id 1574 attribute values. The client MUST ensure that active task_ids are 1575 not duplicated: a client MUST NOT reuse a task_id a start record 1576 until it has sent a stop record for that task_id. Servers MUST not 1577 make assumptions about the format of a task_id. 1579 start_time (Date Time) 1581 The time the action started (in seconds since the epoch.). 1583 stop_time (Date Time) 1585 The time the action stopped (in seconds since the epoch.) 1587 elapsed_time (Numeric) 1589 The elapsed time in seconds for the action. 1591 timezone (String) 1593 The timezone abbreviation for all timestamps included in this packet. 1595 event (String) 1597 Used only when "service=system". Current values are "net_acct", 1598 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1599 These indicate system-level changes. The flags field SHOULD indicate 1600 whether the service started or stopped. 1602 reason (String) 1604 Accompanies an event attribute. It describes why the event occurred. 1606 bytes (Numeric) 1608 The number of bytes transferred by this action 1610 bytes_in (Numeric) 1612 The number of bytes transferred by this action from the endstation to 1613 the client port 1615 bytes_out (Numeric) 1617 The number of bytes transferred by this action from the client to the 1618 endstation port 1620 paks (Numeric) 1622 The number of packets transferred by this action. 1624 paks_in (Numeric) 1626 The number of input packets transferred by this action from the 1627 endstation to the client port. 1629 paks_out (Numeric) 1631 The number of output packets transferred by this action from the 1632 client port to the endstation. 1634 err_msg (String) 1636 A printable US-ASCII string describing the status of the action. 1638 8. Privilege Levels 1640 The TACACS+ Protocol supports flexible authorization schemes through 1641 the extensible attributes. 1643 One scheme is built into the protocol and has been extensively used 1644 for Session-based shell authorization: Privilege Levels. Privilege 1645 Levels are ordered values from 0 to 15 with each level being a 1646 superset of the next lower value. Configuration and implementation 1647 of the client will map actions (such as the permission to execute of 1648 specific commands) to different privilege levels. Pre-defined values 1649 are: 1651 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1653 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1655 TAC_PLUS_PRIV_LVL_USER := 0x01 1657 TAC_PLUS_PRIV_LVL_MIN := 0x00 1659 A Privilege level can be assigned to a shell (EXEC) session when it 1660 starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will permit 1661 the actions associated with this level to be executed. This 1662 privilege level is returned by the Server in a session-based shell 1663 authorization (when "service" equals "shell" and "cmd" is empty). 1664 When a user required to perform actions that are mapped to a higher 1665 privilege level, then an ENABLE type reauthentication can be 1666 initiated by the client. The client will insert the required 1667 privilege level into the authentication header for enable 1668 authentication request. 1670 The use of Privilege levels to determine session-based access to 1671 commands and resources is not mandatory for clients. Although the 1672 privilege level scheme is widely supported, its lack of flexibility 1673 in requiring a single monotonic hierarchy of permissions means that 1674 other session-based command authorization schemes have evolved, and 1675 so it is no longer mandatory for clients to use it. However, it is 1676 still common enough that it SHOULD be supported by servers. 1678 9. TACACS+ Security Considerations 1680 The original TACACS+ Draft[1] from 1998 did not address all of the 1681 key security concerns which are considered when designing modern 1682 standards. This section addresses known limitations and concerns 1683 which will impact overall security of the protocol and systems where 1684 this protocol is deployed to manage central authentication, 1685 authorization or accounting for network device administration. 1687 Multiple implementations of the protocol described in the draft[1] 1688 have been deployed. As the protocol was never standardized, current 1689 implementations may be incompatible in non-obvious ways, giving rise 1690 to additional security risks. This section does not claim to 1691 enumerate all possible security vulnerabilities. 1693 9.1. General Security of the Protocol 1695 TACACS+ protocol does not include a security mechanism that would 1696 meet modern-day requirements. Support for MD5-based crypto pad 1697 encryption fails to provide any kind of transport integrity, which 1698 presents at least the following risks: 1700 Accounting information may be modified by the man-in-the-middle 1701 attacker, making such logs unsuitable and untrustable for auditing 1702 purposes. 1704 Only the body of the request is obfuscated which leaves all header 1705 fields open to trivial modification by the man-in-the-middle 1706 attacker. For this reason, deployments SHOULD NOT use connections 1707 with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the 1708 recommendations section. 1710 Invalid or misleading values may be inserted by the man-in-the- 1711 middle attacker in various fields at known offsets to try and 1712 circumvent the authentication or authorization checks even inside 1713 the obfuscated body. 1715 While the protocol provides some measure of transport privacy, it is 1716 vulnerable to at least the following attacks: 1718 Brute force attacks exploiting increased efficiency of MD5 digest 1719 computation. 1721 Known plaintext attacks which may decrease the cost of brute force 1722 attack. 1724 Chosen plaintext attacks which may decrease the cost of a brute 1725 force attack. 1727 No forward secrecy. 1729 Even though, to the best knowledge of authors, this method of 1730 encryption wasn't rigorously tested, enough information is available 1731 that it is best referred to as "obfuscation" and not "encryption". 1733 For these reasons, users deploying TACACS+ protocol in their 1734 environments MUST limit access to known clients and MUST control the 1735 security of the entire transmission path. Attackers who can guess 1736 the key or otherwise break the obfuscation will gain unrestricted and 1737 undetected access to all TACACS+ traffic. Ensuring that a 1738 centralized AAA system like TACACS+ is deployed on a secured 1739 transport is essential to managing the security risk of such an 1740 attack. 1742 The following parts of this section enumerate only the session- 1743 specific risks which are in addition to general risk associated with 1744 bare obfuscation and lack of integrity checking. 1746 9.2. Security of Authentication Sessions 1748 Authentication sessions SHOULD be used via a secure transport as the 1749 man-in-the-middle attack may completely subvert them. Even CHAP, 1750 which may be considered resistant to password interception, is unsafe 1751 as it does not protect the username from a trivial man-in-the-middle 1752 attack. 1754 This document deprecates the redirection mechanism using the 1755 TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the 1756 original draft. As part of this process, the secret key for a new 1757 server was sent to the client. This public exchange of secret keys 1758 means that once one session is broken, it may be possible to leverage 1759 that key to attacking connections to other servers. This mechanism 1760 SHOULD NOT be used in modern deployments. It MUST NOT be used 1761 outside a secured deployment. 1763 9.3. Security of Authorization Sessions 1765 Authorization sessions SHOULD be used via a secure transport as it's 1766 trivial to execute a successful man-in-the-middle attacks that 1767 changes well-known plaintext in either requests or responses. 1769 As an example, take the field "authen_method". It's not unusual in 1770 actual deployments to authorize all commands received via the device 1771 local serial port (a console port) as that one is usually considered 1772 secure by virtue of the device located in a physically secure 1773 location. If an administrator would configure the authorization 1774 system to allow all commands entered by the user on a local console 1775 to aid in troubleshooting, that would give all access to all commands 1776 to any attacker that would be able to change the "authen_method" from 1777 TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In 1778 this regard, the obfuscation provided by the protocol itself wouldn't 1779 help much, because: 1781 Lack of integrity means that any byte in the payload may be 1782 changed without either side detecting the change. 1784 Known plaintext means that an attacker would know with certainty 1785 which octet is the target of the attack (in this case, 1st octet 1786 after the header). 1788 In combination with known plaintext, the attacker can determine 1789 with certainty the value of the crypto-pad octet used to obfuscate 1790 the original octet. 1792 9.4. Security of Accounting Sessions 1794 Accounting sessions are not directly involved in authentication or 1795 authorizing operations on the device. However, man-in-the-middle 1796 attacker may do any of the following: 1798 Replace accounting data with new valid or garbage which prevents 1799 to provide distraction or hide information related to their 1800 authentication and/or authorization attack attempts. 1802 Try and poison accounting log with entries designed to make 1803 systems behave in unintended ways (which includes TACACS+ server 1804 and any other systems that would manage accounting entries). 1806 In addition to these direct manipulations, different client 1807 implementations pass different fidelity of accounting data. Some 1808 vendors have been observed in the wild that pass sensitive data like 1809 passwords, encryption keys and similar as part of the accounting log. 1810 Due to lack of strong encryption with perfect forward secrecy, this 1811 data may be revealed in future, leading to a security incident. 1813 9.5. TACACS+ Best Practices 1815 With respect to the observations about the security issues described 1816 above, a network administrator MUST NOT rely on the obfuscation of 1817 the TACACS+ protocol and TACACS+ MUST be deployed over networks which 1818 ensure privacy and integrity of the communication. TACACS+ MUST be 1819 used within a secure deployment. Failure to do so will impact 1820 overall network security. 1822 The following recommendations impose restrictions on how the protocol 1823 is applied. These restrictions were not imposed in the original 1824 draft. New implementations, and upgrades of current implementations, 1825 MUST implement these recommendations. 1827 9.5.1. Shared Secrets 1829 TACACS+ servers and clients MUST treat shared secrets as sensitive 1830 data to be managed securely, as would be expected for other sensitive 1831 data such as identity credential information. TACACS+ servers MUST 1832 not leak sensitive data. For example, TACACS+ servers should not 1833 expose shared secrets in logs. 1835 TACACS+ servers MUST allow a dedicated secret key to be defined for 1836 each client. 1838 TACACS+ servers SHOULD warn administrators if secret keys are not 1839 unique per client. 1841 TACACS+ server administrators SHOULD always define a secret for each 1842 client. 1844 TACACS+ servers and clients MUST support shared keys that are at 1845 least 32 characters long. 1847 TACACS+ clients SHOULD NOT allow servers to be configured without 1848 shared secret key, or shared key that is less than 16 characters 1849 long. 1851 TACACS+ server administrators SHOULD configure secret keys of minimum 1852 16 characters length. 1854 TACACS+ server administrators SHOULD change secret keys at regular 1855 intervals. 1857 9.5.2. Connections and Obfuscation 1859 TACACS+ servers MUST allow the definition of individual clients. The 1860 servers MUST only accept network connection attempts from these 1861 defined, known clients. 1863 TACACS+ servers MUST reject connections with 1864 TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on 1865 the server for the client requesting the connection. 1867 If an invalid shared secret is detected when processing packets for a 1868 client, TACACS+ servers MUST NOT accept any new sessions on that 1869 connection. TACACS+ servers MUST terminate the connection on 1870 completion of any sessions that were previously established with a 1871 valid shared secret on that connection. 1873 TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG when a secret 1874 is defined. Clients MUST be implemented in a way that requires 1875 explicit configuration to enable the use of 1876 TAC_PLUS_UNENCRYPTED_FLAG. 1878 When a TACACS+ client receives responses from servers where: 1880 the response packet was received from the server configured with 1881 shared key, but the packet jas TAC_PLUS_UNENCRYPTED_FLAG set. 1883 the response packet was received from the server configured not to 1884 use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not 1885 set. 1887 then the TACACS+ client MUST close TCP session, and process the 1888 response in the same way that a TAC_PLUS_AUTHEN_STATUS_FAIL 1889 (authentication sessions) or TAC_PLUS_AUTHOR_STATUS_FAIL 1890 (authorization sessions) was received. 1892 9.5.3. Authentication 1894 To allow TACACS+ administraots to select the stronger authentication 1895 options, TACACS+ servers MUST allow the administrator to configure 1896 the server to only accept challenge/response options for 1897 authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or 1898 TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for 1899 authen_type). 1901 TACACS+ server administrators SHOULD enable the option mentioned in 1902 the previous paragraph. TACACS+ Server deployments SHOULD ONLY 1903 enable other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or 1904 TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of 1905 identity/password systems. 1907 TACACS+ server administrators SHOULD NOT allow the same credentials 1908 to be applied in challenge-based (TAC_PLUS_AUTHEN_TYPE_CHAP or 1909 TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non 1910 challenge-based authen_type options as the insecurity of the latter 1911 will compromise the security of the former. 1913 TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options 1914 mentioned in the original draft SHOULD not be used, due to their 1915 security implications. TACACS+ servers SHOULD NOT implement them. 1916 If they must be implemented, the servers MUST default to the options 1917 being disabled and MUST warn the administrator that these options are 1918 not secure. 1920 9.5.4. Authorization 1922 The authorization and accounting features are intended to provide 1923 extensibility and flexibility. There is a base dictionary defined in 1924 this document, but it may be extended in deployments by using new 1925 attribute names. The cost of the flexibility is that administrators 1926 and implementors MUST ensure that the attribute and value pairs 1927 shared between the clients and servers have consistent 1928 interpretation. 1930 TACACS+ clients that receive an unrecognised mandatory attribute MUST 1931 evaluate server response as if they received 1932 TAC_PLUS_AUTHOR_STATUS_FAIL. 1934 9.5.5. Redirection Mechanism 1936 The original draft described a redirection mechanism 1937 (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to 1938 secure. The option to send secret keys in the server list is 1939 particularly insecure, as it can reveal client shared secrets. 1941 TACACS+ servers SHOULD deprecate the redirection mechanism. 1943 If the redirection mechanism is implemented then TACACS+ servers MUST 1944 disable it by default, and MUST warn TACACS+ server administrators 1945 that it must only be enabled within a secure deployment due to the 1946 risks of revealing shared secrets. 1948 TACACS+ clients SHOULD deprecate this feature by treating 1949 TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. 1951 10. Acknowledgements 1953 The authors would like to thank the following reviewers whose 1954 comments and contributions made considerable improvements to the 1955 document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch, 1956 Robert Drake, among many others. 1958 The authors would particularly like to thank Alan DeKok, who provided 1959 significant insights and recommendations on all aspects of the 1960 document and the protocol. Alan DeKok has dedicated considerable 1961 time and effort to help improve the document, identifying weaknesses 1962 and providing remediation. 1964 The authors would also like to thanks the support from the OPSAWG 1965 Chairs and advisors. 1967 11. References 1969 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1970 April 1992. 1972 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1973 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1974 . 1976 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1977 "Randomness Recommendations for Security", RFC 1750, 1978 DOI 10.17487/RFC1750, December 1994, 1979 . 1981 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1982 RFC 2433, DOI 10.17487/RFC2433, October 1998, 1983 . 1985 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1986 RFC 2759, DOI 10.17487/RFC2759, January 2000, 1987 . 1989 [TheDraft] 1990 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 1991 1.78", June 1997, 1992 . 1994 Authors' Addresses 1996 Thorsten Dahm 1997 Google Inc 1998 1600 Amphitheatre Parkway 1999 Mountain View, CA 94043 2000 US 2002 EMail: thorstendlux@google.com 2004 Andrej Ota 2005 Google Inc 2006 1600 Amphitheatre Parkway 2007 Mountain View, CA 94043 2008 US 2010 EMail: andrej@ota.si 2012 Douglas C. Medway Gash 2013 Cisco Systems, Inc. 2014 170 West Tasman Dr. 2015 San Jose, CA 95134 2016 US 2018 EMail: dcmgash@cisco.com 2019 David Carrel 2020 vIPtela, Inc. 2021 1732 North First St. 2022 San Jose, CA 95112 2023 US 2025 EMail: dcarrel@viptela.com 2027 Lol Grant 2029 EMail: lol.grant@gmail.com