idnits 2.17.1 draft-ietf-opsawg-tacacs-04.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 262: '... client MUST NOT send a second packe...' RFC 2119 keyword, line 273: '... The flag MUST be ignored after thes...' RFC 2119 keyword, line 278: '...established, multiple sessions MUST be...' RFC 2119 keyword, line 328: '...ket in a session MUST have the sequenc...' RFC 2119 keyword, line 379: '...ta fields which are unused MUST have a...' (51 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 (July 8, 2016) is 2848 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: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations T. Dahm 3 Internet-Draft A. Ota 4 Intended status: Informational Google Inc 5 Expires: January 9, 2017 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 8 vIPtela, Inc. 9 L. Grant 10 July 8, 2016 12 The TACACS+ Protocol 13 draft-ietf-opsawg-tacacs-04 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 January 9, 2017. 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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 8 77 3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.7. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 11 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 The TACACS+ protocol separates the functions of Authentication, 125 Authorization and Accounting. It allows for arbitrary length and 126 content authentication exchanges, which will support any 127 authentication mechanism to be utilized with TACACS+ clients. It is 128 extensible to provide for site customization and future development 129 features, and it uses TCP to ensure reliable delivery. The protocol 130 allows the TACACS+ client to request very fine-grained access control 131 and allows the server to respond to each component of that request. 133 The separation of authentication, authorization and accounting is a 134 fundamental component of the design of TACACS+. The distinction 135 between them is very important so this document will address each one 136 separately. It is important to note that TACACS+ provides for all 137 three, but an implementation or configuration is not required to 138 employ all three. Each one serves a unique purpose that alone is 139 useful, and together can be quite powerful. 141 This document restricts itself to a description of the protocol that 142 is used by TACACS+. It does not cover deployment or best practices. 144 2. Technical Definitions 146 This section provides a few basic definitions that are applicable to 147 this document 149 Authentication 151 Authentication is the action of determining who a user (or entity) 152 is. Authentication can take many forms. Traditional authentication 153 utilizes a name and a fixed password. However, fixed passwords have 154 limitations, mainly in the area of security. Many modern 155 authentication mechanisms utilize "one-time" passwords or a 156 challenge-response query. TACACS+ is designed to support all of 157 these, and should be powerful enough to handle any future mechanisms. 158 Authentication generally takes place when the user first logs in to a 159 machine or requests a service of it. 161 Authentication is not mandatory; it is a site-configured option. 162 Some sites do not require it. Others require it only for certain 163 services (see authorization below). Authentication may also take 164 place when a user attempts to gain extra privileges, and must 165 identify himself or herself as someone who possesses the required 166 information (passwords, etc.) for those privileges. 168 Authorization 170 It is important to distinguish Authorization from Authentication. 171 Authorization is the action of determining what a user is allowed to 172 do. Generally authentication precedes authorization, but again, this 173 is not required. An authorization request may indicate that the user 174 is not authenticated (we don't know who they are). In this case it 175 is up to the authorization agent to determine if an unauthenticated 176 user is allowed the services in question. 178 In TACACS+, authorization does not merely provide yes or no answers, 179 but it may also customize the service for the particular user. 180 Examples of when authorization would be performed are: When a user 181 first logs in and wants to start a shell, or when a user starts PPP 182 and wants to use IP over PPP with a particular IP address. The 183 TACACS+ server might respond to these requests by allowing the 184 service, but placing a time restriction on the login shell, or by 185 requiring IP access lists on the PPP connection. For a list of 186 authorization attributes, see the authorization section (Section 5) . 188 Accounting 190 Accounting is typically the third action after authentication and 191 authorization. But again, neither authentication nor authorization 192 is required. Accounting is the action of recording what a user is 193 doing, and/or has done. Accounting in TACACS+ can serve two 194 purposes: It may be used as an auditing tool for security services. 195 It may also be used to account for services used, such as in a 196 billing environment. To this end, TACACS+ supports three types of 197 accounting records. Start records indicate that a service is about 198 to begin. Stop records indicate that a service has just terminated, 199 and Update records are intermediate notices that indicate that a 200 service is still being performed. TACACS+ accounting records contain 201 all the information used in the authorization records, and also 202 contain accounting specific information such as start and stop times 203 (when appropriate) and resource usage information. A list of 204 accounting attributes is defined in the accounting section 205 (Section 6) . 207 Client 209 The client is any device, (often a Network Access Server) that 210 provides access services. The clients usually provide a character 211 mode front end and then allow the user to telnet or rlogin to another 212 host. A client may also support protocol based access services. 214 Server 216 The server receives TACACS+ protocol requests, and replies according 217 to its business model, in accordance with the flows defined in this 218 document. 220 Packet 222 All uses of the word packet in this document refer to TACACS+ 223 protocol packets unless explicitly noted otherwise. 225 3. TACACS+ Connections and Sessions 227 3.1. Connection 229 TACACS+ uses TCP for its transport. Server port 49 is allocated for 230 TACACS+ traffic. 232 3.1.1. Security Considerations 234 The protocol includes an obfuscation mechanism referred to in the 235 original draft as Body Encryption. It is intended to follow up this 236 document with enhancements to TACACS+ security. 238 It is recommended to separate the management traffic from the regular 239 network access traffic, and to use Body Encryption in production 240 environments. 242 3.2. Session 244 The concept of a session is used throughout this document. A TACACS+ 245 session is a single authentication sequence, a single authorization 246 exchange, or a single accounting exchange. 248 An accounting and authorization session will consist of a single pair 249 of packets (the request and its reply). An authentication session 250 may involve an arbitrary number of packets being exchanged. The 251 session is an operational concept that is maintained between the 252 TACACS+ client and server. It does not necessarily correspond to a 253 given user or user action. 255 3.3. Single Connect Mode 257 The packet header (see below) contains a flag to allow sessions to be 258 multiplexed on a connection. 260 If a client sets this flag, this indicates that it supports 261 multiplexing TACACS+ sessions over a single TCP connection. The 262 client MUST NOT send a second packet on a connection until single- 263 connect status has been established. 265 If the server sets this flag in the first reply packet in response to 266 the first packet from a client, this indicates its willingness to 267 support single-connection over the current connection. The server 268 may set this flag even if the client does not set it, but the client 269 is under no obligation to honor it. 271 The flag is only relevant for the first two packets on a connection, 272 to allow the client and server to establish single connection mode. 273 The flag MUST be ignored after these two packets since the single- 274 connect status of a connection, once established, must not be 275 changed. The connection must instead be closed and a new connection 276 opened, if required. 278 When single-connect status is established, multiple sessions MUST be 279 allowed simultaneously and/or consecutively on a single TCP 280 connection. If single-connect status has not been established in the 281 first two packets of a TCP connection, then the connection must be 282 closed at the end of the first session. 284 3.4. The TACACS+ Packet Header 286 All TACACS+ packets begin with the following 12 byte header. The 287 header describes the remainder of the packet: 289 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 290 +----------------+----------------+----------------+----------------+ 291 |major | minor | | | | 292 |version| version| type | seq_no | flags | 293 +----------------+----------------+----------------+----------------+ 294 | | 295 | session_id | 296 +----------------+----------------+----------------+----------------+ 297 | | 298 | length | 299 +----------------+----------------+----------------+----------------+ 301 major_version 303 This is the major TACACS+ version number. 305 TAC_PLUS_MAJOR_VER := 0xc 307 minor_version 309 The minor TACACS+ version number. 311 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 313 TAC_PLUS_MINOR_VER_ONE := 0x1 315 type 317 This is the packet type. Legal values are: 319 TAC_PLUS_AUTHEN := 0x01 (Authentication) 321 TAC_PLUS_AUTHOR := 0x02 (Authorization) 323 TAC_PLUS_ACCT := 0x03 (Accounting) 325 seq_no 327 This is the sequence number of the current packet for the current 328 session. The first packet in a session MUST have the sequence number 329 1 and each subsequent packet will increment the sequence number by 330 one. Thus clients only send packets containing odd sequence numbers, 331 and TACACS+ servers only send packets containing even sequence 332 numbers. 334 The sequence number must never wrap i.e. if the sequence number 2^8-1 335 is ever reached, that session must terminate and be restarted with a 336 sequence number of 1. 338 flags 340 This field contains various bitmapped flags. 342 The unencrypted flag bit says whether encryption is being used on the 343 body of the packet (the entire portion after the header). 345 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 347 If this flag is set, then body encryption is not used. If this flag 348 is cleared, the packet is encrypted. Unencrypted packets are 349 intended for testing, and are not recommended for normal use. 351 The single-connection flag: 353 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 355 This flag is used to allow a client and server to agree whether 356 multiple sessions may be multiplexed onto a single connection. 358 session_id 360 The Id for this TACACS+ session. The session id should be randomly 361 chosen. This field does not change for the duration of the TACACS+ 362 session. (If this value is not a cryptographically strong random 363 number, it will compromise the protocol's security, see RFC 1750 364 [RFC1750] ) 366 length 368 The total length of the packet body (not including the header). This 369 value is in network byte order. Packets are never padded beyond this 370 length. 372 3.5. The TACACS+ Packet Body 374 The TACACS+ body types are defined in the packet header. The 375 remainder of this document will address the contents of the different 376 TACACS+ bodies. The following general rules apply to all TACACS+ 377 body types: 379 - Any variable length data fields which are unused MUST have a 380 length value equal to zero. 382 - Unused fixed length fields SHOULD have values of zero. 384 - All data and message fields in a packet MUST NOT be null 385 terminated. 387 - All length values are unsigned and in network byte order. 389 - There should be no padding in any of the fields or at the end of 390 a packet. 392 3.6. Encryption 394 The body of packets may be encrypted. The following sections 395 describe the encryption mechanism that is supported to enable 396 backwards compatibility with 'The Draft'. 398 When the encryption mechanism relies on a secret key, it is referring 399 to a shared secret value that is known to both the client and the 400 server. This document does not discuss the management and storage of 401 those keys. It is an implementation detail of the server and client, 402 as to whether they will maintain only one key, or a different key for 403 each client or server with which they communicate. For security 404 reasons, the latter options should be available, but it is a site 405 dependent decision as to whether the use of separate keys is 406 appropriate. 408 The encrypted flag field may be set as follows: 410 TAC_PLUS_UNENCRYPTED_FLAG == 0x0 412 In this case, the packet body is encrypted by XOR-ing it byte-wise 413 with a pseudo random pad. 415 ENCRYPTED {data} == data ^ pseudo_pad 417 The pad is generated by concatenating a series of MD5 hashes (each 16 418 bytes long) and truncating it to the length of the input data. 420 Whenever used in this document, MD5 refers to the "RSA Data Security, 421 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 422 . 424 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 425 The first MD5 hash is generated by concatenating the session_id, the 426 secret key, the version number and the sequence number and then 427 running MD5 over that stream. All of those input values are 428 available in the packet header, except for the secret key which is a 429 shared secret between the TACACS+ client and server. 431 The version number is the one byte concatenation of the major and 432 minor version numbers. 434 The session id is used in network byte order. 436 Subsequent hashes are generated by using the same input stream, but 437 concatenating the previous hash value at the end of the input stream. 439 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 440 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 441 version, seq_no, MD5_n-1} 443 When a server detects that the secret(s) it has configured for the 444 device mismatch, it MUST return ERROR. The handling of the TCP 445 connection by the server is implementation independent. 447 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 449 In this case, the entire packet body is in cleartext. Encryption and 450 decryption are null operations. This method should only be used for 451 debugging. It does not provide data protection or authentication and 452 is highly susceptible to packet spoofing. Implementing this 453 encryption method is optional. 455 NOTE: Implementations should take care not to skip decryption simply 456 because an incoming packet indicates that it is not encrypted. If 457 the unencrypted flag is not set, and the packet is not encrypted, it 458 must be dropped. 460 After a packet body is decrypted, the lengths of the component values 461 in the packet should be summed and checked against the cleartext 462 datalength value from the header. Any packets which fail this check 463 should be discarded and an error signalled. Commonly such failures 464 may be expected to be seen when there are mismatched keys between the 465 client and the TACACS+ server. 467 If an error must be declared but the type of the incoming packet 468 cannot be determined, a packet with the identical cleartext header 469 but with a sequence number incremented by one and the length set to 470 zero MUST be returned to indicate an error. 472 3.7. Text Encoding 474 All text fields in TACACS+ MUST be US-ASCII, excepting special 475 consideration given to user field and data fields used for passwords. 477 To ensure interoperability of current deployments, the TACACS+ client 478 and server MUST handle user field and data fields used for passwords 479 as 8 bit octet strings. The deployment operator MUST ensure that 480 consistent character encoding is applied. The encoding SHOULD be 481 UTF-8, and other encodings outside US-ASCII SHOULD be deprecated. 483 4. Authentication 485 4.1. The Authentication START Packet Body 487 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 488 +----------------+----------------+----------------+----------------+ 489 | action | priv_lvl | authen_type | authen_service | 490 +----------------+----------------+----------------+----------------+ 491 | user len | port len | rem_addr len | data len | 492 +----------------+----------------+----------------+----------------+ 493 | user ... 494 +----------------+----------------+----------------+----------------+ 495 | port ... 496 +----------------+----------------+----------------+----------------+ 497 | rem_addr ... 498 +----------------+----------------+----------------+----------------+ 499 | data... 500 +----------------+----------------+----------------+----------------+ 502 Packet fields are as follows: 504 action 506 This describes the authentication action to be performed. Legal 507 values are: 509 TAC_PLUS_AUTHEN_LOGIN := 0x01 511 TAC_PLUS_AUTHEN_CHPASS := 0x02 513 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 515 priv_lvl 517 This indicates the privilege level that the user is authenticating 518 as. Please refer to the Privilege Level section (Section 8) below. 520 authen_type 522 The type of authentication that is being performed. Legal values 523 are: 525 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 527 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 529 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 531 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 533 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 535 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 537 authen_service 539 This is the service that is requesting the authentication. Legal 540 values are: 542 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 544 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 546 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 548 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 550 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 552 TAC_PLUS_AUTHEN_SVC_PT := 0x05 554 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 556 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 558 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 560 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 562 The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization 563 application of this field that indicates that no authentication was 564 performed by the device. 566 The TAC_PLUS_AUTHEN_SVC_LOGIN option is identifies regular login (as 567 opposed to ENABLE) to a client device. 569 The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE service, 570 which refers to a service requesting authentication in order to grant 571 the user different privileges. This is comparable to the Unix 572 "su(1)" command. A service value of NONE should only be used when 573 none of the other service values are appropriate. ENABLE may be 574 requested independently, no requirements for previous authentications 575 or authorizations are imposed by the protocol. 577 Other options are included for legacy/backwards compatibility. 579 user 581 The username. It is optional in this packet, depending upon the 582 class of authentication. 584 port 586 The US-ASCII name of the client port on which the authentication is 587 taking place. The value of this field is client specific. (For 588 example, Cisco uses "tty10" to denote the tenth tty line and 589 "Async10" to denote the tenth async interface). 591 rem_addr 593 An US-ASCII string this is a "best effort" description of the remote 594 location from which the user has connected to the client. It is 595 intended to hold a network address if the user is connected via a 596 network, a caller ID is the user is connected via ISDN or a POTS, or 597 any other remote location information that is available. This field 598 is optional (since the information may not be available). 600 data 602 This field is used to send data appropriate for the action and 603 authen_type. It is described in more detail in the section Common 604 Authentication flows (Section 4.4.2) . 606 4.2. The Authentication REPLY Packet Body 608 The TACACS+ server sends only one type of authentication packet (a 609 REPLY packet) to the client. The REPLY packet body looks as follows: 611 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 612 +----------------+----------------+----------------+----------------+ 613 | status | flags | server_msg len | 614 +----------------+----------------+----------------+----------------+ 615 | data len | server_msg ... 616 +----------------+----------------+----------------+----------------+ 617 | data ... 618 +----------------+----------------+ 620 status 622 The current status of the authentication. Legal values are: 624 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 626 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 628 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 630 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 632 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 634 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 636 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 638 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 640 flags 642 Bitmapped flags that modify the action to be taken. The following 643 values are defined: 645 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 647 server_msg 649 c A message to be displayed to the user. This field is optional. If 650 it exists, it is intended to be presented to the user. US-ASCII 651 charset must be used. 653 data 655 This field holds data that is a part of the authentication exchange 656 and is intended for the client, not the user. It is described in 657 more detail in the section Common Authentication flows 658 (Section 4.4.2) . 660 4.3. The Authentication CONTINUE Packet Body 662 This packet is sent from the client to the server following the 663 receipt of a REPLY packet. 665 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 666 +----------------+----------------+----------------+----------------+ 667 | user_msg len | data len | 668 +----------------+----------------+----------------+----------------+ 669 | flags | user_msg ... 670 +----------------+----------------+----------------+----------------+ 671 | data ... 672 +----------------+ 674 user_msg 676 This field is the string that the user entered, or the client 677 provided on behalf of the user, in response to the server_msg from a 678 REPLY packet. 680 data 682 This field carries information that is specific to the action and the 683 authen_type for this session. Valid uses of this field are described 684 below. 686 flags 688 This holds the bitmapped flags that modify the action to be taken. 689 The following values are defined: 691 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 693 4.4. Description of Authentication Process 695 The action, authen_type and service fields (described above) combine 696 to determine what kind of authentication is to be performed Every 697 authentication START, REPLY and CONTINUE packet includes a data 698 field. The use of this field is dependent upon the kind of the 699 Authentication. 701 A set of standard kinds of authentication is defined in this 702 document. Each authentication flow consists of a START packet. The 703 server responds either with a request for more information (GETDATA, 704 GETUSER or GETPASS) or a termination (PASS or FAIL). The actions and 705 meanings when the server sends a RESTART, ERROR or FOLLOW are common 706 and are described further below. 708 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 709 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 710 then authentication continues and the SHOULD provide server_msg 711 content for the client to prompt the user for more information. The 712 client MUST then return a CONTINUE packet containing the requested 713 information in the user_msg field. 715 All three cause the same action to be performed, but the use of 716 TAC_PLUS_AUTHEN_STATUS_GETUSER, indicates to the client that the user 717 response will be interpreted as a username, and for 718 TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents 719 will be interpreted as a password. TAC_PLUS_AUTHEN_STATUS_GETDATA is 720 the generic request for more information to flexibly support future 721 requirements. If the TAC_PLUS_REPLY_FLAG_NOECHO flag is set in the 722 REPLY, then the user response must not be echoed as it is entered. 723 The data field is only used in the REPLY where explicitly defined 724 below. 726 4.4.1. Version Behaviour 728 The TACACS+ protocol is versioned to allow revisions while 729 maintaining backwards compatibility. The version number is in every 730 packet header. The changes between minor_version 0 and 1 apply only 731 to the authentication process, and all deal with the way that CHAP 732 and PAP authentications are handled. minor_version 1 may only be used 733 for authentication kinds that explicitly call for it in the table 734 below: 736 LOGIN CHPASS SENDAUTH 737 ASCII v0 v0 - 738 PAP v1 - v1 739 CHAP v1 - v1 740 MS-CHAPv1/2 v1 - v1 742 The '-' symbol represents that the option is not valid. 744 When a server receives a packet with a minor_version that it does not 745 support, it should return an ERROR status with the minor_version set 746 to the closest supported value. 748 In minor_version 0, Inbound PAP performed a normal LOGIN, sending the 749 username in the START packet and then waiting for a GETPASS and 750 sending the password in a CONTINUE packet. 752 In minor_version 1, CHAP and inbound PAP use LOGIN to perform inbound 753 authentication and the exchanges use the data field so that the 754 client only sends a single START packet and expects to receive a PASS 755 or FAIL. SENDAUTH is only used for PPP when performing outbound 756 authentication. 758 NOTE: Only those requests which have changed from their minor_version 759 0 implementation (i.e. CHAP, MS-CHAP and PAP authentications) should 760 use the new minor_version number of 1. All other requests (i.e. all 761 authorisation and accounting and ASCII authentication) MUST continue 762 to use the same minor_version number of 0. The removal of SENDPASS 763 was prompted by security concerns, and is no longer considered part 764 of the TACACS+ protocol. 766 4.4.2. Common Authentication Flows 768 This section describes common authentication flows. If the options 769 are implemented, they MUST follow the description. If the server 770 does not implement an option, it should respond with 771 TAC_PLUS_AUTHEN_STATUS_ERROR. 773 Inbound ASCII Login 775 action = TAC_PLUS_AUTHEN_LOGIN 776 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 777 minor_version = 0x0 779 This is a standard ASCII authentication. The START packet may 780 contain the username, but need not do so. The data fields in both 781 the START and CONTINUE packets are not used for ASCII logins. There 782 is a single START followed by zero or more pairs of REPLYs and 783 CONTINUEs, followed by a terminating REPLY (PASS or FAIL). 785 Inbound PAP Login 787 action = TAC_PLUS_AUTHEN_LOGIN 788 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 789 minor_version = 0x1 791 The entire exchange MUST consist of a single START packet and a 792 single REPLY. The START packet MUST contain a username and the data 793 field MUST contain the PAP ASCII password. A PAP authentication only 794 consists of a username and password RFC 1334 [RFC1334] . The REPLY 795 from the server MUST be either a PASS or FAIL. 797 Inbound CHAP login 798 action = TAC_PLUS_AUTHEN_LOGIN 799 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 800 minor_version = 0x1 802 The entire exchange MUST consist of a single START packet and a 803 single REPLY. The START packet MUST contain the username in the user 804 field and the data field will be a concatenation of the PPP id, the 805 challenge and the response. 807 The length of the challenge value can be determined from the length 808 of the data field minus the length of the id (always 1 octet) and the 809 length of the response field (always 16 octets). 811 To perform the authentication, the server will run MD5 over the id, 812 the user's secret and the challenge, as defined in the PPP 813 Authentication RFC RFC 1334 [RFC1334] and then compare that value 814 with the response. The REPLY from the server MUST be a PASS or FAIL. 816 Inbound MS-CHAP v1 login 818 action = TAC_PLUS_AUTHEN_LOGIN 819 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 820 minor_version = 0x1 822 The entire exchange MUST consist of a single START packet and a 823 single REPLY. The START packet MUST contain the username in the user 824 field and the data field will be a concatenation of the PPP id, the 825 MS-CHAP challenge and the MS-CHAP response. 827 The length of the challenge value can be determined from the length 828 of the data field minus the length of the id (always 1 octet) and the 829 length of the response field (always 49 octets). 831 To perform the authentication, the server will use a combination of 832 MD4 and DES on the user's secret and the challenge, as defined in RFC 833 2433 [RFC2433] and then compare the resulting value with the 834 response. The REPLY from the server MUST be a PASS or FAIL. 836 For best practices, please refer to RFC 2433 [RFC2433] 838 Inbound MS-CHAP v2 login 840 action = TAC_PLUS_AUTHEN_LOGIN 841 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 842 minor_version = 0x1 844 The entire exchange MUST consist of a single START packet and a 845 single REPLY. The START packet MUST contain the username in the user 846 field and the data field will be a concatenation of the PPP id, the 847 MS-CHAP challenge and the MS-CHAP response. 849 The length of the challenge value can be determined from the length 850 of the data field minus the length of the id (always 1 octet) and the 851 length of the response field (always 49 octets). 853 To perform the authentication, the server will use a the algorithm 854 specified RFC2759 [RFC2759] on the user's secret and challenge and 855 then compare the resulting value with the response. The REPLY from 856 the server MUST be a PASS or FAIL. 858 For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] 860 Enable Requests 862 action = TAC_PLUS_AUTHEN_LOGIN 863 priv_lvl = implementation dependent 864 authen_type = not used 865 service = TAC_PLUS_AUTHEN_SVC_ENABLE 867 This is an ENABLE request, used to change the current running 868 privilege level of a principal. The exchange MAY consist of multiple 869 messages while the server collects the information it requires in 870 order to allow changing the principal's privilege level. This 871 exchange is very similar to an Inbound ASCII login. 873 In order to readily distinguish enable requests from other types of 874 request, the value of the service field MUST be set to 875 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 876 set to this value when requesting any other operation. 878 ASCII change password request 880 action = TAC_PLUS_AUTHEN_CHPASS 881 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 883 This exchange consists of multiple messages while the server collects 884 the information it requires in order to change the user's password. 885 It is very similar to an ASCII login. The status value 886 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 887 "new" password. It MAY be sent multiple times. When requesting the 888 "old" password, the status value MUST be set to 889 TAC_PLUS_AUTHEN_STATUS_GETDATA. 891 4.4.3. Aborting an Authentication Session 893 The client may prematurely terminate a session by setting the 894 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 895 flag is set, the data portion of the message may contain an ASCII 896 message explaining the reason for the abort. The session is 897 terminated and no REPLY message is sent. 899 There are three other possible return status values that can be used 900 in a REPLY packet. These can be sent regardless of the action or 901 authen_type. Each of these indicates that the TACACS+ authentication 902 session should be terminated. In each case, the server_msg may 903 contain a message to be displayed to the user. 905 When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet 906 indicates that the TACACS+ server requests that authentication should 907 be performed with an alternate server. The data field MUST contain 908 ASCII text describing one or more servers. A server description 909 appears like this: 911 [@@]>[@] 913 If more than one host is specified, they MUST be separated into rows 914 by an ASCII Carriage Return (0x0D). 916 The protocol and key are optional, and apply only to host in the same 917 row. The protocol can describe an alternate way of performing the 918 authentication, other than TACACS+. If the protocol is not present, 919 then TACACS+ is assumed. 921 Protocols are ASCII numbers corresponding to the methods listed in 922 the authen_method field of authorization packets (defined below). 923 The host is specified as either a fully qualified domain name, or an 924 ASCII numeric IPV4 address specified as octets separated by dots 925 ('.'), or IPV6 adress test representation defined in RFC 4291. 927 If a key is supplied, the client MAY use the key in order to 928 authenticate to that host. The client may use a preconfigured key 929 for the host if it has one. If not then the client may communicate 930 with the host using unencrypted option. 932 Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the 933 discretion of the TACACS+ client. It may choose to use any one, all 934 or none of these hosts. If it chooses to use none, then it MUST 935 treat the authentication as if the return status was 936 TAC_PLUS_AUTHEN_STATUS_FAIL. 938 While the order of hosts in this packet indicates a preference, but 939 the client is not obliged to use that ordering. 941 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 942 indicating that it is experiencing an unrecoverable error and the 943 authentication should proceed as if that host could not be contacted. 944 The data field may contain a message to be printed on an 945 administrative console or log. 947 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 948 authentication sequence should be restarted with a new START packet 949 from the client. This REPLY packet indicates that the current 950 authen_type value (as specified in the START packet) is not 951 acceptable for this session, but that others may be. 953 If a client chooses not to accept the TAC_PLUS_AUTHEN_STATUS_RESTART 954 packet, then it should be TREATED as if the status was 955 TAC_PLUS_AUTHEN_STATUS_FAIL. 957 5. Authorization 959 This part of the TACACS+ protocol provides an extensible way of 960 providing remote authorization services. An authorization session is 961 defined as a single pair of messages, a REQUEST followed by a 962 RESPONSE. 964 The authorization REQUEST message contains a fixed set of fields that 965 indicate how the user was authenticated or processed and a variable 966 set of arguments that describe the services and options for which 967 authorization is requested. 969 The RESPONSE contains a variable set of response arguments 970 (attribute-value pairs) that can restrict or modify the clients 971 actions. 973 The arguments in both a REQUEST and a RESPONSE can be specified as 974 either mandatory or optional. An optional argument is one that may 975 or may not be used, modified or even understood by the recipient. 977 A mandatory argument MUST be both understood and used. This allows 978 for extending the attribute list while providing secure backwards 979 compatibility. 981 5.1. The Authorization REQUEST Packet Body 982 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 983 +----------------+----------------+----------------+----------------+ 984 | authen_method | priv_lvl | authen_type | authen_service | 985 +----------------+----------------+----------------+----------------+ 986 | user len | port len | rem_addr len | arg_cnt | 987 +----------------+----------------+----------------+----------------+ 988 | arg 1 len | arg 2 len | ... | arg N len | 989 +----------------+----------------+----------------+----------------+ 990 | user ... 991 +----------------+----------------+----------------+----------------+ 992 | port ... 993 +----------------+----------------+----------------+----------------+ 994 | rem_addr ... 995 +----------------+----------------+----------------+----------------+ 996 | arg 1 ... 997 +----------------+----------------+----------------+----------------+ 998 | arg 2 ... 999 +----------------+----------------+----------------+----------------+ 1000 | ... 1001 +----------------+----------------+----------------+----------------+ 1002 | arg N ... 1003 +----------------+----------------+----------------+----------------+ 1005 authen_method 1007 This indicates the authentication method used by the client to 1008 acquire the user information. 1010 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1012 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1014 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1016 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1018 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1020 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1022 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1024 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1026 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1028 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1029 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1031 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1032 password associated with the terminal line used to gain access. 1033 LOCAL is a client local user database. ENABLE is a command that 1034 authenticates in order to grant new privileges. TACACSPLUS is, of 1035 course, TACACS+. GUEST is an unqualified guest authentication, such 1036 as an ARAP guest login. RADIUS is the Radius authentication 1037 protocol. RCMD refers to authentication provided via the R-command 1038 protocols from Berkeley Unix. (One should be aware of the security 1039 limitations to R-command authentication.) 1041 priv_lvl 1043 This field is used in the same way as the priv_lvl field in 1044 authentication request and is described in the Privilege Level 1045 section (Section 8) below. It indicates the users current privilege 1046 level. 1048 authen_type 1050 This field matches the authen_type field in the authentication 1051 section (Section 4) above. It indicates the type of authentication 1052 that was performed. If this information is not available, then the 1053 client should set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 1054 0x00. This value is valid only in authorization and accounting 1055 requests. 1057 authen_service 1059 This field matches the service field in the authentication section 1060 (Section 4) above. It indicates the service through which the user 1061 authenticated. 1063 user 1065 This field contains the user's account name. 1067 port 1069 This field matches the port field in the authentication section 1070 (Section 4) above. 1072 rem_addr 1074 This field matches the rem_addr field in the authentication section 1075 (Section 4) above. 1077 arg_cnt 1079 The number of authorization arguments to follow 1081 arg 1083 An attribute-value pair that describes the command to be performed. 1084 (see below) 1086 The authorization arguments in both the REQUEST and the RESPONSE are 1087 attribute-value pairs. The attribute and the value are in a single 1088 US-ASCII string and are separated by either a "=" (0X3D) or a "*" 1089 (0X2A). The equals sign indicates a mandatory argument. The 1090 asterisk indicates an optional one. 1092 It is not legal for an attribute name to contain either of the 1093 separators. It is legal for attribute values to contain the 1094 separators. 1096 Optional arguments are ones that may be disregarded by either client 1097 or server. Mandatory arguments require that the receiving side 1098 understands the attribute and will act on it. If the client receives 1099 a mandatory argument that it cannot oblige or does not understand, it 1100 MUST consider the authorization to have failed. It is legal to send 1101 an attribute-value pair with a NULL (zero length) value. 1103 Attribute-value strings are not NULL terminated, rather their length 1104 value indicates their end. The maximum length of an attribute-value 1105 string is 255 characters. the minimum is two characters (one name 1106 value and the separator) 1108 5.2. The Authorization RESPONSE Packet Body 1109 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 1110 +----------------+----------------+----------------+----------------+ 1111 | status | arg_cnt | server_msg len | 1112 +----------------+----------------+----------------+----------------+ 1113 + data len | arg 1 len | arg 2 len | 1114 +----------------+----------------+----------------+----------------+ 1115 | ... | arg N len | server_msg ... 1116 +----------------+----------------+----------------+----------------+ 1117 | data ... 1118 +----------------+----------------+----------------+----------------+ 1119 | arg 1 ... 1120 +----------------+----------------+----------------+----------------+ 1121 | arg 2 ... 1122 +----------------+----------------+----------------+----------------+ 1123 | ... 1124 +----------------+----------------+----------------+----------------+ 1125 | arg N ... 1126 +----------------+----------------+----------------+----------------+ 1128 status This field indicates the authorization status 1130 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1132 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1134 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1136 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1138 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1140 server_msg 1142 This is an US-ASCII string that may be presented to the user. The 1143 decision to present this message is client specific. 1145 data 1147 This is an US-ASCII string that may be presented on an administrative 1148 display, console or log. The decision to present this message is 1149 client specific. 1151 arg_cnt 1153 The number of authorization arguments to follow. 1155 arg 1156 An attribute-value pair that describes the command to be performed. 1157 (see below) 1159 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the 1160 appropriate action is to deny the user action. 1162 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1163 arguments specified in the request are authorized and the arguments 1164 in the response are to be used IN ADDITION to those arguments. 1166 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the 1167 arguments in the request are to be completely replaced by the 1168 arguments in the response. 1170 If the intended action is to approve the authorization with no 1171 modifications, then the status should be set to 1172 TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt should be set to 0. 1174 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1175 on the server. 1177 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1178 arg_cnt MUST be 0. In that case, the actions to be taken and the 1179 contents of the data field are identical to the 1180 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. None of the 1181 arg values have any relevance if an ERROR is set, and must be 1182 ignored. 1184 6. Accounting 1186 6.1. The Account REQUEST Packet Body 1188 TACACS+ accounting is very similar to authorization. The packet 1189 format is also similar. There is a fixed portion and an extensible 1190 portion. The extensible portion uses all the same attribute-value 1191 pairs that authorization uses, and adds several more. 1193 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 1194 +----------------+----------------+----------------+----------------+ 1195 | flags | authen_method | priv_lvl | authen_type | 1196 +----------------+----------------+----------------+----------------+ 1197 | authen_service | user len | port len | rem_addr len | 1198 +----------------+----------------+----------------+----------------+ 1199 | arg_cnt | arg 1 len | arg 2 len | ... | 1200 +----------------+----------------+----------------+----------------+ 1201 | arg N len | user ... 1202 +----------------+----------------+----------------+----------------+ 1203 | port ... 1204 +----------------+----------------+----------------+----------------+ 1205 | rem_addr ... 1206 +----------------+----------------+----------------+----------------+ 1207 | arg 1 ... 1208 +----------------+----------------+----------------+----------------+ 1209 | arg 2 ... 1210 +----------------+----------------+----------------+----------------+ 1211 | ... 1212 +----------------+----------------+----------------+----------------+ 1213 | arg N ... 1214 +----------------+----------------+----------------+----------------+ 1216 flags 1218 This holds bitmapped flags. 1220 TAC_PLUS_ACCT_FLAG_START := 0x02 1222 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1224 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1226 All other fields are defined in the authorization and authentication 1227 sections above and have the same semantics. 1229 See section 12 Accounting Attribute-value Pairs for the dictionary of 1230 attributes relevant to accounting. 1232 6.2. The Accounting REPLY Packet Body 1234 The response to an accounting message is used to indicate that the 1235 accounting function on the server has completed. The server should 1236 reply with success only when the record has been committed to the 1237 required level of security, relieving the burden on the client from 1238 ensuring any better form of accounting is required. 1240 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 1241 +----------------+----------------+----------------+----------------+ 1242 | server_msg len | data len | 1243 +----------------+----------------+----------------+----------------+ 1244 | status | server_msg ... 1245 +----------------+----------------+----------------+----------------+ 1246 | data ... 1247 +----------------+ 1249 status 1251 This is the return status. Values are: 1253 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1255 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1257 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1259 server_msg 1261 This is a US-ASCII string that may be presented to the user. The 1262 decision to present this message is client specific. 1264 data 1266 This is a US-ASCII string that may be presented on an administrative 1267 display, console or log. The decision to present this message is 1268 client specific. 1270 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1271 to be taken and the contents of the data field are identical to the 1272 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1274 The server MUST terminate the session after sending a REPLY. 1276 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1277 accounting message. Start messages should only be sent once when a 1278 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1279 a stop record and that the task has terminated. The 1280 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1281 Update records are sent at the client's discretion when the task is 1282 still running. 1284 Summary of Accounting Packets 1285 +----------+-------+-------+-------------+-------------------------+ 1286 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1287 +----------+-------+-------+-------------+-------------------------+ 1288 | 0 | 0 | 0 | 0 | INVALID | 1289 | 0 | 0 | 1 | 2 | Start Accounting Record | 1290 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1291 | 0 | 1 | 1 | 6 | INVALID | 1292 | 1 | 0 | 0 | 8 | Watchdog, no update | 1293 | 1 | 0 | 1 | A | Watchdog, with update | 1294 | 1 | 1 | 0 | C | INVALID | 1295 | 1 | 1 | 1 | E | INVALID | 1296 +----------+-------+-------+-------------+-------------------------+ 1298 The START and STOP flags are mutually exclusive. When the WATCHDOG 1299 flag is set along with the START flag, it indicates that the update 1300 record is a duplicate of the original START record. If the START 1301 flag is not set, then this indicates a minimal record indicating only 1302 that task is still running. The STOP flag MUST NOT be set in 1303 conjunction with the WATCHDOG flag. 1305 The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client 1306 requests an INVALID option. 1308 7. Attribute-Value Pairs 1310 TACACS+ is intended to be an extensible protocol. The attributes 1311 used in Authorization and Accounting are not fixed. Some attributes 1312 are defined below for common use cases, clients MUST use these 1313 attributes when supporting the corresponding use cases. 1315 All numeric values in an attribute-value string are provided as 1316 decimal US-ASCII numbers, unless otherwise stated. 1318 All boolean attributes are encoded with values "true" or "false". 1320 It is recommended that hosts be specified as a numeric address so as 1321 to avoid any ambiguities. 1323 Absolute times should be specified in seconds since the epoch, 1324 12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone 1325 attribute is specified. 1327 Attributes may be submitted with no value, in which case they consist 1328 of the name and the mandatory or optional separator. For example, 1329 the attribute "cmd" which has no value is transmitted as a string of 1330 4 characters "cmd=" 1332 7.1. Authorization Attributes 1334 service 1336 The primary service. Specifying a service attribute indicates that 1337 this is a request for authorization or accounting of that service. 1338 Current values are "slip", "ppp", "shell", "tty-server", 1339 "connection", "system" and "firewall". This attribute MUST always be 1340 included. 1342 protocol 1344 a protocol that is a subset of a service. An example would be any 1345 PPP NCP. Currently known values are "lcp", "ip", "ipx", "atalk", 1346 "vines", "lat", "xremote", "tn3270", "telnet", "rlogin", "pad", 1347 "vpdn", "ftp", "http", "deccp", "osicp" and "unknown". 1349 cmd 1351 a shell (exec) command. This indicates the command name for a shell 1352 command that is to be run. This attribute MUST be specified if 1353 service equals "shell". If no value is present then the shell itself 1354 is being referred to. 1356 cmd-arg 1358 an argument to a shell (exec) command. This indicates an argument 1359 for the shell command that is to be run. Multiple cmd-arg attributes 1360 may be specified, and they are order dependent. 1362 acl 1364 US-ASCII number representing a connection access list. Used only 1365 when value of service is "shell"" and cmd has no value. 1367 inacl 1369 US-ASCII identifier for an interface input access list. 1371 outacl 1373 US-ASCII identifier for an interface output access list. 1375 zonelist 1377 A numeric zonelist value. (Applicable to AppleTalk only). 1379 addr 1380 a network address 1382 addr-pool 1384 The identifier of an address pool from which the client should assign 1385 an address. 1387 routing 1389 A boolean. Specifies whether routing information is to be propagated 1390 to, and accepted from this interface. 1392 route 1394 Indicates a route that is to be applied to this interface. Values 1395 MUST be of the form " []". If a 1396 is not specified, the resulting route should be via 1397 the requesting peer. 1399 timeout 1401 an absolute timer for the connection (in minutes). A value of zero 1402 indicates no timeout. 1404 idletime 1406 an idle-timeout for the connection (in minutes). A value of zero 1407 indicates no timeout. 1409 autocmd 1411 an auto-command to run. Used only when service=shell and cmd=NULL 1413 noescape 1415 Boolean. Prevents user from using an escape character. Used only 1416 when service=shell and cmd=NULL 1418 nohangup 1420 Boolean. Do not disconnect after an automatic command. Used only 1421 when service=shell and cmd=NULL 1423 priv-lvl 1425 privilege level to be assigned. Please refer to the Privilege Level 1426 section (Section 8) below. 1428 remote_user 1430 remote userid (authen_method must have the value 1431 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1432 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1433 remote_user and remote_host attributes will provide the remote user 1434 and host information to enable rhost style authorization. The 1435 response may request that a privilege level be set for the user. 1437 remote_host 1439 remote host (authen_method must have the value 1440 TAC_PLUS_AUTHEN_METH_RCMD) 1442 callback-dialstring 1444 Indicates that callback should be done. Value is NULL, or a 1445 dialstring. A NULL value indicates that the service MAY choose to 1446 get the dialstring through other means. 1448 callback-line 1450 The line number to use for a callback. 1452 callback-rotary 1454 The rotary number to use for a callback. 1456 nocallback-verify 1458 Do not require authentication after callback. 1460 7.2. Accounting Attributes 1462 The following new attributes are defined for TACACS+ accounting only. 1463 When these attribute-value pairs are included in the argument list, 1464 they should precede any attribute-value pairs that are defined in the 1465 authorization section (Section 5) above. 1467 task_id 1469 Start and stop records for the same event MUST have matching task_id 1470 attribute values. The client must not reuse a specific task_id in a 1471 start record until it has sent a stop record for that task_id. 1473 start_time 1475 The time the action started (). 1477 stop_time 1479 The time the action stopped (in seconds since the epoch.) 1481 elapsed_time 1483 The elapsed time in seconds for the action. Useful when the device 1484 does not keep real time. 1486 timezone 1488 The timezone abbreviation for all timestamps included in this packet. 1490 event 1492 Used only when "service=system". Current values are "net_acct", 1493 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1494 These indicate system level changes. The flags field SHOULD indicate 1495 whether the service started or stopped. 1497 reason 1499 Accompanies an event attribute. It describes why the event occurred. 1501 bytes 1503 The number of bytes transferred by this action 1505 bytes_in 1507 The number of input bytes transferred by this action 1509 bytes_out 1511 The number of output bytes transferred by this action 1513 paks 1515 The number of packets transferred by this action. 1517 paks_in 1519 The number of input packets transferred by this action. 1521 paks_out 1523 The number of output packets transferred by this action. 1525 status 1527 The numeric status value associated with the action. This is a 1528 signed four (4) byte word in network byte order. 0 is defined as 1529 success. Negative numbers indicate errors. Positive numbers 1530 indicate non-error failures. The exact status values may be defined 1531 by the client. 1533 err_msg 1535 An US-ASCII string describing the status of the action. 1537 8. Privilege Levels 1539 The TACACS+ Protocol supports flexible authorization schemes through 1540 the extensible attributes. One scheme is built in to the protocol: 1541 Privilege Levels. Privilege Levels are ordered values from 0 to 15 1542 with each level representing a privilege level that is a superset of 1543 the next lower value. Pre-defined values are: 1545 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1547 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1549 TAC_PLUS_PRIV_LVL_USER := 0x01 1551 TAC_PLUS_PRIV_LVL_MIN := 0x00 1553 If a client uses a different privilege level scheme, then it must map 1554 the privilege level to scheme above. 1556 Privilege Levels are applied in two ways in the TACACS+ protocol: 1558 - As an argument in authorization EXEC phase (when service=shell 1559 and cmd=NULL), where it is primarily used to set the initial 1560 privilege level for the EXEC session. 1562 - In the packet headers for Authentication, Authorization and 1563 Accounting. The privilege level in the header is primarily 1564 significant in the Authentication phase for enable authentication 1565 where a different privilege level is required. 1567 The use of Privilege levels to determine session-based access to 1568 commands and resources is not mandatory for clients, but it is in 1569 common use so SHOULD be supported by servers. 1571 9. References 1573 [TheDraft] 1574 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 1575 1.78", June 1997, . 1578 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1579 April 1992. 1581 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1582 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1583 . 1585 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1586 "Randomness Recommendations for Security", RFC 1750, 1587 DOI 10.17487/RFC1750, December 1994, 1588 . 1590 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1591 RFC 2433, DOI 10.17487/RFC2433, October 1998, 1592 . 1594 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1595 RFC 2759, DOI 10.17487/RFC2759, January 2000, 1596 . 1598 Authors' Addresses 1600 Thorsten Dahm 1601 Google Inc 1602 1600 Amphitheatre Parkway 1603 Mountain View, CA 94043 1604 US 1606 EMail: thorstendlux@google.com 1608 Andrej Ota 1609 Google Inc 1610 1600 Amphitheatre Parkway 1611 Mountain View, CA 94043 1612 US 1614 EMail: aota@google.com 1615 Douglas C. Medway Gash 1616 Cisco Systems, Inc. 1617 170 West Tasman Dr. 1618 San Jose, CA 95134 1619 US 1621 Phone: +44 0208 8244508 1622 EMail: dcmgash@cisco.com 1624 David Carrel 1625 vIPtela, Inc. 1626 1732 North First St. 1627 San Jose, CA 95112 1628 US 1630 EMail: dcarrel@viptela.com 1632 Lol Grant