idnits 2.17.1 draft-dahm-opsawg-tacacs-01.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 252: '...sport encryption SHOULD be used in dep...' RFC 2119 keyword, line 254: '... encryption MAY be configured to all...' RFC 2119 keyword, line 262: '...nsport encryption MUST utilise the TLS...' RFC 2119 keyword, line 267: '...g TLS encryption MUST implement at lea...' RFC 2119 keyword, line 268: '...rsion 1.2. They MAY implement higher ...' (64 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 (October 2, 2015) is 3122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 246, but not defined == Missing Reference: 'UTF-8' is mentioned on line 627, but not defined == Unused Reference: 'TheDraft' is defined on line 1661, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TheDraft' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2433 ** Downref: Normative reference to an Informational RFC: RFC 2759 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations T. Dahm 3 Internet-Draft A. Ota 4 Intended status: Standards Track Google Inc 5 Expires: April 4, 2016 D. Medway Gash 6 Cisco Systems, Inc. 7 D. Carrel 9 L. Grant 10 October 2, 2015 12 The TACACS+ Protocol 13 draft-dahm-opsawg-tacacs-01.txt 15 Abstract 17 TACACS+ provides access control for routers, network access servers 18 and other networked computing devices via one or more centralized 19 servers. TACACS+ provides separate authentication, authorization and 20 accounting services. This document describes the protocol that is 21 used by TACACS+. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 4, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 71 3. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 6 72 3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.1. Security Considerations . . . . . . . . . . . . . . . 6 74 3.1.2. TLS Cypher Requirements . . . . . . . . . . . . . . . 6 75 3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 7 77 3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 8 78 3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 10 79 3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.6.1. Legacy Body Encryption . . . . . . . . . . . . . . . 10 81 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.1. The Authentication START Packet Body . . . . . . . . . . 12 83 4.2. The Authentication REPLY Packet Body . . . . . . . . . . 14 84 4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 15 85 4.4. Description of Authentication Process . . . . . . . . . . 16 86 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 87 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 88 4.4.3. Aborting an Authentication Session . . . . . . . . . 22 89 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 23 90 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 24 91 5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 26 92 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 94 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 95 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 31 96 7.1. Authorization Attributes . . . . . . . . . . . . . . . . 31 97 7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 98 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 36 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 102 1. Introduction 104 This Internet-Draft is submitted in full conformance with the 105 provisions of BCP 78 and BCP 79. 107 Internet-Drafts are working documents of the Internet Engineering 108 Task Force (IETF). Note that other groups may also distribute 109 working documents as Internet-Drafts. The list of current Internet- 110 Drafts is at http://datatracker.ietf.org/drafts/current/. 112 Internet-Drafts are draft documents valid for a maximum of six months 113 and may be updated, replaced, or obsoleted by other documents at any 114 time. It is inappropriate to use Internet-Drafts as reference 115 material or to cite them other than as "work in progress." 117 This Internet-Draft will expire on December 10, 2015. 119 A wide range of TACACS+ clients and servers are already deployed in 120 the field, based upon ``The Draft''. This specification is 121 essentially a refactoring of the draft with some minor additions. 122 The definitions in the draft should map onto this document, such that 123 any implementations based on the draft will be compliant with this 124 document. Chief changes between the documents: 126 - This document introduces a TLS encryption option 128 - This document supports MS-CHAPv2 130 - This document officially removes SENDPASS for security reasons. 131 This option was still documented as 'deprecated' in ''The Draft'' 133 - This document deprecates description of legacy features such as 134 ARAP and outbound authentication. The required enumerations are 135 kept, but related normative description is removed. 137 The TACACS+ protocol is the latest generation of TACACS. It 138 separates the functions of Authentication, Authorization and 139 Accounting. It allows for arbitrary length and content 140 authentication exchanges, which will support any authentication 141 mechanism to be utilized with TACACS+ clients. It is extensible to 142 provide for site customization and future development features, and 143 it uses TCP to ensure reliable delivery. The protocol allows the 144 TACACS+ client to request very fine-grained access control and allows 145 the server to respond to each component of that request. 147 The separation of authentication, authorization and accounting is a 148 fundamental component of the design of TACACS+. The distinction 149 between them is very important so this document will address each one 150 separately. It is important to note that TACACS+ provides for all 151 three, but an implementation or configuration is not required to 152 employ all three. Each one serves a unique purpose that alone is 153 useful, and together can be quite powerful. A very important benefit 154 to separating authentication from authorization is that authorization 155 (and per-user profiles) can be a dynamic process. Instead of a one- 156 shot user profile, TACACS+ can be integrated with other negotiations, 157 such as a PPP negotiation, for far greater flexibility. The 158 accounting portion can serve to provide security auditing or 159 accounting/ billing services. 161 2. Technical Definitions 163 This section provides a few basic definitions that are applicable to 164 this document 166 Authentication 168 Authentication is the action of determining who a user (or entity) 169 is. Authentication can take many forms. Traditional authentication 170 utilizes a name and a fixed password. Most computers work this way, 171 and TACACS+ can also work this way. However, fixed passwords have 172 limitations, mainly in the area of security. Many modern 173 authentication mechanisms utilize "one-time" passwords or a 174 challenge-response query. TACACS+ is designed to support all of 175 these, and should be powerful enough to handle any future mechanisms. 176 Authentication generally takes place when the user first logs in to a 177 machine or requests a service of it. 179 Authentication is not mandatory; it is a site-configured option. 180 Some sites do not require it. Others require it only for certain 181 services (see authorization below). Authentication may also take 182 place when a user attempts to gain extra privileges, and must 183 identify himself or herself as someone who possesses the required 184 information (passwords, etc.) for those privileges. 186 Authorization 188 It is important to distinguish Authorization from Authentication. 189 Authorization is the action of determining what a user is allowed to 190 do. Generally authentication precedes authorization, but again, this 191 is not required. An authorization request may indicate that the user 192 is not authenticated (we don't know who they are). In this case it 193 is up to the authorization agent to determine if an unauthenticated 194 user is allowed the services in question. 196 In TACACS+, authorization does not merely provide yes or no answers, 197 but it may also customize the service for the particular user. 198 Examples of when authorization would be performed are: When a user 199 first logs in and wants to start a shell, or when a user starts PPP 200 and wants to use IP over PPP with a particular IP address. The 201 TACACS+ server might respond to these requests by allowing the 202 service, but placing a time restriction on the login shell, or by 203 requiring IP access lists on the PPP connection. For a list of 204 authorization attributes, see the authorization section (Section 5) . 206 Accounting 208 Accounting is typically the third action after authentication and 209 authorization. But again, neither authentication nor authorization 210 is required. Accounting is the action of recording what a user is 211 doing, and/or has done. Accounting in TACACS+ can serve two 212 purposes: It may be used as an auditing tool for security services. 213 It may also be used to account for services used, such as in a 214 billing environment. To this end, TACACS+ supports three types of 215 accounting records. Start records indicate that a service is about 216 to begin. Stop records indicate that a service has just terminated, 217 and Update records are intermediate notices that indicate that a 218 service is still being performed. TACACS+ accounting records contain 219 all the information used in the authorization records, and also 220 contain accounting specific information such as start and stop times 221 (when appropriate) and resource usage information. A list of 222 accounting attributes is defined in the accounting section 223 (Section 6) . 225 Client 227 The client is any device, (often a Network Access Server) that 228 provides access services. The clients usually provide a character 229 mode front end and then allow the user to telnet or rlogin to another 230 host. A client may also support protocol based access services. 232 Server 234 The server receives TACACS+ protocol requests, and replies according 235 to its business model, in accordance with the flows defined in this 236 document. 238 Packet 239 All uses of the word packet in this document refer to TACACS+ 240 protocol packets unless explicitly noted otherwise. 242 3. TACACS+ Connections and Sessions 244 3.1. Connection 246 TACACS+ uses TCP for its transport. Server port [TBD] is allocated 247 for Transport encrypted TACACS+ traffic. Server port 49 is allocated 248 for non Transport encrypted TACACS+ traffic. 250 3.1.1. Security Considerations 252 Transport encryption SHOULD be used in deployments when both the 253 clients and servers support it. Servers that support Transport 254 encryption MAY be configured to allow Legacy Body Encryption when 255 Transport encryption is not supported by the client. 257 It is NOT recommended to deploy TACACS+ without Transport or Legacy 258 Body encryption, other than for test environments. 260 3.1.2. TLS Cypher Requirements 262 TACACS+ Servers supporting Transport encryption MUST utilise the TLS 263 options described in the following sections. 265 3.1.2.1. TLS Protocol Version 267 TACACS+ Servers supporting TLS encryption MUST implement at least TLS 268 version 1.2. They MAY implement higher TLS versions. 270 3.1.2.2. Mandatory Cipher Suites 272 TLS 1.2 RFC 5246 [RFC5246] allows specifying application profiles 273 prescribing which cipher suites to implement for interoperability 274 purposes. To maintain simplicity of current TACACS+ configuration 275 using preshared secrets, the server implementation MUST implement: 277 TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA 279 TLS_DHE_PSK_WITH_AES_128_CBC_SHA 281 TLS_DHE_PSK_WITH_AES_256_CBC_SHA 283 Client MUST implement at least one of cipher suites which are 284 implemented on the server, and it MAY implement all of them. 286 Both clients and servers MAY implement other cipher suites, but their 287 interoperability is not guaranteed and their implementation is 288 outside of scope of this document. 290 3.1.2.3. PSK Identity Requirements 292 Because determining a correct PSK value on the server side is a 293 computationally intensive operation requiring multiple round trips, a 294 mechanism for hitless key change must be defined. During TLS 295 handshake, a client MUST use PSK identity as defined in RFC 4279 296 [RFC4279] to signal to the server which PSK value to use. If server 297 does not recognize PSK identity it MUST respond with decrypt_error 298 alert and MUST NOT respond with unknown_psk_identity. Process to 299 change preshared keys on server and client is then: 301 1. Add new key with new PSK identity on the server. 303 2. Add new key with new PSK identity on the client. 305 3. Remove old key with old PSK identity from the client. 307 4. Remove old key with old PSK identity from the server. 309 Note: PSK identity is transmitted in clear text and must not contain 310 information which could aid an attacker who can eavesdrop on the 311 connection. 313 3.2. Session 315 The concept of a session is used throughout this document. A TACACS+ 316 session is a single authentication sequence, a single authorization 317 exchange, or a single accounting exchange. 319 An accounting and authorization session will consist of a single pair 320 of packets (the request and its reply). An authentication session 321 may involve an arbitrary number of packets being exchanged. The 322 session is an operational concept that is maintained between the 323 TACACS+ client and server. It does not necessarily correspond to a 324 given user or user action. 326 3.3. Single Connect Mode 328 The packet header (see below) contains a flag to allow sessions to be 329 multiplexed on a connection. 331 If a client sets this flag, this indicates that it supports 332 multiplexing TACACS+ sessions over a single TCP connection. The 333 client MUST NOT send a second packet on a connection until single- 334 connect status has been established. 336 If the server sets this flag in the first reply packet in response to 337 the first packet from a client, this indicates its willingness to 338 support single-connection over the current connection. The server 339 may set this flag even if the client does not set it, but the client 340 is under no obligation to honor it. 342 The flag is only relevant for the first two packets on a connection, 343 to allow the client and server to establish single connection mode. 344 The flag MUST be ignored after these two packets since the single- 345 connect status of a connection, once established, must not be 346 changed. The connection must instead be closed and a new connection 347 opened, if required. 349 When single-connect status is established, multiple sessions MUST be 350 allowed simultaneously and/or consecutively on a single TCP 351 connection. If single-connect status has not been established in the 352 first two packets of a TCP connection, then the connection must be 353 closed at the end of the first session. 355 3.4. The TACACS+ Packet Header 357 All TACACS+ packets always begin with the following 12 byte header. 358 The header is always cleartext and describes the remainder of the 359 packet: 361 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 362 +----------------+----------------+----------------+----------------+ 363 |major | minor | | | | 364 |version| version| type | seq_no | flags | 365 +----------------+----------------+----------------+----------------+ 366 | | 367 | session_id | 368 +----------------+----------------+----------------+----------------+ 369 | | 370 | length | 371 +----------------+----------------+----------------+----------------+ 373 major_version 375 This is the major TACACS+ version number. 377 TAC_PLUS_MAJOR_VER := 0xc 379 minor_version 380 The minor TACACS+ version number. 382 TAC_PLUS_MINOR_VER_DEFAULT := 0x0 384 TAC_PLUS_MINOR_VER_ONE := 0x1 386 type 388 This is the packet type. Legal values are: 390 TAC_PLUS_START_TLS := 0x00 (Upgrade Connection to TLS) 392 TAC_PLUS_AUTHEN := 0x01 (Authentication) 394 TAC_PLUS_AUTHOR := 0x02 (Authorization) 396 TAC_PLUS_ACCT := 0x03 (Accounting) 398 seq_no 400 This is the sequence number of the current packet for the current 401 session. The first packet in a session MUST have the sequence number 402 1 and each subsequent packet will increment the sequence number by 403 one. Thus clients only send packets containing odd sequence numbers, 404 and TACACS+ servers only send packets containing even sequence 405 numbers. 407 The sequence number must never wrap i.e. if the sequence number 2^8-1 408 is ever reached, that session must terminate and be restarted with a 409 sequence number of 1. 411 flags 413 This field contains various bitmapped flags. 415 The unencrypted flag bit says whether encryption is being used on the 416 body of the packet (the entire portion after the header). 418 TAC_PLUS_UNENCRYPTED_FLAG := 0x01 420 If this flag is set, the packet is not encrypted. If this flag is 421 cleared, the packet is encrypted. Unencrypted packets are intended 422 for testing, and are not recommended for normal use. 424 The single-connection flag: 426 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 427 This flag is used to allow a client and server to agree whether 428 multiple sessions may be multiplexed onto a single connection. 430 session_id 432 The Id for this TACACS+ session. The session id should be randomly 433 chosen. This field does not change for the duration of the TACACS+ 434 session. (If this value is not a cryptographically strong random 435 number, it will compromise the protocol's security, see RFC 1750 436 [RFC1750] ) 438 length 440 The total length of the packet body (not including the header). This 441 value is in network byte order. Packets are never padded beyond this 442 length. 444 3.5. The TACACS+ Packet Body 446 The TACACS+ body types are defined in the packet header. The 447 remainder of this document will address the contents of the different 448 TACACS+ bodies. The following general rules apply to all TACACS+ 449 body types: 451 - Any variable length data fields which are unused MUST have a 452 length value equal to zero. 454 - Unused fixed length fields SHOULD have values of zero. 456 - All data and message fields in a packet MUST NOT be null 457 terminated. 459 - All length values are unsigned and in network byte order. 461 - There should be no padding in any of the fields or at the end of 462 a packet. 464 3.6. Encryption 466 3.6.1. Legacy Body Encryption 468 The body of packets may be encrypted. The following sections 469 describe the legacy encryption mechanism that is supported to enable 470 backwards compatibility with "The Draft". 472 When the encryption mechanism relies on a secret key, it is referring 473 to a shared secret value that is known to both the client and the 474 server. This document does not discuss the management and storage of 475 those keys. It is an implementation detail of the server and client, 476 as to whether they will maintain only one key, or a different key for 477 each client or server with which they communicate. For security 478 reasons, the latter options should be available, but it is a site 479 dependent decision as to whether the use of separate keys is 480 appropriate. 482 The encrypted flag field may be set as follows: 484 TAC_PLUS_UNENCRYPTED_FLAG == 0x0 486 In this case, the packet body is encrypted by XOR-ing it byte-wise 487 with a pseudo random pad. 489 ENCRYPTED {data} == data ^ pseudo_pad 491 The pad is generated by concatenating a series of MD5 hashes (each 16 492 bytes long) and truncating it to the length of the input data. 494 Whenever used in this document, MD5 refers to the "RSA Data Security, 495 Inc. MD5 Message-Digest Algorithm" as specified in RFC 1321 [RFC1321] 496 . 498 pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) 500 The first MD5 hash is generated by concatenating the session_id, the 501 secret key, the version number and the sequence number and then 502 running MD5 over that stream. All of those input values are 503 available in the packet header, except for the secret key which is a 504 shared secret between the TACACS+ client and server. 506 The version number is the one byte concatenation of the major and 507 minor version numbers. 509 The session id is used in network byte order. 511 Subsequent hashes are generated by using the same input stream, but 512 concatenating the previous hash value at the end of the input stream. 514 MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, 515 key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, 516 version, seq_no, MD5_n-1} 518 TAC_PLUS_UNENCRYPTED_FLAG == 0x1 520 In this case, the entire packet body is in cleartext. Encryption and 521 decryption are null operations. This method should only be used for 522 debugging. It does not provide data protection or authentication and 523 is highly susceptible to packet spoofing. Implementing this 524 encryption method is optional. 526 NOTE: Implementations should take care not to skip decryption simply 527 because an incoming packet indicates that it is not encrypted. If 528 the unencrypted flag is not set, and the packet is not encrypted, it 529 must be dropped. 531 After a packet body is decrypted, the lengths of the component values 532 in the packet should be summed and checked against the cleartext 533 datalength value from the header. Any packets which fail this check 534 should be discarded and an error signalled. Commonly such failures 535 may be expected to be seen when there are mismatched keys between the 536 client and the TACACS+ server. 538 If an error must be declared but the type of the incoming packet 539 cannot be determined, a packet with the identical cleartext header 540 but with a sequence number incremented by one and the length set to 541 zero MUST be returned to indicate an error. 543 4. Authentication 545 4.1. The Authentication START Packet Body 547 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 548 +----------------+----------------+----------------+----------------+ 549 | action | priv_lvl | authen_type | service | 550 +----------------+----------------+----------------+----------------+ 551 | user len | port len | rem_addr len | data len | 552 +----------------+----------------+----------------+----------------+ 553 | user ... 554 +----------------+----------------+----------------+----------------+ 555 | port ... 556 +----------------+----------------+----------------+----------------+ 557 | rem_addr ... 558 +----------------+----------------+----------------+----------------+ 559 | data... 560 +----------------+----------------+----------------+----------------+ 562 Packet fields are as follows: 564 action 566 This describes the authentication action to be performed. Legal 567 values are: 569 TAC_PLUS_AUTHEN_LOGIN := 0x01 570 TAC_PLUS_AUTHEN_CHPASS := 0x02 572 TAC_PLUS_AUTHEN_SENDAUTH := 0x04 574 priv_lvl 576 This indicates the privilege level that the user is authenticating 577 as. Please refer to the Privilege Level section (Section 8) below. 579 authen_type 581 The type of authentication that is being performed. Legal values 582 are: 584 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 586 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 588 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 590 TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) 592 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 594 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 596 service 598 This is the service that is requesting the authentication. Legal 599 values are: 601 TAC_PLUS_AUTHEN_SVC_NONE := 0x00 603 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 605 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 607 TAC_PLUS_AUTHEN_SVC_PPP := 0x03 609 TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 611 TAC_PLUS_AUTHEN_SVC_PT := 0x05 613 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 615 TAC_PLUS_AUTHEN_SVC_X25 := 0x07 617 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 618 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 620 The ENABLE service refers to a service requesting authentication in 621 order to grant the user different privileges. This is comparable to 622 the Unix "su(1)" command. A service value of NONE should only be 623 used when none of the other service values are appropriate. 625 user 627 The username. It is encoded in [UTF-8]. It is optional in this 628 packet, depending upon the class of authentication. 630 port 632 The ASCII name of the client port on which the authentication is 633 taking place. The value of this field is client specific. (For 634 example, Cisco uses "tty10" to denote the tenth tty line and 635 "Async10" to denote the tenth async interface). 637 rem_addr 639 An ASCII string this is a "best effort" description of the remote 640 location from which the user has connected to the client. It is 641 intended to hold a network address if the user is connected via a 642 network, a caller ID is the user is connected via ISDN or a POTS, or 643 any other remote location information that is available. This field 644 is optional (since the information may not be available). 646 data 648 This field is used to send data appropriate for the action and 649 authen_type. It is described in more detail below. 651 4.2. The Authentication REPLY Packet Body 653 The TACACS+ server sends only one type of authentication packet (a 654 REPLY packet) to the client. The REPLY packet body looks as follows: 656 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 657 +----------------+----------------+----------------+----------------+ 658 | status | flags | server_msg len | 659 +----------------+----------------+----------------+----------------+ 660 | data len | server_msg ... 661 +----------------+----------------+----------------+----------------+ 662 | data ... 663 +----------------+----------------+ 665 status 666 The current status of the authentication. Legal values are: 668 TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 670 TAC_PLUS_AUTHEN_STATUS_FAIL := 0x02 672 TAC_PLUS_AUTHEN_STATUS_GETDATA := 0x03 674 TAC_PLUS_AUTHEN_STATUS_GETUSER := 0x04 676 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 678 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 680 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 682 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 684 flags 686 Bitmapped flags that modify the action to be taken. The following 687 values are defined: 689 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 691 server_msg 693 A message to be displayed to the user. This field is optional. If 694 it exists, it is intended to be presented to the user. US-ASCII 695 charset must be used. 697 data 699 This field holds data that is a part of the authentication exchange 700 and is intended for the client, not the user. Valid uses of this 701 field are described below. 703 4.3. The Authentication CONTINUE Packet Body 705 This packet is sent from the client to the server following the 706 receipt of a REPLY packet. 708 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 709 +----------------+----------------+----------------+----------------+ 710 | user_msg len | data len | 711 +----------------+----------------+----------------+----------------+ 712 | flags | user_msg ... 713 +----------------+----------------+----------------+----------------+ 714 | data ... 715 +----------------+ 717 user_msg 719 This field is the string that the user entered, or the client 720 provided on behalf of the user, in response to the server_msg from a 721 REPLY packet. 723 data 725 This field carries information that is specific to the action and the 726 authen_type for this session. Valid uses of this field are described 727 below. 729 flags 731 This holds the bitmapped flags that modify the action to be taken. 732 The following values are defined: 734 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 736 4.4. Description of Authentication Process 738 Authentications are classified by the action, authen_type and service 739 fields in the START packet of the authentication Session. The user, 740 priv_lvl, service, port and rem_addr in the START packet are all 741 provided to help identify the conditions on the client. 743 The information necessary to transact the authentication is passed in 744 the data field of every START, REPLY and CONTINUE packet. The usage 745 of this field varies according to the classification of the 746 authentication, and is described below. For all REPLY packets, the 747 server_msg may contain a message to be displayed to the user. 749 A set of standard authentication classifications is defined in this 750 document. Each authentication flow consists of a START packet. The 751 server responds either with a request for more information (GETDATA, 752 GETUSER or GETPASS) or a termination (PASS or FAIL). The actions and 753 meanings when the server sends a RESTART, ERROR or FOLLOW are common 754 and are described further below. 756 When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, 757 TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, 758 then authentication continues and the server_msg may be used by the 759 client to prompt the user for more information. The client MUST then 760 return a CONTINUE packet containing the requested information in the 761 user_msg field. 763 All three cause the same action to be performed, but in the case of 764 TAC_PLUS_AUTHEN_STATUS_GETUSER, the client can know that the 765 information that the user responds with is a username, and for 766 TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a 767 password. TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic request for 768 more information. If the TAC_PLUS_REPLY_FLAG_NOECHO flag is set in 769 the REPLY, then the user response must not be echoed as it is 770 entered. The data field is only used in the REPLY where explicitly 771 defined below. 773 4.4.1. Version Behaviour 775 The TACACS+ protocol is versioned to allow revisions while 776 maintaining backwards compatibility. The version number is in every 777 packet header. The changes between minor_version 0 and 1 apply only 778 to the authentication process, and all deal with the way that CHAP 779 and PAP authentications are handled. minor_version 1 may only be used 780 for authentication classes that explicitly call for it in the table 781 below: 783 LOGIN CHPASS SENDAUTH 784 ASCII v0 v0 NA 785 PAP v1 NA v1 786 CHAP v1 NA v1 787 MS-CHAP v1 NA v1 789 When a server receives a packet with a minor_version that it does not 790 support, it should return an ERROR status with the minor_version set 791 to the closest supported value. 793 In minor_version 0, CHAP and outbound PAP authentications were 794 performed by the client sending a SENDPASS packet to the server. The 795 SENDPASS requested a copy of the user's plaintext password so that 796 the client could complete the authentication. The CHAP hashing was 797 performed on the client. Inbound PAP performed a normal LOGIN, 798 sending the username in the START packet and then waiting for a 799 GETPASS and sending the password in a CONTINUE packet. 801 In minor_version 1, CHAP and inbound PAP use LOGIN to perform inbound 802 authentication and the exchanges use the data field so that the 803 client only sends a single START packet and expects to receive a PASS 804 or FAIL. SENDPASS has been deprecated and SENDAUTH introduced, so 805 that the client can request authentication credentials for 806 authenticating to a remote peer. SENDAUTH is only used for PPP when 807 performing outbound authentication. 809 NOTE: Only those requests which have changed from their minor_version 810 0 implementation (i.e. CHAP, MS-CHAP and PAP authentications) should 811 use the new minor_version number of 1. All other requests (i.e. all 812 authorisation and accounting and ASCII authentication) MUST continue 813 to use the same minor_version number of 0. The removal of SENDPASS 814 was prompted by security concerns, and is no longer considered part 815 of the TACACS+ protocol. 817 4.4.2. Common Authentication Flows 819 This section describes the authentication flows that should be 820 supported. 822 Inbound ASCII Login 824 action = TAC_PLUS_AUTHEN_LOGIN 825 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 826 minor_version = 0x0 828 This is a standard ASCII authentication. The START packet may 829 contain the username, but need not do so. The data fields in both 830 the START and CONTINUE packets are not used for ASCII logins. There 831 is a single START followed by zero or more pairs of REPLYs and 832 CONTINUEs, followed by a terminating REPLY (PASS or FAIL). 834 Inbound PAP Login 836 action = TAC_PLUS_AUTHEN_LOGIN 837 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 838 minor_version = 0x1 840 The entire exchange MUST consist of a single START packet and a 841 single REPLY. The START packet MUST contain a username and the data 842 field MUST contain the PAP ASCII password. A PAP authentication only 843 consists of a username and password RFC 1334 [RFC1334] . The REPLY 844 from the server MUST be either a PASS or FAIL. 846 Inbound CHAP login 847 action = TAC_PLUS_AUTHEN_LOGIN 848 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 849 minor_version = 0x1 851 The entire exchange MUST consist of a single START packet and a 852 single REPLY. The START packet MUST contain the username in the user 853 field and the data field will be a concatenation of the PPP id, the 854 challenge and the response. 856 The length of the challenge value can be determined from the length 857 of the data field minus the length of the id (always 1 octet) and the 858 length of the response field (always 16 octets). 860 To perform the authentication, the server will run MD5 over the id, 861 the user's secret and the challenge, as defined in the PPP 862 Authentication RFC RFC 1334 [RFC1334] and then compare that value 863 with the response. The REPLY from the server MUST be a PASS or FAIL. 865 Inbound MS-CHAP v1 login 867 action = TAC_PLUS_AUTHEN_LOGIN 868 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 869 minor_version = 0x1 871 The entire exchange MUST consist of a single START packet and a 872 single REPLY. The START packet MUST contain the username in the user 873 field and the data field will be a concatenation of the PPP id, the 874 MS-CHAP challenge and the MS-CHAP response. 876 The length of the challenge value can be determined from the length 877 of the data field minus the length of the id (always 1 octet) and the 878 length of the response field (always 49 octets). 880 To perform the authentication, the server will use a combination of 881 MD4 and DES on the user's secret and the challenge, as defined in RFC 882 2433 [RFC2433] and then compare the resulting value with the 883 response. The REPLY from the server MUST be a PASS or FAIL. 885 Inbound MS-CHAP v2 login 887 action = TAC_PLUS_AUTHEN_LOGIN 888 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 889 minor_version = 0x1 891 The entire exchange MUST consist of a single START packet and a 892 single REPLY. The START packet MUST contain the username in the user 893 field and the data field will be a concatenation of the PPP id, the 894 MS-CHAP challenge and the MS-CHAP response. 896 The length of the challenge value can be determined from the length 897 of the data field minus the length of the id (always 1 octet) and the 898 length of the response field (always 49 octets). 900 To perform the authentication, the server will use a the algorithm 901 specified RFC RFC2759 [RFC2759] on the user's secret and challenge 902 and then compare the resulting value with the response. The REPLY 903 from the server MUST be a PASS or FAIL. 905 Outbound PAP request (Backward compatibility, not for new designs) 907 action = TAC_PLUS_AUTHEN_SENDAUTH 908 authen_type = TAC_PLUS_AUTHEN_TYPE_PAP 909 minor_version = 0x1 911 This is used when the client needs to provide PAP authentication 912 credentials to the remote PPP peer. The entire exchange MUST consist 913 of a single START packet and a single REPLY. The START packet 914 contains a username in the user field. A REPLY with status set to 915 PASS MUST contain a cleartext password in the data field. Caution is 916 urged when using this. By sending a cleartext password to the 917 client, that password will then be passed to the remote PPP peer. It 918 should be ensured that the provided password can never be used to 919 authenticate back to the client. Use of this is discouraged, but 920 supported for complete interoperability with the PPP protocol. 922 Outbound CHAP request (Backward compatibility, not for new designs) 924 action = TAC_PLUS_AUTHEN_SENDAUTH 925 authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP 926 minor_version = 0x1 928 This is used when the client needs to provide CHAP authentication 929 credentials to the remote PPP peer. The entire exchange MUST consist 930 of a single START packet and a single REPLY. The START packet MUST 931 contain the username in the user field and the data field will be a 932 concatenation of the PPP id and the challenge. 934 The length of the challenge value can be determined from the length 935 of the data field minus the length of the id (always 1 octet). The 936 server will run MD5 over the id, the user's secret and the challenge, 937 as defined in the PPP Authentication RFC RFC 1334 [RFC1334] . 939 The REPLY from the server MUST be a PASS or FAIL. If the status is 940 PASS, then the data field MUST contain the 16 octet MD5 output 942 Outbound MS-CHAP request (Backward compatibility, not for new 943 designs) 945 action = TAC_PLUS_AUTHEN_SENDAUTH 946 authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP 947 minor_version = 0x1 949 This is used when the client needs to provide MS-CHAP authentication 950 credentials to the remote PPP peer. The entire exchange MUST consist 951 of a single START packet and a single REPLY. The START packet MUST 952 contain the username in the user field and the data field will be a 953 concatenation of the PPP id and the challenge. 955 The length of the challenge value can be determined from the length 956 of the data field minus the length of the id (always 1 octet). The 957 server will use MD4 and DES to process the user's secret and the 958 challenge, as defined in RFC 2433 [RFC2433] . 960 The REPLY from the server MUST be a PASS or FAIL. If the status is 961 PASS, then the data field MUST contain the 49-octet output, in which 962 24 octets are MD4 output for the Microsoft LAN Manager compatible 963 challenge response, 24 octets are MD4 output for the Microsoft 964 Windows NT compatible challenge response and 1 octet is the flag to 965 determine which part of the response packet should be utilized. 967 Enable Requests 969 action = TAC_PLUS_AUTHEN_LOGIN 970 priv_lvl = implementation dependent 971 authen_type = not used 972 service = TAC_PLUS_AUTHEN_SVC_ENABLE 974 This is an ENABLE request, used to change the current running 975 privilege level of a principal. The exchange MAY consist of multiple 976 messages while the server collects the information it requires in 977 order to allow changing the principal's privilege level. This 978 exchange is very similar to an Inbound ASCII login (which see). 980 In order to readily distinguish enable requests from other types of 981 request, the value of the service field MUST be set to 982 TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be 983 set to this value when requesting any other operation. 985 ASCII change password request 987 action = TAC_PLUS_AUTHEN_CHPASS 988 authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII 990 This exchange consists of multiple messages while the server collects 991 the information it requires in order to change the user's password. 992 It is very similar to an ASCII login. The status value 993 TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the 994 "new" password. It MAY be sent multiple times. When requesting the 995 "old" password, the status value MUST be set to 996 TAC_PLUS_AUTHEN_STATUS_GETDATA. 998 4.4.3. Aborting an Authentication Session 1000 The client may prematurely terminate a session by setting the 1001 TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this 1002 flag is set, the data portion of the message may contain an ASCII 1003 message explaining the reason for the abort. The session is 1004 terminated and no REPLY message is sent. 1006 There are three other possible return status values that can be used 1007 in a REPLY packet. These can be sent regardless of the action or 1008 authen_type. Each of these indicates that the TACACS+ authentication 1009 session should be terminated. In each case, the server_msg may 1010 contain a message to be displayed to the user. 1012 When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet 1013 indicates that the TACACS+ server requests that authentication should 1014 be performed with an alternate server. The data field MUST contain 1015 ASCII text describing one or more servers. A server description 1016 appears like this: 1018 [@@]>[@] 1020 The protocol and key are optional. The protocol can describe an 1021 alternate way of performing the authentication, other than TACACS+. 1022 If the protocol is not present, then TACACS+ is assumed. 1024 Protocols are ASCII numbers corresponding to the methods listed in 1025 the authen_method field of authorization packets (defined below). 1026 The host is specified as either a fully qualified domain name, or an 1027 ASCII numeric IP address specified as octets separated by dots (`.'). 1029 If a key is supplied, the client MAY use the key in order to 1030 authenticate to that host. If more than one host is specified, they 1031 MUST be separated by an ASCII Carriage Return (0x0D). 1033 Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the 1034 discretion of the TACACS+ client. It may choose to use any one, all 1035 or none of these hosts. If it chooses to use none, then it MUST 1036 treat the authentication as if the return status was 1037 TAC_PLUS_AUTHEN_STATUS_FAIL. 1039 While the order of hosts in this packet indicates a preference, but 1040 the client is not obliged to use that ordering. 1042 If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is 1043 indicating that it is experiencing an unrecoverable error and the 1044 authentication should proceed as if that host could not be contacted. 1045 The data field may contain a message to be printed on an 1046 administrative console or log. 1048 If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the 1049 authentication sequence should be restarted with a new START packet 1050 from the client. This REPLY packet indicates that the current 1051 authen_type value (as specified in the START packet) is not 1052 acceptable for this session, but that others may be. 1054 The TAC_PLUS_AUTHEN_STATUS_RESTART REPLY packet may contain a list of 1055 valid authen_type values in the data portion of the packet. The 1056 authen_type values are a single byte in length so the data_len value 1057 indicates the number of authen_type values included. This packet is 1058 only currently intended for PPP authentication when multiple 1059 authentication mechanisms are available and can be negotiated between 1060 the client and the remote peer. This also requires future PPP 1061 authentication extensions which have not yet been passed through the 1062 IETF. If a client chooses not to accept the 1063 TAC_PLUS_AUTHEN_STATUS_RESTART packet, then it should be TREATED as 1064 if the status was TAC_PLUS_AUTHEN_STATUS_FAIL. 1066 5. Authorization 1068 TACACS+ authorization is an extensible way of providing remote 1069 authorization services. An authorization session is defined as a 1070 single pair of messages, a REQUEST followed by a RESPONSE. 1072 The authorization REQUEST message contains a fixed set of fields that 1073 describe the authenticity of the user or process, and a variable set 1074 of arguments that describe the services and options for which 1075 authorization is requested. 1077 The RESPONSE contains a variable set of response arguments 1078 (attribute-value pairs) that can restrict or modify the clients 1079 actions. 1081 The arguments in both a REQUEST and a RESPONSE can be specified as 1082 either mandatory or optional. An optional argument is one that may 1083 or may not be used, modified or even understood by the recipient. 1085 A mandatory argument MUST be both understood and used. This allows 1086 for extending the attribute list while providing secure backwards 1087 compatibility. 1089 5.1. The Authorization REQUEST Packet Body 1091 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 1092 +----------------+----------------+----------------+----------------+ 1093 | authen_method | priv_lvl | authen_type | authen_service | 1094 +----------------+----------------+----------------+----------------+ 1095 | user len | port len | rem_addr len | arg_cnt | 1096 +----------------+----------------+----------------+----------------+ 1097 | arg 1 len | arg 2 len | ... | arg N len | 1098 +----------------+----------------+----------------+----------------+ 1099 | user ... 1100 +----------------+----------------+----------------+----------------+ 1101 | port ... 1102 +----------------+----------------+----------------+----------------+ 1103 | rem_addr ... 1104 +----------------+----------------+----------------+----------------+ 1105 | arg 1 ... 1106 +----------------+----------------+----------------+----------------+ 1107 | arg 2 ... 1108 +----------------+----------------+----------------+----------------+ 1109 | ... 1110 +----------------+----------------+----------------+----------------+ 1111 | arg N ... 1112 +----------------+----------------+----------------+----------------+ 1114 authen_method 1116 This indicates the authentication method used by the client to 1117 acquire the user information. 1119 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 1121 TAC_PLUS_AUTHEN_METH_NONE := 0x01 1123 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 1124 TAC_PLUS_AUTHEN_METH_LINE := 0x03 1126 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 1128 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 1130 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 1132 TAC_PLUS_AUTHEN_METH_GUEST := 0x08 1134 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 1136 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 1138 TAC_PLUS_AUTHEN_METH_RCMD := 0x20 1140 KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed 1141 password associated with the line used to gain access. LOCAL is a 1142 client local user database. ENABLE is a command that authenticates 1143 in order to grant new privileges. TACACSPLUS is, of course, TACACS+. 1144 GUEST is an unqualified guest authentication, such as an ARAP guest 1145 login. RADIUS is the Radius authentication protocol. RCMD refers to 1146 authentication provided via the R-command protocols from Berkeley 1147 Unix. (One should be aware of the security limitations to R-command 1148 authentication.) 1150 priv_lvl 1152 This field matches the priv_lvl field in authentication request and 1153 is described in the Privilege Level section (Section 8) below. It 1154 indicates the users current privilege level. 1156 authen_type 1158 This field matches the authen_type field in the authentication 1159 section (Section 4) above. It indicates the type of authentication 1160 that was performed. 1162 authen_service 1164 This field matches the service field in the authentication section 1165 (Section 4) above. It indicates the service through which the user 1166 authenticated. 1168 user 1170 This field contains the user's account name. 1172 port 1174 This field matches the port field in the authentication section 1175 (Section 4) above. 1177 rem_addr 1179 This field matches the rem_addr field in the authentication section 1180 (Section 4) above. 1182 arg_cnt 1184 The number of authorization arguments to follow 1186 arg 1188 An attribute-value pair that describes the command to be performed. 1189 (see below) 1191 The authorization arguments in both the REQUEST and the RESPONSE are 1192 attribute-value pairs. The attribute and the value are in a single 1193 US-ASCII string and are separated by either a "=" (0X3D) or a "*" 1194 (0X2A). The equals sign indicates a mandatory argument. The 1195 asterisk indicates an optional one. 1197 Optional arguments are ones that may be disregarded by either client 1198 or server. Mandatory arguments require that the receiving side 1199 understands the attribute and will act on it. If the client receives 1200 a mandatory argument that it cannot oblige or does not understand, it 1201 MUST consider the authorization to have failed. It is legal to send 1202 an attribute-value pair with a NULL (zero length) value. 1204 Attribute-value strings are not NULL terminated, rather their length 1205 value indicates their end. The maximum length of an attribute-value 1206 string is 255 characters. 1208 5.2. The Authorization RESPONSE Packet Body 1209 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 1210 +----------------+----------------+----------------+----------------+ 1211 | status | arg_cnt | server_msg len | 1212 +----------------+----------------+----------------+----------------+ 1213 + data len | arg 1 len | arg 2 len | 1214 +----------------+----------------+----------------+----------------+ 1215 | ... | arg N len | server_msg ... 1216 +----------------+----------------+----------------+----------------+ 1217 | data ... 1218 +----------------+----------------+----------------+----------------+ 1219 | arg 1 ... 1220 +----------------+----------------+----------------+----------------+ 1221 | arg 2 ... 1222 +----------------+----------------+----------------+----------------+ 1223 | ... 1224 +----------------+----------------+----------------+----------------+ 1225 | arg N ... 1226 +----------------+----------------+----------------+----------------+ 1228 status This field indicates the authorization status 1230 TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 1232 TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 1234 TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 1236 TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 1238 TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 1240 server_msg 1242 This is an ASCII string that may be presented to the user. The 1243 decision to present this message is client specific. 1245 data 1247 This is an ASCII string that may be presented on an administrative 1248 display, console or log. The decision to present this message is 1249 client specific. 1251 arg_cnt 1253 The number of authorization arguments to follow. 1255 arg 1256 An attribute-value pair that describes the command to be performed. 1257 (see below) 1259 If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the 1260 appropriate action is to deny the user action. 1262 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the 1263 arguments specified in the request are authorized and the arguments 1264 in the response are to be used IN ADDITION to those arguments. 1266 If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the 1267 arguments in the request are to be completely replaced by the 1268 arguments in the response. 1270 If the intended action is to approve the authorization with no 1271 modifications, then the status should be set to 1272 TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt should be set to 0. 1274 A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred 1275 on the server. 1277 When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the 1278 arg_cnt MUST be 0. In that case, the actions to be taken and the 1279 contents of the data field are identical to the 1280 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. None of the 1281 arg values have any relevance if an ERROR is set, and must be 1282 ignored. 1284 6. Accounting 1286 6.1. The Account REQUEST Packet Body 1287 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 1288 +----------------+----------------+----------------+----------------+ 1289 | flags | authen_method | priv_lvl | authen_type | 1290 +----------------+----------------+----------------+----------------+ 1291 | authen_service | user len | port len | rem_addr len | 1292 +----------------+----------------+----------------+----------------+ 1293 | arg_cnt | arg 1 len | arg 2 len | ... | 1294 +----------------+----------------+----------------+----------------+ 1295 | arg N len | user ... 1296 +----------------+----------------+----------------+----------------+ 1297 | port ... 1298 +----------------+----------------+----------------+----------------+ 1299 | rem_addr ... 1300 +----------------+----------------+----------------+----------------+ 1301 | arg 1 ... 1302 +----------------+----------------+----------------+----------------+ 1303 | arg 2 ... 1304 +----------------+----------------+----------------+----------------+ 1305 | ... 1306 +----------------+----------------+----------------+----------------+ 1307 | arg N ... 1308 +----------------+----------------+----------------+----------------+ 1310 flags 1312 This holds bitmapped flags. 1314 TAC_PLUS_ACCT_FLAG_START := 0x02 1316 TAC_PLUS_ACCT_FLAG_STOP := 0x04 1318 TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 1320 All other fields are defined in the authorization and authentication 1321 sections above and have the same semantics. 1323 See section 12 Accounting Attribute-value Pairs for the dictionary of 1324 attributes relevant to accounting. 1326 6.2. The Accounting REPLY Packet Body 1328 The response to an accounting message is used to indicate that the 1329 accounting function on the server has completed. The server should 1330 reply with success only when the record has been committed to the 1331 required level of security, relieving the burden on the client from 1332 ensuring any better form of accounting is required. 1334 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 1335 +----------------+----------------+----------------+----------------+ 1336 | server_msg len | data len | 1337 +----------------+----------------+----------------+----------------+ 1338 | status | server_msg ... 1339 +----------------+----------------+----------------+----------------+ 1340 | data ... 1341 +----------------+ 1343 status 1345 This is the return status. Values are: 1347 TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 1349 TAC_PLUS_ACCT_STATUS_ERROR := 0x02 1351 TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 1353 server_msg 1355 This is an ASCII string that may be presented to the user. The 1356 decision to present this message is client specific. 1358 data 1360 This is an ASCII string that may be presented on an administrative 1361 display, console or log. The decision to present this message is 1362 client specific. 1364 When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions 1365 to be taken and the contents of the data field are identical to the 1366 TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. 1368 The server MUST terminate the session after sending a REPLY. 1370 The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start 1371 accounting message. Start messages should only be sent once when a 1372 task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is 1373 a stop record and that the task has terminated. The 1374 TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. 1375 Update records are sent at the client's discretion when the task is 1376 still running. 1378 Summary of Accounting Packets 1379 +----------+-------+-------+-------------+-------------------------+ 1380 | Watchdog | Stop | Start | Flags & 0xE | Meaning | 1381 +----------+-------+-------+-------------+-------------------------+ 1382 | 0 | 0 | 0 | 0 | INVALID | 1383 | 0 | 0 | 1 | 2 | Start Accounting Record | 1384 | 0 | 1 | 0 | 4 | Stop Accounting Record | 1385 | 0 | 1 | 1 | 6 | INVALID | 1386 | 1 | 0 | 0 | 8 | Watchdog, no update | 1387 | 1 | 0 | 1 | A | Watchdog, with update | 1388 | 1 | 1 | 0 | C | INVALID | 1389 | 1 | 1 | 1 | E | INVALID | 1390 +----------+-------+-------+-------------+-------------------------+ 1392 The START and STOP flags are mutually exclusive. When the WATCHDOG 1393 flag is set along with the START flag, it indicates that the update 1394 record is a duplicate of the original START record. If the START 1395 flag is not set, then this indicates a minimal record indicating only 1396 that task is still running. The STOP flag MUST NOT be set in 1397 conjunction with the WATCHDOG flag. 1399 7. Attribute-Value Pairs 1401 TACACS+ is intended to be an extensible protocol. The attributes 1402 used in Authorization and Accounting are not fixed. Some attributes 1403 are defined below for common use cases, clients MUST use these 1404 attributes when supporting the corresponding use cases. 1406 All numeric values in an attribute-value string are provided as 1407 decimal ASCII numbers, unless otherwise stated. 1409 All boolean attributes are encoded with values "true" or "false". 1411 It is recommended that hosts be specified as a numeric address so as 1412 to avoid any ambiguities. 1414 Absolute times should be specified in seconds since the epoch, 1415 12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone 1416 attribute is specified. 1418 A value of NULL means an attribute with a zero length string for its 1419 value i.e. cmd=NULL is actually transmitted as the string of 4 1420 characters "cmd=". 1422 7.1. Authorization Attributes 1424 service 1425 The primary service. Specifying a service attribute indicates that 1426 this is a request for authorization or accounting of that service. 1427 Current values are "slip", "ppp", "shell", "tty-server", 1428 "connection", "system" and "firewall". This attribute MUST always be 1429 included. 1431 protocol 1433 a protocol that is a subset of a service. An example would be any 1434 PPP NCP. Currently known values are "lcp", "ip", "ipx", "atalk", 1435 "vines", "lat", "xremote", "tn3270", "telnet", "rlogin", "pad", 1436 "vpdn", "ftp", "http", "deccp", "osicp" and "unknown". 1438 cmd 1440 a shell (exec) command. This indicates the command name for a shell 1441 command that is to be run. This attribute MUST be specified if 1442 service equals "shell". A NULL value indicates that the shell itself 1443 is being referred to. 1445 cmd-arg 1447 an argument to a shell (exec) command. This indicates an argument 1448 for the shell command that is to be run. Multiple cmd-arg attributes 1449 may be specified, and they are order dependent. 1451 acl 1453 ASCII number representing a connection access list. Used only when 1454 service=shell and cmd=NULL 1456 inacl 1458 ASCII identifier for an interface input access list. 1460 outacl 1462 ASCII identifier for an interface output access list. 1464 zonelist 1466 A numeric zonelist value. (Applicable to AppleTalk only). 1468 addr 1470 a network address 1472 addr-pool 1473 The identifier of an address pool from which the client should assign 1474 an address. 1476 routing 1478 A boolean. Specifies whether routing information is to be propagated 1479 to, and accepted from this interface. 1481 route 1483 Indicates a route that is to be applied to this interface. Values 1484 MUST be of the form " []". If a 1485 is not specified, the resulting route should be via 1486 the requesting peer. 1488 timeout 1490 an absolute timer for the connection (in minutes). A value of zero 1491 indicates no timeout. 1493 idletime 1495 an idle-timeout for the connection (in minutes). A value of zero 1496 indicates no timeout. 1498 autocmd 1500 an auto-command to run. Used only when service=shell and cmd=NULL 1502 noescape 1504 Boolean. Prevents user from using an escape character. Used only 1505 when service=shell and cmd=NULL 1507 nohangup 1509 Boolean. Do no disconnect after an automatic command. Used only 1510 when service=shell and cmd=NULL 1512 priv-lvl 1514 privilege level to be assigned. Please refer to the Privilege Level 1515 section (Section 8) below. 1517 remote_user 1519 remote userid (authen_method must have the value 1520 TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the 1521 authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the 1522 remote_user and remote_host attributes will provide the remote user 1523 and host information to enable rhost style authorization. The 1524 response may request that a privilege level be set for the user. 1526 remote_host 1528 remote host (authen_method must have the value 1529 TAC_PLUS_AUTHEN_METH_RCMD) 1531 callback-dialstring 1533 Indicates that callback should be done. Value is NULL, or a 1534 dialstring. A NULL value indicates that the service MAY choose to 1535 get the dialstring through other means. 1537 callback-line 1539 The line number to use for a callback. 1541 callback-rotary 1543 The rotary number to use for a callback. 1545 nocallback-verify 1547 Do not require authentication after callback. 1549 7.2. Accounting Attributes 1551 The following new attributes are defined for TACACS+ accounting only. 1552 When these attribute-value pairs are included in the argument list, 1553 they should precede any attribute-value pairs that are defined in the 1554 authorization section (Section 5) above. 1556 task_id 1558 Start and stop records for the same event MUST have matching task_id 1559 attribute values. The client must not reuse a specific task_id in a 1560 start record until it has sent a stop record for that task_id. 1562 start_time 1564 The time the action started (). 1566 stop_time 1568 The time the action stopped (in seconds since the epoch.) 1569 elapsed_time 1571 The elapsed time in seconds for the action. Useful when the device 1572 does not keep real time. 1574 timezone 1576 The timezone abbreviation for all timestamps included in this packet. 1578 event 1580 Used only when "service=system". Current values are "net_acct", 1581 "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". 1582 These indicate system level changes. The flags field SHOULD indicate 1583 whether the service started or stopped. 1585 reason 1587 Accompanies an event attribute. It describes why the event occurred. 1589 bytes 1591 The number of bytes transferred by this action 1593 bytes_in 1595 The number of input bytes transferred by this action 1597 bytes_out 1599 The number of output bytes transferred by this action 1601 paks 1603 The number of packets transferred by this action. 1605 paks_in 1607 The number of input packets transferred by this action. 1609 paks_out 1611 The number of output packets transferred by this action. 1613 status 1615 The numeric status value associated with the action. This is a 1616 signed four (4) byte word in network byte order. 0 is defined as 1617 success. Negative numbers indicate errors. Positive numbers 1618 indicate non-error failures. The exact status values may be defined 1619 by the client. 1621 err_msg 1623 An ASCII string describing the status of the action. 1625 8. Privilege Levels 1627 The TACACS+ Protocol supports flexible authorization schemes through 1628 the extensible attributes. One scheme is built in to the protocol: 1629 Privilege Levels. Privilege Levels are ordered values from 0 to 15 1630 with each level representing a privilege level that is a superset of 1631 the next lower value. Pre-defined values are: 1633 TAC_PLUS_PRIV_LVL_MAX := 0x0f 1635 TAC_PLUS_PRIV_LVL_ROOT := 0x0f 1637 TAC_PLUS_PRIV_LVL_USER := 0x01 1639 TAC_PLUS_PRIV_LVL_MIN := 0x00 1641 If a client uses a different privilege level scheme, then it must map 1642 the privilege level to scheme above. 1644 Privilege Levels are applied in two ways in the TACACS+ protocol: 1646 - As an argument in authorization EXEC phase (when service=shell 1647 and cmd=NULL), where it is primarily used to set the initial 1648 privilege level for the EXEC session. 1650 - In the packet headers for Authentication, Authorization and 1651 Accounting. The privilege level in the header is primarily 1652 significant in the Authentication phase for enable authentication 1653 where a different privilege level is required. 1655 The use of Privilege levels to determine session-based access to 1656 commands and resources is not mandatory for clients, but it is in 1657 common use so SHOULD be supported by servers. 1659 9. References 1661 [TheDraft] 1662 Carrel, D. and L. Grant, "The TACACS+ Protocol Version 1663 1.78", June 1997, . 1666 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1667 April 1992. 1669 [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 1670 RFC 1334, DOI 10.17487/RFC1334, October 1992, 1671 . 1673 [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1674 "Randomness Recommendations for Security", RFC 1750, 1675 DOI 10.17487/RFC1750, December 1994, 1676 . 1678 [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", 1679 RFC 2433, DOI 10.17487/RFC2433, October 1998, 1680 . 1682 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1683 RFC 2759, DOI 10.17487/RFC2759, January 2000, 1684 . 1686 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 1687 Ciphersuites for Transport Layer Security (TLS)", 1688 RFC 4279, DOI 10.17487/RFC4279, December 2005, 1689 . 1691 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1692 (TLS) Protocol Version 1.2", RFC 5246, 1693 DOI 10.17487/RFC5246, August 2008, 1694 . 1696 Authors' Addresses 1698 Thorsten Dahm 1699 Google Inc 1700 1600 Amphitheatre Parkway 1701 Mountain View, CA 94043 1702 US 1704 EMail: thorstendlux@google.com 1706 Andrej Ota 1707 Google Inc 1708 1600 Amphitheatre Parkway 1709 Mountain View, CA 94043 1710 US 1712 EMail: aota@google.com 1713 Douglas C. Medway Gash 1714 Cisco Systems, Inc. 1715 170 West Tasman Dr. 1716 San Jose, CA 95134 1717 US 1719 Phone: +44 0208 8244508 1720 EMail: dcmgash@cisco.com 1722 David Carrel 1724 Lol Grant