draft-ietf-opsawg-tacacs-16.txt   draft-ietf-opsawg-tacacs-17.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: May 20, 2020 D. Medway Gash Expires: July 30, 2020 D. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
D. Carrel D. Carrel
vIPtela, Inc. vIPtela, Inc.
L. Grant L. Grant
November 17, 2019 January 27, 2020
The TACACS+ Protocol The TACACS+ Protocol
draft-ietf-opsawg-tacacs-16 draft-ietf-opsawg-tacacs-17
Abstract Abstract
Terminal Access Controller Access-Control System Plus (TACACS+) This document describes the Terminal Access Controller Access-Control
provides Device Administration for routers, network access servers System Plus (TACACS+) protocol which is widely deployed today to
and other networked computing devices via one or more centralized provide Device Administration for routers, network access servers and
servers. This document describes the protocol that is used by other networked computing devices via one or more centralized
TACACS+. servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 20, 2020. This Internet-Draft will expire on July 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 3. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4
3.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Packet . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Packet . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Connection . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Treatment of Enumerated Protocol Values . . . . . . . . . 5 3.6. Treatment of Enumerated Protocol Values . . . . . . . . . 5
3.7. Treatment of Text Strings . . . . . . . . . . . . . . . . 5 3.7. Treatment of Text Strings . . . . . . . . . . . . . . . . 6
4. TACACS+ Packets and Sessions . . . . . . . . . . . . . . . . 6 4. TACACS+ Packets and Sessions . . . . . . . . . . . . . . . . 6
4.1. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 6 4.1. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 6
4.2. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 8 4.2. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 8
4.3. Single Connection Mode . . . . . . . . . . . . . . . . . 8 4.3. Single Connection Mode . . . . . . . . . . . . . . . . . 8
4.4. Session Completion . . . . . . . . . . . . . . . . . . . 9 4.4. Session Completion . . . . . . . . . . . . . . . . . . . 9
4.5. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 10 4.5. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 11
5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 12 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. The Authentication START Packet Body . . . . . . . . . . 12 5.1. The Authentication START Packet Body . . . . . . . . . . 13
5.2. The Authentication REPLY Packet Body . . . . . . . . . . 15 5.2. The Authentication REPLY Packet Body . . . . . . . . . . 15
5.3. The Authentication CONTINUE Packet Body . . . . . . . . . 16 5.3. The Authentication CONTINUE Packet Body . . . . . . . . . 17
5.4. Description of Authentication Process . . . . . . . . . . 17 5.4. Description of Authentication Process . . . . . . . . . . 17
5.4.1. Version Behavior . . . . . . . . . . . . . . . . . . 17 5.4.1. Version Behavior . . . . . . . . . . . . . . . . . . 18
5.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 5.4.2. Common Authentication Flows . . . . . . . . . . . . . 19
5.4.3. Aborting an Authentication Session . . . . . . . . . 21 5.4.3. Aborting an Authentication Session . . . . . . . . . 22
6. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23 6.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23
6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 27
7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 29
7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 30
8. Argument-Value Pairs . . . . . . . . . . . . . . . . . . . . 31 8. Argument-Value Pairs . . . . . . . . . . . . . . . . . . . . 31
8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 32
8.2. Authorization Arguments . . . . . . . . . . . . . . . . . 32 8.2. Authorization Arguments . . . . . . . . . . . . . . . . . 33
8.3. Accounting Arguments . . . . . . . . . . . . . . . . . . 34 8.3. Accounting Arguments . . . . . . . . . . . . . . . . . . 35
9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10.1. General Security of the Protocol . . . . . . . . . . . . 37 10.1. General Security of the Protocol . . . . . . . . . . . . 37
10.2. Security of Authentication Sessions . . . . . . . . . . 38 10.2. Security of Authentication Sessions . . . . . . . . . . 38
10.3. Security of Authorization Sessions . . . . . . . . . . . 38 10.3. Security of Authorization Sessions . . . . . . . . . . . 39
10.4. Security of Accounting Sessions . . . . . . . . . . . . 39 10.4. Security of Accounting Sessions . . . . . . . . . . . . 39
10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39 10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 40
10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39 10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 40
10.5.2. Connections and Obfuscation . . . . . . . . . . . . 40 10.5.2. Connections and Obfuscation . . . . . . . . . . . . 41
10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41 10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 42
10.5.4. Authorization . . . . . . . . . . . . . . . . . . . 42 10.5.4. Authorization . . . . . . . . . . . . . . . . . . . 42
10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 42 10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
Terminal Access Controller Access-Control System Plus (TACACS+) was This document describes the Terminal Access Controller Access-Control
conceived initially as a general Authentication, Authorization and System Plus (TACACS+) protocol. It was conceived initially as a
Accounting protocol. It's use today is mainly confined to Device general Authentication, Authorization and Accounting (AAA) protocol.
Administration: authenticating access to network devices, providing It is widely deployed today but is mainly confined for a specific
central authorization of operations, and audit of those operations. subset of AAA: Device Administration, that is: 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, and draft document that was originally intended for IETF publication, but
is known as `The Draft' [TheDraft]. This did not address all of the was never standardized. The draft document is known as `The Draft'
[TheDraft].
This Draft was a product of its time, and did not address all of the
key security concerns which are considered when designing modern key security concerns which are considered when designing modern
standards. Deployment must therefore be executed with care. These standards. Deployment must therefore be executed with care. These
concerns are addressed in the security section (Section 10). concerns are addressed in the security section (Section 10).
This is intended to document the TACACS+ protocol as it is currently The primary intent of this informational document is to clarify the
deployed. It is intended that all implementations which conform to subset of `The Draft' which is common to implementations supporting
this document will conform to `The Draft'. However, attention is Device Administration. It is intended that all implementations which
drawn to the following specific adjustments of the protocol conform to this document will conform to `The Draft'. However, it is
specification from 'The Draft': not intended that all implementations which conform to 'The Draft'
will conform to this document. The following features from `The
Draft' have been removed:
This document officially removes SENDPASS for security reasons. This document officially removes SENDPASS for security reasons.
The normative description of Legacy features such as ARAP and The normative description of Legacy features such as ARAP and
outbound authentication has been removed. outbound authentication has been removed.
The Support for forwarding to an alternative daemon The Support for forwarding to an alternative daemon
(TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated. (TAC_PLUS_AUTHEN_STATUS_FOLLOW) has been deprecated.
The TACACS+ protocol allows for arbitrary length and content The TACACS+ protocol allows for arbitrary length and content
skipping to change at page 6, line 41 skipping to change at page 7, line 5
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | | |
| session_id | | session_id |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| | | |
| length | | length |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
The following general rules apply to all TACACS+ packet types: The following general rules apply to all TACACS+ packet types:
- To signal that any variable length data fields are unused, their - To signal that any variable length data fields are unused, the
length value is set to zero. Such fields MUST be ignored, and corresponding length values are set to zero. Such fields MUST be
treated as if not present. ignored, and treated as if not present.
- the lengths of data and message fields in a packet are specified - the lengths of data and message fields in a packet are specified
by their corresponding length fields, (and are not null by their corresponding length fields, (and are not null
terminated.) terminated.)
- All length values are unsigned and in network byte order. - All length values are unsigned and in network byte order.
major_version major_version
This is the major TACACS+ version number. This is the major TACACS+ version number.
TAC_PLUS_MAJOR_VER := 0xc TAC_PLUS_MAJOR_VER := 0xc
minor_version minor_version
The minor TACACS+ version number. The minor TACACS+ version number.
TAC_PLUS_MINOR_VER_DEFAULT := 0x0 TAC_PLUS_MINOR_VER_DEFAULT := 0x0
skipping to change at page 7, line 39 skipping to change at page 8, line 4
in a session MUST have the sequence number 1 and each subsequent in a session MUST have the sequence number 1 and each subsequent
packet will increment the sequence number by one. TACACS+ Clients packet will increment the sequence number by one. TACACS+ Clients
only send packets containing odd sequence numbers, and TACACS+ only send packets containing odd sequence numbers, and TACACS+
servers only send packets containing even sequence numbers. servers only send packets containing even sequence numbers.
The sequence number must never wrap i.e. if the sequence number 2^8-1 The sequence number must never wrap i.e. if the sequence number 2^8-1
is ever reached, that session must terminate and be restarted with a is ever reached, that session must terminate and be restarted with a
sequence number of 1. sequence number of 1.
flags flags
This field contains various bitmapped flags. This field contains various bitmapped flags.
The flag bit: The flag bit:
TAC_PLUS_UNENCRYPTED_FLAG := 0x01 TAC_PLUS_UNENCRYPTED_FLAG := 0x01
This flag indicates that the sender did not obfuscate the body of the This flag indicates that the sender did not obfuscate the body of the
packet. The application of this flag will be covered in the security packet. This option MUST NOT be used in production. The application
section (Section 10). of this flag will be covered in the security section (Section 10).
This flag SHOULD be clear in all deployments. Modern network traffic This flag SHOULD be clear in all deployments. Modern network traffic
tools support encrypted traffic when configured with the shared tools support encrypted traffic when configured with the shared
secret (see section below), so obfuscated mode can and SHOULD be used secret (see section below), so obfuscated mode can and SHOULD be used
even during test. even during test.
The single-connection flag: The single-connection flag:
TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04
skipping to change at page 8, line 37 skipping to change at page 8, line 49
The total length of the packet body (not including the header). The total length of the packet body (not including the header).
4.2. The TACACS+ Packet Body 4.2. The TACACS+ Packet Body
The TACACS+ body types are defined in the packet header. The next The TACACS+ body types are defined in the packet header. The next
sections of this document will address the contents of the different sections of this document will address the contents of the different
TACACS+ bodies. TACACS+ bodies.
4.3. Single Connection Mode 4.3. Single Connection Mode
Single Connection Mode is intended to improve performance by allowing Single Connection Mode is intended to improve performance where there
a client to multiplex multiple session on a single TCP connection. is a lot of traffic between a client and a server by allowing the
client to multiplex multiple session on a single TCP connection.
The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by
the client and server to negotiate the use of Single Connect Mode. the client and server to negotiate the use of Single Connect Mode.
The client sets this flag, to indicate that it supports multiplexing The client sets this flag, to indicate that it supports multiplexing
TACACS+ sessions over a single TCP connection. The client MUST NOT TACACS+ sessions over a single TCP connection. The client MUST NOT
send a second packet on a connection until single-connect status has send a second packet on a connection until single-connect status has
been established. been established.
To indicate it will support Single Connection Mode, the server sets To indicate it will support Single Connection Mode, the server sets
skipping to change at page 9, line 23 skipping to change at page 9, line 35
If single Connection Mode has not been established in the first two If single Connection Mode has not been established in the first two
packets of a TCP connection, then both the client and the server packets of a TCP connection, then both the client and the server
close the connection at the end of the first session. close the connection at the end of the first session.
The client negotiates Single Connection Mode to improve efficiency. The client negotiates Single Connection Mode to improve efficiency.
The server may refuse to allow Single Connection Mode for the client. The server may refuse to allow Single Connection Mode for the client.
For example, it may not be appropriate to allocate a long-lasting TCP For example, it may not be appropriate to allocate a long-lasting TCP
connection to a specific client in some deployments. Even if the connection to a specific client in some deployments. Even if the
server is configured to permit single Connection Mode for a specific server is configured to permit single Connection Mode for a specific
client, the server may close the connection. For example: a server client, the server may close the connection. For example: a server
may be configured to time out a Single Connection Mode TCP Connection MUST be configured to time out a Single Connection Mode TCP
after a specific period of inactivity to preserve its resources. The Connection after a specific period of inactivity to preserve its
client MUST accommodate such closures on a TCP session even after resources. The client MUST accommodate such closures on a TCP
Single Connection Mode has been established. session even after Single Connection Mode has been established.
The TCP connection underlying the Single Connection Mode will close
eventually, either because of the timeout from the server or from an
intermediate link. If a session is in progress when the client
detects disconnect then the client should handle it as described in
Section 4.4. If a session is not in progress, then the client will
need to detect this, and restart the single connection mode when the
it initiates the next session.
4.4. Session Completion 4.4. Session Completion
The REPLY packets defined for the packets types in the sections below The REPLY packets defined for the packets types in the sections below
(Authentication, Authorization and Accounting) contain a status (Authentication, Authorization and Accounting) contain a status
field. The complete set of options for this field depend upon the field. The complete set of options for this field depend upon the
packet type, but all three REPLY packet types define values packet type, but all three REPLY packet types define values
representing PASS, ERROR and FAIL, which indicate the last packet of representing PASS, ERROR and FAIL, which indicate the last packet of
a regular session (one which is not aborted). a regular session (one which is not aborted).
The server responds with a PASS or a FAIL to indicate that the The server responds with a PASS or a FAIL to indicate that the
processing of the request completed and the client can apply the processing of the request completed and the client can apply the
result (PASS or FAIL) to control the execution of the action which result (PASS or FAIL) to control the execution of the action which
prompted the request to be sent to the server. prompted the request to be sent to the server.
The server responds with an ERROR to indicate that the processing of The server responds with an ERROR to indicate that the processing of
the request did not complete. The client can not apply the result the request did not complete. The client cannot apply the result and
and it MUST behave as if the server could not be connected to. For it MUST behave as if the server could not be connected to. For
example, the client tries alternative methods, if they are available, example, the client tries alternative methods, if they are available,
such as sending the request to a backup server, or using local such as sending the request to a backup server, or using local
configuration to determine whether the action which prompted the configuration to determine whether the action which prompted the
request should be executed. request should be executed.
Refer to the section (Section 5.4.3) on Aborting Authentication Refer to Section 5.4.3 on Aborting Authentication Sessions for
Sessions for details on handling additional status options. details on handling additional status options.
When the session is complete, then the TCP connection should be When the session is complete, then the TCP connection should be
handled as follows, according to whether Single Connection Mode was handled as follows, according to whether Single Connection Mode was
negotiated: negotiated:
If Single Connection Mode was not negotiated, then the connection If Single Connection Mode was not negotiated, then the connection
should be closed should be closed
If Single Connection Mode was enabled, then the connection SHOULD be If Single Connection Mode was enabled, then the connection SHOULD be
left open (see section (Section 4.3)), but may still be closed after left open (see Section 4.3), but may still be closed after a timeout
a timeout period to preserve deployment resources. period to preserve deployment resources.
If Single Connection Mode was enabled, but an ERROR occurred due to If Single Connection Mode was enabled, but an ERROR occurred due to
connection issues (such as an incorrect secret, see section connection issues (such as an incorrect secret, see Section 4.5),
(Section 4.5)), then any further new sessions MUST NOT be accepted on then any further new sessions MUST NOT be accepted on the connection.
the connection. If there are any sessions that have already been If there are any sessions that have already been established then
established then they MAY be completed. Once all active sessions are they MAY be completed. Once all active sessions are completed then
completed then the connection MUST be closed. the connection MUST be closed.
It is recommended that client implementations provide robust schemes It is recommended that client implementations provide robust schemes
for dealing with servers which cannot be connected to. Options for dealing with servers which cannot be connected to. Options
include providing a list of servers for redundancy, and an option for include providing a list of servers for redundancy, and an option for
a local fallback configuration if no servers can be reached. Details a local fallback configuration if no servers can be reached. Details
will be implementation specific. will be implementation specific.
The client should manage connections and handle the case of a server The client should manage connections and handle the case of a server
which establishes a connection, but does not respond. The exact which establishes a connection, but does not respond. The exact
behavior is implementation specific. It is recommended that the behavior is implementation specific. It is recommended that the
skipping to change at page 10, line 50 skipping to change at page 11, line 21
termed as encryption in this document. termed as encryption in this document.
The obfuscation mechanism relies on a secret key, a shared secret The obfuscation mechanism relies on a secret key, a shared secret
value that is known to both the client and the server. The secret value that is known to both the client and the server. The secret
keys MUST remain secret. keys MUST remain secret.
Server implementations MUST allow a unique secret key to be Server implementations MUST allow a unique secret key to be
associated with each client. It is a site-dependent decision as to associated with each client. It is a site-dependent decision as to
whether the use of separate keys is appropriate. whether the use of separate keys is appropriate.
The flag field may be set as follows: The flag field MUST be configured with the following bit as follows:
TAC_PLUS_UNENCRYPTED_FLAG = 0x0 TAC_PLUS_UNENCRYPTED_FLAG = 0x0
In this case, the packet body is obfuscated by XOR-ing it byte-wise
with a pseudo-random pad. So that the packet body is obfuscated by XOR-ing it byte-wise with a
pseudo-random pad.
ENCRYPTED {data} = data ^ pseudo_pad ENCRYPTED {data} = data ^ pseudo_pad
The packet body can then be de-obfuscated by XOR-ing it byte-wise The packet body can then be de-obfuscated by XOR-ing it byte-wise
with a pseudo random pad. with a pseudo random pad.
data = ENCRYPTED {data} ^ pseudo_pad data = ENCRYPTED {data} ^ pseudo_pad
The pad is generated by concatenating a series of MD5 hashes (each 16 The pad is generated by concatenating a series of MD5 hashes (each 16
bytes long) and truncating it to the length of the input data. bytes long) and truncating it to the length of the input data.
skipping to change at page 11, line 30 skipping to change at page 12, line 4
pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data) pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data)
The first MD5 hash is generated by concatenating the session_id, the The first MD5 hash is generated by concatenating the session_id, the
secret key, the version number and the sequence number and then secret key, the version number and the sequence number and then
running MD5 over that stream. All of those input values are running MD5 over that stream. All of those input values are
available in the packet header, except for the secret key which is a available in the packet header, except for the secret key which is a
shared secret between the TACACS+ client and server. shared secret between the TACACS+ client and server.
The version number and session_id are extracted from the header The version number and session_id are extracted from the header
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 When a server detects that the secret(s) it has configured for the
device mismatch, it MUST return ERROR. For details of TCP connection device mismatch, it MUST return ERROR. For details of TCP connection
handling on ERROR, refer to section (Section 4.4). handling on ERROR, refer to Section 4.4.
TAC_PLUS_UNENCRYPTED_FLAG == 0x1 TAC_PLUS_UNENCRYPTED_FLAG == 0x1
In this case, the entire packet body is in cleartext. Obfuscation This option is deprecated and MUST NOT be used in production. In
and de-obfuscation are null operations. This method should be this case, the entire packet body is in cleartext. A request MUST be
avoided unless absolutely required for debug purposes, when tooling dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true.
does not permit de-obfuscation.
If deployment is configured for obfuscating a connection then the
request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true.
After a packet body is de-obfuscated, the lengths of the component After a packet body is de-obfuscated, the lengths of the component
values in the packet are summed. If the sum is not identical to the values in the packet are summed. If the sum is not identical to the
cleartext datalength value from the header, the packet MUST be cleartext datalength value from the header, the packet MUST be
discarded, and an ERROR signaled. For details of TCP connection discarded, and an ERROR signaled. For details of TCP connection
handling on ERROR, refer to section (Section 4.4). handling on ERROR, refer to Section 4.4.
Commonly such failures are seen when the keys are mismatched between Commonly such failures are seen when the keys are mismatched between
the client and the TACACS+ server. the client and the TACACS+ server.
5. Authentication 5. 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
employs a name and a fixed password. However, fixed passwords are employs a name and a fixed password. However, fixed passwords are
vulnerable security, so many modern authentication mechanisms utilize vulnerable security, so many modern authentication mechanisms utilize
skipping to change at page 21, line 49 skipping to change at page 22, line 27
5.4.3. Aborting an Authentication Session 5.4.3. Aborting an Authentication Session
The client may prematurely terminate a session by setting the The client may prematurely terminate a session by setting the
TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this
flag is set, the data portion of the message may contain a message flag is set, the data portion of the message may contain a message
explaining the reason for the abort. For details of text encoding, explaining the reason for the abort. For details of text encoding,
see (Section 3.7). This information will be handled by the server see (Section 3.7). This information will be handled by the server
according to the requirements of the deployment. The session is according to the requirements of the deployment. The session is
terminated, for more details about session termination, refer to terminated, for more details about session termination, refer to
section (Section 4.4). Section 4.4.
In cases of PASS, FAIL or ERROR, the server can insert a message into In cases of PASS, FAIL or ERROR, the server can insert a message into
server_msg to be displayed to the user. server_msg to be displayed to the user.
The Draft `The Draft' [TheDraft] defined a mechanism to direct The Draft `The Draft' [TheDraft] defined a mechanism to direct
authentication requests to an alternative server. This mechanism is authentication requests to an alternative server. This mechanism is
regarded as insecure, is deprecated, and not covered here. The regarded as insecure, is deprecated, and not covered here. The
client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as
TAC_PLUS_AUTHEN_STATUS_FAIL TAC_PLUS_AUTHEN_STATUS_FAIL
skipping to change at page 24, line 4 skipping to change at page 24, line 41
subject to verification, it is recommended that this field is subject to verification, it is recommended that this field is
ignored. ignored.
TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00 TAC_PLUS_AUTHEN_METH_NOT_SET := 0x00
TAC_PLUS_AUTHEN_METH_NONE := 0x01 TAC_PLUS_AUTHEN_METH_NONE := 0x01
TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 TAC_PLUS_AUTHEN_METH_KRB5 := 0x02
TAC_PLUS_AUTHEN_METH_LINE := 0x03 TAC_PLUS_AUTHEN_METH_LINE := 0x03
TAC_PLUS_AUTHEN_METH_ENABLE := 0x04 TAC_PLUS_AUTHEN_METH_ENABLE := 0x04
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. This document does not
password associated with the terminal line used to gain access. cover how the client performed the authentication, so normative
LOCAL is a client local user database. ENABLE is a command that references will not be given . LINE refers to a fixed password
authenticates in order to grant new privileges. TACACSPLUS is, of associated with the terminal line used to gain access. LOCAL is a
course, TACACS+. GUEST is an unqualified guest authentication. client local user database. ENABLE is a command that authenticates
RADIUS is the Radius authentication protocol. RCMD refers to in order to grant new privileges. TACACSPLUS is, of course, TACACS+.
authentication provided via the R-command protocols from Berkeley GUEST is an unqualified guest authentication. RADIUS is the Radius
Unix. authentication protocol. RCMD refers to authentication provided via
the R-command protocols from Berkeley Unix.
priv_lvl priv_lvl
This field is used in the same way as the priv_lvl field in This field is used in the same way as the priv_lvl field in
authentication request and is described in the Privilege Level authentication request and is described in the Privilege Level
section (Section 9) below. It indicates the users current privilege section (Section 9) below. It indicates the users current privilege
level. level.
authen_type authen_type
skipping to change at page 27, line 40 skipping to change at page 28, line 33
If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client
MUST use the authorization argument-value pairs (if any) in the MUST use the authorization argument-value pairs (if any) in the
response, instead of the authorization argument-value pairs from the response, instead of the authorization argument-value pairs from the
request. request.
To approve the authorization with no modifications, the server sets To approve the authorization with no modifications, the server sets
the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0.
A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred
on the server. For the differences between ERROR and FAIL, refer to on the server. For the differences between ERROR and FAIL, refer to
section Session Completion (Section 4.4). None of the arg values Session Completion (Section 4.4). None of the arg values have any
have any relevance if an ERROR is set, and must be ignored. relevance if an ERROR is set, and must be ignored.
When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the
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. TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication.
7. Accounting 7. Accounting
Accounting is typically the third action after authentication and Accounting is typically the third action after authentication and
authorization. But again, neither authentication nor authorization authorization. But again, neither authentication nor authorization
skipping to change at page 32, line 4 skipping to change at page 32, line 41
separated by dots ('.'), IPv6 address text representation defined in separated by dots ('.'), IPv6 address text representation defined in
RFC 5952 [RFC5952]. RFC 5952 [RFC5952].
Date Time Date Time
Absolute date/times are specified in seconds since the epoch, 12:00am Absolute date/times are specified in seconds since the epoch, 12:00am
Jan 1 1970. The timezone MUST be UTC unless a timezone argument is Jan 1 1970. The timezone MUST be UTC unless a timezone argument is
specified. specified.
String String
Many values have no specific type representation and so are
interpreted as plain strings. Many values have no specific type representation and are interpreted
as plain strings.
Empty Values Empty Values
Arguments may be submitted with no value, in which case they consist Arguments may be submitted with no value, in which case they consist
of the name and the mandatory or optional separator. For example, of the name and the mandatory or optional separator. For example,
the argument "cmd" which has no value is transmitted as a string of the argument "cmd" which has no value is transmitted as a string of
four characters "cmd=" four characters "cmd="
8.2. Authorization Arguments 8.2. Authorization Arguments
skipping to change at page 36, line 31 skipping to change at page 37, line 24
and "cmd" is empty). When a user required to perform actions that and "cmd" is empty). When a user required to perform actions that
are mapped to a higher privilege level, then an ENABLE type are mapped to a higher privilege level, then an ENABLE type
reauthentication can be initiated by the client. The client will reauthentication can be initiated by the client. The client will
insert the required privilege level into the authentication header insert the required privilege level into the authentication header
for enable authentication request. for enable authentication request.
The use of Privilege levels to determine session-based access to The use of Privilege levels to determine session-based access to
commands and resources is not mandatory for clients. Although the commands and resources is not mandatory for clients. Although the
privilege level scheme is widely supported, its lack of flexibility privilege level scheme is widely supported, its lack of flexibility
in requiring a single monotonic hierarchy of permissions means that in requiring a single monotonic hierarchy of permissions means that
other session-based command authorization schemes have evolved, and other session-based command authorization schemes have evolved.
so it is no longer mandatory for clients to use it. However, it is However, it is still common enough that it SHOULD be supported by
still common enough that it SHOULD be supported by servers. servers.
10. Security Considerations 10. Security Considerations
The original TACACS+ Draft `The Draft' [TheDraft] from 1998 did not The original TACACS+ Draft `The Draft' [TheDraft] from 1998 did not
address all of the key security concerns which are considered when address all of the key security concerns which are considered when
designing modern standards. This section addresses known limitations designing modern standards. This section addresses known limitations
and concerns which will impact overall security of the protocol and and concerns which will impact overall security of the protocol and
systems where this protocol is deployed to manage central systems where this protocol is deployed to manage central
authentication, authorization or accounting for network device authentication, authorization or accounting for network device
administration. administration.
skipping to change at page 40, line 41 skipping to change at page 41, line 31
TACACS+ server administrators SHOULD configure secret keys of minimum TACACS+ server administrators SHOULD configure secret keys of minimum
16 characters length. 16 characters length.
10.5.2. Connections and Obfuscation 10.5.2. Connections and Obfuscation
TACACS+ servers MUST allow the definition of individual clients. The TACACS+ servers MUST allow the definition of individual clients. The
servers MUST only accept network connection attempts from these servers MUST only accept network connection attempts from these
defined, known clients. defined, known clients.
TACACS+ servers MUST reject connections with TACACS+ servers MUST reject connections with
TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on TAC_PLUS_UNENCRYPTED_FLAG set. There MUST always be a shared secret
the server for the client requesting the connection. set on the server for the client requesting the connection.
If an invalid shared secret is detected when processing packets for a If an invalid shared secret is detected when processing packets for a
client, TACACS+ servers MUST NOT accept any new sessions on that client, TACACS+ servers MUST NOT accept any new sessions on that
connection. TACACS+ servers MUST terminate the connection on connection. TACACS+ servers MUST terminate the connection on
completion of any sessions that were previously established with a completion of any sessions that were previously established with a
valid shared secret on that connection. valid shared secret on that connection.
TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG when a secret TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG. Clients MUST
is defined. Clients MUST be implemented in a way that requires be implemented in a way that requires explicit configuration to
explicit configuration to enable the use of enable the use of TAC_PLUS_UNENCRYPTED_FLAG, this option MUST NOT be
TAC_PLUS_UNENCRYPTED_FLAG. used when the client is in production
When a TACACS+ client receives responses from servers where: When a TACACS+ client receives responses from servers where:
the response packet was received from the server configured with the response packet was received from the server configured with
shared key, but the packet has TAC_PLUS_UNENCRYPTED_FLAG set. shared key, but the packet has TAC_PLUS_UNENCRYPTED_FLAG set.
the response packet was received from the server configured not to the response packet was received from the server configured not to
use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not
set. set.
skipping to change at page 42, line 11 skipping to change at page 42, line 44
If they must be implemented, the servers MUST default to the options If they must be implemented, the servers MUST default to the options
being disabled and MUST warn the administrator that these options are being disabled and MUST warn the administrator that these options are
not secure. not secure.
10.5.4. Authorization 10.5.4. Authorization
The authorization and accounting features are intended to provide The authorization and accounting features are intended to provide
extensibility and flexibility. There is a base dictionary defined in extensibility and flexibility. There is a base dictionary defined in
this document, but it may be extended in deployments by using new this document, but it may be extended in deployments by using new
argument names. The cost of the flexibility is that administrators argument names. The cost of the flexibility is that administrators
and implementors MUST ensure that the argument and value pairs shared and implementers MUST ensure that the argument and value pairs shared
between the clients and servers have consistent interpretation. between the clients and servers have consistent interpretation.
TACACS+ clients that receive an unrecognized mandatory argument MUST TACACS+ clients that receive an unrecognized mandatory argument MUST
evaluate server response as if they received evaluate server response as if they received
TAC_PLUS_AUTHOR_STATUS_FAIL. TAC_PLUS_AUTHOR_STATUS_FAIL.
10.5.5. Redirection Mechanism 10.5.5. Redirection Mechanism
The original draft described a redirection mechanism The original draft described a redirection mechanism
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to
 End of changes. 48 change blocks. 
109 lines changed or deleted 123 lines changed or added

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