idnits 2.17.1 draft-ietf-opsawg-tacacs-10.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 212: '...e TCP connection. The client MUST NOT...' RFC 2119 keyword, line 225: '...lient and server MUST ignore the flag ...' RFC 2119 keyword, line 240: '... client MUST accommodate such closur...' RFC 2119 keyword, line 259: '... and it MUST behave as if the server...' RFC 2119 keyword, line 275: '...enabled, then the connection SHOULD be...' (90 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Start and stop records for the same event MUST have matching task_id attribute values. The client MUST ensure that active task_ids are not duplicated: a client MUST NOT reuse a task_id a start record until it has sent a stop record for that task_id. Servers MUST not make assumptions about the format of a task_id. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks that are considered secure. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 15, 2018) is 2204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1691 ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations T. Dahm 3 Internet-Draft A. Ota 4 Intended status: Informational Google Inc 5 Expires: October 17, 2018 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 April 15, 2018 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-10 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 October 17, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 70 3. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 4 71 3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.3. Single Connection Mode . . . . . . . . . . . . . . . . . 5 74 3.4. Session Completion . . . . . . . . . . . . . . . . . . . 6 75 3.5. Treatment of Enumerated Protocol Values . . . . . . . . . 7 76 3.6. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 7 77 3.7. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 7 78 3.8. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 9 79 3.9. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 11 80 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.1. The Authentication START Packet Body . . . . . . . . . . 12 82 4.2. The Authentication REPLY Packet Body . . . . . . . . . . 14 83 4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 16 84 4.4. Description of Authentication Process . . . . . . . . . . 16 85 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 86 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 87 4.4.3. Aborting an Authentication Session . . . . . . . . . 21 88 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 89 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 22 90 5.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 91 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 93 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 94 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 95 7.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 96 7.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 97 7.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 98 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 99 9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 100 9.1. General Security of The Protocol . . . . . . . . . . . . 36 101 9.2. Security of Authentication Sessions . . . . . . . . . . . 38 102 9.3. Security of Authorization Sessions . . . . . . . . . . . 38 103 9.4. Security of Accounting Sessions . . . . . . . . . . . . . 39 104 9.5. TACACS+ Client Implementation Recommendations . . . . . . 39 105 9.6. TACACS+ Server Implementation Recommendations . . . . . . 39 106 9.7. TACACS+ Deployment Best Practices . . . . . . . . . . . . 40 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 111 1. Introduction 113 Terminal Access Controller Access-Control System Plus (TACACS+) was 114 conceived initially as a general Authentication, Authorization and 115 Accounting protocol. It is primarily used today for Device 116 Administration: authenticating access to network devices, providing 117 central authorization of operations, and audit of those operations. 119 A wide range of TACACS+ clients and servers are already deployed in 120 the field. The TACACS+ protocol they are based on is defined in a 121 draft document that was originally intended for IETF publication. 122 This document is known as `The Draft' [TheDraft] . 124 It is intended that all implementations which conform to this 125 document will conform to `The Draft'. However, attention is drawn to 126 the following specific adjustments of the protocol specification from 127 'The Draft': 129 This document officially removes SENDPASS for security reasons. 131 The normative description of Legacy features such as ARAP and 132 outbound authentication has been removed, however, the required 133 enumerations are kept. 135 The Support for forwarding to an alternative daemon 136 (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated. 138 The TACACS+ protocol separates the functions of Authentication, 139 Authorization and Accounting. It allows for arbitrary length and 140 content authentication exchanges, to support future authentication 141 mechanisms. It is extensible to provide for site customization and 142 future development features, and it uses TCP to ensure reliable 143 delivery. The protocol allows the TACACS+ client to request very 144 fine-grained access control and allows the server to respond to each 145 component of that request. 147 The separation of authentication, authorization and accounting was a 148 key element of the design of TACACS+ protocol. Essentially it makes 149 TACACS+ a suite of three protocols. This document will address each 150 one in separate sections. Although TACACS+ defines all three, but an 151 implementation or configuration is not required to employ all three. 152 Separating the elements is useful for Device Administration use case, 153 specifically, for authorization of individual commands in a session. 154 Note that there is no provision made at the protocol level for 155 association of an authentication to each authorization request. 157 This document restricts itself to a description of the protocol that 158 is used by TACACS+. It does not cover deployment or best practices. 160 2. Technical Definitions 162 This section provides a few basic definitions that are applicable to 163 this document 165 Client 167 The client is any device, (often a Network Access Server) that 168 provides access services. The clients usually provide a character 169 mode front end and then allow the user to telnet or rlogin to another 170 host. 172 Server 174 The server receives TACACS+ protocol requests, and replies according 175 to its business model, in accordance with the flows defined in this 176 document. 178 Packet 180 All uses of the word packet in this document refer to TACACS+ 181 protocol packets unless explicitly noted otherwise. 183 3. TACACS+ Connections and Sessions 185 3.1. Connection 187 TACACS+ uses TCP for its transport. Server port 49 is allocated for 188 TACACS+ traffic. 190 3.2. Session 192 The concept of a session is used throughout this document. A TACACS+ 193 session is a single authentication sequence, a single authorization 194 exchange, or a single accounting exchange. 196 An accounting and authorization session will consist of a single pair 197 of packets (the request and its reply). An authentication session 198 may involve an arbitrary number of packets being exchanged. The 199 session is an operational concept that is maintained between the 200 TACACS+ client and server. It does not necessarily correspond to a 201 given user or user action. 203 3.3. Single Connection Mode 205 Single Connection Mode is intended to improve performance by allowing 206 a client to multiplex multiple session on a single TCP connection. 208 The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by 209 the client and server to negotiate the use of Single Connect Mode. 211 The client sets this flag, to indicate that it supports multiplexing 212 TACACS+ sessions over a single TCP connection. The client MUST NOT 213 send a second packet on a connection until single-connect status has 214 been established. 216 To indicate it will support Single Connection Mode, the server sets 217 this flag in the first reply packet in response to the first request 218 from a client. The server may set this flag even if the client does 219 not set it, but the client may ignore the flag and close the 220 connection after the session completes. 222 The flag is only relevant for the first two packets on a connection, 223 to allow the client and server to establish Single Connection Mode. 224 No provision is made for changing Single Connection Mode after the 225 first two packets: the client and server MUST ignore the flag after 226 the second packet on a connection. 228 If single Connection Mode has not been established in the first two 229 packets of a TCP connection, then both the client and the server 230 close the connection at the end of the first session. 232 The client negotiates Single Connection Mode to improve efficiency. 233 The server may refuse to allow Single Connection Mode for the client. 234 For example, it may not be appropriate to allocate a long-lasting TCP 235 connection to a specific client in some deployments. Even if the 236 server is configured to permit single Connection Mode for a specific 237 client, the server may close the connection. For example: a server 238 may be configured to time out a Single Connection Mode TCP Connection 239 after a specific period of inactivity to preserve its resources. The 240 client MUST accommodate such closures on a TCP session even after 241 Single Connection Mode has been established. 243 3.4. Session Completion 245 The REPLY packets defined for the packets types in the sections below 246 (Authentication, Authorization and Accounting) contain a status 247 field. The complete set of options for this field depend upon the 248 packet type, but all three REPLY packet types define values 249 representing PASS, ERROR and FAIL, which indicate the last packet of 250 a regular session (one which is not aborted). 252 The server responds with a PASS or a FAIL to indicate that the 253 processing of the request completed and the client can apply the 254 result (PASS or FAIL) to control the execution of the action which 255 prompted the request to be sent to the server. 257 The server responds with an ERROR to indicate that the processing of 258 the request did not complete. The client can not apply the result 259 and it MUST behave as if the server could not be connected to. For 260 example, the client tries alternative methods, if they are available, 261 such as sending the request to a backup server, or using local 262 configuration to determine whether the action which prompted the 263 request should be executed. 265 Refer to the section (Section 4.4.3) on Aborting Authentication 266 Sessions for details on handling additional status options. 268 When the session is complete, then the TCP connection should be 269 handled as follows, according to whether Single Connection Mode was 270 negotiated: 272 If Single Connection Mode was not negotiated, then the connection 273 should be closed 275 If Single Connection Mode was enabled, then the connection SHOULD be 276 left open (see section (Section 3.3) ), but may still be closed after 277 a timeout period to preserve deployment resources 279 If Single Connection Mode was enabled, but an ERROR occurred due to 280 connection issues (such as an incorrect secret, see section 281 (Section 3.7) ), then any further new sessions MUST NOT be accepted 282 on the connection. If there are any sessions that have already been 283 established then they MAY be completed. Once all active sessions are 284 completed then the connection MUST be closed. 286 It is recommended that client implementations provide robust schemes 287 for dealing with servers which cannot be connected to. Options 288 include providing a list of servers for redundancy, and an option for 289 a local fallback configuration if no servers can be reached. Details 290 will be implementation specific. 292 The client should manage connections and handle the case of a server 293 which establishes a connection, but does not respond. The exact 294 behavior is implementation specific. It is recommended that the 295 client should close the connection after a configurable timeout. 297 3.5. Treatment of Enumerated Protocol Values 299 This document describes various enumerated values in the packet 300 header and the headers for specific packet types. For example in the 301 Authentication start packet type, this document defines the action 302 field with three values TAC_PLUS_AUTHEN_LOGIN, TAC_PLUS_AUTHEN_CHPASS 303 and TAC_PLUS_AUTHEN_SENDAUTH. 305 If the server does not implement one of the defined options in a 306 packet that it receives, or it encounters an option that is not 307 listed in this document for a header field, then it should respond 308 with a ERROR and terminate the session. This will allow the client 309 to try a different option. 311 If an error occurs but the type of the incoming packet cannot be 312 determined, a packet with the identical cleartext header but with a 313 sequence number incremented by one and the length set to zero MUST be 314 returned to indicate an error. 316 3.6. Text Encoding 318 All text fields in TACACS+ MUST be printable US-ASCII, excepting 319 special consideration given to user field and data fields used for 320 passwords. 322 To ensure interoperability of current deployments, the TACACS+ client 323 and server MUST handle user fields and those data fields used for 324 passwords as 8-bit octet strings. The deployment operator MUST 325 ensure that consistent character encoding is applied from the end 326 client to the server. The encoding SHOULD be UTF-8, and other 327 encodings outside printable US-ASCII SHOULD be deprecated. 329 3.7. Data Obfuscation 331 The body of packets may be obfuscated. The following sections 332 describe the obfuscation method that is supported in the protocol. 333 In 'The Draft' this process was actually referred to as Encryption, 334 but the algorithm would not meet modern standards, and so will not be 335 termed as encryption in this document. 337 The obfuscation mechanism relies on a secret key, a shared secret 338 value that is known to both the client and the server. This document 339 does not discuss the management and storage of those keys, other than 340 to require that the secret keys MUST remain secret. 342 Server implementations MUST allow a unique secret key to be 343 associated with every client. It is a site-dependent decision as to 344 whether the use of separate keys is appropriate. 346 The flag field may be set as follows: 348 TAC_PLUS_UNENCRYPTED_FLAG = 0x0 350 In this case, the packet body is obfuscated by XOR-ing it byte-wise 351 with a pseudo-random pad. 353 ENCRYPTED {data} = data ^ pseudo_pad 355 The packet body can then be de-obfuscated by XOR-ing it byte-wise 356 with a pseudo random pad. 358 data = ENCRYPTED {data} ^ pseudo_pad 360 The pad is generated by concatenating a series of MD5 hashes (each 16 361 bytes long) and truncating it to the length of the input data. 363 Whenever used in this document, MD5 refers to the "RSA Data Security, 364 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 365 . 367 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 369 The first MD5 hash is generated by concatenating the session_id, the 370 secret key, the version number and the sequence number and then 371 running MD5 over that stream. All of those input values are 372 available in the packet header, except for the secret key which is a 373 shared secret between the TACACS+ client and server. 375 The version number and session_id are used as extracted from the 376 header 378 Subsequent hashes are generated by using the same input stream, but 379 concatenating the previous hash value at the end of the input stream. 381 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 382 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 383 version, seq_no, MD5_n-1} 385 When a server detects that the secret(s) it has configured for the 386 device mismatch, it MUST return ERROR. For details of TCP connection 387 handling on ERROR, refer to section (Section 3.4) 389 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 391 In this case, the entire packet body is in cleartext. Obfuscation 392 and de-obfuscation are null operations. This method should be 393 avoided unless absolutely required for debug purposes, when tooling 394 does not permit de-obfuscation. 396 If deployment is configured for obfuscating a connection then the 397 request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. 399 After a packet body is de-obfuscated, the lengths of the component 400 values in the packet are summed. If the sum is not identical to the 401 cleartext datalength value from the header, the packet MUST be 402 discarded, and an ERROR signaled. For details of TCP connection 403 handling on ERROR, refer to section (Section 3.4) 405 Commonly such failures are seen when the keys are mismatched between 406 the client and the TACACS+ server. 408 3.8. The TACACS+ Packet Header 410 All TACACS+ packets begin with the following 12-byte header. The 411 header describes the remainder of the packet: 413 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 414 +----------------+----------------+----------------+----------------+ 415 |major | minor | | | | 416 |version| version| type | seq_no | flags | 417 +----------------+----------------+----------------+----------------+ 418 | | 419 | session_id | 420 +----------------+----------------+----------------+----------------+ 421 | | 422 | length | 423 +----------------+----------------+----------------+----------------+ 425 major_version 427 This is the major TACACS+ version number. 429 TAC_PLUS_MAJOR_VER := 0xc 431 minor_version 433 The minor TACACS+ version number. 435 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 437 TAC_PLUS_MINOR_VER_ONE := 0x1 439 type 441 This is the packet type. Legal values are: 443 TAC_PLUS_AUTHEN := 0x01 (Authentication) 445 TAC_PLUS_AUTHOR := 0x02 (Authorization) 447 TAC_PLUS_ACCT := 0x03 (Accounting) 449 seq_no 451 This is the sequence number of the current packet. The first packet 452 in a session MUST have the sequence number 1 and each subsequent 453 packet will increment the sequence number by one. Thus clients only 454 send packets containing odd sequence numbers, and TACACS+ servers 455 only send packets containing even sequence numbers. 457 The sequence number must never wrap i.e. if the sequence number 2^8-1 458 is ever reached, that session must terminate and be restarted with a 459 sequence number of 1. 461 flags 463 This field contains various bitmapped flags. 465 The flag bit: 467 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 469 This flag indicates that the sender did not obfuscate the body of the 470 packet. The application of this flag will be covered in the security 471 section (Section 9) . 473 This flag SHOULD be clear in all deployments. Modern network traffic 474 tools support encrypted traffic when configured with the shared 475 secret (see section below), so obfuscated mode can and SHOULD be used 476 even during test. 478 The single-connection flag: 480 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 482 This flag is used to allow a client and server to negotiate Single 483 Connection Mode. 485 session_id 487 The Id for this TACACS+ session. This field does not change for the 488 duration of the TACACS+ session. This number MUST be generated by a 489 cryptographically strong random number generation method. Failure to 490 do so will compromise security of the session. For more details 491 refer to RFC 1750 [RFC1750] 493 length 495 The total length of the packet body (not including the header). 497 3.9. The TACACS+ Packet Body 499 The TACACS+ body types are defined in the packet header. The next 500 sections of this document will address the contents of the different 501 TACACS+ bodies. The following general rules apply to all TACACS+ 502 body types: 504 - To signal that any variable length data fields are unused, their 505 length value is set to zero. Such fields MUST be ignored, and 506 treated as if not present. 508 - the lengths of data and message fields in a packet are specified 509 by their corresponding length fields, (and are not null 510 terminated.) 512 - All length values are unsigned and in network byte order. 514 4. Authentication 516 Authentication is the action of determining who a user (or entity) 517 is. Authentication can take many forms. Traditional authentication 518 employs a name and a fixed password. However, fixed passwords are 519 vulnerable security, so many modern authentication mechanisms utilize 520 "one-time" passwords or a challenge-response query. TACACS+ is 521 designed to support all of these, and be flexible enough to handle 522 any future mechanisms. Authentication generally takes place when the 523 user first logs in to a machine or requests a service of it. 525 Authentication is not mandatory; it is a site-configured option. 526 Some sites do not require it. Others require it only for certain 527 services (see authorization below). Authentication may also take 528 place when a user attempts to gain extra privileges, and must 529 identify himself or herself as someone who possesses the required 530 information (passwords, etc.) for those privileges. 532 4.1. The Authentication START Packet Body 534 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 535 +----------------+----------------+----------------+----------------+ 536 | action | priv_lvl | authen_type | authen_service | 537 +----------------+----------------+----------------+----------------+ 538 | user_len | port_len | rem_addr_len | data_len | 539 +----------------+----------------+----------------+----------------+ 540 | user ... 541 +----------------+----------------+----------------+----------------+ 542 | port ... 543 +----------------+----------------+----------------+----------------+ 544 | rem_addr ... 545 +----------------+----------------+----------------+----------------+ 546 | data... 547 +----------------+----------------+----------------+----------------+ 549 Packet fields are as follows: 551 action 553 This indicates the authentication action. Legal values are listed 554 below. 556 TAC_PLUS_AUTHEN_LOGIN := 0x01 558 TAC_PLUS_AUTHEN_CHPASS := 0x02 560 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 562 priv_lvl 564 This indicates the privilege level that the user is authenticating 565 as. Please refer to the Privilege Level section (Section 8) below. 567 authen_type 569 The type of authentication. Legal values are: 571 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 572 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 574 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 576 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 578 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 580 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 582 authen_service 584 This is the service that is requesting the authentication. Legal 585 values are: 587 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 589 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 591 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 593 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 595 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 597 TAC_PLUS_AUTHEN_SVC_PT := 0x05 599 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 601 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 603 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 605 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 607 The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization 608 application of this field that indicates that no authentication was 609 performed by the device. 611 The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates regular login (as 612 opposed to ENABLE) to a client device. 614 The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE 615 authen_service, which refers to a service requesting authentication 616 in order to grant the user different privileges. This is comparable 617 to the Unix "su(1)" command, which substitutes the current user's 618 identity with another. An authen_service value of NONE is only to be 619 used when none of the other authen_service values are appropriate. 621 ENABLE may be requested independently, no requirements for previous 622 authentications or authorizations are imposed by the protocol. 624 Other options are included for legacy/backwards compatibility. 626 user, user_len 628 The username is optional in this packet, depending upon the class of 629 authentication. If it is absent, the client MUST set user_len to 0. 630 If included, the user_len indicates the length of the user field, in 631 bytes. 633 port, port_len 635 The printable US-ASCII name of the client port on which the 636 authentication is taking place, and its length in bytes. The value 637 of this field is client specific. (For example, Cisco uses "tty10" 638 to denote the tenth tty line and "Async10" to denote the tenth async 639 interface). The port_len indicates the length of the port field, in 640 bytes. 642 rem_addr, rem_addr_len 644 A printable US-ASCII string indicating the remote location from which 645 the user has connected to the client. It is intended to hold a 646 network address if the user is connected via a network, a caller ID 647 is the user is connected via ISDN or a POTS, or any other remote 648 location information that is available. This field is optional 649 (since the information may not be available). The rem_addr_len 650 indicates the length of the user field, in bytes. 652 data, data_len 654 This field is used to send data appropriate for the action and 655 authen_type. It is described in more detail in the section Common 656 Authentication flows (Section 4.4.2) . The data_len indicates the 657 length of the data field, in bytes. 659 4.2. The Authentication REPLY Packet Body 661 The TACACS+ server sends only one type of authentication packet (a 662 REPLY packet) to the client. 664 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 665 +----------------+----------------+----------------+----------------+ 666 | status | flags | server_msg_len | 667 +----------------+----------------+----------------+----------------+ 668 | data_len | server_msg ... 669 +----------------+----------------+----------------+----------------+ 670 | data ... 671 +----------------+----------------+ 673 status 675 The current status of the authentication. Legal values are: 677 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 679 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 681 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 683 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 685 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 687 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 689 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 691 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 693 flags 695 Bitmapped flags that modify the action to be taken. The following 696 values are defined: 698 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 700 server_msg, server_msg_len 702 A message to be displayed to the user. This field is optional. The 703 printable US-ASCII charset MUST be used. The server_msg_len 704 indicates the length of the server_msg field, in bytes. 706 data, data_len 708 This field holds data that is a part of the authentication exchange 709 and is intended for the client, not the user. Examples of its use 710 are shown in the section Common Authentication flows (Section 4.4.2) 711 . The data_len indicates the length of the data field, in bytes. 713 4.3. The Authentication CONTINUE Packet Body 715 This packet is sent from the client to the server following the 716 receipt of a REPLY packet. 718 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 719 +----------------+----------------+----------------+----------------+ 720 | user_msg len | data_len | 721 +----------------+----------------+----------------+----------------+ 722 | flags | user_msg ... 723 +----------------+----------------+----------------+----------------+ 724 | data ... 725 +----------------+ 727 user_msg, user_msg_len 729 This field is the string that the user entered, or the client 730 provided on behalf of the user, in response to the server_msg from a 731 REPLY packet. The user_len indicates the length of the user field, 732 in bytes. 734 data, data_len 736 This field carries information that is specific to the action and the 737 authen_type for this session. Valid uses of this field are described 738 below. The data_len indicates the length of the data field, in 739 bytes. 741 flags 743 This holds the bitmapped flags that modify the action to be taken. 744 The following values are defined: 746 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 748 4.4. Description of Authentication Process 750 The action, authen_type and authen_service fields (described above) 751 combine to indicate what kind of authentication is to be performed. 752 Every authentication START, REPLY and CONTINUE packet includes a data 753 field. The use of this field is dependent upon the kind of the 754 Authentication. 756 This document defines a core set of authentication flows to be 757 supported by TACACS+. Each authentication flow consists of a START 758 packet. The server responds either with a request for more 759 information (GETDATA, GETUSER or GETPASS) or a termination PASS, 760 FAIL, ERROR or RESTART. The actions and meanings when the server 761 sends a RESTART or ERROR are common and are described further below. 763 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 764 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 765 then authentication continues and the server SHOULD provide 766 server_msg content for the client to prompt the user for more 767 information. The client MUST then return a CONTINUE packet 768 containing the requested information in the user_msg field. 770 The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a 771 request for username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request 772 for password. The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic 773 request for more information to flexibly support future requirements. 775 If the information being requested by the server form the client is 776 sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO 777 flag. When the client queries the user for the information, the 778 response MUST NOT be echoed as it is entered. 780 The data field is only used in the REPLY where explicitly defined 781 below. 783 4.4.1. Version Behaviour 785 The TACACS+ protocol is versioned to allow revisions while 786 maintaining backwards compatibility. The version number is in every 787 packet header. The changes between minor_version 0 and 1 apply only 788 to the authentication process, and all deal with the way that CHAP 789 and PAP authentications are handled. minor_version 1 may only be used 790 for authentication kinds that explicitly call for it in the table 791 below: 793 LOGIN CHPASS SENDAUTH 794 ASCII v0 v0 - 795 PAP v1 - v1 796 CHAP v1 - v1 797 MS-CHAPv1/2 v1 - v1 799 The '-' symbol represents that the option is not valid. 801 All authorisation and accounting and ASCII authentication use 802 minor_version number of 0. 804 PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange 805 is a single START packet from the client and a single REPLY from the 806 server. 808 The removal of SENDPASS was prompted by security concerns, and is no 809 longer considered part of the TACACS+ protocol. 811 4.4.2. Common Authentication Flows 813 This section describes common authentication flows. If the server 814 does not implement an option, it MUST respond with 815 TAC_PLUS_AUTHEN_STATUS_FAIL. 817 4.4.2.1. ASCII Login 819 action = TAC_PLUS_AUTHEN_LOGIN 820 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 821 minor_version = 0x0 823 This is a standard ASCII authentication. The START packet MAY 824 contain the username. If the user does not include the username then 825 the server MUST obtain it from the client with a CONTINUE 826 TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user does not provide a 827 username then the server can send another 828 TAC_PLUS_AUTHEN_STATUS_GETUSER request, but the server MUST limit the 829 number of retries that are permitted, recommended limit is three 830 attempts. When the server has the username, it will obtain the 831 password using a continue with TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII 832 login uses the user_msg field for both the username and password. 833 The data fields in both the START and CONTINUE packets are not used 834 for ASCII logins, any content MUST be ignored. The session is 835 composed of a single START followed by zero or more pairs of REPLYs 836 and CONTINUEs, followed by a final REPLY indicating PASS, FAIL or 837 ERROR. 839 4.4.2.2. PAP Login 841 action = TAC_PLUS_AUTHEN_LOGIN 842 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 843 minor_version = 0x1 845 The entire exchange MUST consist of a single START packet and a 846 single REPLY. The START packet MUST contain a username and the data 847 field MUST contain the PAP ASCII password. A PAP authentication only 848 consists of a username and password RFC 1334 [RFC1334] . The REPLY 849 from the server MUST be either a PASS, FAIL or ERROR. 851 4.4.2.3. CHAP login 853 action = TAC_PLUS_AUTHEN_LOGIN 854 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 855 minor_version = 0x1 857 The entire exchange MUST consist of a single START packet and a 858 single REPLY. The START packet MUST contain the username in the user 859 field and the data field is a concatenation of the PPP id, the 860 challenge and the response. 862 The length of the challenge value can be determined from the length 863 of the data field minus the length of the id (always 1 octet) and the 864 length of the response field (always 16 octets). 866 To perform the authentication, the server calculates the PPP hash as 867 defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then 868 compare that value with the response. The MD5 algorithm option is 869 always used. The REPLY from the server MUST be a PASS, FAIL or 870 ERROR. 872 In cases where the client conducts the exchange with the endstation 873 and then sends the resulting materials (challenge and response) to 874 the server, the selection of the challenge and its length are not an 875 aspect of the TACACS+ protocol. However, it is strongly recommended 876 that the client/endstation interaction is configured with a secure 877 challenge. The TACACS+ server can help by rejecting authentications 878 where the challenge is below a minimum length (Minimum recommended is 879 8 bytes). 881 In cases where the TACACS+ Server generates the challenge then it 882 MUST change for every request and MUST be derived from a strong 883 cryptographic source. 885 4.4.2.4. MS-CHAP v1 login 887 action = TAC_PLUS_AUTHEN_LOGIN 888 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 889 minor_version = 0x1 891 The entire exchange MUST consist of a single START packet and a 892 single REPLY. The START packet MUST contain the username in the user 893 field and the data field will be a concatenation of the PPP id, the 894 MS-CHAP challenge and the MS-CHAP response. 896 The length of the challenge value can be determined from the length 897 of the data field minus the length of the id (always 1 octet) and the 898 length of the response field (always 49 octets). 900 To perform the authentication, the server will use a combination of 901 MD4 and DES on the user's secret and the challenge, as defined in RFC 902 2433 [RFC2433] and then compare the resulting value with the 903 response. The REPLY from the server MUST be a PASS or FAIL. 905 For best practices, please refer to RFC 2433 [RFC2433] . The TACACS+ 906 server MUST reject authentications where the challenge deviates from 907 8 bytes as defined in the RFC. 909 4.4.2.5. MS-CHAP v2 login 911 action = TAC_PLUS_AUTHEN_LOGIN 912 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 913 minor_version = 0x1 915 The entire exchange MUST consist of a single START packet and a 916 single REPLY. The START packet MUST contain the username in the user 917 field and the data field will be a concatenation of the PPP id, the 918 MS-CHAP challenge and the MS-CHAP response. 920 The length of the challenge value can be determined from the length 921 of the data field minus the length of the id (always 1 octet) and the 922 length of the response field (always 49 octets). 924 To perform the authentication, the server will use the algorithm 925 specified RFC 2759 [RFC2759] on the user's secret and challenge and 926 then compare the resulting value with the response. The REPLY from 927 the server MUST be a PASS or FAIL. 929 For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] 930 . The TACACS+ server MUST rejects authentications where the challenge 931 deviates from 16 bytes as defined in the RFC. 933 4.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 4.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 4.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 4.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 3.4) 974 In the case of PALL, FAIL or ERROR, the server can insert a message 975 into 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 5. 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 7.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 5.1. The Authorization REQUEST Packet Body 1033 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 1034 +----------------+----------------+----------------+----------------+ 1035 | authen_method | priv_lvl | authen_type | authen_service | 1036 +----------------+----------------+----------------+----------------+ 1037 | user_len | port_len | rem_addr_len | arg_cnt | 1038 +----------------+----------------+----------------+----------------+ 1039 | arg_1_len | arg_2_len | ... | arg_N_len | 1040 +----------------+----------------+----------------+----------------+ 1041 | user ... 1042 +----------------+----------------+----------------+----------------+ 1043 | port ... 1044 +----------------+----------------+----------------+----------------+ 1045 | rem_addr ... 1046 +----------------+----------------+----------------+----------------+ 1047 | arg_1 ... 1048 +----------------+----------------+----------------+----------------+ 1049 | arg_2 ... 1050 +----------------+----------------+----------------+----------------+ 1051 | ... 1052 +----------------+----------------+----------------+----------------+ 1053 | arg_N ... 1054 +----------------+----------------+----------------+----------------+ 1056 authen_method 1058 This indicates the authentication method used by the client to 1059 acquire the user information. As this information is not always 1060 subject to verification, it is recommended that this field is 1061 ignored. 1063 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1065 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1067 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1069 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1071 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1073 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1075 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1077 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1079 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1080 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1082 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1084 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1085 password associated with the terminal line used to gain access. 1086 LOCAL is a client local user database. ENABLE is a command that 1087 authenticates in order to grant new privileges. TACACSPLUS is, of 1088 course, TACACS+. GUEST is an unqualified guest authentication, such 1089 as an ARAP guest login. RADIUS is the Radius authentication 1090 protocol. RCMD refers to authentication provided via the R-command 1091 protocols from Berkeley Unix. 1093 priv_lvl 1095 This field is used in the same way as the priv_lvl field in 1096 authentication request and is described in the Privilege Level 1097 section (Section 8) below. It indicates the users current privilege 1098 level. 1100 authen_type 1102 This field coresponds to the authen_type field in the authentication 1103 section (Section 4) above. It indicates the type of authentication 1104 that was performed. If this information is not available, then the 1105 client will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. 1106 This value is valid only in authorization and accounting requests. 1108 authen_service 1110 This field is the same as the authen_service field in the 1111 authentication section (Section 4) above. It indicates the service 1112 through which the user authenticated. 1114 user, user_len 1116 This field contains the user's account name. The user_len MUST 1117 indicate the length of the user field, in bytes. 1119 port, port_len 1121 This field matches the port field in the authentication section 1122 (Section 4) above. The port_len indicates the length of the port 1123 field, in bytes. 1125 rem_addr, rem_addr_len 1126 This field matches the rem_addr field in the authentication section 1127 (Section 4) above. The rem_addr_len indicates the length of the port 1128 field, in bytes. 1130 arg_cnt 1132 The number of authorization arguments to follow 1134 arg_1 ... arg_N, arg_1_len .... arg_N_len 1136 The arguments are the primary elements of the authorization 1137 interaction. In the request packet they describe the specifics of 1138 the authorization that is being requested. Each argument is encoded 1139 in the packet as a single arg filed (arg_1... arg_N) with a 1140 corresponding length fields (which indicates the length of each 1141 argument in bytes). 1143 The authorization arguments in both the REQUEST and the REPLY are 1144 attribute-value pairs. The attribute and the value are in a single 1145 printable US-ASCII string and are separated by either a "=" (0X3D) or 1146 a "*" (0X2A). The equals sign indicates a mandatory argument. The 1147 asterisk indicates an optional one. 1149 It is not legal for an attribute name to contain either of the 1150 separators. It is legal for attribute values to contain the 1151 separators. This means that the arguments must be parsed until the 1152 first separator is encountered, all characters in the argument, after 1153 this separator, are interpreted as the argument value. 1155 Optional arguments are ones that may be disregarded by either client 1156 or server. Mandatory arguments require that the receiving side can 1157 handle the attribute, that is: its implementation and configuration 1158 includes the details of how to act on it. If the client receives a 1159 mandatory argument that it cannot handle, it MUST consider the 1160 authorization to have failed. It is legal to send an attribute-value 1161 pair with a zero length value. 1163 Attribute-value strings are not NULL terminated, rather their length 1164 value indicates their end. The maximum length of an attribute-value 1165 string is 255 characters. The minimum is two characters (one name- 1166 value character and the separator) 1168 Though the attributes allow extensibility, a common core set of 1169 authorization attributes SHOULD be supported by clients and servers, 1170 these are listed in the Authorization Attributes (Section 7.2) 1171 section below. 1173 5.2. The Authorization REPLY Packet Body 1175 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 1176 +----------------+----------------+----------------+----------------+ 1177 | status | arg_cnt | server_msg len | 1178 +----------------+----------------+----------------+----------------+ 1179 + data_len | arg_1_len | arg_2_len | 1180 +----------------+----------------+----------------+----------------+ 1181 | ... | arg_N_len | server_msg ... 1182 +----------------+----------------+----------------+----------------+ 1183 | data ... 1184 +----------------+----------------+----------------+----------------+ 1185 | arg_1 ... 1186 +----------------+----------------+----------------+----------------+ 1187 | arg_2 ... 1188 +----------------+----------------+----------------+----------------+ 1189 | ... 1190 +----------------+----------------+----------------+----------------+ 1191 | arg_N ... 1192 +----------------+----------------+----------------+----------------+ 1194 status This field indicates the authorization status 1196 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1198 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1200 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1202 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1204 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1206 server_msg, server_msg_len 1208 This is a printable US-ASCII string that may be presented to the 1209 user. The server_msg_len indicates the length of the server_msg 1210 field, in bytes. 1212 data, data_len 1214 This is a printable US-ASCII string that may be presented on an 1215 administrative display, console or log. The decision to present this 1216 message is client specific. The data_len indicates the length of the 1217 data field, in bytes. 1219 arg_cnt 1220 The number of authorization arguments to follow. 1222 arg_1 ... arg_N, arg_1_len .... arg_N_len 1224 The arguments describe the specifics of the authorization that is 1225 being requested. For details of the content of the args, refer to: 1226 Authorization Attributes (Section 7.2) section below. Each argument 1227 is encoded in the packet as a single arg field (arg_1... arg_N) with 1228 a corresponding length fields (which indicates the length of each 1229 argument in bytes). 1231 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested 1232 authorization MUST be denied. 1234 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1235 arguments specified in the request are authorized and the arguments 1236 in the response MUST be applied according to the rules described 1237 above. 1239 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client 1240 MUST use the authorization attribute-value pairs (if any) in the 1241 response, instead of the authorization attribute-value pairs from the 1242 request. 1244 To approve the authorization with no modifications, the server sets 1245 the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. 1247 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1248 on the server. For the differences between ERROR and FAIL, refer to 1249 section Session Completion (Section 3.4) . None of the arg values 1250 have any relevance if an ERROR is set, and must be ignored. 1252 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1253 arg_cnt MUST be 0. In that case, the actions to be taken and the 1254 contents of the data field are identical to the 1255 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1257 6. Accounting 1259 Accounting is typically the third action after authentication and 1260 authorization. But again, neither authentication nor authorization 1261 is required. Accounting is the action of recording what a user is 1262 doing, and/or has done. Accounting in TACACS+ can serve two 1263 purposes: It may be used as an auditing tool for security services. 1264 It may also be used to account for services used, such as in a 1265 billing environment. To this end, TACACS+ supports three types of 1266 accounting records. Start records indicate that a service is about 1267 to begin. Stop records indicate that a service has just terminated, 1268 and Update records are intermediate notices that indicate that a 1269 service is still being performed. TACACS+ accounting records contain 1270 all the information used in the authorization records, and also 1271 contain accounting specific information such as start and stop times 1272 (when appropriate) and resource usage information. A list of 1273 accounting attributes is defined in the accounting section 1274 (Section 6) . 1276 6.1. The Account REQUEST Packet Body 1278 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 1279 +----------------+----------------+----------------+----------------+ 1280 | flags | authen_method | priv_lvl | authen_type | 1281 +----------------+----------------+----------------+----------------+ 1282 | authen_service | user_len | port_len | rem_addr_len | 1283 +----------------+----------------+----------------+----------------+ 1284 | arg_cnt | arg_1_len | arg_2_len | ... | 1285 +----------------+----------------+----------------+----------------+ 1286 | arg_N_len | user ... 1287 +----------------+----------------+----------------+----------------+ 1288 | port ... 1289 +----------------+----------------+----------------+----------------+ 1290 | rem_addr ... 1291 +----------------+----------------+----------------+----------------+ 1292 | arg_1 ... 1293 +----------------+----------------+----------------+----------------+ 1294 | arg_2 ... 1295 +----------------+----------------+----------------+----------------+ 1296 | ... 1297 +----------------+----------------+----------------+----------------+ 1298 | arg_N ... 1299 +----------------+----------------+----------------+----------------+ 1301 flags 1303 This holds bitmapped flags. 1305 TAC_PLUS_ACCT_FLAG_START := 0x02 1307 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1309 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1311 All other fields are defined in the authorization and authentication 1312 sections above and have the same semantics. They provide details for 1313 the conditions on the client, and authentication context, so that 1314 these details may be logged for accounting purposes. 1316 See section 12 Accounting Attribute-value Pairs for the dictionary of 1317 attributes relevant to accounting. 1319 6.2. The Accounting REPLY Packet Body 1321 The purpose of accounting is to record the action that has occurred 1322 on the client. The server MUST reply with success only when the 1323 accounting request has been recorded. If the server did not record 1324 the accounting request then it MUST reply with ERROR. 1326 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 1327 +----------------+----------------+----------------+----------------+ 1328 | server_msg len | data_len | 1329 +----------------+----------------+----------------+----------------+ 1330 | status | server_msg ... 1331 +----------------+----------------+----------------+----------------+ 1332 | data ... 1333 +----------------+ 1335 status 1337 This is the return status. Values are: 1339 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1341 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1343 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1345 server_msg, server_msg_len 1347 This is a printable US-ASCII string that may be presented to the 1348 user. The server_msg_len indicates the length of the server_msg 1349 field, in bytes. 1351 data, data_len 1353 This is a printable US-ASCII string that may be presented on an 1354 administrative display, console or log. The decision to present this 1355 message is client specific. The data_len indicates the length of the 1356 data field, in bytes. 1358 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1359 to be taken and the contents of the data field are identical to the 1360 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1362 TACACS+ accounting is intended to record various types of events on 1363 clients, for example: login sessions, command entry, and others as 1364 required by the client implementation. These events are collectively 1365 referred to in `The Draft' [TheDraft] as "tasks". 1367 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1368 accounting message. Start messages will only be sent once when a 1369 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1370 a stop record and that the task has terminated. The 1371 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1373 Summary of Accounting Packets 1375 +----------+-------+-------+-------------+-------------------------+ 1376 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1377 +----------+-------+-------+-------------+-------------------------+ 1378 | 0 | 0 | 0 | 0 | INVALID | 1379 | 0 | 0 | 1 | 2 | Start Accounting Record | 1380 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1381 | 0 | 1 | 1 | 6 | INVALID | 1382 | 1 | 0 | 0 | 8 | Watchdog, no update | 1383 | 1 | 0 | 1 | A | Watchdog, with update | 1384 | 1 | 1 | 0 | C | INVALID | 1385 | 1 | 1 | 1 | E | INVALID | 1386 +----------+-------+-------+-------------+-------------------------+ 1388 The START and STOP flags are mutually exclusive. 1390 The WATCHDOG flag is used by the client to communicate ongoing status 1391 of a long-running task. Update records are sent at the client's 1392 discretion. The frequency of the update depends upon the intended 1393 application: A watchdog to provide progress indication will require 1394 higher frequency than a daily keep-alive. When the WATCHDOG flag is 1395 set along with the START flag, it indicates that the update record 1396 provides additional or updated arguments from the original START 1397 record. If the START flag is not set, then this indicates only that 1398 task is still running, and no new information is provided (servers 1399 MUST ignore any arguments). The STOP flag MUST NOT be set in 1400 conjunction with the WATCHDOG flag. 1402 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1403 requests an INVALID option. 1405 7. Attribute-Value Pairs 1407 TACACS+ is intended to be an extensible protocol. The attributes 1408 used in Authorization and Accounting are not limited by this 1409 document. Some attributes are defined below for common use cases, 1410 clients MUST use these attributes when supporting the corresponding 1411 use cases. 1413 7.1. Value Encoding 1415 All attribute values are encoded as printable US-ASCII strings. The 1416 following type representations SHOULD be followed 1418 Numeric 1420 All numeric values in an attribute-value string are provided as 1421 decimal printable US-ASCII numbers, unless otherwise stated. 1423 Boolean 1425 All boolean attributes are encoded as printable US-ASCII with values 1426 "true" or "false". 1428 IP-Address 1430 It is recommended that hosts be specified as a IP address so as to 1431 avoid any ambiguities. IPV4 address are specified as US-ASCII octet 1432 numerics separated by dots ('.'), IPV6 address text representation 1433 defined in RFC 4291. 1435 Date Time 1437 Absolute date/times are specified in seconds since the epoch, 12:00am 1438 Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is 1439 specified. Stardate is canonically inconsistent and so SHOULD NOT be 1440 used. 1442 String 1444 Many values have no specific type representation and so are 1445 interpreted as plain strings. 1447 Empty Values 1449 Attributes may be submitted with no value, in which case they consist 1450 of the name and the mandatory or optional separator. For example, 1451 the attribute "cmd" which has no value is transmitted as a string of 1452 four characters "cmd=" 1454 7.2. Authorization Attributes 1456 service (String) 1458 The primary service. Specifying a service attribute indicates that 1459 this is a request for authorization or accounting of that service. 1461 For example: "shell", "tty-server", "connection", "system" and 1462 "firewall". This attribute MUST always be included. 1464 protocol (String) 1466 the protocol field may be used to indicate a subset of a service. 1468 cmd (String) 1470 a shell (exec) command. This indicates the command name of the 1471 command that is to be run. The "cmd" attribute MUST be specified if 1472 service equals "shell". 1474 Authorization of shell commands is a common use-case for the TACACS+ 1475 protocol. Command Authorization generally takes one of two forms: 1476 session-based and command-based. 1478 For session-based shell authorization, the "cmd" argument will have 1479 an empty value. The client determines which commands are allowed in 1480 a session according to the arguments present in the authorization. 1482 In command-based authorization, the client requests that the server 1483 determine whether a command is allowed by making an authorization 1484 request for each command. The "cmd" argument will have the command 1485 name as its value. 1487 cmd-arg (String) 1489 an argument to a shell (exec) command. This indicates an argument 1490 for the shell command that is to be run. Multiple cmd-arg attributes 1491 may be specified, and they are order dependent. 1493 acl (Numeric) 1495 printable US-ASCII number representing a connection access list. 1496 Applicable only to session-based shell authorization. 1498 inacl (String) 1500 printable US-ASCII identifier for an interface input access list. 1502 outacl (String) 1504 printable US-ASCII identifier for an interface output access list. 1506 addr (IP-Address) 1508 a network address 1509 addr-pool (String) 1511 The identifier of an address pool from which the client can assign an 1512 address. 1514 routing (Boolean) 1516 Specifies whether routing information is to be propagated to, and 1517 accepted from this interface. 1519 route (String) 1521 Indicates a route that is to be applied to this interface. Values 1522 MUST be of the form " []". If a 1523 is not specified, the resulting route is via the 1524 requesting peer. 1526 timeout (Numeric) 1528 an absolute timer for the connection (in minutes). A value of zero 1529 indicates no timeout. 1531 idletime (Numeric) 1533 an idle-timeout for the connection (in minutes). A value of zero 1534 indicates no timeout. 1536 autocmd (String) 1538 an auto-command to run. Applicable only to session-based shell 1539 authorization. 1541 noescape (Boolean) 1543 Prevents user from using an escape character. Applicable only to 1544 session-based shell authorization. 1546 nohangup (Boolean) 1548 Boolean. Do not disconnect after an automatic command. Applicable 1549 only to session-based shell authorization. 1551 priv-lvl (Numeric) 1553 privilege level to be assigned. Please refer to the Privilege Level 1554 section (Section 8) below. 1556 remote_user (String) 1557 remote userid (authen_method must have the value 1558 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1559 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1560 remote_user and remote_host attributes will provide the remote user 1561 and host information to enable rhost style authorization. The 1562 response may request that a privilege level be set for the user. 1564 remote_host (String) 1566 remote host (authen_method must have the value 1567 TAC_PLUS_AUTHEN_METH_RCMD) 1569 7.3. Accounting Attributes 1571 The following attributes are defined for TACACS+ accounting only. 1572 They MUST precede any attribute-value pairs that are defined in the 1573 authorization section (Section 5) above. 1575 task_id (String) 1577 Start and stop records for the same event MUST have matching task_id 1578 attribute values. The client MUST ensure that active task_ids are 1579 not duplicated: a client MUST NOT reuse a task_id a start record 1580 until it has sent a stop record for that task_id. Servers MUST not 1581 make assumptions about the format of a task_id. 1583 start_time (Date Time) 1585 The time the action started (in seconds since the epoch.). 1587 stop_time (Date Time) 1589 The time the action stopped (in seconds since the epoch.) 1591 elapsed_time (Numeric) 1593 The elapsed time in seconds for the action. 1595 timezone (String) 1597 The timezone abbreviation for all timestamps included in this packet. 1599 event (String) 1601 Used only when "service=system". Current values are "net_acct", 1602 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1603 These indicate system-level changes. The flags field SHOULD indicate 1604 whether the service started or stopped. 1606 reason (String) 1608 Accompanies an event attribute. It describes why the event occurred. 1610 bytes (Numeric) 1612 The number of bytes transferred by this action 1614 bytes_in (Numeric) 1616 The number of bytes transferred by this action from the endstation to 1617 the client port 1619 bytes_out (Numeric) 1621 The number of bytes transferred by this action from the client to the 1622 endstation port 1624 paks (Numeric) 1626 The number of packets transferred by this action. 1628 paks_in (Numeric) 1630 The number of input packets transferred by this action from the 1631 endstation to the client port. 1633 paks_out (Numeric) 1635 The number of output packets transferred by this action from the 1636 client port to the endstation. 1638 err_msg (String) 1640 A printable US-ASCII string describing the status of the action. 1642 8. Privilege Levels 1644 The TACACS+ Protocol supports flexible authorization schemes through 1645 the extensible attributes. 1647 One scheme is built into the protocol and has been extensively used 1648 for Session-based shell authorization: Privilege Levels. Privilege 1649 Levels are ordered values from 0 to 15 with each level being a 1650 superset of the next lower value. Configuration and implementation 1651 of the client will map actions (such as the permission to execute of 1652 specific commands) to different privilege levels. Pre-defined values 1653 are: 1655 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1657 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1659 TAC_PLUS_PRIV_LVL_USER := 0x01 1661 TAC_PLUS_PRIV_LVL_MIN := 0x00 1663 A Privilege level can be assigned to a shell (EXEC) session when it 1664 starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will permit 1665 the actions associated with this level to be executed. This 1666 privilege level is returned by the Server in a session-based shell 1667 authorization (when "service" equals "shell" and "cmd" is empty). 1668 When a user required to perform actions that are mapped to a higher 1669 privilege level, then an ENABLE type reauthentication can be 1670 initiated by the client. The client will insert the required 1671 privilege level into the authentication header for enable 1672 authentication request. 1674 The use of Privilege levels to determine session-based access to 1675 commands and resources is not mandatory for clients. Although the 1676 privilege level scheme is widely supported, its lack of flexibility 1677 in requiring a single monotonic hierarchy of permissions means that 1678 other session-based command authorization schemes have evolved, and 1679 so it is no longer mandatory for clients to use it. However, it is 1680 still common enough that it SHOULD be supported by servers. 1682 9. TACACS+ Security Considerations 1684 The original TACACS+ Draft[1] from 1998 did not address all of the 1685 key security concerns which are considered when designing modern 1686 standards. This section addresses known limitations and concerns 1687 which will impact overall security of the protocol and systems where 1688 this protocol is deployed to manage central authentication, 1689 authorization or accounting for network device administration. 1691 Multiple implementations of the protocol described in the draft[1] 1692 have been deployed. As the protocol was never standardized, current 1693 implementations may be incompatible in non-obvious ways, giving rise 1694 to additional security risks. This section does not claim to 1695 enumerate all possible security vulnerabilities. 1697 9.1. General Security of The Protocol 1699 TACACS+ protocol does not include a security mechanism that would 1700 meet modern-day requirements. Support for MD5-based crypto pad 1701 encryption fails to provide any kind of transport integrity, which 1702 presents at least the following risks: 1704 Accounting information may be modified by the man-in-the-middle 1705 attacker, making such logs unsuitable and untrustable for auditing 1706 purposes. 1708 Only the body of the request is encrypted which leaves all header 1709 fields open to trivial modification by the man-in-the-middle 1710 attacker. For this reason, connections with 1711 TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the 1712 recommendations section. 1714 Invalid or misleading values may be inserted by the man-in-the- 1715 middle attacker in various fields at known offsets to try and 1716 circumvent the authentication or authorization checks even inside 1717 the encrypted body. 1719 While the protocol provides some measure of transport privacy, it is 1720 vulnerable to at least the following attacks: 1722 Brute force attacks exploiting increased efficiency of MD5 digest 1723 computation. 1725 Known plaintext attacks which may decrease the cost of brute force 1726 attack. 1728 Chosen plaintext attacks which may decrease the cost of a brute 1729 force attack. 1731 No forward secrecy. 1733 Even though, to the best knowledge of authors, this method of 1734 encryption wasn't rigorously tested, enough information is available 1735 that it is best referred to as "obfuscation" and not "encryption". 1737 For these reasons, users deploying TACACS+ protocol in their 1738 environments MUST limit access to known clients and MUST control the 1739 security of the entire transmission path. Attacks who can guess the 1740 key or otherwise break the obfuscation will gain unrestricted and 1741 undetected access to all TACACS+ traffic. Ensuring that a 1742 centralized AAA system like TACACS+ is deployed on a secured 1743 transport is essential to managing security risk of such an attack. 1745 The following parts of this section enumerate only the session- 1746 specific risks which are in addition to general risk associated with 1747 bare obfuscation and lack of integrity checking. 1749 9.2. Security of Authentication Sessions 1751 Authentication sessions SHOULD NOT be used via insecure transport as 1752 the man-in-the-middle attack may completely subvert them. Even CHAP, 1753 which may be considered resistant to password interception, is unsafe 1754 as it does not protect the username from a trivial man-in-the-middle 1755 attack. 1757 This document deprecates the redirection mechanism using the 1758 TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the 1759 original draft. As part of this process, the secret key for a new 1760 server was sent to the client. This public exchange of secret keys 1761 means that once one session is broken, it may be possible to leverage 1762 that key to attacking connections to other servers. This mechanism 1763 SHOULD NOT be used in modern deployments. It MUST NOT be used 1764 outside a secured deployment. 1766 9.3. Security of Authorization Sessions 1768 Authorization sessions MUST be used via secure transport only as it's 1769 trivial to execute a successful man-in-the-middle attacks that 1770 changes well-known plaintext in either requests or responses. 1772 As an example, take the field "authen_method". It's not unusual in 1773 actual deployments to authorize all commands received via the device 1774 local serial port (a console port) as that one is usually considered 1775 secure by virtue of the device located in a physically secure 1776 location. If an administrator would configure the authorization 1777 system to allow all commands entered by the user on a local console 1778 to aid in troubleshooting, that would give all access to all commands 1779 to any attacker that would be able to change the "authen_method" from 1780 TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In 1781 this regard, the obfuscation provided by the protocol itself wouldn't 1782 help much, because: 1784 Lack of integrity means that any byte in the payload may be 1785 changed without either side detecting the change. 1787 Known plaintext means that an attacker would know with certainty 1788 which octet is the target of the attack (in this case, 1st octet 1789 after the header). 1791 In combination with known plaintext, the attacker can determine 1792 with certainty the value of the crypto-pad octet used to obfuscate 1793 the original octet. 1795 9.4. Security of Accounting Sessions 1797 Accounting sessions are not directly involved in authentication or 1798 authorizing operations on the device. However, man-in-the-middle 1799 attacker may do any of the following: 1801 Replace accounting data with new valid or garbage which prevents 1802 to provide distraction or hide information related to their 1803 authentication and/or authorization attack attempts. 1805 Try and poison accounting log with entries designed to make 1806 systems behave in unintended ways (which includes TACACS+ server 1807 and any other systems that would manage accounting entries). 1809 In addition to these direct manipulations, different client 1810 implementations pass different fidelity of accounting data. Some 1811 vendors have been observed in the wild that pass sensitive data like 1812 passwords, encryption keys and similar as part of the accounting log. 1813 Due to lack of strong encryption with perfect forward secrecy, this 1814 data may be revealed in future, leading to a security incident. 1816 9.5. TACACS+ Client Implementation Recommendations 1818 The following recommendations are made when implementing a TACACS+ 1819 client: 1821 Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks 1822 that are considered secure. 1824 Treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as 1825 TAC_PLUS_AUTHEN_STATUS_FAIL. 1827 If receiving an unknown mandatory authorization attribute, behave 1828 as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. 1830 9.6. TACACS+ Server Implementation Recommendations 1832 The following recommendations are made when implementing a TACACS+ 1833 server: 1835 The Server SHOULD NOT accept any connections which have the 1836 TAC_PLUS_UNENCRYPTED_FLAG set and SHOULD reject those packets with 1837 applicable ERROR response for type of packet. 1839 The configuration of dedicated secret keys per individual client MUST 1840 be supported by the Server implementation. It is also recommended 1841 that Servers SHOULD warn administrators if secret keys are not unique 1842 per client. 1844 If an invalid shared secret is detected, Servers MUST NOT accept any 1845 new sessions on a connection, and terminate the connection on 1846 completion of any sessions previously established with a valid shared 1847 secret. 1849 The Server implementation must allow the administrator to mandate: 1851 TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type 1853 TAC_PLUS_AUTHEN_METH_TACACSPLUS for authen_method in authorization 1855 Minimum length for shared secrets. 1857 9.7. TACACS+ Deployment Best Practices 1859 Due to above observations about the TACACS+ protocol, it is critical 1860 to only deploy it using secure transport. A secure transport for 1861 TACACS+ is defined as any means that ensure privacy and integrity of 1862 all data passed between clients and servers. There are multiple 1863 means of achieving this, all of them beyond the scope of this 1864 document. 1866 Symmetric encryption key represents a possible attack vector at the 1867 protocol itself. For this reason, servers SHOULD accept only those 1868 network connection attempts that arrive from known clients. This 1869 limits the exposure and prevents remote brute force attacks from 1870 unknown clients. 1872 Due to the security deficiencies of the protocol, it is critical that 1873 it be deployed in a secure manner. The following recommendations are 1874 made for those deploying and configuring TACACS+ as a solution for 1875 device administration: 1877 Secure the Deployment: TACACS+ MUST BE deployed over networks 1878 which ensure an appropriate privacy and integrity of the 1879 communication. The way this is ensured will depend upon the 1880 organizational means: a dedicated and secure management network 1881 where available in enterprise deployments, or IPsec where 1882 dedicated networks are not available. 1884 Do not use the TAC_PLUS_UNENCRYPTED_FLAG option. 1886 Always configure a secret key (recommended minimum 16 characters) 1887 on the server for each client. 1889 Consider shared secrets to be sensitive data, and manage securely 1890 on server and client. 1892 Change secret keys at regular intervals. 1894 Do not use TAC_PLUS_AUTHEN_SENDAUTH or TAC_PLUS_AUTHEN_SENDPASS 1895 options. 1897 Use TAC_PLUS_AUTHEN_TYPE_CHAP or MS_CHAP options for authen_type 1898 where possible. Use other options only when unavoidable due to 1899 requirements of identity/password systems. 1901 Require TACACS+ authentication for authorization requests (i.e. 1902 TAC_PLUS_AUTHEN_METH_TACACSPLUS is used). 1904 Do not use the redirection mechanism 1905 (TAC_PLUS_AUTHEN_STATUS_FOLLOW). Specifically avoid the option to 1906 send secret keys in the server list. 1908 Take case when applying extensions to the dictionary of 1909 authorization/accounting arguments. Ensure that the client and 1910 server use of new argument names are consistent. 1912 In summary: It is strongly advised that TACACS+ MUST be used within a 1913 secure deployment. Failure to do so may impact overall network 1914 security. 1916 10. Acknowledgements 1918 The authors would like to thank the following reviewers whose 1919 comments and contributions made considerable improvements to the 1920 document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch, 1921 Robert Drake, among many others. 1923 The authors would particularly like to thank Alan DeKok, who provided 1924 significant insights and recommendations on all aspects of the 1925 document and the protocol. Alan DeKok has dedicated considerable 1926 effort to identify weaknesses and provide remedies to help improve 1927 the document. 1929 The authors would also like to thanks the support from the OPSAWG 1930 Chairs and advisors. 1932 11. References 1934 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1935 April 1992. 1937 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1938 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1939 . 1941 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1942 "Randomness Recommendations for Security", RFC 1750, 1943 DOI 10.17487/RFC1750, December 1994, 1944 . 1946 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1947 RFC 2433, DOI 10.17487/RFC2433, October 1998, 1948 . 1950 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1951 RFC 2759, DOI 10.17487/RFC2759, January 2000, 1952 . 1954 [TheDraft] 1955 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 1956 1.78", June 1997, 1957 . 1959 Authors' Addresses 1961 Thorsten Dahm 1962 Google Inc 1963 1600 Amphitheatre Parkway 1964 Mountain View, CA 94043 1965 US 1967 EMail: thorstendlux@google.com 1969 Andrej Ota 1970 Google Inc 1971 1600 Amphitheatre Parkway 1972 Mountain View, CA 94043 1973 US 1975 EMail: aota@google.com 1977 Douglas C. Medway Gash 1978 Cisco Systems, Inc. 1979 170 West Tasman Dr. 1980 San Jose, CA 95134 1981 US 1983 Phone: +44 0208 8244508 1984 EMail: dcmgash@cisco.com 1985 David Carrel 1986 vIPtela, Inc. 1987 1732 North First St. 1988 San Jose, CA 95112 1989 US 1991 EMail: dcarrel@viptela.com 1993 Lol Grant 1995 EMail: lol.grant@gmail.com