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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/