draft-ietf-opsawg-tacacs-02.txt   draft-ietf-opsawg-tacacs-03.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: October 13, 2016 D. Medway Gash Expires: December 22, 2016 D. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
D. Carrel D. Carrel
vIPtela, Inc. vIPtela, Inc.
L. Grant L. Grant
April 11, 2016 June 20, 2016
The TACACS+ Protocol The TACACS+ Protocol
draft-ietf-opsawg-tacacs-02 draft-ietf-opsawg-tacacs-03
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 October 13, 2016. This Internet-Draft will expire on December 22, 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 24 skipping to change at page 2, line 24
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 3 2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4
3. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 5 3. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 5
3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Security Considerations . . . . . . . . . . . . . . . 5 3.1.1. Security Considerations . . . . . . . . . . . . . . . 6
3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 6 3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 6
3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 6 3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 7
3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 8 3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 9
3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9
3.6.1. Body Encryption . . . . . . . . . . . . . . . . . . . 9 3.6.1. Body Encryption . . . . . . . . . . . . . . . . . . . 9
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 10 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. The Authentication START Packet Body . . . . . . . . . . 10 4.1. The Authentication START Packet Body . . . . . . . . . . 11
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 . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . 16
4.4.2. Common Authentication Flows . . . . . . . . . . . . . 16 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 17
4.4.3. Aborting an Authentication Session . . . . . . . . . 19 4.4.3. Aborting an Authentication Session . . . . . . . . . 20
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 21 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 21
5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 24 5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 24
6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 25 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 26
6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 26 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 27
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 28 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 29
7.1. Authorization Attributes . . . . . . . . . . . . . . . . 29 7.1. Authorization Attributes . . . . . . . . . . . . . . . . 30
7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 31 7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 32
8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 33 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Terminal Access Controller Access-Control System Plus (TACACS+) was
originally conceived as a general Authentication, Authorization and
Accounting protocol. It is primarily used today for Device
Administration: authenticating access to network devices, providing
central authorization of operations, and audit of those operations.
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
document will conform to 'The Draft'. However, some options have document will conform to `The Draft'. However, the following
been removed. This document officially removes SENDPASS for security specific adjustments of the protocol specification from 'The Draft'
reasons. The normative description of Legacy features such as ARAP should be noted:
and outbound authentication have been removed, however the required
enumerations are kept. This document officially removes SENDPASS for security reasons.
The normative description of Legacy features such as ARAP and
outbound authentication have been removed, however the required
enumerations are kept.
Usernames and passwords are specifically mentioned as being
encoded in UTF-8 rather than plain US-ASCII. US-ASCII text is
valid UTF-8, and specification of UTF-8 specifically for username
and password fields enhances interoperability with external
identity systems.
The TACACS+ protocol separates the functions of Authentication, The TACACS+ protocol separates the functions of Authentication,
Authorization and Accounting. It allows for arbitrary length and Authorization and Accounting. It allows for arbitrary length and
content authentication exchanges, which will support any content authentication exchanges, which will support any
authentication mechanism to be utilized with TACACS+ clients. It is authentication mechanism to be utilized with TACACS+ clients. It is
extensible to provide for site customization and future development extensible to provide for site customization and future development
features, and it uses TCP to ensure reliable delivery. The protocol features, and it uses TCP to ensure reliable delivery. The protocol
allows the TACACS+ client to request very fine-grained access control allows the TACACS+ client to request very fine-grained access control
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.
Whilse originally conceived for all access purposes, TACACS+ is This document restricts itself to a description of the protocol that
primarily used today for Device Administration. In addition to is used by TACACS+. It does not cover deployment or best practices.
authenticating access to network devices, it provides central
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
skipping to change at page 5, line 37 skipping to change at page 6, line 7
3. TACACS+ Connections and Sessions 3. TACACS+ Connections and Sessions
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 protocol includes an obfuscation mechanism referred to in the
as obfuscation. It will be referred to here as Body Encryption. A original draft as Body Encryption. It is intended to follow up this
transport based scheme will be specified in a separate document. document with enhancements to TACACS+ security.
It is NOT recommended to deploy TACACS+ without Body encryption, It is recommended to separate the management traffic from the regular
other than for test environments. network access traffic, and to use Body Encryption in production
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.
An accounting and authorization session will consist of a single pair An accounting and authorization session will consist of a single pair
of packets (the request and its reply). An authentication session of packets (the request and its reply). An authentication session
may involve an arbitrary number of packets being exchanged. The may involve an arbitrary number of packets being exchanged. The
skipping to change at page 10, line 17 skipping to change at page 10, line 31
The session id is used in network byte order. The session id is used in network byte order.
Subsequent hashes are generated by using the same input stream, but Subsequent hashes are generated by using the same input stream, but
concatenating the previous hash value at the end of the input stream. concatenating the previous hash value at the end of the input stream.
MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id, MD5_1 = MD5{session_id, key, version, seq_no} MD5_2 = MD5{session_id,
key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key, key, version, seq_no, MD5_1} .... MD5_n = MD5{session_id, key,
version, seq_no, MD5_n-1} version, seq_no, MD5_n-1}
When a server detects that the secret(s) it has configured for the
device mismatch, it MUST return ERROR. The handling of the TCP
connection by the server is implementation independent.
TAC_PLUS_UNENCRYPTED_FLAG == 0x1 TAC_PLUS_UNENCRYPTED_FLAG == 0x1
In this case, the entire packet body is in cleartext. Encryption and In this case, the entire packet body is in cleartext. Encryption and
decryption are null operations. This method should only be used for decryption are null operations. This method should only be used for
debugging. It does not provide data protection or authentication and debugging. It does not provide data protection or authentication and
is highly susceptible to packet spoofing. Implementing this is highly susceptible to packet spoofing. Implementing this
encryption method is optional. encryption method is optional.
NOTE: Implementations should take care not to skip decryption simply NOTE: Implementations should take care not to skip decryption simply
because an incoming packet indicates that it is not encrypted. If because an incoming packet indicates that it is not encrypted. If
skipping to change at page 11, line 4 skipping to change at page 11, line 15
client and the TACACS+ server. client and the TACACS+ server.
If an error must be declared but the type of the incoming packet If an error must be declared but the type of the incoming packet
cannot be determined, a packet with the identical cleartext header cannot be determined, a packet with the identical cleartext header
but with a sequence number incremented by one and the length set to but with a sequence number incremented by one and the length set to
zero MUST be returned to indicate an error. zero MUST be returned to indicate an error.
4. Authentication 4. Authentication
4.1. The Authentication START Packet Body 4.1. The Authentication START Packet Body
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| action | priv_lvl | authen_type | service | | action | priv_lvl | authen_type | authen_service |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user len | port len | rem_addr len | data len | | user len | port len | rem_addr len | data len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user ... | user ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| port ... | port ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| rem_addr ... | rem_addr ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| data... | data...
skipping to change at page 12, line 4 skipping to change at page 12, line 16
TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01
TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 TAC_PLUS_AUTHEN_TYPE_PAP := 0x02
TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03
TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)
TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05
TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06
service authen_service
This is the service that is requesting the authentication. Legal This is the service that is requesting the authentication. Legal
values are: values are:
TAC_PLUS_AUTHEN_SVC_NONE := 0x00 TAC_PLUS_AUTHEN_SVC_NONE := 0x00
TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01 TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01
TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02 TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02
skipping to change at page 12, line 31 skipping to change at page 12, line 44
TAC_PLUS_AUTHEN_SVC_PT := 0x05 TAC_PLUS_AUTHEN_SVC_PT := 0x05
TAC_PLUS_AUTHEN_SVC_RCMD := 0x06 TAC_PLUS_AUTHEN_SVC_RCMD := 0x06
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 TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization
order to grant the user different privileges. This is comparable to application of this field that indicates that no authentication was
the Unix "su(1)" command. A service value of NONE should only be performed by the device.
used when none of the other service values are appropriate. ENABLE
may be requested independently, no requirements for previous The TAC_PLUS_AUTHEN_SVC_LOGIN option is identifies regular login (as
authentications or authorizations are imposed by the protocol. opposed to ENABLE) to a client device.
The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE service,
which 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. ENABLE may be
requested independently, no requirements for previous authentications
or authorizations are imposed by the protocol.
Other options are included for legacy/backwards compatibility.
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 13, line 14 skipping to change at page 13, line 39
An US-ASCII string this is a "best effort" description of the remote An US-ASCII string this is a "best effort" description of the remote
location from which the user has connected to the client. It is location from which the user has connected to the client. It is
intended to hold a network address if the user is connected via a intended to hold a network address if the user is connected via a
network, a caller ID is the user is connected via ISDN or a POTS, or network, a caller ID is the user is connected via ISDN or a POTS, or
any other remote location information that is available. This field any other remote location information that is available. This field
is optional (since the information may not be available). is optional (since the information may not be available).
data data
This field is used to send data appropriate for the action and This field is used to send data appropriate for the action and
authen_type. It is described in more detail below. authen_type. It is described in more detail in the section Common
Authentication flows (Section 4.4.2) .
4.2. The Authentication REPLY Packet Body 4.2. The Authentication REPLY Packet Body
The TACACS+ server sends only one type of authentication packet (a The TACACS+ server sends only one type of authentication packet (a
REPLY packet) to the client. The REPLY packet body looks as follows: REPLY packet) to the client. The REPLY packet body looks as follows:
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| status | flags | server_msg len | | status | flags | server_msg len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
skipping to change at page 14, line 4 skipping to change at page 14, line 35
TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05 TAC_PLUS_AUTHEN_STATUS_GETPASS := 0x05
TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06 TAC_PLUS_AUTHEN_STATUS_RESTART := 0x06
TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07 TAC_PLUS_AUTHEN_STATUS_ERROR := 0x07
TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21 TAC_PLUS_AUTHEN_STATUS_FOLLOW := 0x21
flags flags
Bitmapped flags that modify the action to be taken. The following Bitmapped flags that modify the action to be taken. The following
values are defined: values are defined:
TAC_PLUS_REPLY_FLAG_NOECHO := 0x01 TAC_PLUS_REPLY_FLAG_NOECHO := 0x01
server_msg server_msg
A message to be displayed to the user. This field is optional. If c A message to be displayed to the user. This field is optional. If
it exists, it is intended to be presented to the user. US-ASCII it exists, it is intended to be presented to the user. US-ASCII
charset must be used. charset must be used.
data data
This field holds data that is a part of the authentication exchange This field holds data that is a part of the authentication exchange
and is intended for the client, not the user. Valid uses of this and is intended for the client, not the user. It is described in
field are described below. more detail in the section Common Authentication flows
(Section 4.4.2) .
4.3. The Authentication CONTINUE Packet Body 4.3. The Authentication CONTINUE Packet Body
This packet is sent from the client to the server following the This packet is sent from the client to the server following the
receipt of a REPLY packet. receipt of a REPLY packet.
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user_msg len | data len | | user_msg len | data len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
skipping to change at page 15, line 9 skipping to change at page 15, line 40
flags flags
This holds the bitmapped flags that modify the action to be taken. This holds the bitmapped flags that modify the action to be taken.
The following values are defined: The following values are defined:
TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01 TAC_PLUS_CONTINUE_FLAG_ABORT := 0x01
4.4. Description of Authentication Process 4.4. Description of Authentication Process
Authentications are classified by the action, authen_type and service The action, authen_type and service fields (described above) combine
fields in the START packet of the authentication Session. The user, to determine what kind of authentication is to be performed Every
priv_lvl, service, port and rem_addr in the START packet are all authentication START, REPLY and CONTINUE packet includes a data
provided to help identify the conditions on the client. field. The use of this field is dependent upon the kind of the
Authentication.
The information necessary to transact the authentication is passed in
the data field of every START, REPLY and CONTINUE packet. The usage
of this field varies according to the classification of the
authentication, and is described below. For all REPLY packets, the
server_msg may contain a message to be displayed to the user.
A set of standard authentication classifications is defined in this A set of standard kinds of authentication is defined in this
document. Each authentication flow consists of a START packet. The document. Each authentication flow consists of a START packet. The
server responds either with a request for more information (GETDATA, server responds either with a request for more information (GETDATA,
GETUSER or GETPASS) or a termination (PASS or FAIL). The actions and GETUSER or GETPASS) or a termination (PASS or FAIL). The actions and
meanings when the server sends a RESTART, ERROR or FOLLOW are common meanings when the server sends a RESTART, ERROR or FOLLOW are common
and are described further below. and are described further below.
When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA,
TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS,
then authentication continues and the server_msg may be used by the then authentication continues and the SHOULD provide server_msg
client to prompt the user for more information. The client MUST then content for the client to prompt the user for more information. The
return a CONTINUE packet containing the requested information in the client MUST then return a CONTINUE packet containing the requested
user_msg field. information in the user_msg field.
All three cause the same action to be performed, but in the case of All three cause the same action to be performed, but the use of
TAC_PLUS_AUTHEN_STATUS_GETUSER, the client can know that the TAC_PLUS_AUTHEN_STATUS_GETUSER, indicates to the client that the user
information that the user responds with is a username, and for response will be interpreted as a username, and for
TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents
password. TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic request for will be interpreted as a password. TAC_PLUS_AUTHEN_STATUS_GETDATA is
more information. If the TAC_PLUS_REPLY_FLAG_NOECHO flag is set in the generic request for more information to flexibly support future
the REPLY, then the user response must not be echoed as it is requirements. If the TAC_PLUS_REPLY_FLAG_NOECHO flag is set in the
entered. The data field is only used in the REPLY where explicitly REPLY, then the user response must not be echoed as it is entered.
defined below. The data field is only used in the REPLY where explicitly defined
below.
4.4.1. Version Behaviour 4.4.1. Version Behaviour
The TACACS+ protocol is versioned to allow revisions while The TACACS+ protocol is versioned to allow revisions while
maintaining backwards compatibility. The version number is in every maintaining backwards compatibility. The version number is in every
packet header. The changes between minor_version 0 and 1 apply only packet header. The changes between minor_version 0 and 1 apply only
to the authentication process, and all deal with the way that CHAP to the authentication process, and all deal with the way that CHAP
and PAP authentications are handled. minor_version 1 may only be used and PAP authentications are handled. minor_version 1 may only be used
for authentication classes that explicitly call for it in the table for authentication kinds that explicitly call for it in the table
below: below:
LOGIN CHPASS SENDAUTH LOGIN CHPASS SENDAUTH
ASCII v0 v0 NA ASCII v0 v0 -
PAP v1 NA v1 PAP v1 - v1
CHAP v1 NA v1 CHAP v1 - v1
MS-CHAP v1 NA v1 MS-CHAPv1/2 v1 - v1
The '-' symbol represents that the option is not valid.
When a server receives a packet with a minor_version that it does not When a server receives a packet with a minor_version that it does not
support, it should return an ERROR status with the minor_version set support, it should return an ERROR status with the minor_version set
to the closest supported value. to the closest supported value.
In minor_version 0, CHAP and outbound PAP authentications were In minor_version 0, Inbound PAP performed a normal LOGIN, sending the
performed by the client sending a SENDPASS packet to the server. The username in the START packet and then waiting for a GETPASS and
SENDPASS requested a copy of the user's plaintext password so that sending the password in a CONTINUE packet.
the client could complete the authentication. The CHAP hashing was
performed on the client. Inbound PAP performed a normal LOGIN,
sending the username in the START packet and then waiting for a
GETPASS and sending the password in a CONTINUE packet.
In minor_version 1, CHAP and inbound PAP use LOGIN to perform inbound In minor_version 1, CHAP and inbound PAP use LOGIN to perform inbound
authentication and the exchanges use the data field so that the authentication and the exchanges use the data field so that the
client only sends a single START packet and expects to receive a PASS client only sends a single START packet and expects to receive a PASS
or FAIL. SENDPASS has been deprecated and SENDAUTH introduced, so or FAIL. SENDAUTH is only used for PPP when performing outbound
that the client can request authentication credentials for authentication.
authenticating to a remote peer. SENDAUTH is only used for PPP when
performing outbound authentication.
NOTE: Only those requests which have changed from their minor_version NOTE: Only those requests which have changed from their minor_version
0 implementation (i.e. CHAP, MS-CHAP and PAP authentications) should 0 implementation (i.e. CHAP, MS-CHAP and PAP authentications) should
use the new minor_version number of 1. All other requests (i.e. all use the new minor_version number of 1. All other requests (i.e. all
authorisation and accounting and ASCII authentication) MUST continue authorisation and accounting and ASCII authentication) MUST continue
to use the same minor_version number of 0. The removal of SENDPASS to use the same minor_version number of 0. The removal of SENDPASS
was prompted by security concerns, and is no longer considered part was prompted by security concerns, and is no longer considered part
of the TACACS+ protocol. of the TACACS+ protocol.
4.4.2. Common Authentication Flows 4.4.2. Common Authentication Flows
This section describes the authentication flows that should be This section describes common authentication flows. If the options
supported. are implemented, they MUST follow the description. If the server
does not implement an option, it should respond with
TAC_PLUS_AUTHEN_STATUS_ERROR.
Inbound ASCII Login Inbound ASCII Login
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
minor_version = 0x0 minor_version = 0x0
This is a standard ASCII authentication. The START packet may This is a standard ASCII authentication. The START packet may
contain the username, but need not do so. The data fields in both contain the username, but need not do so. The data fields in both
the START and CONTINUE packets are not used for ASCII logins. There the START and CONTINUE packets are not used for ASCII logins. There
skipping to change at page 18, line 19 skipping to change at page 18, line 42
The length of the challenge value can be determined from the length The length of the challenge value can be determined from the length
of the data field minus the length of the id (always 1 octet) and the of the data field minus the length of the id (always 1 octet) and the
length of the response field (always 49 octets). length of the response field (always 49 octets).
To perform the authentication, the server will use a combination of To perform the authentication, the server will use a combination of
MD4 and DES on the user's secret and the challenge, as defined in RFC MD4 and DES on the user's secret and the challenge, as defined in RFC
2433 [RFC2433] and then compare the resulting value with the 2433 [RFC2433] and then compare the resulting value with the
response. The REPLY from the server MUST be a PASS or FAIL. response. The REPLY from the server MUST be a PASS or FAIL.
For best practices, please refer to RFC 2433 [RFC2433]
Inbound MS-CHAP v2 login Inbound MS-CHAP v2 login
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2
minor_version = 0x1 minor_version = 0x1
The entire exchange MUST consist of a single START packet and a The entire exchange MUST consist of a single START packet and a
single REPLY. The START packet MUST contain the username in the user single REPLY. The START packet MUST contain the username in the user
field and the data field will be a concatenation of the PPP id, the field and the data field will be a concatenation of the PPP id, the
MS-CHAP challenge and the MS-CHAP response. MS-CHAP challenge and the MS-CHAP response.
The length of the challenge value can be determined from the length The length of the challenge value can be determined from the length
of the data field minus the length of the id (always 1 octet) and the of the data field minus the length of the id (always 1 octet) and the
length of the response field (always 49 octets). length of the response field (always 49 octets).
To perform the authentication, the server will use a the algorithm To perform the authentication, the server will use a the algorithm
specified RFC RFC2759 [RFC2759] on the user's secret and challenge specified RFC2759 [RFC2759] on the user's secret and challenge and
and then compare the resulting value with the response. The REPLY then compare the resulting value with the response. The REPLY from
from the server MUST be a PASS or FAIL. the server MUST be a PASS or FAIL.
For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759]
Enable Requests Enable Requests
action = TAC_PLUS_AUTHEN_LOGIN action = TAC_PLUS_AUTHEN_LOGIN
priv_lvl = implementation dependent priv_lvl = implementation dependent
authen_type = not used authen_type = not used
service = TAC_PLUS_AUTHEN_SVC_ENABLE service = TAC_PLUS_AUTHEN_SVC_ENABLE
This is an ENABLE request, used to change the current running This is an ENABLE request, used to change the current running
privilege level of a principal. The exchange MAY consist of multiple privilege level of a principal. The exchange MAY consist of multiple
messages while the server collects the information it requires in messages while the server collects the information it requires in
order to allow changing the principal's privilege level. This order to allow changing the principal's privilege level. This
exchange is very similar to an Inbound ASCII login (which see). exchange is very similar to an Inbound ASCII login.
In order to readily distinguish enable requests from other types of In order to readily distinguish enable requests from other types of
request, the value of the service field MUST be set to request, the value of the service field MUST be set to
TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be TAC_PLUS_AUTHEN_SVC_ENABLE when requesting an ENABLE. It MUST NOT be
set to this value when requesting any other operation. set to this value when requesting any other operation.
ASCII change password request ASCII change password request
action = TAC_PLUS_AUTHEN_CHPASS action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
skipping to change at page 19, line 45 skipping to change at page 20, line 27
contain a message to be displayed to the user. contain a message to be displayed to the user.
When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet
indicates that the TACACS+ server requests that authentication should indicates that the TACACS+ server requests that authentication should
be performed with an alternate server. The data field MUST contain be performed with an alternate server. The data field MUST contain
ASCII text describing one or more servers. A server description ASCII text describing one or more servers. A server description
appears like this: appears like this:
[@<protocol>@]<host>>[@<key>] [@<protocol>@]<host>>[@<key>]
The protocol and key are optional. The protocol can describe an If more than one host is specified, they MUST be separated into rows
alternate way of performing the authentication, other than TACACS+. by an ASCII Carriage Return (0x0D).
If the protocol is not present, then TACACS+ is assumed.
The protocol and key are optional, and apply only to host in the same
row. The protocol can describe an alternate way of performing the
authentication, other than TACACS+. If the protocol is not present,
then TACACS+ is assumed.
Protocols are ASCII numbers corresponding to the methods listed in Protocols are ASCII numbers corresponding to the methods listed in
the authen_method field of authorization packets (defined below). the authen_method field of authorization packets (defined below).
The host is specified as either a fully qualified domain name, or an The host is specified as either a fully qualified domain name, or an
ASCII numeric IP address specified as octets separated by dots (`.'). ASCII numeric IPV4 address specified as octets separated by dots
(`.'), or IPV6
If a key is supplied, the client MAY use the key in order to If a key is supplied, the client MAY use the key in order to
authenticate to that host. If more than one host is specified, they authenticate to that host. The client may use a preconfigured key
MUST be separated by an ASCII Carriage Return (0x0D). for the host if it has one. If not then the client may communicate
with the host using unencrypted option.
Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the
discretion of the TACACS+ client. It may choose to use any one, all discretion of the TACACS+ client. It may choose to use any one, all
or none of these hosts. If it chooses to use none, then it MUST or none of these hosts. If it chooses to use none, then it MUST
treat the authentication as if the return status was treat the authentication as if the return status was
TAC_PLUS_AUTHEN_STATUS_FAIL. TAC_PLUS_AUTHEN_STATUS_FAIL.
While the order of hosts in this packet indicates a preference, but While the order of hosts in this packet indicates a preference, but
the client is not obliged to use that ordering. the client is not obliged to use that ordering.
skipping to change at page 20, line 33 skipping to change at page 21, line 20
authentication should proceed as if that host could not be contacted. authentication should proceed as if that host could not be contacted.
The data field may contain a message to be printed on an The data field may contain a message to be printed on an
administrative console or log. administrative console or log.
If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the
authentication sequence should be restarted with a new START packet authentication sequence should be restarted with a new START packet
from the client. This REPLY packet indicates that the current from the client. This REPLY packet indicates that the current
authen_type value (as specified in the START packet) is not authen_type value (as specified in the START packet) is not
acceptable for this session, but that others may be. acceptable for this session, but that others may be.
The TAC_PLUS_AUTHEN_STATUS_RESTART REPLY packet may contain a list of If a client chooses not to accept the TAC_PLUS_AUTHEN_STATUS_RESTART
valid authen_type values in the data portion of the packet. The packet, then it should be TREATED as if the status was
authen_type values are a single byte in length so the data_len value TAC_PLUS_AUTHEN_STATUS_FAIL.
indicates the number of authen_type values included. This packet is
only currently intended for PPP authentication when multiple
authentication mechanisms are available and can be negotiated between
the client and the remote peer. This also requires future PPP
authentication extensions which have not yet been passed through the
IETF. If a client chooses not to accept the
TAC_PLUS_AUTHEN_STATUS_RESTART packet, then it should be TREATED as
if the status was TAC_PLUS_AUTHEN_STATUS_FAIL.
5. Authorization 5. Authorization
This part of the TACACS+ protocol provides an extensible way of This part of the TACACS+ protocol provides an extensible way of
providing remote authorization services. An authorization session is providing remote authorization services. An authorization session is
defined as a single pair of messages, a REQUEST followed by a defined as a single pair of messages, a REQUEST followed by a
RESPONSE. RESPONSE.
The authorization REQUEST message contains a fixed set of fields that The authorization REQUEST message contains a fixed set of fields that
describe the authenticity of the user or process, and a variable set indicate how the user was authenticated or processed and a variable
of arguments that describe the services and options for which set of arguments that describe the services and options for which
authorization is requested. authorization is requested.
The RESPONSE contains a variable set of response arguments The RESPONSE contains a variable set of response arguments
(attribute-value pairs) that can restrict or modify the clients (attribute-value pairs) that can restrict or modify the clients
actions. actions.
The arguments in both a REQUEST and a RESPONSE can be specified as The arguments in both a REQUEST and a RESPONSE can be specified as
either mandatory or optional. An optional argument is one that may either mandatory or optional. An optional argument is one that may
or may not be used, modified or even understood by the recipient. or may not be used, modified or even understood by the recipient.
skipping to change at page 22, line 21 skipping to change at page 23, line 4
TAC_PLUS_AUTHEN_METH_LOCAL := 0x05 TAC_PLUS_AUTHEN_METH_LOCAL := 0x05
TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06 TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06
TAC_PLUS_AUTHEN_METH_GUEST := 0x08 TAC_PLUS_AUTHEN_METH_GUEST := 0x08
TAC_PLUS_AUTHEN_METH_RADIUS := 0x10 TAC_PLUS_AUTHEN_METH_RADIUS := 0x10
TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 TAC_PLUS_AUTHEN_METH_KRB4 := 0x11
TAC_PLUS_AUTHEN_METH_RCMD := 0x20 TAC_PLUS_AUTHEN_METH_RCMD := 0x20
KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed KRB5 and KRB4 are Kerberos version 5 and 4. LINE refers to a fixed
password associated with the line used to gain access. LOCAL is a password associated with the terminal line used to gain access.
client local user database. ENABLE is a command that authenticates LOCAL is a client local user database. ENABLE is a command that
in order to grant new privileges. TACACSPLUS is, of course, TACACS+. authenticates in order to grant new privileges. TACACSPLUS is, of
GUEST is an unqualified guest authentication, such as an ARAP guest course, TACACS+. GUEST is an unqualified guest authentication, such
login. RADIUS is the Radius authentication protocol. RCMD refers to as an ARAP guest login. RADIUS is the Radius authentication
authentication provided via the R-command protocols from Berkeley protocol. RCMD refers to authentication provided via the R-command
Unix. (One should be aware of the security limitations to R-command protocols from Berkeley Unix. (One should be aware of the security
authentication.) limitations to R-command authentication.)
priv_lvl priv_lvl
This field matches the priv_lvl field in authentication request and This field is used in the same way as the priv_lvl field in
is described in the Privilege Level section (Section 8) below. It authentication request and is described in the Privilege Level
indicates the users current privilege level. section (Section 8) below. It 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. If this information is not available, then the that was performed. If this information is not available, then the
client should set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := client should set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET :=
0x00. This value is valid only in authorization and accounting 0x00. This value is valid only in authorization and accounting
requests. requests.
skipping to change at page 23, line 38 skipping to change at page 24, line 21
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 It is not legal for an attribute name to contain either of the
separators. It is legal for attribute values to contain the
separators. 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. the minimum is two characters (one name
value and the separator)
5.2. The Authorization RESPONSE Packet Body 5.2. The Authorization RESPONSE Packet Body
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| status | arg_cnt | server_msg len | | status | arg_cnt | server_msg len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
+ data len | arg 1 len | arg 2 len | + data len | arg 1 len | arg 2 len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| ... | arg N len | server_msg ... | ... | arg N len | server_msg ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| data ... | data ...
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
skipping to change at page 25, line 39 skipping to change at page 26, line 36
arg_cnt MUST be 0. In that case, the actions to be taken and the arg_cnt MUST be 0. In that case, the actions to be taken and the
contents of the data field are identical to the contents of the data field are identical to the
TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. None of the TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. None of the
arg values have any relevance if an ERROR is set, and must be arg values have any relevance if an ERROR is set, and must be
ignored. ignored.
6. Accounting 6. Accounting
6.1. The Account REQUEST Packet Body 6.1. The Account REQUEST Packet Body
TACACS+ accounting is very similar to authorization. The packet for- TACACS+ accounting is very similar to authorization. The packet
mat is also similar. There is a fixed portion and an extensible por- format is also similar. There is a fixed portion and an extensible
tion. The extensible portion uses all the same attribute-value pairs portion. The extensible portion uses all the same attribute-value
that authorization uses, and adds several more. pairs that authorization uses, and adds several more.
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 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
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| flags | authen_method | priv_lvl | authen_type | | flags | authen_method | priv_lvl | authen_type |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| authen_service | user len | port len | rem_addr len | | authen_service | user len | port len | rem_addr len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg_cnt | arg 1 len | arg 2 len | ... | | arg_cnt | arg 1 len | arg 2 len | ... |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| arg N len | user ... | arg N len | user ...
skipping to change at page 28, line 46 skipping to change at page 29, line 46
All boolean attributes are encoded with values "true" or "false". All boolean attributes are encoded with values "true" or "false".
It is recommended that hosts be specified as a numeric address so as It is recommended that hosts be specified as a numeric address so as
to avoid any ambiguities. to avoid any ambiguities.
Absolute times should be specified in seconds since the epoch, Absolute times should be specified in seconds since the epoch,
12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone 12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone
attribute is specified. attribute is specified.
A value of NULL means an attribute with a zero length string for its Attributes may be submitted with no value, in which case they consist
value i.e. cmd=NULL is actually transmitted as the string of 4 of the name and the mandatory or optional separator. For example,
characters "cmd=". the attribute "cmd" which has no value is transmitted as a string of
4 characters "cmd="
7.1. Authorization Attributes 7.1. Authorization Attributes
service service
The primary service. Specifying a service attribute indicates that The primary service. Specifying a service attribute indicates that
this is a request for authorization or accounting of that service. this is a request for authorization or accounting of that service.
Current values are "slip", "ppp", "shell", "tty-server", Current values are "slip", "ppp", "shell", "tty-server",
"connection", "system" and "firewall". This attribute MUST always be "connection", "system" and "firewall". This attribute MUST always be
included. included.
skipping to change at page 29, line 26 skipping to change at page 30, line 26
a protocol that is a subset of a service. An example would be any a protocol that is a subset of a service. An example would be any
PPP NCP. Currently known values are "lcp", "ip", "ipx", "atalk", PPP NCP. Currently known values are "lcp", "ip", "ipx", "atalk",
"vines", "lat", "xremote", "tn3270", "telnet", "rlogin", "pad", "vines", "lat", "xremote", "tn3270", "telnet", "rlogin", "pad",
"vpdn", "ftp", "http", "deccp", "osicp" and "unknown". "vpdn", "ftp", "http", "deccp", "osicp" and "unknown".
cmd cmd
a shell (exec) command. This indicates the command name for a shell a shell (exec) command. This indicates the command name for a shell
command that is to be run. This attribute MUST be specified if command that is to be run. This attribute MUST be specified if
service equals "shell". A NULL value indicates that the shell itself service equals "shell". If no value is present then the shell itself
is being referred to. is being referred to.
cmd-arg cmd-arg
an argument to a shell (exec) command. This indicates an argument an argument to a shell (exec) command. This indicates an argument
for the shell command that is to be run. Multiple cmd-arg attributes for the shell command that is to be run. Multiple cmd-arg attributes
may be specified, and they are order dependent. may be specified, and they are order dependent.
acl acl
US-ASCII number representing a connection access list. Used only US-ASCII number representing a connection access list. Used only
when service=shell and cmd=NULL when value of service is "shell"" and cmd has no value.
inacl inacl
US-ASCII identifier for an interface input access list. US-ASCII identifier for an interface input access list.
outacl outacl
US-ASCII identifier for an interface output access list. US-ASCII identifier for an interface output access list.
zonelist zonelist
skipping to change at page 30, line 44 skipping to change at page 31, line 44
an auto-command to run. Used only when service=shell and cmd=NULL an auto-command to run. Used only when service=shell and cmd=NULL
noescape noescape
Boolean. Prevents user from using an escape character. Used only Boolean. Prevents user from using an escape character. Used only
when service=shell and cmd=NULL when service=shell and cmd=NULL
nohangup nohangup
Boolean. Do no disconnect after an automatic command. Used only Boolean. Do not disconnect after an automatic command. Used only
when service=shell and cmd=NULL when service=shell and cmd=NULL
priv-lvl priv-lvl
privilege level to be assigned. Please refer to the Privilege Level privilege level to be assigned. Please refer to the Privilege Level
section (Section 8) below. section (Section 8) below.
remote_user remote_user
remote userid (authen_method must have the value remote userid (authen_method must have the value
 End of changes. 56 change blocks. 
143 lines changed or deleted 174 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/