--- 1/draft-ietf-opsawg-tacacs-01.txt 2016-04-12 07:16:04.179312688 -0700 +++ 2/draft-ietf-opsawg-tacacs-02.txt 2016-04-12 07:16:04.239314179 -0700 @@ -1,23 +1,23 @@ Operations T. Dahm Internet-Draft A. Ota Intended status: Informational Google Inc -Expires: September 9, 2016 D. Medway Gash +Expires: October 13, 2016 D. Medway Gash Cisco Systems, Inc. D. Carrel vIPtela, Inc. L. Grant - March 8, 2016 + April 11, 2016 The TACACS+ Protocol - draft-ietf-opsawg-tacacs-01 + draft-ietf-opsawg-tacacs-02 Abstract TACACS+ provides Device Administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document describes the protocol that is used by TACACS+. Status of This Memo @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 9, 2016. + This Internet-Draft will expire on October 13, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,29 +79,29 @@ 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. The Authentication START Packet Body . . . . . . . . . . 10 4.2. The Authentication REPLY Packet Body . . . . . . . . . . 13 4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 14 4.4. Description of Authentication Process . . . . . . . . . . 15 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 15 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 16 4.4.3. Aborting an Authentication Session . . . . . . . . . 19 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 21 - 5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 23 + 5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 24 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 25 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 26 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 28 - 7.1. Authorization Attributes . . . . . . . . . . . . . . . . 28 + 7.1. Authorization Attributes . . . . . . . . . . . . . . . . 29 7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 31 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 33 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction A wide range of TACACS+ clients and servers are already deployed in the field. The TACACS+ protocol they are based on is defined in a draft document that was originally intended for IETF publication. This document is known as `The Draft' [TheDraft] . It is intended that all implementations which conform to this @@ -121,35 +121,35 @@ and allows the server to respond to each component of that request. The separation of authentication, authorization and accounting is a fundamental component of the design of TACACS+. The distinction between them is very important so this document will address each one separately. It is important to note that TACACS+ provides for all three, but an implementation or configuration is not required to employ all three. Each one serves a unique purpose that alone is useful, and together can be quite powerful. - TACACS+ is primarily used for Device Administration. In addition to + Whilse originally conceived for all access purposes, TACACS+ is + primarily used today for Device Administration. In addition to authenticating access to network devices, it provides central authorization of operations, and audit of those operations 2. Technical Definitions This section provides a few basic definitions that are applicable to this document Authentication Authentication is the action of determining who a user (or entity) is. Authentication can take many forms. Traditional authentication - utilizes a name and a fixed password. Most computers work this way, - and TACACS+ can also work this way. However, fixed passwords have + utilizes a name and a fixed password. However, fixed passwords have limitations, mainly in the area of security. Many modern authentication mechanisms utilize "one-time" passwords or a challenge-response query. TACACS+ is designed to support all of these, and should be powerful enough to handle any future mechanisms. Authentication generally takes place when the user first logs in to a machine or requests a service of it. Authentication is not mandatory; it is a site-configured option. Some sites do not require it. Others require it only for certain services (see authorization below). Authentication may also take @@ -218,21 +218,21 @@ 3.1. Connection TACACS+ uses TCP for its transport. Server port 49 is allocated for TACACS+ traffic. 3.1.1. Security Considerations The encryption mechanism specified by 'The Draft' would be regarded as obfuscation. It will be referred to here as Body Encryption. A - transport based scheme will be specified in a separate document + transport based scheme will be specified in a separate document. It is NOT recommended to deploy TACACS+ without Body encryption, other than for test environments. 3.2. Session The concept of a session is used throughout this document. A TACACS+ session is a single authentication sequence, a single authorization exchange, or a single accounting exchange. @@ -532,21 +532,23 @@ TAC_PLUS_AUTHEN_SVC_X25 := 0x07 TAC_PLUS_AUTHEN_SVC_NASI := 0x08 TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 The ENABLE service refers to a service requesting authentication in order to grant the user different privileges. This is comparable to the Unix "su(1)" command. A service value of NONE should only be - used when none of the other service values are appropriate. + used when none of the other service values are appropriate. ENABLE + may be requested independently, no requirements for previous + authentications or authorizations are imposed by the protocol. user The username. It is encoded in [UTF-8]. It is optional in this packet, depending upon the class of authentication. port The US-ASCII name of the client port on which the authentication is taking place. The value of this field is client specific. (For @@ -1011,24 +1011,26 @@ priv_lvl This field matches the priv_lvl field in authentication request and is described in the Privilege Level section (Section 8) below. It indicates the users current privilege level. authen_type This field matches the authen_type field in the authentication section (Section 4) above. It indicates the type of authentication - that was performed. + that was performed. If this information is not available, then the + client should set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := + 0x00. This value is valid only in authorization and accounting + requests. authen_service - This field matches the service field in the authentication section (Section 4) above. It indicates the service through which the user authenticated. user This field contains the user's account name. port @@ -1048,20 +1050,23 @@ An attribute-value pair that describes the command to be performed. (see below) The authorization arguments in both the REQUEST and the RESPONSE are attribute-value pairs. The attribute and the value are in a single US-ASCII string and are separated by either a "=" (0X3D) or a "*" (0X2A). The equals sign indicates a mandatory argument. The asterisk indicates an optional one. + It is not legal for an attribute name to contain either of the + separators. + Optional arguments are ones that may be disregarded by either client or server. Mandatory arguments require that the receiving side understands the attribute and will act on it. If the client receives a mandatory argument that it cannot oblige or does not understand, it MUST consider the authorization to have failed. It is legal to send an attribute-value pair with a NULL (zero length) value. Attribute-value strings are not NULL terminated, rather their length value indicates their end. The maximum length of an attribute-value string is 255 characters. @@ -1256,20 +1263,23 @@ | 1 | 1 | 1 | E | INVALID | +----------+-------+-------+-------------+-------------------------+ The START and STOP flags are mutually exclusive. When the WATCHDOG flag is set along with the START flag, it indicates that the update record is a duplicate of the original START record. If the START flag is not set, then this indicates a minimal record indicating only that task is still running. The STOP flag MUST NOT be set in conjunction with the WATCHDOG flag. + The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client + requests an INVALID option. + 7. Attribute-Value Pairs TACACS+ is intended to be an extensible protocol. The attributes used in Authorization and Accounting are not fixed. Some attributes are defined below for common use cases, clients MUST use these attributes when supporting the corresponding use cases. All numeric values in an attribute-value string are provided as decimal US-ASCII numbers, unless otherwise stated.