idnits 2.17.1 draft-ietf-opsawg-tacacs-07.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 207: '...e TCP connection. The client MUST NOT...' RFC 2119 keyword, line 234: '... client MUST accommodate such closur...' RFC 2119 keyword, line 253: '... and it MUST behave as if the server...' RFC 2119 keyword, line 269: '...enabled, then the connection SHOULD be...' RFC 2119 keyword, line 275: '...ther new sessions MUST NOT be accepted...' (92 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 (August 21, 2017) is 2440 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations T. Dahm 3 Internet-Draft A. Ota 4 Intended status: Informational Google Inc 5 Expires: February 22, 2018 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 August 21, 2017 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-07 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 http://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 February 22, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 5 74 3.4. Session Completion . . . . . . . . . . . . . . . . . . . 5 75 3.5. Treatment of Enumerated Protocol Values . . . . . . . . . 6 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 . . . . . . . . . . 11 82 4.2. The Authentication REPLY Packet Body . . . . . . . . . . 14 83 4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 15 84 4.4. Description of Authentication Process . . . . . . . . . . 16 85 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 86 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 17 87 4.4.3. Aborting an Authentication Session . . . . . . . . . 21 88 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 89 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23 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. Authorization Attributes . . . . . . . . . . . . . . . . 31 96 7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 98 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 99 9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 100 9.1. Overall 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 . . . . . . . . . . . . . 38 104 9.5. TACACS+ Deployment Recommendations . . . . . . . . . . . 39 105 9.6. TACACS+ Client Implementation Recommendations . . . . . . 39 106 9.7. TACACS+ Server Implementation Recommendations . . . . . . 40 107 9.8. TACACS+ Security and Operational Concerns . . . . . . . . 40 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 111 1. Introduction 113 Terminal Access Controller Access-Control System Plus (TACACS+) was 114 originally conceived 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 have been removed, however the required 133 enumerations are kept. 135 The TACACS+ protocol separates the functions of Authentication, 136 Authorization and Accounting. It allows for arbitrary length and 137 content authentication exchanges, which will support any 138 authentication mechanism to be utilized with TACACS+ clients. It is 139 extensible to provide for site customization and future development 140 features, and it uses TCP to ensure reliable delivery. The protocol 141 allows the TACACS+ client to request very fine-grained access control 142 and allows the server to respond to each component of that request. 144 The separation of authentication, authorization and accounting is a 145 fundamental component of the design of TACACS+. The distinction 146 between them is very important so this document will address each one 147 separately. It is important to note that TACACS+ provides for all 148 three, but an implementation or configuration is not required to 149 employ all three. Each one serves a unique purpose that alone is 150 useful, and together can be quite powerful. 152 This document restricts itself to a description of the protocol that 153 is used by TACACS+. It does not cover deployment or best practices. 155 2. Technical Definitions 157 This section provides a few basic definitions that are applicable to 158 this document 160 Client 162 The client is any device, (often a Network Access Server) that 163 provides access services. The clients usually provide a character 164 mode front end and then allow the user to telnet or rlogin to another 165 host. A client may also support protocol based access services. 167 Server 169 The server receives TACACS+ protocol requests, and replies according 170 to its business model, in accordance with the flows defined in this 171 document. 173 Packet 175 All uses of the word packet in this document refer to TACACS+ 176 protocol packets unless explicitly noted otherwise. 178 3. TACACS+ Connections and Sessions 180 3.1. Connection 182 TACACS+ uses TCP for its transport. Server port 49 is allocated for 183 TACACS+ traffic. 185 3.2. Session 187 The concept of a session is used throughout this document. A TACACS+ 188 session is a single authentication sequence, a single authorization 189 exchange, or a single accounting exchange. 191 An accounting and authorization session will consist of a single pair 192 of packets (the request and its reply). An authentication session 193 may involve an arbitrary number of packets being exchanged. The 194 session is an operational concept that is maintained between the 195 TACACS+ client and server. It does not necessarily correspond to a 196 given user or user action. 198 3.3. Single Connect Mode 200 Single Connection Mode is intended to improve performance by allowing 201 a client to multiplex multiple session on a single TCP connection. 203 The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by 204 the client and server to negotiate the use of Single Connect Mode. 206 The client sets this flag, to indicate that it supports multiplexing 207 TACACS+ sessions over a single TCP connection. The client MUST NOT 208 send a second packet on a connection until single-connect status has 209 been established. 211 To indicate it will support Single Connect Mode, the server sets this 212 flag in the first reply packet in response to the first request from 213 a client. The server may set this flag even if the client does not 214 set it, but the client may ignore the flag and close the connection 215 after the session completes. 217 The flag is only relevant for the first two packets on a connection, 218 to allow the client and server to establish Single Connect Mode. 219 This protocol does not define a procedure for changing Single Connect 220 Mode after the first two packets. 222 If single Connect Mode has not been established in the first two 223 packets of a TCP connection, then both the client and the server 224 close the connection at the end of the first session. 226 The client negotiates single Connection Mode to improve efficiency. 227 The server may refuse to allow Single connection Mode for the client. 228 For example it may not fit the specific deployment to allocate a long 229 lasting TCP connection to a specific client. Even if the server is 230 configured to permit single Connection Mode for a specific client, 231 the server may close the connection. For example: a server may be 232 configured to time out a Single Connection Mode TCP Connection after 233 a specific period of inactivity to preserve its resources. The 234 client MUST accommodate such closures on a TCP session even after 235 Single Conenction Mode has been established. 237 3.4. Session Completion 239 The REPLY packets defined for the packets types in the sections below 240 (Authentication, Authorization and Accounting) contain a status 241 field. The complete set of options for this field depend upon the 242 packet type, but all three REPLY packet types define values 243 representing PASS, ERROR and FAIL, which indicate the last packet of 244 a regular session (one which is not aborted). 246 The server responds with a PASS or a FAIL to indicate that the 247 processing of the request completed and the client can apply the 248 result (PASS or FAIL) to control the execution of the action which 249 prompted the request to be sent to the server. 251 The server responds with an ERROR to indicate that the processing of 252 the request did not complete. The client can not apply the result 253 and it MUST behave as if the server could not be connected to. For 254 example, the client try alternative methods, if they are available, 255 such as sending the request to a backup server, or using local 256 configuration to determine whether the action which prompted the 257 request should be executed. 259 Refer to the section (Section 4.4.3) on Aborting Authentication 260 Sessions for details on handling additional status options . 262 When the session is complete, then the TCP connection should be 263 handled as follows, according to whether Single Connect Mode was 264 negotiated: 266 If Single Connection Mode was not negotiated, then the connection 267 should be closed 269 If Single Connection Mode was enabled, then the connection SHOULD be 270 left open (see section (Section 3.3) ), but may still be closed after 271 a timeout period to preserve deployment resources 273 If Single Connection Mode was enabled, but an ERROR occurred due to 274 connection issues (such as an incorrect secret, see section 275 (Section 3.7) ), then any further new sessions MUST NOT be accepted 276 on the connection. If there are any sessions that have already been 277 established then they MAY be completed. Once all active sessions are 278 completed then the connection MUST be closed. 280 3.5. Treatment of Enumerated Protocol Values 282 This document describes various enumerated values in the packet 283 header and the headers for specific packet types. for example in the 284 Authentication start packet type, this document defines the action 285 field with three values TAC_PLUS_AUTHEN_LOGIN, TAC_PLUS_AUTHEN_CHPASS 286 and TAC_PLUS_AUTHEN_SENDAUTH. 288 If the server does not implement one of the defined options in a 289 packet that it receives, or it encounters an option that is not 290 listed in this document for a header field, then it should respond 291 with a ERROR and terminate the session. This will allow the client 292 to try a different option. 294 If an error occurs but the type of the incoming packet cannot be 295 determined, a packet with the identical cleartext header but with a 296 sequence number incremented by one and the length set to zero MUST be 297 returned to indicate an error. 299 3.6. Text Encoding 301 All text fields in TACACS+ MUST be US-ASCII, excepting special 302 consideration given to user field and data fields used for passwords. 304 To ensure interoperability of current deployments, the TACACS+ client 305 and server MUST handle user fields and those data fields used for 306 passwords as 8 bit octet strings. The deployment operator MUST 307 ensure that consistent character encoding is applied. The encoding 308 SHOULD be UTF-8, and other encodings outside US-ASCII SHOULD be 309 deprecated. 311 3.7. Data Obfuscation 313 The body of packets may be obfuscated. The following sections 314 describe the obfuscation mechanism that is supported in the protocol. 315 In 'The Draft' this process was actually referred to as Encryption, 316 but by modern day standards the mechanims would not meet the 317 requirements of an encryption mechanism. 319 The obfuscation mechanism relies on a secret key, it is referring to 320 a shared secret value that is known to both the client and the 321 server. This document does not discuss the management and storage of 322 those keys. It is an implementation detail of the server and client, 323 as to whether they will maintain only one key, or a different key for 324 each client or server with which they communicate. For security 325 reasons, the latter options MUST be available, but it is a site 326 dependent decision as to whether the use of separate keys is 327 appropriate. 329 The flag field may be set as follows: 331 TAC_PLUS_UNENCRYPTED_FLAG == 0x0 333 In this case, the packet body is obfuscated by XOR-ing it byte-wise 334 with a pseudo random pad. 336 ENCRYPTED {data} == data ^ pseudo_pad 337 The pad is generated by concatenating a series of MD5 hashes (each 16 338 bytes long) and truncating it to the length of the input data. 340 Whenever used in this document, MD5 refers to the "RSA Data Security, 341 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 342 . 344 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 346 The first MD5 hash is generated by concatenating the session_id, the 347 secret key, the version number and the sequence number and then 348 running MD5 over that stream. All of those input values are 349 available in the packet header, except for the secret key which is a 350 shared secret between the TACACS+ client and server. 352 The version number is the one byte concatenation of the major and 353 minor version numbers. 355 The session id is used in network byte order. 357 Subsequent hashes are generated by using the same input stream, but 358 concatenating the previous hash value at the end of the input stream. 360 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 361 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 362 version, seq_no, MD5_n-1} 364 When a server detects that the secret(s) it has configured for the 365 device mismatch, it MUST return ERROR. The handling of the TCP 366 connection by the server is implementation independent. 368 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 370 In this case, the entire packet body is in cleartext. Obfuscation 371 and de-obfuscation are null operations. This method should be 372 avoided unless absolutely required for debug purposes, when tooling 373 does not permit de-obfuscation. 375 If deployment is configured for obfuscating a connection then do no 376 skip de-obfuscation simply because an incoming packet indicates that 377 it is not obfuscated. If the flag is not set when expected, then it 378 must be dropped. 380 After a packet body is de-obfuscated, the lengths of the component 381 values in the packet are summed. If the sum is not identical to the 382 cleartext datalength value from the header, the packet MUST be 383 discarded, and an error signalled. The underlying TCP connection MAY 384 also be closed, if it is not being used for other sessions in single- 385 connect mode. 387 Commonly such failures are seen when the keys are mismatched between 388 the client and the TACACS+ server. 390 If an error must be declared but the type of the incoming packet 391 cannot be determined, a packet with the identical cleartext header 392 but with a sequence number incremented by one and the length set to 393 zero MUST be returned to indicate an error. 395 3.8. The TACACS+ Packet Header 397 All TACACS+ packets begin with the following 12 byte header. The 398 header describes the remainder of the packet: 400 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 401 +----------------+----------------+----------------+----------------+ 402 |major | minor | | | | 403 |version| version| type | seq_no | flags | 404 +----------------+----------------+----------------+----------------+ 405 | | 406 | session_id | 407 +----------------+----------------+----------------+----------------+ 408 | | 409 | length | 410 +----------------+----------------+----------------+----------------+ 412 major_version 414 This is the major TACACS+ version number. 416 TAC_PLUS_MAJOR_VER := 0xc 418 minor_version 420 The minor TACACS+ version number. 422 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 424 TAC_PLUS_MINOR_VER_ONE := 0x1 426 type 428 This is the packet type. Legal values are: 430 TAC_PLUS_AUTHEN := 0x01 (Authentication) 431 TAC_PLUS_AUTHOR := 0x02 (Authorization) 433 TAC_PLUS_ACCT := 0x03 (Accounting) 435 seq_no 437 This is the sequence number of the current packet. The first packet 438 in a session MUST have the sequence number 1 and each subsequent 439 packet will increment the sequence number by one. Thus clients only 440 send packets containing odd sequence numbers, and TACACS+ servers 441 only send packets containing even sequence numbers. 443 The sequence number must never wrap i.e. if the sequence number 2^8-1 444 is ever reached, that session must terminate and be restarted with a 445 sequence number of 1. 447 flags 449 This field contains various bitmapped flags. 451 The flag bit: 453 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 455 This flag indicates that the sender did not obfuscate the bode of the 456 packet. The application of this flag will be covered in the security 457 section (Section 9) . section. 459 This flag SHOULD be clear in all deployments. Modern network traffic 460 tools easily support encryted traffic when configured with the shared 461 secret (see section below), so even in test scenarios, the obfuscated 462 mode SHOULD be used. 464 The single-connection flag: 466 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 468 This flag is used to allow a client and server to negotiate Single 469 Connection Mode. 471 session_id 473 The Id for this TACACS+ session. This field does not change for the 474 duration of the TACACS+ session. This number MUST be generated by a 475 cryptographically strong random number generation method. Failure to 476 do so will compromise security of the session. For more details 477 refer to RFC 1750 [RFC1750] 478 length 480 The total length of the packet body (not including the header). 482 3.9. The TACACS+ Packet Body 484 The TACACS+ body types are defined in the packet header. The next 485 sections of this document will address the contents of the different 486 TACACS+ bodies. The following general rules apply to all TACACS+ 487 body types: 489 - To signal that any variable length data fields are unused, their 490 length value is set to zero. 492 - the lengths of data and message fields in a packet are specified 493 by their corresponding length fields, (and are not null 494 terminated.) 496 - All length values are unsigned and in network byte order. 498 4. Authentication 500 Authentication is the action of determining who a user (or entity) 501 is. Authentication can take many forms. Traditional authentication 502 utilizes a name and a fixed password. However, fixed passwords have 503 limitations, mainly in the area of security. Many modern 504 authentication mechanisms utilize "one-time" passwords or a 505 challenge-response query. TACACS+ is designed to support all of 506 these, and be powerful enough to handle any future mechanisms. 507 Authentication generally takes place when the user first logs in to a 508 machine or requests a service of it. 510 Authentication is not mandatory; it is a site-configured option. 511 Some sites do not require it. Others require it only for certain 512 services (see authorization below). Authentication may also take 513 place when a user attempts to gain extra privileges, and must 514 identify himself or herself as someone who possesses the required 515 information (passwords, etc.) for those privileges. 517 4.1. The Authentication START Packet Body 518 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 519 +----------------+----------------+----------------+----------------+ 520 | action | priv_lvl | authen_type | authen_service | 521 +----------------+----------------+----------------+----------------+ 522 | user_len | port_len | rem_addr_len | data_len | 523 +----------------+----------------+----------------+----------------+ 524 | user ... 525 +----------------+----------------+----------------+----------------+ 526 | port ... 527 +----------------+----------------+----------------+----------------+ 528 | rem_addr ... 529 +----------------+----------------+----------------+----------------+ 530 | data... 531 +----------------+----------------+----------------+----------------+ 533 Packet fields are as follows: 535 action 537 This indicates the authentication action. Legal values are listed 538 below. 540 TAC_PLUS_AUTHEN_LOGIN := 0x01 542 TAC_PLUS_AUTHEN_CHPASS := 0x02 544 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 546 priv_lvl 548 This indicates the privilege level that the user is authenticating 549 as. Please refer to the Privilege Level section (Section 8) below. 551 authen_type 553 The type of authentication. Legal values are: 555 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 557 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 559 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 561 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 563 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 565 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 567 authen_service 569 This is the service that is requesting the authentication. Legal 570 values are: 572 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 574 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 576 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 578 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 580 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 582 TAC_PLUS_AUTHEN_SVC_PT := 0x05 584 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 586 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 588 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 590 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 592 The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization 593 application of this field that indicates that no authentication was 594 performed by the device. 596 The TAC_PLUS_AUTHEN_SVC_LOGIN option is identifies regular login (as 597 opposed to ENABLE) to a client device. 599 The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE 600 authen_service, which refers to a service requesting authentication 601 in order to grant the user different privileges. This is comparable 602 to the Unix "su(1)" command. An authen_service value of NONE is only 603 to be used when none of the other authen_service values are 604 appropriate. ENABLE may be requested independently, no requirements 605 for previous authentications or authorizations are imposed by the 606 protocol. 608 Other options are included for legacy/backwards compatibility. 610 user, user_len 612 The username is optional in this packet, depending upon the class of 613 authentication. If it is absent, the client MUST set user_len to 0. 615 If included, the user_len indicates the length of the user field, in 616 bytes. 618 port, port_len 620 The US-ASCII name of the client port on which the authentication is 621 taking place, and its length in bytes. The value of this field is 622 client specific. (For example, Cisco uses "tty10" to denote the 623 tenth tty line and "Async10" to denote the tenth async interface). 624 The port_len indicates the length of the port field, in bytes. 626 rem_addr, rem_addr_len 628 An US-ASCII string indicating the remote location from which the user 629 has connected to the client. It is intended to hold a network 630 address if the user is connected via a network, a caller ID is the 631 user is connected via ISDN or a POTS, or any other remote location 632 information that is available. This field is optional (since the 633 information may not be available). The rem_addr_len indicates the 634 length of the user field, in bytes. 636 data, data_len 638 This field is used to send data appropriate for the action and 639 authen_type. It is described in more detail in the section Common 640 Authentication flows (Section 4.4.2) . The data_len indicates the 641 length of the data field, in bytes. 643 4.2. The Authentication REPLY Packet Body 645 The TACACS+ server sends only one type of authentication packet (a 646 REPLY packet) to the client. 648 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 649 +----------------+----------------+----------------+----------------+ 650 | status | flags | server_msg_len | 651 +----------------+----------------+----------------+----------------+ 652 | data_len | server_msg ... 653 +----------------+----------------+----------------+----------------+ 654 | data ... 655 +----------------+----------------+ 657 status 659 The current status of the authentication. Legal values are: 661 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 662 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 664 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 666 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 668 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 670 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 672 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 674 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 676 flags 678 Bitmapped flags that modify the action to be taken. The following 679 values are defined: 681 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 683 server_msg, server_msg_len 685 A message to be displayed to the user. This field is optional. If 686 it exists, it is intended to be presented to the user. US-ASCII 687 charset MUST be used. The server_msg_len indicates the length of the 688 server_msg field, in bytes. 690 data, data_len 692 This field holds data that is a part of the authentication exchange 693 and is intended for the client, not the user. Examples of its use 694 are shown in the section Common Authentication flows (Section 4.4.2) 695 . The data_len indicates the length of the data field, in bytes. 697 4.3. The Authentication CONTINUE Packet Body 699 This packet is sent from the client to the server following the 700 receipt of a REPLY packet. 702 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 703 +----------------+----------------+----------------+----------------+ 704 | user_msg len | data_len | 705 +----------------+----------------+----------------+----------------+ 706 | flags | user_msg ... 707 +----------------+----------------+----------------+----------------+ 708 | data ... 709 +----------------+ 710 user_msg, user_msg_len 712 This field is the string that the user entered, or the client 713 provided on behalf of the user, in response to the server_msg from a 714 REPLY packet. The user_len indicates the length of the user field, 715 in bytes. 717 data, data_len 719 This field carries information that is specific to the action and the 720 authen_type for this session. Valid uses of this field are described 721 below. The data_len indicates the length of the data field, in 722 bytes. 724 flags 726 This holds the bitmapped flags that modify the action to be taken. 727 The following values are defined: 729 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 731 4.4. Description of Authentication Process 733 The action, authen_type and authen_service fields (described above) 734 combine to indicate what kind of authentication is to be performed. 735 Every authentication START, REPLY and CONTINUE packet includes a data 736 field. The use of this field is dependent upon the kind of the 737 Authentication. 739 This document defines a standard set of the kinds of authentication 740 supported by TACACS+. Each authentication flow consists of a START 741 packet. The server responds either with a request for more 742 information (GETDATA, GETUSER or GETPASS) or a termination PASS, 743 FAIL, ERROR, RESTART or FOLLOW. The actions and meanings when the 744 server sends a RESTART, ERROR or FOLLOW are common and are described 745 further below. 747 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 748 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 749 then authentication continues and the server SHOULD provide 750 server_msg content for the client to prompt the user for more 751 information. The client MUST then return a CONTINUE packet 752 containing the requested information in the user_msg field. 754 The client should interpret TAC_PLUS_AUTHEN_STATUS_GETUSER as a 755 request for username and TAC_PLUS_AUTHEN_STATUS_GETPASS as a request 756 for password. The TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic 757 request for more information to flexibly support future requirements. 759 If the information being requested by the server form the client is 760 sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO 761 flag. When the client queries the user for the information, the 762 response MUST NOT be echoed as it is entered. 764 The data field is only used in the REPLY where explicitly defined 765 below. 767 4.4.1. Version Behaviour 769 The TACACS+ protocol is versioned to allow revisions while 770 maintaining backwards compatibility. The version number is in every 771 packet header. The changes between minor_version 0 and 1 apply only 772 to the authentication process, and all deal with the way that CHAP 773 and PAP authentications are handled. minor_version 1 may only be used 774 for authentication kinds that explicitly call for it in the table 775 below: 777 LOGIN CHPASS SENDAUTH 778 ASCII v0 v0 - 779 PAP v1 - v1 780 CHAP v1 - v1 781 MS-CHAPv1/2 v1 - v1 783 The '-' symbol represents that the option is not valid. 785 All authorisation and accounting and ASCII authentication use 786 minor_version number of 0. 788 PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange 789 is a single START packet from the client and a single REPLY from the 790 server. 792 SENDAUTH is only used for PPP when performing outbound 793 authentication. 795 The removal of SENDPASS was prompted by security concerns, and is no 796 longer considered part of the TACACS+ protocol. 798 4.4.2. Common Authentication Flows 800 This section describes common authentication flows. If the server 801 does not implement an option, it MUST respond with 802 TAC_PLUS_AUTHEN_STATUS_FAIL. 804 Inbound ASCII Login 805 action = TAC_PLUS_AUTHEN_LOGIN 806 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 807 minor_version = 0x0 809 This is a standard ASCII authentication. The START packet MAY 810 contain the username. If the user does not include the username then 811 the server MUST obtain it from the client with a CONTINUE 812 TAC_PLUS_AUTHEN_STATUS_GETUSER. When the server has the username, it 813 will obtain the password using a continue with 814 TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII login uses the user_msg field 815 for both the username and password. The data fields in both the 816 START and CONTINUE packets are not used for ASCII logins, any content 817 MUST be ignored. The session is composed of a single START followed 818 by zero or more pairs of REPLYs and CONTINUEs, followed by a final 819 REPLY indicating PASS, FAIL or ERROR. 821 Inbound PAP Login 823 action = TAC_PLUS_AUTHEN_LOGIN 824 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 825 minor_version = 0x1 827 The entire exchange MUST consist of a single START packet and a 828 single REPLY. The START packet MUST contain a username and the data 829 field MUST contain the PAP ASCII password. A PAP authentication only 830 consists of a username and password RFC 1334 [RFC1334] . The REPLY 831 from the server MUST be either a PASS, FAIL or ERROR. 833 Inbound CHAP login 835 action = TAC_PLUS_AUTHEN_LOGIN 836 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 837 minor_version = 0x1 839 The entire exchange MUST consist of a single START packet and a 840 single REPLY. The START packet MUST contain the username in the user 841 field and the data field is a concatenation of the PPP id, the 842 challenge and the response. 844 The length of the challenge value can be determined from the length 845 of the data field minus the length of the id (always 1 octet) and the 846 length of the response field (always 16 octets). 848 To perform the authentication, the server calculates the PAP hash as 849 defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then 850 compare that value with the response. The REPLY from the server MUST 851 be a PASS, FAIL or ERROR. 853 The client condcuts the exchange with the endstation and then sends 854 the resulting materials (challenge and responsee) to the server. So 855 although the selection of the challenge and its length are not an 856 aspect of the TACACS+ protocol, it is strongly recommended that the 857 client/endstation interaction is configured with a secure challenge 858 in mind, and the TACACS+ server can help by rejecting authentications 859 where the challenge is below a minimum length (for example, 8 bytes). 861 Inbound MS-CHAP v1 login 863 action = TAC_PLUS_AUTHEN_LOGIN 864 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 865 minor_version = 0x1 867 The entire exchange MUST consist of a single START packet and a 868 single REPLY. The START packet MUST contain the username in the user 869 field and the data field will be a concatenation of the PPP id, the 870 MS-CHAP challenge and the MS-CHAP response. 872 The length of the challenge value can be determined from the length 873 of the data field minus the length of the id (always 1 octet) and the 874 length of the response field (always 49 octets). 876 To perform the authentication, the server will use a combination of 877 MD4 and DES on the user's secret and the challenge, as defined in RFC 878 2433 [RFC2433] and then compare the resulting value with the 879 response. The REPLY from the server MUST be a PASS or FAIL. 881 For best practices, please refer to RFC 2433 [RFC2433] 883 Inbound MS-CHAP v2 login 885 action = TAC_PLUS_AUTHEN_LOGIN 886 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 887 minor_version = 0x1 889 The entire exchange MUST consist of a single START packet and a 890 single REPLY. The START packet MUST contain the username in the user 891 field and the data field will be a concatenation of the PPP id, the 892 MS-CHAP challenge and the MS-CHAP response. 894 The length of the challenge value can be determined from the length 895 of the data field minus the length of the id (always 1 octet) and the 896 length of the response field (always 49 octets). 898 To perform the authentication, the server will use the algorithm 899 specified RFC 2759 [RFC2759] on the user's secret and challenge and 900 then compare the resulting value with the response. The REPLY from 901 the server MUST be a PASS or FAIL. 903 For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] 905 Enable Requests 907 action = TAC_PLUS_AUTHEN_LOGIN 908 priv_lvl = implementation dependent 909 authen_type = not used 910 service = TAC_PLUS_AUTHEN_SVC_ENABLE 912 This is an ENABLE request, used to change the current running 913 privilege level of a user. The exchange MAY consist of multiple 914 messages while the server collects the information it requires in 915 order to allow changing the principal's privilege level. This 916 exchange is very similar to an Inbound ASCII login. 918 In order to readily distinguish enable requests from other types of 919 request, the value of the authen_service field MUST be set to 920 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 921 set to this value when requesting any other operation. 923 ASCII change password request 925 action = TAC_PLUS_AUTHEN_CHPASS 926 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 928 This exchange consists of multiple messages while the server collects 929 the information it requires in order to change the user's password. 930 It is very similar to an ASCII login. The status value 931 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 932 "new" password. It MAY be sent multiple times. When requesting the 933 "old" password, the status value MUST be set to 934 TAC_PLUS_AUTHEN_STATUS_GETDATA. 936 4.4.3. Aborting an Authentication Session 938 The client may prematurely terminate a session by setting the 939 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 940 flag is set, the data portion of the message may contain an ASCII 941 message explaining the reason for the abort. This information will 942 be handled by the server according to the requirements of the 943 deployment. The session is terminated, for more details about 944 session temrination, oplease refer to section (Section 3.4) 946 In the case of PALL, FAIL or ERROR, the server can insert a message 947 into server_msg to be displayed to the user. 949 The Draft `The Draft' [TheDraft] defined a mechanism to direct 950 authentication requests to an alternative server. This mechanism is 951 regarded as legacy and its implementation is optional. 953 If this feature is not implemented, then the client should treat 954 TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL 956 When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet 957 indicates that the TACACS+ server requests that authentication is 958 performed with an alternate server. The data field MUST contain 959 ASCII text describing one or more servers. A server description 960 appears like this: 962 [@@]>[@] 964 If more than one host is specified, they MUST be separated into rows 965 by an ASCII Carriage Return (0x0D). 967 The protocol and key are optional, and apply only to host in the same 968 row. The protocol can describe an alternate way of performing the 969 authentication, other than TACACS+. If the protocol is not present, 970 then TACACS+ is assumed. 972 Protocols are ASCII numbers corresponding to the methods listed in 973 the authen_method field of authorization packets (defined below). 974 The host is specified as either a fully qualified domain name, or an 975 ASCII numeric IPV4 address specified as octets separated by dots 976 ('.'), or IPV6 address text representation defined in RFC 4291. 978 If a key is supplied, the client MAY use the key in order to 979 authenticate to that host. The client may use a preconfigured key 980 for the host if it has one. 982 Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the 983 discretion of the TACACS+ client. It may choose to use any one, all 984 or none of these hosts. If it chooses to use none, then it MUST 985 treat the authentication as if the return status was 986 TAC_PLUS_AUTHEN_STATUS_FAIL. 988 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 989 indicating that it is experiencing an unrecoverable error and the 990 authentication will proceed as if that host could not be contacted. 991 The data field may contain a message to be printed on an 992 administrative console or log. 994 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 995 authentication sequence is restarted with a new START packet from the 996 client, with new session Id, and seq_no set to 1. This REPLY packet 997 indicates that the current authen_type value (as specified in the 998 START packet) is not acceptable for this session. The client may try 999 an alternative authen_type. 1001 If a client does not implement TAC_PLUS_AUTHEN_STATUS_RESTART option, 1002 then it MUST process the response as if the status was 1003 TAC_PLUS_AUTHEN_STATUS_FAIL. 1005 5. Authorization 1007 In the TACACS+ Protocol, authorization is the action of determining 1008 what a user is allowed to do. Generally authentication precedes 1009 authorization, though it is not mandatory that a client use the same 1010 service for authentication that it will use for authorization. An 1011 authorization request may indicate that the user is not authenticated 1012 (we don't know who they are). In this case it is up to the server to 1013 determine, according to its configuration, if an unauthenticated user 1014 is allowed the services in question. 1016 Authorization does not merely provide yes or no answers, but it may 1017 also customize the service for the particular user. A common use of 1018 authorization is to provision a shell session when a user first logs 1019 in to a device to administer it. The TACACS+ server might respond to 1020 the request by allowing the service, but placing a time restriction 1021 on the login shell. For a list of common attributes used in 1022 authorization, see the Authorization Attributes section (Section 7.1) 1023 . 1025 In the TACACS+ protocol an authorization is always a single pair of 1026 messages: a REQUEST from the client followed by a REPLY from the 1027 server. 1029 The authorization REQUEST message contains a fixed set of fields that 1030 indicate how the user was authenticated and a variable set of 1031 arguments that describe the services and options for which 1032 authorization is requested. 1034 The REPLY contains a variable set of response arguments (attribute- 1035 value pairs) that can restrict or modify the clients actions. 1037 5.1. The Authorization REQUEST Packet Body 1039 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 1040 +----------------+----------------+----------------+----------------+ 1041 | authen_method | priv_lvl | authen_type | authen_service | 1042 +----------------+----------------+----------------+----------------+ 1043 | user_len | port_len | rem_addr_len | arg_cnt | 1044 +----------------+----------------+----------------+----------------+ 1045 | arg_1_len | arg_2_len | ... | arg_N_len | 1046 +----------------+----------------+----------------+----------------+ 1047 | user ... 1048 +----------------+----------------+----------------+----------------+ 1049 | port ... 1050 +----------------+----------------+----------------+----------------+ 1051 | rem_addr ... 1052 +----------------+----------------+----------------+----------------+ 1053 | arg_1 ... 1054 +----------------+----------------+----------------+----------------+ 1055 | arg_2 ... 1056 +----------------+----------------+----------------+----------------+ 1057 | ... 1058 +----------------+----------------+----------------+----------------+ 1059 | arg_N ... 1060 +----------------+----------------+----------------+----------------+ 1062 authen_method 1064 This indicates the authentication method used by the client to 1065 acquire the user information. 1067 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1069 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1071 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1073 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1075 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1077 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1078 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1080 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1082 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1084 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1086 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1088 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1089 password associated with the terminal line used to gain access. 1090 LOCAL is a client local user database. ENABLE is a command that 1091 authenticates in order to grant new privileges. TACACSPLUS is, of 1092 course, TACACS+. GUEST is an unqualified guest authentication, such 1093 as an ARAP guest login. RADIUS is the Radius authentication 1094 protocol. RCMD refers to authentication provided via the R-command 1095 protocols from Berkeley Unix. 1097 priv_lvl 1099 This field is used in the same way as the priv_lvl field in 1100 authentication request and is described in the Privilege Level 1101 section (Section 8) below. It indicates the users current privilege 1102 level. 1104 authen_type 1106 This field corrsponds to the authen_type field in the authentication 1107 section (Section 4) above. It indicates the type of authentication 1108 that was performed. If this information is not available, then the 1109 client will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. 1110 This value is valid only in authorization and accounting requests. 1112 authen_service 1114 This field matches the authen_service field in the authentication 1115 section (Section 4) above. It indicates the service through which 1116 the user authenticated. 1118 user, user_len 1120 This field contains the user's account name. The user_len MUST 1121 indicate the length of the user field, in bytes. 1123 port, port_len 1124 This field matches the port field in the authentication section 1125 (Section 4) above. The port_len indicates the length of the port 1126 field, in bytes. 1128 rem_addr, rem_addr_len 1130 This field matches the rem_addr field in the authentication section 1131 (Section 4) above. The rem_addr_len indicates the length of the port 1132 field, in bytes. 1134 arg_cnt 1136 The number of authorization arguments to follow 1138 arg_1 ... arg_N, arg_1_len .... arg_N_len 1140 The arguments are the primary elements of the authorization 1141 interaction. In the request packet they describe the specifics of 1142 the authorization that is being requested. Each argument is encoded 1143 in the packet as a single arg filed (arg_1... arg_N) with a 1144 corresponding length fields (which indicates the length of each 1145 argument in bytes). 1147 The authorization arguments in both the REQUEST and the REPLY are 1148 attribute-value pairs. The attribute and the value are in a single 1149 US-ASCII string and are separated by either a "=" (0X3D) or a "*" 1150 (0X2A). The equals sign indicates a mandatory argument. The 1151 asterisk indicates an optional one. 1153 It is not legal for an attribute name to contain either of the 1154 separators. It is legal for attribute values to contain the 1155 separators. 1157 Optional arguments are ones that may be disregarded by either client 1158 or server. Mandatory arguments require that the receiving side can 1159 handle the attribute, that is: its implementation and configuration 1160 includes the details of how to act on it. If the client receives a 1161 mandatory argument that it cannot handle, it MUST consider the 1162 authorization to have failed. It is legal to send an attribute-value 1163 pair with a zero length value. 1165 Attribute-value strings are not NULL terminated, rather their length 1166 value indicates their end. The maximum length of an attribute-value 1167 string is 255 characters. The minimum is two characters (one name 1168 value character and the separator) 1170 Though the attributes allow extensibility, a common core set of 1171 authorization attributes SHOULD be supported by clients and servers, 1172 these are listed in the Authorization Attributes (Section 7.1) 1173 section below. 1175 5.2. The Authorization REPLY Packet Body 1177 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1178 +----------------+----------------+----------------+----------------+ 1179 | status | arg_cnt | server_msg len | 1180 +----------------+----------------+----------------+----------------+ 1181 + data_len | arg_1_len | arg_2_len | 1182 +----------------+----------------+----------------+----------------+ 1183 | ... | arg_N_len | server_msg ... 1184 +----------------+----------------+----------------+----------------+ 1185 | data ... 1186 +----------------+----------------+----------------+----------------+ 1187 | arg_1 ... 1188 +----------------+----------------+----------------+----------------+ 1189 | arg_2 ... 1190 +----------------+----------------+----------------+----------------+ 1191 | ... 1192 +----------------+----------------+----------------+----------------+ 1193 | arg_N ... 1194 +----------------+----------------+----------------+----------------+ 1196 status This field indicates the authorization status 1198 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1200 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1202 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1204 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1206 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1208 server_msg, server_msg_len 1210 This is an US-ASCII string that may be presented to the user. The 1211 server_msg_len indicates the length of the server_msg field, in 1212 bytes. 1214 data, data_len 1216 This is an US-ASCII string that may be presented on an administrative 1217 display, console or log. The decision to present this message is 1218 client specific. The data_len indicates the length of the data 1219 field, in bytes. 1221 arg_cnt 1223 The number of authorization arguments to follow. 1225 arg_1 ... arg_N, arg_1_len .... arg_N_len 1227 The arguments describe the specifics of the authorization that is 1228 being requested. For details of the content of the args, refer to: 1229 Authorization Attributes (Section 7.1) section below. Each argument 1230 is encoded in the packet as a single arg field (arg_1... arg_N) with 1231 a corresponding length fields (which indicates the length of each 1232 argument in bytes). 1234 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested 1235 authorization MUST be denied. 1237 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1238 arguments specified in the request are authorized and the arguments 1239 in the response MUST be applied according to the rules described 1240 above. 1242 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client 1243 MUST use the authorization attribute-value pairs (if any) in the 1244 response, instead of the authorization attribute-value pairs from the 1245 request. 1247 To approve the authorization with no modifications, the server sets 1248 the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. 1250 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1251 on the server. For the differences between ERROR and FAIL, refer to 1252 section Session Completion (Section 3.4) . None of the arg values 1253 have any relevance if an ERROR is set, and must be ignored. 1255 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1256 arg_cnt MUST be 0. In that case, the actions to be taken and the 1257 contents of the data field are identical to the 1258 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1260 6. Accounting 1262 Accounting is typically the third action after authentication and 1263 authorization. But again, neither authentication nor authorization 1264 is required. Accounting is the action of recording what a user is 1265 doing, and/or has done. Accounting in TACACS+ can serve two 1266 purposes: It may be used as an auditing tool for security services. 1267 It may also be used to account for services used, such as in a 1268 billing environment. To this end, TACACS+ supports three types of 1269 accounting records. Start records indicate that a service is about 1270 to begin. Stop records indicate that a service has just terminated, 1271 and Update records are intermediate notices that indicate that a 1272 service is still being performed. TACACS+ accounting records contain 1273 all the information used in the authorization records, and also 1274 contain accounting specific information such as start and stop times 1275 (when appropriate) and resource usage information. A list of 1276 accounting attributes is defined in the accounting section 1277 (Section 6) . 1279 6.1. The Account REQUEST Packet Body 1281 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 1282 +----------------+----------------+----------------+----------------+ 1283 | flags | authen_method | priv_lvl | authen_type | 1284 +----------------+----------------+----------------+----------------+ 1285 | authen_service | user_len | port_len | rem_addr_len | 1286 +----------------+----------------+----------------+----------------+ 1287 | arg_cnt | arg_1_len | arg_2_len | ... | 1288 +----------------+----------------+----------------+----------------+ 1289 | arg_N_len | user ... 1290 +----------------+----------------+----------------+----------------+ 1291 | port ... 1292 +----------------+----------------+----------------+----------------+ 1293 | rem_addr ... 1294 +----------------+----------------+----------------+----------------+ 1295 | arg_1 ... 1296 +----------------+----------------+----------------+----------------+ 1297 | arg_2 ... 1298 +----------------+----------------+----------------+----------------+ 1299 | ... 1300 +----------------+----------------+----------------+----------------+ 1301 | arg_N ... 1302 +----------------+----------------+----------------+----------------+ 1304 flags 1306 This holds bitmapped flags. 1308 TAC_PLUS_ACCT_FLAG_START := 0x02 1310 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1312 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1314 All other fields are defined in the authorization and authentication 1315 sections above and have the same semantics. They provide details for 1316 the conditions on the client, and authentication context, so that 1317 these details may be logged for accounting purposes. 1319 See section 12 Accounting Attribute-value Pairs for the dictionary of 1320 attributes relevant to accounting. 1322 6.2. The Accounting REPLY Packet Body 1324 The purpose of accounting is to record the action that has occurred 1325 on the client. The server MUST reply with success only when the 1326 accounting request has been recorded. If the server did not record 1327 the accounting request then it MUST reply with ERROR. 1329 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 1330 +----------------+----------------+----------------+----------------+ 1331 | server_msg len | data_len | 1332 +----------------+----------------+----------------+----------------+ 1333 | status | server_msg ... 1334 +----------------+----------------+----------------+----------------+ 1335 | data ... 1336 +----------------+ 1338 status 1340 This is the return status. Values are: 1342 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1344 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1346 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1348 server_msg, server_msg_len 1350 This is a US-ASCII string that may be presented to the user. The 1351 server_msg_len indicates the length of the server_msg field, in 1352 bytes. 1354 data, data_len 1356 This is a US-ASCII string that may be presented on an administrative 1357 display, console or log. The decision to present this message is 1358 client specific. The data_len indicates the length of the data 1359 field, in bytes. 1361 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1362 to be taken and the contents of the data field are identical to the 1363 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1365 TACACS+ accounting is intended to record various types of events on 1366 clients, for example: login sessions, command entry, and others as 1367 required by the client implementation. These events are collectively 1368 referred to in `The Draft' [TheDraft] as "tasks". 1370 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1371 accounting message. Start messages will only be sent once when a 1372 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1373 a stop record and that the task has terminated. The 1374 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1375 Update records are sent at the client's discretion if the task has 1376 not finished. 1378 Summary of Accounting Packets 1380 +----------+-------+-------+-------------+-------------------------+ 1381 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1382 +----------+-------+-------+-------------+-------------------------+ 1383 | 0 | 0 | 0 | 0 | INVALID | 1384 | 0 | 0 | 1 | 2 | Start Accounting Record | 1385 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1386 | 0 | 1 | 1 | 6 | INVALID | 1387 | 1 | 0 | 0 | 8 | Watchdog, no update | 1388 | 1 | 0 | 1 | A | Watchdog, with update | 1389 | 1 | 1 | 0 | C | INVALID | 1390 | 1 | 1 | 1 | E | INVALID | 1391 +----------+-------+-------+-------------+-------------------------+ 1393 The START and STOP flags are mutually exclusive. When the WATCHDOG 1394 flag is set along with the START flag, it indicates that the update 1395 record is a duplicate of the original START record. If the START 1396 flag is not set, then this indicates only that task is still running. 1397 The STOP flag MUST NOT be set in conjunction with the WATCHDOG flag. 1399 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1400 requests an INVALID option. 1402 7. Attribute-Value Pairs 1404 TACACS+ is intended to be an extensible protocol. The attributes 1405 used in Authorization and Accounting are not limited by thsi 1406 document. Some attributes are defined below for common use cases, 1407 clients MUST use these attributes when supporting the corresponding 1408 use cases. 1410 All numeric values in an attribute-value string are provided as 1411 decimal US-ASCII numbers, unless otherwise stated. 1413 All boolean attributes are encoded with values "true" or "false". 1415 It is recommended that hosts be specified as a IP address so as to 1416 avoid any ambiguities. ASCII numeric IPV4 address are specified as 1417 octets separated by dots ('.'), IPV6 address text representation 1418 defined in RFC 4291. 1420 Absolute times are specified in seconds since the epoch, 12:00am Jan 1421 1 1970. The timezone MUST be UTC unless a timezone attribute is 1422 specified. 1424 Attributes may be submitted with no value, in which case they consist 1425 of the name and the mandatory or optional separator. For example, 1426 the attribute "cmd" which has no value is transmitted as a string of 1427 four characters "cmd=" 1429 7.1. Authorization Attributes 1431 service 1433 The primary service. Specifying a service attribute indicates that 1434 this is a request for authorization or accounting of that service. 1435 For example: "shell", "tty-server", "connection", "system" and 1436 "firewall". This attribute MUST always be included. 1438 protocol 1440 the ptotocol field may be used to indicate a subset of a setvice. 1442 cmd 1444 a shell (exec) command. This indicates the command name of the 1445 command that is to be run. The "cmd" attribute MUST be specified if 1446 service equals "shell". 1448 Authorization of shell commands is a common use-case for the TACACS+ 1449 protocol. Command Authorization generally takes one of two forms: 1450 session-based and command-based. 1452 For session-based shell authorization, the "cmd" argument will have 1453 an empty value. The client determines which commands are allowed in 1454 a session according to the arguments present in the authorization. 1456 In command-based authorization, the client requests that the server 1457 determine whether a command is allowed by making an authorization 1458 request for each command. The "cmd" argument will have the command 1459 name as its value. 1461 cmd-arg 1463 an argument to a shell (exec) command. This indicates an argument 1464 for the shell command that is to be run. Multiple cmd-arg attributes 1465 may be specified, and they are order dependent. 1467 acl 1469 US-ASCII number representing a connection access list. Applicable 1470 only to session-based shell authorization. 1472 inacl 1474 US-ASCII identifier for an interface input access list. 1476 outacl 1478 US-ASCII identifier for an interface output access list. 1480 addr 1482 a network address 1484 addr-pool 1486 The identifier of an address pool from which the client can assign an 1487 address. 1489 routing 1491 Boolean. Specifies whether routing information is to be propagated 1492 to, and accepted from this interface. 1494 route 1496 Indicates a route that is to be applied to this interface. Values 1497 MUST be of the form " []". If a 1498 is not specified, the resulting route is via the 1499 requesting peer. 1501 timeout 1503 an absolute timer for the connection (in minutes). A value of zero 1504 indicates no timeout. 1506 idletime 1507 an idle-timeout for the connection (in minutes). A value of zero 1508 indicates no timeout. 1510 autocmd 1512 an auto-command to run. Applicable only to session-based shell 1513 authorization. 1515 noescape 1517 Boolean. Prevents user from using an escape character. Applicable 1518 only to session-based shell authorization. 1520 nohangup 1522 Boolean. Do not disconnect after an automatic command. Applicable 1523 only to session-based shell authorization.y. 1525 priv-lvl 1527 privilege level to be assigned. Please refer to the Privilege Level 1528 section (Section 8) below. 1530 remote_user 1532 remote userid (authen_method must have the value 1533 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1534 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1535 remote_user and remote_host attributes will provide the remote user 1536 and host information to enable rhost style authorization. The 1537 response may request that a privilege level be set for the user. 1539 remote_host 1541 remote host (authen_method must have the value 1542 TAC_PLUS_AUTHEN_METH_RCMD) 1544 callback-dialstring 1546 Indicates that callback is to be done. Value is a dialstring, or 1547 empty. Empty value indicates that the service MAY choose to get the 1548 dialstring through other means. 1550 callback-line 1552 The line number to use for a callback. 1554 callback-rotary 1555 The rotary number to use for a callback. 1557 nocallback-verify 1559 Do not require authentication after callback. 1561 7.2. Accounting Attributes 1563 The following attributes are defined for TACACS+ accounting only. 1564 They MUST precede any attribute-value pairs that are defined in the 1565 authorization section (Section 5) above. 1567 task_id 1569 Start and stop records for the same event MUST have matching task_id 1570 attribute values. The client MUST ensure that active task_ids are 1571 not duplicated: a client MUST NOT reuse a task_id a start record 1572 until it has sent a stop record for that task_id. Servers MUST not 1573 make assumptions about the format of a task_id. 1575 start_time 1577 The time the action started (in seconds since the epoch.). 1579 stop_time 1581 The time the action stopped (in seconds since the epoch.) 1583 elapsed_time 1585 The elapsed time in seconds for the action. 1587 timezone 1589 The timezone abbreviation for all timestamps included in this packet. 1591 event 1593 Used only when "service=system". Current values are "net_acct", 1594 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1595 These indicate system level changes. The flags field SHOULD indicate 1596 whether the service started or stopped. 1598 reason 1600 Accompanies an event attribute. It describes why the event occurred. 1602 bytes 1603 The number of bytes transferred by this action 1605 bytes_in 1607 The number of input bytes transferred by this action to the port 1609 bytes_out 1611 The number of output bytes transferred by this action from the port 1613 paks 1615 The number of packets transferred by this action. 1617 paks_in 1619 The number of input packets transferred by this action to the port. 1621 paks_out 1623 The number of output packets transferred by this action from the 1624 port. 1626 status 1628 The numeric status value associated with the action. This is a 1629 signed four (4) byte word in network byte order. 0 is defined as 1630 success. Negative numbers indicate errors. Positive numbers 1631 indicate non-error failures. The exact status values may be defined 1632 by the client. 1634 err_msg 1636 An 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 in to 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 starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will 1661 permit 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 perfrom actions that are mapped to a higher 1665 privilege level, then an ENABLE type reuthentication can be initiated 1666 by the client, in a way similar to su in unix. The client will 1667 insert the required privilege level into the authentication header 1668 for enable 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 Although in widespread use, the TACACS+ protocol (as defined in "the 1681 Draft") does not meet modern security standards on its own. For this 1682 reason, the authors intend to follow up this document with a more 1683 secure version of the protocol. 1685 TACACS+ was originally specified in "The Draft" (1998) is incomplete, 1686 and leaves key points unspecified. As a result, software authors 1687 have had to make implementation choices about what should, or should 1688 not, be done in certain situations. These implementation choices are 1689 somewhat constrained by ad hoc interoperability tests. That is, all 1690 TACACS+ clients and servers interoperate, so there is a rough 1691 consensus on how the protocol works. 1693 9.1. Overall 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 encrypted which leaves all header 1705 fields open to trivial modification by the man-in-the-middle 1706 attacker. 1708 Invalid or misleading values may be inserted by the man-in-the- 1709 middle attacker in various fields at known offsets to try and 1710 circumvent the authentication or authorization checks even inside 1711 the encrypted body. 1713 While the protocol provides some measure of transport privacy, it is 1714 vulnerable to at least the following attacks: 1716 Brute force attacks exploiting increased efficiency of MD5 digest 1717 computation. 1719 Known plaintext attacks which may decrease the cost of brute force 1720 attack. 1722 Chosen plaintext attacks which may decrease the cost of a brute 1723 force attack. 1725 No forward secrecy means that original data may be revealed at the 1726 later time and still provide valuable information to the attacker. 1728 Even though, to the best knowledge of authors, this method of 1729 encryption wasn't rigorously tested, authors feel that enough 1730 information is available that it is best referred to as "obfuscation" 1731 and not "encryption" and as such it MUST NOT BE relied upon to 1732 provide privacy. 1734 For example, a "session_id" can be replaced by an alternate one, 1735 which could allow an unprivileged administrator to "steal" the 1736 authorization from a session for a privileged administrator. An 1737 attacker could also update the "flags" field to indicate that one or 1738 the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG, 1739 which would subvert the obfuscation mechanism. 1741 For this reasons, users deploying TACACS+ protocol in their 1742 environments MUST limit access to known clients and MUST control the 1743 security of the entire transmission path. Attacks who can guess the 1744 key or otherwise break the obfuscation WILL gain unrestricted and 1745 undetected access to all TACACS+ traffic. The security risk of such 1746 attack succeeding against a centralised AAA system like TACACS+ 1747 cannot be overstated. 1749 9.2. Security of Authentication Sessions 1751 The authentication options include options which MUST NOT be used 1752 outside a secured deployment. Specifically, options which permit the 1753 exchange of clear-text passwords or MSCHAPv1 and MS-CHAPv2. As of 1754 the publication of this document, there has been no similar attacks 1755 on the CHAP protocol. 1757 Section 4.4.3 permits the redirection of a session to another server 1758 via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this 1759 process, the secret key for a new server can be sent to the client. 1760 This public exchange of secret keys means that once one session is 1761 broken, it may be possible to leverage that attack to attacking 1762 connections to other servers. This option MUST NOT be used outside a 1763 secured deployment. 1765 9.3. Security of Authorization Sessions 1767 TACACS+ authorization is specifically separate from authentication. 1768 Careful consideration must be given to whether this mode is 1769 appropriate for the target deployment. Authorization sessions are 1770 not cryptographically linked to any authentication sessions. 1771 Instead, sessions are tied together implicitly by the contents of the 1772 other fields, such as "use", "port", "rem_addr", etc. 1774 The specification allows for the exchange of attribute-value pairs. 1775 While a few such attributes are defined here, the protocol is 1776 extensible, and vendors can define their own attributes. There is no 1777 registry for such attributes, and in the absence of a published 1778 specification, no way for a client or server to know the meaning of a 1779 new attribute. 1781 As a result, implemetors MUST ensure that new attribute-value pairs 1782 are used consistently to communicate between client and server 1783 implementations. 1785 9.4. Security of Accounting Sessions 1787 The security considerations for accounting sessions are largely the 1788 same as for authorization sessions. This section describes 1789 additional issues specific to accounting sessions. 1791 There is no way in TACACS+ to signal that accounting is required. 1792 There is no way for a server to signal a client how often accounting 1793 is required. The accounting packets are received solely at the 1794 clients discretion. Adding such functionality would assist with 1795 auditing of user actions. 1797 The "task_id" field is defined only for accounting packets, and not 1798 for authentication or authorization packets. As such, it is 1799 difficult to correlate accounting data with a previous authentication 1800 or authorization request. 1802 9.5. TACACS+ Deployment Recommendations 1804 Due to the above concerns with the protocol, it is critical that it 1805 be deployed in a secure manner. The following recommendations are 1806 made for those deploying and configuring TACACS+ as a solution for 1807 Device Administration: 1809 Secure the Deployment: TACACS+ does not provide modern security so 1810 TACACS+ MUST BE employed over networks which ensure privacy and 1811 integrity of the communication. The way this is ensured will 1812 depend upon the organisational means: a dedicated and secure 1813 management network where available in enterprise deployments, or 1814 IPsec where dedicated networks are not available. 1816 Always set a secret key (recommended minimum 14 characters) on the 1817 client and server when configuring the connection between them. 1819 Servers MUST be configured with a list of known clients. Servers 1820 MUST be configured to reject requests from clients not on the 1821 list. A unique secret key SHOULD be configured for every 1822 individual client. 1824 Restrict to TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type where 1825 possible. Use other options only when unavoidable due to 1826 requirements of identity/password systems. 1828 Servers SHOULD be restricted to requiring TACACS+ authentication 1829 for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS 1830 is used). 1832 Avoid the use of the redirection mechanism. 1833 TAC_PLUS_AUTHEN_STATUS_FOLLOW, specifically avoid the option to 1834 send send secret keys in the server list. 1836 Take case when applying extensions to the dictionary of 1837 authorization/accounting arguments. Ensure that the client and 1838 server use of new argument names are consistent. 1840 9.6. TACACS+ Client Implementation Recommendations 1842 When implementing TACACS+ Clients it is recommended: 1844 Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks 1845 that are considered secure. 1847 Ignore redirects to hosts which are outside of the pre-configured 1848 range or list. A client SHOULD ignore any key provided via 1849 TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a 1850 preconfigured key for that host. 1852 If receiving an unknown mandatory authorization attribute, behave 1853 as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. For full 1854 details, refer to (Authorization attributes section). 1856 9.7. TACACS+ Server Implementation Recommendations 1858 When implementing TACACS+ Servers, it is recommended: 1860 Server SHOULD reject all connections which have the 1861 TAC_PLUS_UNENCRYPTED_FLAG with applicable ERROR response for type 1862 of packet. 1864 Servers MUST permit configuration of secret keys per individual 1865 client. Servers SHOULD warn administrators if secret keys are not 1866 unique per client. 1868 On detection of an invalid shared secret: Servers SHOULD NOT 1869 accept any new sessions on a connection, and terminate the 1870 connection on completion of any sessions previously established 1871 with a valid shared secret. 1873 Allow the administrator to mandate : - TAC_PLUS_AUTHEN_TYPE_CHAP 1874 for authen_type - TAC_PLUS_AUTHEN_METH_TACACSPLUS for 1875 authen_method in authorization - Minimum length for shared secrets 1877 9.8. TACACS+ Security and Operational Concerns 1879 This section identifies some of the known security and operational 1880 concerns. It is important to acknowledge that TACACS+ on its own 1881 does not provide modern levels of security, and that it MUST be used 1882 within a secure deployment. 1884 The "encryption" is based upon MD5. In modern terms this can be 1885 regarded merely as "obfuscation". 1887 Only the packet body (not header) is obfuscated. For example, 1888 session_id, flags containing TAC_PLUS_UNENCRYPTED_FLAG is exposed 1889 in cleartext. 1891 Support of insecure authentication protocols such as plaintext, 1892 MS-CHAP. 1894 Difficulty to correlate authentication, authorization, and 1895 accounting requests for a single unit of end client activity. 1897 Potential confusion between clients and servers from different 1898 vendors of the meaning of specific argument attributes. 1900 Potential confusion between clients and servers from different 1901 vendors of the meaning of specific commands. 1903 In summary: It is strongly advised that TACACS+ MUST be used within a 1904 secure deployment. Failure to do so may impact overall network 1905 security. 1907 10. References 1909 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1910 April 1992. 1912 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1913 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1914 . 1916 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1917 "Randomness Recommendations for Security", RFC 1750, 1918 DOI 10.17487/RFC1750, December 1994, 1919 . 1921 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1922 RFC 2433, DOI 10.17487/RFC2433, October 1998, 1923 . 1925 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1926 RFC 2759, DOI 10.17487/RFC2759, January 2000, 1927 . 1929 [TheDraft] 1930 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 1931 1.78", June 1997, . 1934 Authors' Addresses 1935 Thorsten Dahm 1936 Google Inc 1937 1600 Amphitheatre Parkway 1938 Mountain View, CA 94043 1939 US 1941 EMail: thorstendlux@google.com 1943 Andrej Ota 1944 Google Inc 1945 1600 Amphitheatre Parkway 1946 Mountain View, CA 94043 1947 US 1949 EMail: aota@google.com 1951 Douglas C. Medway Gash 1952 Cisco Systems, Inc. 1953 170 West Tasman Dr. 1954 San Jose, CA 95134 1955 US 1957 Phone: +44 0208 8244508 1958 EMail: dcmgash@cisco.com 1960 David Carrel 1961 vIPtela, Inc. 1962 1732 North First St. 1963 San Jose, CA 95112 1964 US 1966 EMail: dcarrel@viptela.com 1968 Lol Grant