idnits 2.17.1 draft-ietf-opsawg-tacacs-03.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 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 268: '... client MUST NOT send a second packe...' RFC 2119 keyword, line 279: '... The flag MUST be ignored after thes...' RFC 2119 keyword, line 284: '...established, multiple sessions MUST be...' RFC 2119 keyword, line 333: '...ket in a session MUST have the sequenc...' RFC 2119 keyword, line 384: '...ta fields which are unused MUST have a...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2016) is 2866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UTF-8' is mentioned on line 576, but not defined ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) Summary: 5 errors (**), 0 flaws (~~), 3 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: December 22, 2016 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 June 20, 2016 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-03 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 December 22, 2016. 39 Copyright Notice 41 Copyright (c) 2016 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 . . . . . . . . . . . . . . 5 71 3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1.1. Security Considerations . . . . . . . . . . . . . . . 6 73 3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 6 75 3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 7 76 3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 9 77 3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.6.1. Body Encryption . . . . . . . . . . . . . . . . . . . 9 79 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.1. The Authentication START Packet Body . . . . . . . . . . 11 81 4.2. The Authentication REPLY Packet Body . . . . . . . . . . 13 82 4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 15 83 4.4. Description of Authentication Process . . . . . . . . . . 15 84 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 16 85 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 17 86 4.4.3. Aborting an Authentication Session . . . . . . . . . 20 87 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 21 88 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 21 89 5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 24 90 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 26 92 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 27 93 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 29 94 7.1. Authorization Attributes . . . . . . . . . . . . . . . . 30 95 7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 32 96 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 34 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 100 1. Introduction 102 Terminal Access Controller Access-Control System Plus (TACACS+) was 103 originally conceived as a general Authentication, Authorization and 104 Accounting protocol. It is primarily used today for Device 105 Administration: authenticating access to network devices, providing 106 central authorization of operations, and audit of those operations. 108 A wide range of TACACS+ clients and servers are already deployed in 109 the field. The TACACS+ protocol they are based on is defined in a 110 draft document that was originally intended for IETF publication. 111 This document is known as `The Draft' [TheDraft] . 113 It is intended that all implementations which conform to this 114 document will conform to `The Draft'. However, the following 115 specific adjustments of the protocol specification from 'The Draft' 116 should be noted: 118 This document officially removes SENDPASS for security reasons. 120 The normative description of Legacy features such as ARAP and 121 outbound authentication have been removed, however the required 122 enumerations are kept. 124 Usernames and passwords are specifically mentioned as being 125 encoded in UTF-8 rather than plain US-ASCII. US-ASCII text is 126 valid UTF-8, and specification of UTF-8 specifically for username 127 and password fields enhances interoperability with external 128 identity systems. 130 The TACACS+ protocol separates the functions of Authentication, 131 Authorization and Accounting. It allows for arbitrary length and 132 content authentication exchanges, which will support any 133 authentication mechanism to be utilized with TACACS+ clients. It is 134 extensible to provide for site customization and future development 135 features, and it uses TCP to ensure reliable delivery. The protocol 136 allows the TACACS+ client to request very fine-grained access control 137 and allows the server to respond to each component of that request. 139 The separation of authentication, authorization and accounting is a 140 fundamental component of the design of TACACS+. The distinction 141 between them is very important so this document will address each one 142 separately. It is important to note that TACACS+ provides for all 143 three, but an implementation or configuration is not required to 144 employ all three. Each one serves a unique purpose that alone is 145 useful, and together can be quite powerful. 147 This document restricts itself to a description of the protocol that 148 is used by TACACS+. It does not cover deployment or best practices. 150 2. Technical Definitions 152 This section provides a few basic definitions that are applicable to 153 this document 155 Authentication 157 Authentication is the action of determining who a user (or entity) 158 is. Authentication can take many forms. Traditional authentication 159 utilizes a name and a fixed password. However, fixed passwords have 160 limitations, mainly in the area of security. Many modern 161 authentication mechanisms utilize "one-time" passwords or a 162 challenge-response query. TACACS+ is designed to support all of 163 these, and should be powerful enough to handle any future mechanisms. 164 Authentication generally takes place when the user first logs in to a 165 machine or requests a service of it. 167 Authentication is not mandatory; it is a site-configured option. 168 Some sites do not require it. Others require it only for certain 169 services (see authorization below). Authentication may also take 170 place when a user attempts to gain extra privileges, and must 171 identify himself or herself as someone who possesses the required 172 information (passwords, etc.) for those privileges. 174 Authorization 176 It is important to distinguish Authorization from Authentication. 177 Authorization is the action of determining what a user is allowed to 178 do. Generally authentication precedes authorization, but again, this 179 is not required. An authorization request may indicate that the user 180 is not authenticated (we don't know who they are). In this case it 181 is up to the authorization agent to determine if an unauthenticated 182 user is allowed the services in question. 184 In TACACS+, authorization does not merely provide yes or no answers, 185 but it may also customize the service for the particular user. 186 Examples of when authorization would be performed are: When a user 187 first logs in and wants to start a shell, or when a user starts PPP 188 and wants to use IP over PPP with a particular IP address. The 189 TACACS+ server might respond to these requests by allowing the 190 service, but placing a time restriction on the login shell, or by 191 requiring IP access lists on the PPP connection. For a list of 192 authorization attributes, see the authorization section (Section 5) . 194 Accounting 196 Accounting is typically the third action after authentication and 197 authorization. But again, neither authentication nor authorization 198 is required. Accounting is the action of recording what a user is 199 doing, and/or has done. Accounting in TACACS+ can serve two 200 purposes: It may be used as an auditing tool for security services. 201 It may also be used to account for services used, such as in a 202 billing environment. To this end, TACACS+ supports three types of 203 accounting records. Start records indicate that a service is about 204 to begin. Stop records indicate that a service has just terminated, 205 and Update records are intermediate notices that indicate that a 206 service is still being performed. TACACS+ accounting records contain 207 all the information used in the authorization records, and also 208 contain accounting specific information such as start and stop times 209 (when appropriate) and resource usage information. A list of 210 accounting attributes is defined in the accounting section 211 (Section 6) . 213 Client 215 The client is any device, (often a Network Access Server) that 216 provides access services. The clients usually provide a character 217 mode front end and then allow the user to telnet or rlogin to another 218 host. A client may also support protocol based access services. 220 Server 222 The server receives TACACS+ protocol requests, and replies according 223 to its business model, in accordance with the flows defined in this 224 document. 226 Packet 228 All uses of the word packet in this document refer to TACACS+ 229 protocol packets unless explicitly noted otherwise. 231 3. TACACS+ Connections and Sessions 233 3.1. Connection 235 TACACS+ uses TCP for its transport. Server port 49 is allocated for 236 TACACS+ traffic. 238 3.1.1. Security Considerations 240 The protocol includes an obfuscation mechanism referred to in the 241 original draft as Body Encryption. It is intended to follow up this 242 document with enhancements to TACACS+ security. 244 It is recommended to separate the management traffic from the regular 245 network access traffic, and to use Body Encryption in production 246 environments. 248 3.2. Session 250 The concept of a session is used throughout this document. A TACACS+ 251 session is a single authentication sequence, a single authorization 252 exchange, or a single accounting exchange. 254 An accounting and authorization session will consist of a single pair 255 of packets (the request and its reply). An authentication session 256 may involve an arbitrary number of packets being exchanged. The 257 session is an operational concept that is maintained between the 258 TACACS+ client and server. It does not necessarily correspond to a 259 given user or user action. 261 3.3. Single Connect Mode 263 The packet header (see below) contains a flag to allow sessions to be 264 multiplexed on a connection. 266 If a client sets this flag, this indicates that it supports 267 multiplexing TACACS+ sessions over a single TCP connection. The 268 client MUST NOT send a second packet on a connection until single- 269 connect status has been established. 271 If the server sets this flag in the first reply packet in response to 272 the first packet from a client, this indicates its willingness to 273 support single-connection over the current connection. The server 274 may set this flag even if the client does not set it, but the client 275 is under no obligation to honor it. 277 The flag is only relevant for the first two packets on a connection, 278 to allow the client and server to establish single connection mode. 279 The flag MUST be ignored after these two packets since the single- 280 connect status of a connection, once established, must not be 281 changed. The connection must instead be closed and a new connection 282 opened, if required. 284 When single-connect status is established, multiple sessions MUST be 285 allowed simultaneously and/or consecutively on a single TCP 286 connection. If single-connect status has not been established in the 287 first two packets of a TCP connection, then the connection must be 288 closed at the end of the first session. 290 3.4. The TACACS+ Packet Header 292 All TACACS+ packets begin with the following 12 byte header. The 293 header describes the remainder of the packet: 295 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 296 +----------------+----------------+----------------+----------------+ 297 |major | minor | | | | 298 |version| version| type | seq_no | flags | 299 +----------------+----------------+----------------+----------------+ 300 | | 301 | session_id | 302 +----------------+----------------+----------------+----------------+ 303 | | 304 | length | 305 +----------------+----------------+----------------+----------------+ 307 major_version 309 This is the major TACACS+ version number. 311 TAC_PLUS_MAJOR_VER := 0xc 313 minor_version 315 The minor TACACS+ version number. 317 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 319 TAC_PLUS_MINOR_VER_ONE := 0x1 321 type 323 This is the packet type. Legal values are: 325 TAC_PLUS_AUTHEN := 0x01 (Authentication) 327 TAC_PLUS_AUTHOR := 0x02 (Authorization) 329 TAC_PLUS_ACCT := 0x03 (Accounting) 331 seq_no 332 This is the sequence number of the current packet for the current 333 session. The first packet in a session MUST have the sequence number 334 1 and each subsequent packet will increment the sequence number by 335 one. Thus clients only send packets containing odd sequence numbers, 336 and TACACS+ servers only send packets containing even sequence 337 numbers. 339 The sequence number must never wrap i.e. if the sequence number 2^8-1 340 is ever reached, that session must terminate and be restarted with a 341 sequence number of 1. 343 flags 345 This field contains various bitmapped flags. 347 The unencrypted flag bit says whether encryption is being used on the 348 body of the packet (the entire portion after the header). 350 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 352 If this flag is set, then body encryption is not used. If this flag 353 is cleared, the packet is encrypted. Unencrypted packets are 354 intended for testing, and are not recommended for normal use. 356 The single-connection flag: 358 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 360 This flag is used to allow a client and server to agree whether 361 multiple sessions may be multiplexed onto a single connection. 363 session_id 365 The Id for this TACACS+ session. The session id should be randomly 366 chosen. This field does not change for the duration of the TACACS+ 367 session. (If this value is not a cryptographically strong random 368 number, it will compromise the protocol's security, see RFC 1750 369 [RFC1750] ) 371 length 373 The total length of the packet body (not including the header). This 374 value is in network byte order. Packets are never padded beyond this 375 length. 377 3.5. The TACACS+ Packet Body 379 The TACACS+ body types are defined in the packet header. The 380 remainder of this document will address the contents of the different 381 TACACS+ bodies. The following general rules apply to all TACACS+ 382 body types: 384 - Any variable length data fields which are unused MUST have a 385 length value equal to zero. 387 - Unused fixed length fields SHOULD have values of zero. 389 - All data and message fields in a packet MUST NOT be null 390 terminated. 392 - All length values are unsigned and in network byte order. 394 - There should be no padding in any of the fields or at the end of 395 a packet. 397 3.6. Encryption 399 3.6.1. Body Encryption 401 The body of packets may be encrypted. The following sections 402 describe the encryption mechanism that is supported to enable 403 backwards compatibility with 'The Draft'. 405 When the encryption mechanism relies on a secret key, it is referring 406 to a shared secret value that is known to both the client and the 407 server. This document does not discuss the management and storage of 408 those keys. It is an implementation detail of the server and client, 409 as to whether they will maintain only one key, or a different key for 410 each client or server with which they communicate. For security 411 reasons, the latter options should be available, but it is a site 412 dependent decision as to whether the use of separate keys is 413 appropriate. 415 The encrypted flag field may be set as follows: 417 TAC_PLUS_UNENCRYPTED_FLAG == 0x0 419 In this case, the packet body is encrypted by XOR-ing it byte-wise 420 with a pseudo random pad. 422 ENCRYPTED {data} == data ^ pseudo_pad 423 The pad is generated by concatenating a series of MD5 hashes (each 16 424 bytes long) and truncating it to the length of the input data. 426 Whenever used in this document, MD5 refers to the "RSA Data Security, 427 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 428 . 430 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 432 The first MD5 hash is generated by concatenating the session_id, the 433 secret key, the version number and the sequence number and then 434 running MD5 over that stream. All of those input values are 435 available in the packet header, except for the secret key which is a 436 shared secret between the TACACS+ client and server. 438 The version number is the one byte concatenation of the major and 439 minor version numbers. 441 The session id is used in network byte order. 443 Subsequent hashes are generated by using the same input stream, but 444 concatenating the previous hash value at the end of the input stream. 446 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 447 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 448 version, seq_no, MD5_n-1} 450 When a server detects that the secret(s) it has configured for the 451 device mismatch, it MUST return ERROR. The handling of the TCP 452 connection by the server is implementation independent. 454 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 456 In this case, the entire packet body is in cleartext. Encryption and 457 decryption are null operations. This method should only be used for 458 debugging. It does not provide data protection or authentication and 459 is highly susceptible to packet spoofing. Implementing this 460 encryption method is optional. 462 NOTE: Implementations should take care not to skip decryption simply 463 because an incoming packet indicates that it is not encrypted. If 464 the unencrypted flag is not set, and the packet is not encrypted, it 465 must be dropped. 467 After a packet body is decrypted, the lengths of the component values 468 in the packet should be summed and checked against the cleartext 469 datalength value from the header. Any packets which fail this check 470 should be discarded and an error signalled. Commonly such failures 471 may be expected to be seen when there are mismatched keys between the 472 client and the TACACS+ server. 474 If an error must be declared but the type of the incoming packet 475 cannot be determined, a packet with the identical cleartext header 476 but with a sequence number incremented by one and the length set to 477 zero MUST be returned to indicate an error. 479 4. Authentication 481 4.1. The Authentication START Packet Body 483 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 484 +----------------+----------------+----------------+----------------+ 485 | action | priv_lvl | authen_type | authen_service | 486 +----------------+----------------+----------------+----------------+ 487 | user len | port len | rem_addr len | data len | 488 +----------------+----------------+----------------+----------------+ 489 | user ... 490 +----------------+----------------+----------------+----------------+ 491 | port ... 492 +----------------+----------------+----------------+----------------+ 493 | rem_addr ... 494 +----------------+----------------+----------------+----------------+ 495 | data... 496 +----------------+----------------+----------------+----------------+ 498 Packet fields are as follows: 500 action 502 This describes the authentication action to be performed. Legal 503 values are: 505 TAC_PLUS_AUTHEN_LOGIN := 0x01 507 TAC_PLUS_AUTHEN_CHPASS := 0x02 509 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 511 priv_lvl 513 This indicates the privilege level that the user is authenticating 514 as. Please refer to the Privilege Level section (Section 8) below. 516 authen_type 517 The type of authentication that is being performed. Legal values 518 are: 520 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 522 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 524 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 526 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 528 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 530 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 532 authen_service 534 This is the service that is requesting the authentication. Legal 535 values are: 537 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 539 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 541 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 543 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 545 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 547 TAC_PLUS_AUTHEN_SVC_PT := 0x05 549 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 551 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 553 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 555 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 557 The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization 558 application of this field that indicates that no authentication was 559 performed by the device. 561 The TAC_PLUS_AUTHEN_SVC_LOGIN option is identifies regular login (as 562 opposed to ENABLE) to a client device. 564 The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE service, 565 which refers to a service requesting authentication in order to grant 566 the user different privileges. This is comparable to the Unix 567 "su(1)" command. A service value of NONE should only be used when 568 none of the other service values are appropriate. ENABLE may be 569 requested independently, no requirements for previous authentications 570 or authorizations are imposed by the protocol. 572 Other options are included for legacy/backwards compatibility. 574 user 576 The username. It is encoded in [UTF-8]. It is optional in this 577 packet, depending upon the class of authentication. 579 port 581 The US-ASCII name of the client port on which the authentication is 582 taking place. The value of this field is client specific. (For 583 example, Cisco uses "tty10" to denote the tenth tty line and 584 "Async10" to denote the tenth async interface). 586 rem_addr 588 An US-ASCII string this is a "best effort" description of the remote 589 location from which the user has connected to the client. It is 590 intended to hold a network address if the user is connected via a 591 network, a caller ID is the user is connected via ISDN or a POTS, or 592 any other remote location information that is available. This field 593 is optional (since the information may not be available). 595 data 597 This field is used to send data appropriate for the action and 598 authen_type. It is described in more detail in the section Common 599 Authentication flows (Section 4.4.2) . 601 4.2. The Authentication REPLY Packet Body 603 The TACACS+ server sends only one type of authentication packet (a 604 REPLY packet) to the client. The REPLY packet body looks as follows: 606 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 607 +----------------+----------------+----------------+----------------+ 608 | status | flags | server_msg len | 609 +----------------+----------------+----------------+----------------+ 610 | data len | server_msg ... 611 +----------------+----------------+----------------+----------------+ 612 | data ... 613 +----------------+----------------+ 615 status 617 The current status of the authentication. Legal values are: 619 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 621 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 623 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 625 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 627 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 629 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 631 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 633 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 635 flags 637 Bitmapped flags that modify the action to be taken. The following 638 values are defined: 640 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 642 server_msg 644 c A message to be displayed to the user. This field is optional. If 645 it exists, it is intended to be presented to the user. US-ASCII 646 charset must be used. 648 data 650 This field holds data that is a part of the authentication exchange 651 and is intended for the client, not the user. It is described in 652 more detail in the section Common Authentication flows 653 (Section 4.4.2) . 655 4.3. The Authentication CONTINUE Packet Body 657 This packet is sent from the client to the server following the 658 receipt of a REPLY packet. 660 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 661 +----------------+----------------+----------------+----------------+ 662 | user_msg len | data len | 663 +----------------+----------------+----------------+----------------+ 664 | flags | user_msg ... 665 +----------------+----------------+----------------+----------------+ 666 | data ... 667 +----------------+ 669 user_msg 671 This field is the string that the user entered, or the client 672 provided on behalf of the user, in response to the server_msg from a 673 REPLY packet. 675 data 677 This field carries information that is specific to the action and the 678 authen_type for this session. Valid uses of this field are described 679 below. 681 flags 683 This holds the bitmapped flags that modify the action to be taken. 684 The following values are defined: 686 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 688 4.4. Description of Authentication Process 690 The action, authen_type and service fields (described above) combine 691 to determine what kind of authentication is to be performed Every 692 authentication START, REPLY and CONTINUE packet includes a data 693 field. The use of this field is dependent upon the kind of the 694 Authentication. 696 A set of standard kinds of authentication is defined in this 697 document. Each authentication flow consists of a START packet. The 698 server responds either with a request for more information (GETDATA, 699 GETUSER or GETPASS) or a termination (PASS or FAIL). The actions and 700 meanings when the server sends a RESTART, ERROR or FOLLOW are common 701 and are described further below. 703 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 704 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 705 then authentication continues and the SHOULD provide server_msg 706 content for the client to prompt the user for more information. The 707 client MUST then return a CONTINUE packet containing the requested 708 information in the user_msg field. 710 All three cause the same action to be performed, but the use of 711 TAC_PLUS_AUTHEN_STATUS_GETUSER, indicates to the client that the user 712 response will be interpreted as a username, and for 713 TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents 714 will be interpreted as a password. TAC_PLUS_AUTHEN_STATUS_GETDATA is 715 the generic request for more information to flexibly support future 716 requirements. If the TAC_PLUS_REPLY_FLAG_NOECHO flag is set in the 717 REPLY, then the user response must not be echoed as it is entered. 718 The data field is only used in the REPLY where explicitly defined 719 below. 721 4.4.1. Version Behaviour 723 The TACACS+ protocol is versioned to allow revisions while 724 maintaining backwards compatibility. The version number is in every 725 packet header. The changes between minor_version 0 and 1 apply only 726 to the authentication process, and all deal with the way that CHAP 727 and PAP authentications are handled. minor_version 1 may only be used 728 for authentication kinds that explicitly call for it in the table 729 below: 731 LOGIN CHPASS SENDAUTH 732 ASCII v0 v0 - 733 PAP v1 - v1 734 CHAP v1 - v1 735 MS-CHAPv1/2 v1 - v1 737 The '-' symbol represents that the option is not valid. 739 When a server receives a packet with a minor_version that it does not 740 support, it should return an ERROR status with the minor_version set 741 to the closest supported value. 743 In minor_version 0, Inbound PAP performed a normal LOGIN, sending the 744 username in the START packet and then waiting for a GETPASS and 745 sending the password in a CONTINUE packet. 747 In minor_version 1, CHAP and inbound PAP use LOGIN to perform inbound 748 authentication and the exchanges use the data field so that the 749 client only sends a single START packet and expects to receive a PASS 750 or FAIL. SENDAUTH is only used for PPP when performing outbound 751 authentication. 753 NOTE: Only those requests which have changed from their minor_version 754 0 implementation (i.e. CHAP, MS-CHAP and PAP authentications) should 755 use the new minor_version number of 1. All other requests (i.e. all 756 authorisation and accounting and ASCII authentication) MUST continue 757 to use the same minor_version number of 0. The removal of SENDPASS 758 was prompted by security concerns, and is no longer considered part 759 of the TACACS+ protocol. 761 4.4.2. Common Authentication Flows 763 This section describes common authentication flows. If the options 764 are implemented, they MUST follow the description. If the server 765 does not implement an option, it should respond with 766 TAC_PLUS_AUTHEN_STATUS_ERROR. 768 Inbound ASCII Login 770 action = TAC_PLUS_AUTHEN_LOGIN 771 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 772 minor_version = 0x0 774 This is a standard ASCII authentication. The START packet may 775 contain the username, but need not do so. The data fields in both 776 the START and CONTINUE packets are not used for ASCII logins. There 777 is a single START followed by zero or more pairs of REPLYs and 778 CONTINUEs, followed by a terminating REPLY (PASS or FAIL). 780 Inbound PAP Login 782 action = TAC_PLUS_AUTHEN_LOGIN 783 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 784 minor_version = 0x1 786 The entire exchange MUST consist of a single START packet and a 787 single REPLY. The START packet MUST contain a username and the data 788 field MUST contain the PAP ASCII password. A PAP authentication only 789 consists of a username and password RFC 1334 [RFC1334] . The REPLY 790 from the server MUST be either a PASS or FAIL. 792 Inbound CHAP login 793 action = TAC_PLUS_AUTHEN_LOGIN 794 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 795 minor_version = 0x1 797 The entire exchange MUST consist of a single START packet and a 798 single REPLY. The START packet MUST contain the username in the user 799 field and the data field will be a concatenation of the PPP id, the 800 challenge and the response. 802 The length of the challenge value can be determined from the length 803 of the data field minus the length of the id (always 1 octet) and the 804 length of the response field (always 16 octets). 806 To perform the authentication, the server will run MD5 over the id, 807 the user's secret and the challenge, as defined in the PPP 808 Authentication RFC RFC 1334 [RFC1334] and then compare that value 809 with the response. The REPLY from the server MUST be a PASS or FAIL. 811 Inbound MS-CHAP v1 login 813 action = TAC_PLUS_AUTHEN_LOGIN 814 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 815 minor_version = 0x1 817 The entire exchange MUST consist of a single START packet and a 818 single REPLY. The START packet MUST contain the username in the user 819 field and the data field will be a concatenation of the PPP id, the 820 MS-CHAP challenge and the MS-CHAP response. 822 The length of the challenge value can be determined from the length 823 of the data field minus the length of the id (always 1 octet) and the 824 length of the response field (always 49 octets). 826 To perform the authentication, the server will use a combination of 827 MD4 and DES on the user's secret and the challenge, as defined in RFC 828 2433 [RFC2433] and then compare the resulting value with the 829 response. The REPLY from the server MUST be a PASS or FAIL. 831 For best practices, please refer to RFC 2433 [RFC2433] 833 Inbound MS-CHAP v2 login 835 action = TAC_PLUS_AUTHEN_LOGIN 836 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 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 will be a concatenation of the PPP id, the 842 MS-CHAP challenge and the MS-CHAP 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 49 octets). 848 To perform the authentication, the server will use a the algorithm 849 specified RFC2759 [RFC2759] on the user's secret and challenge and 850 then compare the resulting value with the response. The REPLY from 851 the server MUST be a PASS or FAIL. 853 For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] 855 Enable Requests 857 action = TAC_PLUS_AUTHEN_LOGIN 858 priv_lvl = implementation dependent 859 authen_type = not used 860 service = TAC_PLUS_AUTHEN_SVC_ENABLE 862 This is an ENABLE request, used to change the current running 863 privilege level of a principal. The exchange MAY consist of multiple 864 messages while the server collects the information it requires in 865 order to allow changing the principal's privilege level. This 866 exchange is very similar to an Inbound ASCII login. 868 In order to readily distinguish enable requests from other types of 869 request, the value of the service field MUST be set to 870 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 871 set to this value when requesting any other operation. 873 ASCII change password request 875 action = TAC_PLUS_AUTHEN_CHPASS 876 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 878 This exchange consists of multiple messages while the server collects 879 the information it requires in order to change the user's password. 880 It is very similar to an ASCII login. The status value 881 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 882 "new" password. It MAY be sent multiple times. When requesting the 883 "old" password, the status value MUST be set to 884 TAC_PLUS_AUTHEN_STATUS_GETDATA. 886 4.4.3. Aborting an Authentication Session 888 The client may prematurely terminate a session by setting the 889 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 890 flag is set, the data portion of the message may contain an ASCII 891 message explaining the reason for the abort. The session is 892 terminated and no REPLY message is sent. 894 There are three other possible return status values that can be used 895 in a REPLY packet. These can be sent regardless of the action or 896 authen_type. Each of these indicates that the TACACS+ authentication 897 session should be terminated. In each case, the server_msg may 898 contain a message to be displayed to the user. 900 When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet 901 indicates that the TACACS+ server requests that authentication should 902 be performed with an alternate server. The data field MUST contain 903 ASCII text describing one or more servers. A server description 904 appears like this: 906 [@@]>[@] 908 If more than one host is specified, they MUST be separated into rows 909 by an ASCII Carriage Return (0x0D). 911 The protocol and key are optional, and apply only to host in the same 912 row. The protocol can describe an alternate way of performing the 913 authentication, other than TACACS+. If the protocol is not present, 914 then TACACS+ is assumed. 916 Protocols are ASCII numbers corresponding to the methods listed in 917 the authen_method field of authorization packets (defined below). 918 The host is specified as either a fully qualified domain name, or an 919 ASCII numeric IPV4 address specified as octets separated by dots 920 (`.'), or IPV6 922 If a key is supplied, the client MAY use the key in order to 923 authenticate to that host. The client may use a preconfigured key 924 for the host if it has one. If not then the client may communicate 925 with the host using unencrypted option. 927 Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the 928 discretion of the TACACS+ client. It may choose to use any one, all 929 or none of these hosts. If it chooses to use none, then it MUST 930 treat the authentication as if the return status was 931 TAC_PLUS_AUTHEN_STATUS_FAIL. 933 While the order of hosts in this packet indicates a preference, but 934 the client is not obliged to use that ordering. 936 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 937 indicating that it is experiencing an unrecoverable error and the 938 authentication should proceed as if that host could not be contacted. 939 The data field may contain a message to be printed on an 940 administrative console or log. 942 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 943 authentication sequence should be restarted with a new START packet 944 from the client. This REPLY packet indicates that the current 945 authen_type value (as specified in the START packet) is not 946 acceptable for this session, but that others may be. 948 If a client chooses not to accept the TAC_PLUS_AUTHEN_STATUS_RESTART 949 packet, then it should be TREATED as if the status was 950 TAC_PLUS_AUTHEN_STATUS_FAIL. 952 5. Authorization 954 This part of the TACACS+ protocol provides an extensible way of 955 providing remote authorization services. An authorization session is 956 defined as a single pair of messages, a REQUEST followed by a 957 RESPONSE. 959 The authorization REQUEST message contains a fixed set of fields that 960 indicate how the user was authenticated or processed and a variable 961 set of arguments that describe the services and options for which 962 authorization is requested. 964 The RESPONSE contains a variable set of response arguments 965 (attribute-value pairs) that can restrict or modify the clients 966 actions. 968 The arguments in both a REQUEST and a RESPONSE can be specified as 969 either mandatory or optional. An optional argument is one that may 970 or may not be used, modified or even understood by the recipient. 972 A mandatory argument MUST be both understood and used. This allows 973 for extending the attribute list while providing secure backwards 974 compatibility. 976 5.1. The Authorization REQUEST Packet Body 977 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 978 +----------------+----------------+----------------+----------------+ 979 | authen_method | priv_lvl | authen_type | authen_service | 980 +----------------+----------------+----------------+----------------+ 981 | user len | port len | rem_addr len | arg_cnt | 982 +----------------+----------------+----------------+----------------+ 983 | arg 1 len | arg 2 len | ... | arg N len | 984 +----------------+----------------+----------------+----------------+ 985 | user ... 986 +----------------+----------------+----------------+----------------+ 987 | port ... 988 +----------------+----------------+----------------+----------------+ 989 | rem_addr ... 990 +----------------+----------------+----------------+----------------+ 991 | arg 1 ... 992 +----------------+----------------+----------------+----------------+ 993 | arg 2 ... 994 +----------------+----------------+----------------+----------------+ 995 | ... 996 +----------------+----------------+----------------+----------------+ 997 | arg N ... 998 +----------------+----------------+----------------+----------------+ 1000 authen_method 1002 This indicates the authentication method used by the client to 1003 acquire the user information. 1005 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1007 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1009 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1011 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1013 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1015 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1017 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1019 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1021 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1023 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1024 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1026 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1027 password associated with the terminal line used to gain access. 1028 LOCAL is a client local user database. ENABLE is a command that 1029 authenticates in order to grant new privileges. TACACSPLUS is, of 1030 course, TACACS+. GUEST is an unqualified guest authentication, such 1031 as an ARAP guest login. RADIUS is the Radius authentication 1032 protocol. RCMD refers to authentication provided via the R-command 1033 protocols from Berkeley Unix. (One should be aware of the security 1034 limitations to R-command authentication.) 1036 priv_lvl 1038 This field is used in the same way as the priv_lvl field in 1039 authentication request and is described in the Privilege Level 1040 section (Section 8) below. It indicates the users current privilege 1041 level. 1043 authen_type 1045 This field matches the authen_type field in the authentication 1046 section (Section 4) above. It indicates the type of authentication 1047 that was performed. If this information is not available, then the 1048 client should set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 1049 0x00. This value is valid only in authorization and accounting 1050 requests. 1052 authen_service 1054 This field matches the service field in the authentication section 1055 (Section 4) above. It indicates the service through which the user 1056 authenticated. 1058 user 1060 This field contains the user's account name. 1062 port 1064 This field matches the port field in the authentication section 1065 (Section 4) above. 1067 rem_addr 1069 This field matches the rem_addr field in the authentication section 1070 (Section 4) above. 1072 arg_cnt 1074 The number of authorization arguments to follow 1076 arg 1078 An attribute-value pair that describes the command to be performed. 1079 (see below) 1081 The authorization arguments in both the REQUEST and the RESPONSE are 1082 attribute-value pairs. The attribute and the value are in a single 1083 US-ASCII string and are separated by either a "=" (0X3D) or a "*" 1084 (0X2A). The equals sign indicates a mandatory argument. The 1085 asterisk indicates an optional one. 1087 It is not legal for an attribute name to contain either of the 1088 separators. It is legal for attribute values to contain the 1089 separators. 1091 Optional arguments are ones that may be disregarded by either client 1092 or server. Mandatory arguments require that the receiving side 1093 understands the attribute and will act on it. If the client receives 1094 a mandatory argument that it cannot oblige or does not understand, it 1095 MUST consider the authorization to have failed. It is legal to send 1096 an attribute-value pair with a NULL (zero length) value. 1098 Attribute-value strings are not NULL terminated, rather their length 1099 value indicates their end. The maximum length of an attribute-value 1100 string is 255 characters. the minimum is two characters (one name 1101 value and the separator) 1103 5.2. The Authorization RESPONSE Packet Body 1104 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 1105 +----------------+----------------+----------------+----------------+ 1106 | status | arg_cnt | server_msg len | 1107 +----------------+----------------+----------------+----------------+ 1108 + data len | arg 1 len | arg 2 len | 1109 +----------------+----------------+----------------+----------------+ 1110 | ... | arg N len | server_msg ... 1111 +----------------+----------------+----------------+----------------+ 1112 | data ... 1113 +----------------+----------------+----------------+----------------+ 1114 | arg 1 ... 1115 +----------------+----------------+----------------+----------------+ 1116 | arg 2 ... 1117 +----------------+----------------+----------------+----------------+ 1118 | ... 1119 +----------------+----------------+----------------+----------------+ 1120 | arg N ... 1121 +----------------+----------------+----------------+----------------+ 1123 status This field indicates the authorization status 1125 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1127 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1129 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1131 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1133 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1135 server_msg 1137 This is an US-ASCII string that may be presented to the user. The 1138 decision to present this message is client specific. 1140 data 1142 This is an US-ASCII string that may be presented on an administrative 1143 display, console or log. The decision to present this message is 1144 client specific. 1146 arg_cnt 1148 The number of authorization arguments to follow. 1150 arg 1151 An attribute-value pair that describes the command to be performed. 1152 (see below) 1154 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the 1155 appropriate action is to deny the user action. 1157 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1158 arguments specified in the request are authorized and the arguments 1159 in the response are to be used IN ADDITION to those arguments. 1161 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the 1162 arguments in the request are to be completely replaced by the 1163 arguments in the response. 1165 If the intended action is to approve the authorization with no 1166 modifications, then the status should be set to 1167 TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt should be set to 0. 1169 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1170 on the server. 1172 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1173 arg_cnt MUST be 0. In that case, the actions to be taken and the 1174 contents of the data field are identical to the 1175 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. None of the 1176 arg values have any relevance if an ERROR is set, and must be 1177 ignored. 1179 6. Accounting 1181 6.1. The Account REQUEST Packet Body 1183 TACACS+ accounting is very similar to authorization. The packet 1184 format is also similar. There is a fixed portion and an extensible 1185 portion. The extensible portion uses all the same attribute-value 1186 pairs that authorization uses, and adds several more. 1188 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 1189 +----------------+----------------+----------------+----------------+ 1190 | flags | authen_method | priv_lvl | authen_type | 1191 +----------------+----------------+----------------+----------------+ 1192 | authen_service | user len | port len | rem_addr len | 1193 +----------------+----------------+----------------+----------------+ 1194 | arg_cnt | arg 1 len | arg 2 len | ... | 1195 +----------------+----------------+----------------+----------------+ 1196 | arg N len | user ... 1197 +----------------+----------------+----------------+----------------+ 1198 | port ... 1199 +----------------+----------------+----------------+----------------+ 1200 | rem_addr ... 1201 +----------------+----------------+----------------+----------------+ 1202 | arg 1 ... 1203 +----------------+----------------+----------------+----------------+ 1204 | arg 2 ... 1205 +----------------+----------------+----------------+----------------+ 1206 | ... 1207 +----------------+----------------+----------------+----------------+ 1208 | arg N ... 1209 +----------------+----------------+----------------+----------------+ 1211 flags 1213 This holds bitmapped flags. 1215 TAC_PLUS_ACCT_FLAG_START := 0x02 1217 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1219 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1221 All other fields are defined in the authorization and authentication 1222 sections above and have the same semantics. 1224 See section 12 Accounting Attribute-value Pairs for the dictionary of 1225 attributes relevant to accounting. 1227 6.2. The Accounting REPLY Packet Body 1229 The response to an accounting message is used to indicate that the 1230 accounting function on the server has completed. The server should 1231 reply with success only when the record has been committed to the 1232 required level of security, relieving the burden on the client from 1233 ensuring any better form of accounting is required. 1235 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 1236 +----------------+----------------+----------------+----------------+ 1237 | server_msg len | data len | 1238 +----------------+----------------+----------------+----------------+ 1239 | status | server_msg ... 1240 +----------------+----------------+----------------+----------------+ 1241 | data ... 1242 +----------------+ 1244 status 1246 This is the return status. Values are: 1248 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1250 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1252 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1254 server_msg 1256 This is a US-ASCII string that may be presented to the user. The 1257 decision to present this message is client specific. 1259 data 1261 This is a US-ASCII string that may be presented on an administrative 1262 display, console or log. The decision to present this message is 1263 client specific. 1265 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1266 to be taken and the contents of the data field are identical to the 1267 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1269 The server MUST terminate the session after sending a REPLY. 1271 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1272 accounting message. Start messages should only be sent once when a 1273 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1274 a stop record and that the task has terminated. The 1275 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1276 Update records are sent at the client's discretion when the task is 1277 still running. 1279 Summary of Accounting Packets 1280 +----------+-------+-------+-------------+-------------------------+ 1281 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1282 +----------+-------+-------+-------------+-------------------------+ 1283 | 0 | 0 | 0 | 0 | INVALID | 1284 | 0 | 0 | 1 | 2 | Start Accounting Record | 1285 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1286 | 0 | 1 | 1 | 6 | INVALID | 1287 | 1 | 0 | 0 | 8 | Watchdog, no update | 1288 | 1 | 0 | 1 | A | Watchdog, with update | 1289 | 1 | 1 | 0 | C | INVALID | 1290 | 1 | 1 | 1 | E | INVALID | 1291 +----------+-------+-------+-------------+-------------------------+ 1293 The START and STOP flags are mutually exclusive. When the WATCHDOG 1294 flag is set along with the START flag, it indicates that the update 1295 record is a duplicate of the original START record. If the START 1296 flag is not set, then this indicates a minimal record indicating only 1297 that task is still running. The STOP flag MUST NOT be set in 1298 conjunction with the WATCHDOG flag. 1300 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1301 requests an INVALID option. 1303 7. Attribute-Value Pairs 1305 TACACS+ is intended to be an extensible protocol. The attributes 1306 used in Authorization and Accounting are not fixed. Some attributes 1307 are defined below for common use cases, clients MUST use these 1308 attributes when supporting the corresponding use cases. 1310 All numeric values in an attribute-value string are provided as 1311 decimal US-ASCII numbers, unless otherwise stated. 1313 All boolean attributes are encoded with values "true" or "false". 1315 It is recommended that hosts be specified as a numeric address so as 1316 to avoid any ambiguities. 1318 Absolute times should be specified in seconds since the epoch, 1319 12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone 1320 attribute is specified. 1322 Attributes may be submitted with no value, in which case they consist 1323 of the name and the mandatory or optional separator. For example, 1324 the attribute "cmd" which has no value is transmitted as a string of 1325 4 characters "cmd=" 1327 7.1. Authorization Attributes 1329 service 1331 The primary service. Specifying a service attribute indicates that 1332 this is a request for authorization or accounting of that service. 1333 Current values are "slip", "ppp", "shell", "tty-server", 1334 "connection", "system" and "firewall". This attribute MUST always be 1335 included. 1337 protocol 1339 a protocol that is a subset of a service. An example would be any 1340 PPP NCP. Currently known values are "lcp", "ip", "ipx", "atalk", 1341 "vines", "lat", "xremote", "tn3270", "telnet", "rlogin", "pad", 1342 "vpdn", "ftp", "http", "deccp", "osicp" and "unknown". 1344 cmd 1346 a shell (exec) command. This indicates the command name for a shell 1347 command that is to be run. This attribute MUST be specified if 1348 service equals "shell". If no value is present then the shell itself 1349 is being referred to. 1351 cmd-arg 1353 an argument to a shell (exec) command. This indicates an argument 1354 for the shell command that is to be run. Multiple cmd-arg attributes 1355 may be specified, and they are order dependent. 1357 acl 1359 US-ASCII number representing a connection access list. Used only 1360 when value of service is "shell"" and cmd has no value. 1362 inacl 1364 US-ASCII identifier for an interface input access list. 1366 outacl 1368 US-ASCII identifier for an interface output access list. 1370 zonelist 1372 A numeric zonelist value. (Applicable to AppleTalk only). 1374 addr 1375 a network address 1377 addr-pool 1379 The identifier of an address pool from which the client should assign 1380 an address. 1382 routing 1384 A boolean. Specifies whether routing information is to be propagated 1385 to, and accepted from this interface. 1387 route 1389 Indicates a route that is to be applied to this interface. Values 1390 MUST be of the form " []". If a 1391 is not specified, the resulting route should be via 1392 the requesting peer. 1394 timeout 1396 an absolute timer for the connection (in minutes). A value of zero 1397 indicates no timeout. 1399 idletime 1401 an idle-timeout for the connection (in minutes). A value of zero 1402 indicates no timeout. 1404 autocmd 1406 an auto-command to run. Used only when service=shell and cmd=NULL 1408 noescape 1410 Boolean. Prevents user from using an escape character. Used only 1411 when service=shell and cmd=NULL 1413 nohangup 1415 Boolean. Do not disconnect after an automatic command. Used only 1416 when service=shell and cmd=NULL 1418 priv-lvl 1420 privilege level to be assigned. Please refer to the Privilege Level 1421 section (Section 8) below. 1423 remote_user 1425 remote userid (authen_method must have the value 1426 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1427 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1428 remote_user and remote_host attributes will provide the remote user 1429 and host information to enable rhost style authorization. The 1430 response may request that a privilege level be set for the user. 1432 remote_host 1434 remote host (authen_method must have the value 1435 TAC_PLUS_AUTHEN_METH_RCMD) 1437 callback-dialstring 1439 Indicates that callback should be done. Value is NULL, or a 1440 dialstring. A NULL value indicates that the service MAY choose to 1441 get the dialstring through other means. 1443 callback-line 1445 The line number to use for a callback. 1447 callback-rotary 1449 The rotary number to use for a callback. 1451 nocallback-verify 1453 Do not require authentication after callback. 1455 7.2. Accounting Attributes 1457 The following new attributes are defined for TACACS+ accounting only. 1458 When these attribute-value pairs are included in the argument list, 1459 they should precede any attribute-value pairs that are defined in the 1460 authorization section (Section 5) above. 1462 task_id 1464 Start and stop records for the same event MUST have matching task_id 1465 attribute values. The client must not reuse a specific task_id in a 1466 start record until it has sent a stop record for that task_id. 1468 start_time 1470 The time the action started (). 1472 stop_time 1474 The time the action stopped (in seconds since the epoch.) 1476 elapsed_time 1478 The elapsed time in seconds for the action. Useful when the device 1479 does not keep real time. 1481 timezone 1483 The timezone abbreviation for all timestamps included in this packet. 1485 event 1487 Used only when "service=system". Current values are "net_acct", 1488 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1489 These indicate system level changes. The flags field SHOULD indicate 1490 whether the service started or stopped. 1492 reason 1494 Accompanies an event attribute. It describes why the event occurred. 1496 bytes 1498 The number of bytes transferred by this action 1500 bytes_in 1502 The number of input bytes transferred by this action 1504 bytes_out 1506 The number of output bytes transferred by this action 1508 paks 1510 The number of packets transferred by this action. 1512 paks_in 1514 The number of input packets transferred by this action. 1516 paks_out 1518 The number of output packets transferred by this action. 1520 status 1522 The numeric status value associated with the action. This is a 1523 signed four (4) byte word in network byte order. 0 is defined as 1524 success. Negative numbers indicate errors. Positive numbers 1525 indicate non-error failures. The exact status values may be defined 1526 by the client. 1528 err_msg 1530 An US-ASCII string describing the status of the action. 1532 8. Privilege Levels 1534 The TACACS+ Protocol supports flexible authorization schemes through 1535 the extensible attributes. One scheme is built in to the protocol: 1536 Privilege Levels. Privilege Levels are ordered values from 0 to 15 1537 with each level representing a privilege level that is a superset of 1538 the next lower value. Pre-defined values are: 1540 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1542 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1544 TAC_PLUS_PRIV_LVL_USER := 0x01 1546 TAC_PLUS_PRIV_LVL_MIN := 0x00 1548 If a client uses a different privilege level scheme, then it must map 1549 the privilege level to scheme above. 1551 Privilege Levels are applied in two ways in the TACACS+ protocol: 1553 - As an argument in authorization EXEC phase (when service=shell 1554 and cmd=NULL), where it is primarily used to set the initial 1555 privilege level for the EXEC session. 1557 - In the packet headers for Authentication, Authorization and 1558 Accounting. The privilege level in the header is primarily 1559 significant in the Authentication phase for enable authentication 1560 where a different privilege level is required. 1562 The use of Privilege levels to determine session-based access to 1563 commands and resources is not mandatory for clients, but it is in 1564 common use so SHOULD be supported by servers. 1566 9. References 1568 [TheDraft] 1569 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 1570 1.78", June 1997, . 1573 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1574 April 1992. 1576 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1577 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1578 . 1580 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1581 "Randomness Recommendations for Security", RFC 1750, 1582 DOI 10.17487/RFC1750, December 1994, 1583 . 1585 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1586 RFC 2433, DOI 10.17487/RFC2433, October 1998, 1587 . 1589 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1590 RFC 2759, DOI 10.17487/RFC2759, January 2000, 1591 . 1593 Authors' Addresses 1595 Thorsten Dahm 1596 Google Inc 1597 1600 Amphitheatre Parkway 1598 Mountain View, CA 94043 1599 US 1601 EMail: thorstendlux@google.com 1603 Andrej Ota 1604 Google Inc 1605 1600 Amphitheatre Parkway 1606 Mountain View, CA 94043 1607 US 1609 EMail: aota@google.com 1610 Douglas C. Medway Gash 1611 Cisco Systems, Inc. 1612 170 West Tasman Dr. 1613 San Jose, CA 95134 1614 US 1616 Phone: +44 0208 8244508 1617 EMail: dcmgash@cisco.com 1619 David Carrel 1620 vIPtela, Inc. 1621 1732 North First St. 1622 San Jose, CA 95112 1623 US 1625 EMail: dcarrel@viptela.com 1627 Lol Grant