draft-ietf-opsawg-tacacs-04.txt | draft-ietf-opsawg-tacacs-05.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: January 9, 2017 D. Medway Gash | Expires: February 21, 2017 D. Medway Gash | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
D. Carrel | D. Carrel | |||
vIPtela, Inc. | vIPtela, Inc. | |||
L. Grant | L. Grant | |||
July 8, 2016 | August 20, 2016 | |||
The TACACS+ Protocol | The TACACS+ Protocol | |||
draft-ietf-opsawg-tacacs-04 | draft-ietf-opsawg-tacacs-05 | |||
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 January 9, 2017. | This Internet-Draft will expire on February 21, 2017. | |||
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 27 ¶ | skipping to change at page 2, line 27 ¶ | |||
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 . . . . . . . . . . . . . . . . . . . . 4 | 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.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 . . . . . . . . . . . . . . . . 7 | 3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 6 | |||
3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 8 | 3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 8 | |||
3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.7. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 11 | 3.7. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 | 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.1. The Authentication START Packet Body . . . . . . . . . . 11 | 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 . . . . . . . . . 15 | 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 . . . . . . . . . . . . . . . . . . 16 | 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 16 | |||
4.4.2. Common Authentication Flows . . . . . . . . . . . . . 17 | 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 17 | |||
4.4.3. Aborting an Authentication Session . . . . . . . . . 20 | 4.4.3. Aborting an Authentication Session . . . . . . . . . 20 | |||
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 21 | 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 21 | 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 22 | |||
5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 24 | 5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 24 | |||
6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 26 | 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 26 | |||
6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 27 | 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 27 | |||
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 29 | 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 29 | |||
7.1. Authorization Attributes . . . . . . . . . . . . . . . . 30 | 7.1. Authorization Attributes . . . . . . . . . . . . . . . . 30 | |||
7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 32 | 7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 32 | |||
8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 34 | 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 34 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 35 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | ||||
1. Introduction | 1. Introduction | |||
Terminal Access Controller Access-Control System Plus (TACACS+) was | Terminal Access Controller Access-Control System Plus (TACACS+) was | |||
originally conceived as a general Authentication, Authorization and | originally conceived as a general Authentication, Authorization and | |||
Accounting protocol. It is primarily used today for Device | Accounting protocol. It is primarily used today for Device | |||
Administration: authenticating access to network devices, providing | Administration: authenticating access to network devices, providing | |||
central authorization of operations, and audit of those operations. | 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, the following | document will conform to `The Draft'. However, attention is drawn to | |||
specific adjustments of the protocol specification from 'The Draft' | the following specific adjustments of the protocol specification from | |||
should be noted: | 'The Draft': | |||
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 have been removed, however the required | outbound authentication have been removed, however the required | |||
enumerations are kept. | enumerations are kept. | |||
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 | |||
skipping to change at page 4, line 18 ¶ | skipping to change at page 4, line 18 ¶ | |||
this document | this document | |||
Authentication | Authentication | |||
Authentication is the action of determining who a user (or entity) | Authentication is the action of determining who a user (or entity) | |||
is. Authentication can take many forms. Traditional authentication | is. Authentication can take many forms. Traditional authentication | |||
utilizes a name and a fixed password. However, fixed passwords have | utilizes a name and a fixed password. However, fixed passwords have | |||
limitations, mainly in the area of security. Many modern | limitations, mainly in the area of security. Many modern | |||
authentication mechanisms utilize "one-time" passwords or a | authentication mechanisms utilize "one-time" passwords or a | |||
challenge-response query. TACACS+ is designed to support all of | challenge-response query. TACACS+ is designed to support all of | |||
these, and should be powerful enough to handle any future mechanisms. | these, and be powerful enough to handle any future mechanisms. | |||
Authentication generally takes place when the user first logs in to a | Authentication generally takes place when the user first logs in to a | |||
machine or requests a service of it. | machine or requests a service of it. | |||
Authentication is not mandatory; it is a site-configured option. | Authentication is not mandatory; it is a site-configured option. | |||
Some sites do not require it. Others require it only for certain | Some sites do not require it. Others require it only for certain | |||
services (see authorization below). Authentication may also take | services (see authorization below). Authentication may also take | |||
place when a user attempts to gain extra privileges, and must | place when a user attempts to gain extra privileges, and must | |||
identify himself or herself as someone who possesses the required | identify himself or herself as someone who possesses the required | |||
information (passwords, etc.) for those privileges. | information (passwords, etc.) for those privileges. | |||
skipping to change at page 5, line 44 ¶ | skipping to change at page 5, line 44 ¶ | |||
All uses of the word packet in this document refer to TACACS+ | All uses of the word packet in this document refer to TACACS+ | |||
protocol packets unless explicitly noted otherwise. | protocol packets unless explicitly noted otherwise. | |||
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 | ||||
The protocol includes an obfuscation mechanism referred to in the | ||||
original draft as Body Encryption. It is intended to follow up this | ||||
document with enhancements to TACACS+ security. | ||||
It is recommended to separate the management traffic from the regular | ||||
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 | |||
session is an operational concept that is maintained between the | session is an operational concept that is maintained between the | |||
skipping to change at page 8, line 33 ¶ | skipping to change at page 8, line 27 ¶ | |||
The single-connection flag: | The single-connection flag: | |||
TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 | TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 | |||
This flag is used to allow a client and server to agree whether | This flag is used to allow a client and server to agree whether | |||
multiple sessions may be multiplexed onto a single connection. | multiple sessions may be multiplexed onto a single connection. | |||
session_id | session_id | |||
The Id for this TACACS+ session. The session id should be randomly | The Id for this TACACS+ session. The session id is to be selected | |||
chosen. This field does not change for the duration of the TACACS+ | randomly. This field does not change for the duration of the TACACS+ | |||
session. (If this value is not a cryptographically strong random | session. (If this value is not a cryptographically strong random | |||
number, it will compromise the protocol's security, see RFC 1750 | number, it will compromise the protocol's security, see RFC 1750 | |||
[RFC1750] ) | [RFC1750] ) | |||
length | length | |||
The total length of the packet body (not including the header). This | The total length of the packet body (not including the header). This | |||
value is in network byte order. Packets are never padded beyond this | value is in network byte order. Packets are never padded beyond this | |||
length. | length. | |||
skipping to change at page 9, line 15 ¶ | skipping to change at page 9, line 7 ¶ | |||
- Any variable length data fields which are unused MUST have a | - Any variable length data fields which are unused MUST have a | |||
length value equal to zero. | length value equal to zero. | |||
- Unused fixed length fields SHOULD have values of zero. | - Unused fixed length fields SHOULD have values of zero. | |||
- All data and message fields in a packet MUST NOT be null | - All data and message fields in a packet MUST NOT be null | |||
terminated. | terminated. | |||
- All length values are unsigned and in network byte order. | - All length values are unsigned and in network byte order. | |||
- There should be no padding in any of the fields or at the end of | - There will be no padding in any of the fields or at the end of a | |||
a packet. | packet. | |||
3.6. Encryption | 3.6. Encryption | |||
The body of packets may be encrypted. The following sections | The body of packets may be encrypted. The following sections | |||
describe the encryption mechanism that is supported to enable | describe the encryption mechanism that is supported to enable | |||
backwards compatibility with 'The Draft'. | backwards compatibility with 'The Draft'. | |||
When the encryption mechanism relies on a secret key, it is referring | When the encryption mechanism relies on a secret key, it is referring | |||
to a shared secret value that is known to both the client and the | to a shared secret value that is known to both the client and the | |||
server. This document does not discuss the management and storage of | server. This document does not discuss the management and storage of | |||
those keys. It is an implementation detail of the server and client, | those keys. It is an implementation detail of the server and client, | |||
as to whether they will maintain only one key, or a different key for | as to whether they will maintain only one key, or a different key for | |||
each client or server with which they communicate. For security | each client or server with which they communicate. For security | |||
reasons, the latter options should be available, but it is a site | reasons, the latter options MUST be available, but it is a site | |||
dependent decision as to whether the use of separate keys is | dependent decision as to whether the use of separate keys is | |||
appropriate. | appropriate. | |||
The encrypted flag field may be set as follows: | The encrypted flag field may be set as follows: | |||
TAC_PLUS_UNENCRYPTED_FLAG == 0x0 | TAC_PLUS_UNENCRYPTED_FLAG == 0x0 | |||
In this case, the packet body is encrypted by XOR-ing it byte-wise | In this case, the packet body is encrypted by XOR-ing it byte-wise | |||
with a pseudo random pad. | with a pseudo random pad. | |||
skipping to change at page 10, line 29 ¶ | skipping to change at page 10, line 21 ¶ | |||
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. The handling of the TCP | device mismatch, it MUST return ERROR. The handling of the TCP | |||
connection by the server is implementation independent. | 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 must 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 | If deployment is configured for encrypting a connection then do no | |||
because an incoming packet indicates that it is not encrypted. If | skip decryption simply because an incoming packet indicates that it | |||
the unencrypted flag is not set, and the packet is not encrypted, it | is not encrypted. If the unencrypted flag is not set when expected, | |||
must be dropped. | then it must be dropped. | |||
After a packet body is decrypted, the lengths of the component values | After a packet body is decrypted, the lengths of the component values | |||
in the packet should be summed and checked against the cleartext | in the packet are summed. If the sum is not identical to the | |||
datalength value from the header. Any packets which fail this check | cleartext datalength value from the header, the packet MUST be | |||
should be discarded and an error signalled. Commonly such failures | discarded, and an error signalled. The underlying TCP connection MAY | |||
may be expected to be seen when there are mismatched keys between the | also be closed, if it is not being used for other sessions in single- | |||
client and the TACACS+ server. | connect mode. | |||
Commonly such failures are seen when the keys are mismatched between | ||||
the 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. | |||
3.7. Text Encoding | 3.7. Text Encoding | |||
All text fields in TACACS+ MUST be US-ASCII, excepting special | All text fields in TACACS+ MUST be US-ASCII, excepting special | |||
consideration given to user field and data fields used for passwords. | consideration given to user field and data fields used for passwords. | |||
skipping to change at page 11, line 24 ¶ | skipping to change at page 11, line 16 ¶ | |||
UTF-8, and other encodings outside US-ASCII SHOULD be deprecated. | UTF-8, and other encodings outside US-ASCII SHOULD be deprecated. | |||
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 | authen_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 13, line 5 ¶ | skipping to change at page 12, line 46 ¶ | |||
TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 | TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09 | |||
The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization | The TAC_PLUS_AUTHEN_SVC_NONE option is intended for the authorization | |||
application of this field that indicates that no authentication was | application of this field that indicates that no authentication was | |||
performed by the device. | performed by the device. | |||
The TAC_PLUS_AUTHEN_SVC_LOGIN option is identifies regular login (as | The TAC_PLUS_AUTHEN_SVC_LOGIN option is identifies regular login (as | |||
opposed to ENABLE) to a client device. | opposed to ENABLE) to a client device. | |||
The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE service, | The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE | |||
which refers to a service requesting authentication in order to grant | authen_service, which refers to a service requesting authentication | |||
the user different privileges. This is comparable to the Unix | in order to grant the user different privileges. This is comparable | |||
"su(1)" command. A service value of NONE should only be used when | to the Unix "su(1)" command. An authen_service value of NONE is only | |||
none of the other service values are appropriate. ENABLE may be | to be used when none of the other authen_service values are | |||
requested independently, no requirements for previous authentications | appropriate. ENABLE may be requested independently, no requirements | |||
or authorizations are imposed by the protocol. | for previous authentications or authorizations are imposed by the | |||
protocol. | ||||
Other options are included for legacy/backwards compatibility. | Other options are included for legacy/backwards compatibility. | |||
user | user, user_len | |||
The username. It is optional in this packet, depending upon the | The username is optional in this packet, depending upon the class of | |||
class of authentication. | authentication. If it is absent, user_len will be 0, if included, | |||
the user_len MUST indicate the length of the user field, in bytes. | ||||
port | port, port_len | |||
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, and its length in bytes. The value of this field is | |||
example, Cisco uses "tty10" to denote the tenth tty line and | client specific. (For example, Cisco uses "tty10" to denote the | |||
"Async10" to denote the tenth async interface). | tenth tty line and "Async10" to denote the tenth async interface). | |||
The port_len MUST indicate the length of the port field, in bytes. | ||||
rem_addr | rem_addr, rem_addr_len | |||
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). The | |||
rem_addr_len MUST indicate the length of the user field, in bytes. | ||||
data | data, data_len | |||
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 in the section Common | authen_type. It is described in more detail in the section Common | |||
Authentication flows (Section 4.4.2) . | Authentication flows (Section 4.4.2) . The data_len MUST indicate the | |||
length of the data field, in bytes. | ||||
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 | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| data len | server_msg ... | | data_len | server_msg ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| data ... | | data ... | |||
+----------------+----------------+ | +----------------+----------------+ | |||
status | status | |||
The current status of the authentication. Legal values are: | The current status of the authentication. Legal values are: | |||
TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 | TAC_PLUS_AUTHEN_STATUS_PASS := 0x01 | |||
skipping to change at page 14, line 41 ¶ | skipping to change at page 14, line 41 ¶ | |||
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, server_msg_len | |||
c 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. The server_msg_len MUST indicate the length of | |||
the server_msg field, in bytes. | ||||
data | data, data_len | |||
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. It is described in | and is intended for the client, not the user. It is described in | |||
more detail in the section Common Authentication flows | more detail in the section Common Authentication flows | |||
(Section 4.4.2) . | (Section 4.4.2) . The data_len MUST indicate the length of the data | |||
field, in bytes. | ||||
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 | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| flags | user_msg ... | | flags | user_msg ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| data ... | | data ... | |||
+----------------+ | +----------------+ | |||
user_msg | user_msg, user_msg_len | |||
This field is the string that the user entered, or the client | This field is the string that the user entered, or the client | |||
provided on behalf of the user, in response to the server_msg from a | provided on behalf of the user, in response to the server_msg from a | |||
REPLY packet. | REPLY packet. The user_len MUST indicate the length of the user | |||
field, in bytes. | ||||
data | data, data_len | |||
This field carries information that is specific to the action and the | This field carries information that is specific to the action and the | |||
authen_type for this session. Valid uses of this field are described | authen_type for this session. Valid uses of this field are described | |||
below. | below. The data_len MUST indicate the length of the data field, in | |||
bytes. | ||||
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 | |||
The action, authen_type and service fields (described above) combine | The action, authen_type and authen_service fields (described above) | |||
to determine what kind of authentication is to be performed Every | combine to determine what kind of authentication is to be performed | |||
authentication START, REPLY and CONTINUE packet includes a data | Every authentication START, REPLY and CONTINUE packet includes a data | |||
field. The use of this field is dependent upon the kind of the | field. The use of this field is dependent upon the kind of the | |||
Authentication. | Authentication. | |||
A set of standard kinds of authentication 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. | |||
skipping to change at page 16, line 42 ¶ | skipping to change at page 16, line 46 ¶ | |||
LOGIN CHPASS SENDAUTH | LOGIN CHPASS SENDAUTH | |||
ASCII v0 v0 - | ASCII v0 v0 - | |||
PAP v1 - v1 | PAP v1 - v1 | |||
CHAP v1 - v1 | CHAP v1 - v1 | |||
MS-CHAPv1/2 v1 - v1 | MS-CHAPv1/2 v1 - v1 | |||
The '-' symbol represents that the option is not valid. | 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 will return an ERROR status with the minor_version set to | |||
to the closest supported value. | the closest supported value. | |||
In minor_version 0, Inbound PAP performed a normal LOGIN, sending the | In minor_version 0, Inbound PAP performed a normal LOGIN, sending the | |||
username in the START packet and then waiting for a GETPASS and | username in the START packet and then waiting for a GETPASS and | |||
sending the password in a CONTINUE packet. | 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. SENDAUTH is only used for PPP when performing outbound | or FAIL. SENDAUTH is only used for PPP when performing outbound | |||
authentication. | 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) will | |||
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 common authentication flows. If the options | This section describes common authentication flows. If the options | |||
are implemented, they MUST follow the description. If the server | are implemented, they MUST follow the description. If the server | |||
does not implement an option, it should respond with | does not implement an option, it will respond with | |||
TAC_PLUS_AUTHEN_STATUS_ERROR. | 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 | |||
skipping to change at page 19, line 35 ¶ | skipping to change at page 19, line 38 ¶ | |||
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. | 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 authen_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 | |||
This exchange consists of multiple messages while the server collects | This exchange consists of multiple messages while the server collects | |||
the information it requires in order to change the user's password. | the information it requires in order to change the user's password. | |||
skipping to change at page 20, line 16 ¶ | skipping to change at page 20, line 22 ¶ | |||
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 an ASCII | flag is set, the data portion of the message may contain an ASCII | |||
message explaining the reason for the abort. The session is | message explaining the reason for the abort. The session is | |||
terminated and no REPLY message is sent. | terminated and no REPLY message is sent. | |||
There are three other possible return status values that can be used | There are three other possible return status values that can be used | |||
in a REPLY packet. These can be sent regardless of the action or | in a REPLY packet. These can be sent regardless of the action or | |||
authen_type. Each of these indicates that the TACACS+ authentication | authen_type. Each of these indicates that the TACACS+ authentication | |||
session should be terminated. In each case, the server_msg may | session is terminated. In each case, the server_msg may contain a | |||
contain a message to be displayed to the user. | 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 is | |||
be performed with an alternate server. The data field MUST contain | 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>] | |||
If more than one host is specified, they MUST be separated into rows | If more than one host is specified, they MUST be separated into rows | |||
by an ASCII Carriage Return (0x0D). | by an ASCII Carriage Return (0x0D). | |||
The protocol and key are optional, and apply only to host in the same | 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 | row. The protocol can describe an alternate way of performing the | |||
authentication, other than TACACS+. If the protocol is not present, | authentication, other than TACACS+. If the protocol is not present, | |||
then TACACS+ is assumed. | 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 IPV4 address specified as octets separated by dots | ASCII numeric IPV4 address specified as octets separated by dots | |||
('.'), or IPV6 adress test representation defined in RFC 4291. | ('.'), or IPV6 address test representation defined in RFC 4291. | |||
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. The client may use a preconfigured key | authenticate to that host. The client may use a preconfigured key | |||
for the host if it has one. If not then the client may communicate | for the host if it has one. If not then the client may communicate | |||
with the host using unencrypted option. | 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. | |||
If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is | If the status equals TAC_PLUS_AUTHEN_STATUS_ERROR, then the host is | |||
indicating that it is experiencing an unrecoverable error and the | indicating that it is experiencing an unrecoverable error and the | |||
authentication should proceed as if that host could not be contacted. | authentication will 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 is restarted with a new START packet from the | |||
from the client. This REPLY packet indicates that the current | client. This REPLY packet indicates that the current authen_type | |||
authen_type value (as specified in the START packet) is not | value (as specified in the START packet) is not acceptable for this | |||
acceptable for this session, but that others may be. | session, but that others may be. | |||
If a client chooses not to accept the TAC_PLUS_AUTHEN_STATUS_RESTART | If a client chooses not to accept the TAC_PLUS_AUTHEN_STATUS_RESTART | |||
packet, then it should be TREATED as if the status was | packet, then it is TREATED as if the status was | |||
TAC_PLUS_AUTHEN_STATUS_FAIL. | 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 | |||
skipping to change at page 22, line 4 ¶ | skipping to change at page 22, line 6 ¶ | |||
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. | |||
A mandatory argument MUST be both understood and used. This allows | A mandatory argument MUST be both understood and used. This allows | |||
for extending the attribute list while providing secure backwards | for extending the attribute list while providing secure backwards | |||
compatibility. | compatibility. | |||
5.1. The Authorization REQUEST Packet Body | 5.1. The Authorization REQUEST 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 | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| authen_method | priv_lvl | authen_type | authen_service | | | authen_method | priv_lvl | authen_type | authen_service | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| user len | port len | rem_addr len | arg_cnt | | | user_len | port_len | rem_addr_len | arg_cnt | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg 1 len | arg 2 len | ... | arg N len | | | arg_1_len | arg_2_len | ... | arg_N_len | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| user ... | | user ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| port ... | | port ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| rem_addr ... | | rem_addr ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg 1 ... | | arg_1 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg 2 ... | | arg_2 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| ... | | ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg N ... | | arg_N ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
authen_method | authen_method | |||
This indicates the authentication method used by the client to | This indicates the authentication method used by the client to | |||
acquire the user information. | acquire the user information. | |||
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 | |||
skipping to change at page 22, line 49 ¶ | skipping to change at page 23, line 4 ¶ | |||
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. LINE refers to a fixed | |||
password associated with the terminal line used to gain access. | password associated with the terminal line used to gain access. | |||
LOCAL is a client local user database. ENABLE is a command that | LOCAL is a client local user database. ENABLE is a command that | |||
authenticates in order to grant new privileges. TACACSPLUS is, of | authenticates in order to grant new privileges. TACACSPLUS is, of | |||
course, TACACS+. GUEST is an unqualified guest authentication, such | course, TACACS+. GUEST is an unqualified guest authentication, such | |||
as an ARAP guest login. RADIUS is the Radius authentication | as an ARAP guest login. RADIUS is the Radius authentication | |||
protocol. RCMD refers to authentication provided via the R-command | protocol. RCMD refers to authentication provided via the R-command | |||
protocols from Berkeley Unix. (One should be aware of the security | protocols from Berkeley Unix. | |||
limitations to R-command authentication.) | ||||
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 8) below. It indicates the users current privilege | section (Section 8) below. It indicates the users current privilege | |||
level. | 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 will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. | |||
0x00. This value is valid only in authorization and accounting | This value is valid only in authorization and accounting requests. | |||
requests. | ||||
authen_service | authen_service | |||
This field matches the service field in the authentication section | This field matches the authen_service field in the authentication | |||
(Section 4) above. It indicates the service through which the user | section (Section 4) above. It indicates the service through which | |||
authenticated. | the user authenticated. | |||
user | user, user_len | |||
This field contains the user's account name. | This field contains the user's account name. The user_len MUST | |||
indicate the length of the user field, in bytes. | ||||
port | port, port_len | |||
This field matches the port field in the authentication section | This field matches the port field in the authentication section | |||
(Section 4) above. | (Section 4) above. The port_len MUST indicate the length of the port | |||
field, in bytes. | ||||
rem_addr | ||||
rem_addr, rem_addr_len | ||||
This field matches the rem_addr field in the authentication section | This field matches the rem_addr field in the authentication section | |||
(Section 4) above. | (Section 4) above. The rem_addr_len MUST indicate the length of the | |||
port field, in bytes. | ||||
arg_cnt | arg_cnt | |||
The number of authorization arguments to follow | The number of authorization arguments to follow | |||
arg | arg_1 ... arg_N, arg_1_len .... arg_N_len | |||
An attribute-value pair that describes the command to be performed. | The attribute-value pair that describes the authorization to be | |||
(see below) | performed. (see below), and their corresponding length fields (which | |||
MUST indicate the length of each argument in bytes). | ||||
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. It is legal for attribute values to contain the | |||
separators. | separators. | |||
skipping to change at page 25, line 8 ¶ | skipping to change at page 25, line 8 ¶ | |||
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. the minimum is two characters (one name | string is 255 characters. the minimum is two characters (one name | |||
value and the separator) | 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 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg 1 ... | | arg_1 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg 2 ... | | arg_2 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| ... | | ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg N ... | | arg_N ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
status This field indicates the authorization status | status This field indicates the authorization status | |||
TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 | TAC_PLUS_AUTHOR_STATUS_PASS_ADD := 0x01 | |||
TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 | TAC_PLUS_AUTHOR_STATUS_PASS_REPL := 0x02 | |||
TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 | TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10 | |||
TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 | TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 | |||
TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 | TAC_PLUS_AUTHOR_STATUS_FOLLOW := 0x21 | |||
server_msg | server_msg, server_msg_len | |||
This is an US-ASCII string that may be presented to the user. The | This is an US-ASCII string that may be presented to the user. The | |||
decision to present this message is client specific. | decision to present this message is client specific. The | |||
server_msg_len MUST indicate the length of the server_msg field, in | ||||
bytes. | ||||
data | data, data_len | |||
This is an US-ASCII string that may be presented on an administrative | This is an US-ASCII string that may be presented on an administrative | |||
display, console or log. The decision to present this message is | display, console or log. The decision to present this message is | |||
client specific. | client specific. The data_len MUST indicate the length of the data | |||
field, in bytes. | ||||
arg_cnt | arg_cnt | |||
The number of authorization arguments to follow. | The number of authorization arguments to follow. | |||
arg | arg_1 ... arg_N, arg_1_len .... arg_N_len | |||
An attribute-value pair that describes the command to be performed. | ||||
(see below) | The attribute-value pair that describes the authorization to be | |||
performed. (see below), and their corresponding length fields (which | ||||
MUST indicate the length of each argument in bytes). | ||||
If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the | If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the | |||
appropriate action is to deny the user action. | appropriate action is to deny the user action. | |||
If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the | If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the | |||
arguments specified in the request are authorized and the arguments | arguments specified in the request are authorized and the arguments | |||
in the response are to be used IN ADDITION to those arguments. | in the response are to be used IN ADDITION to those arguments. | |||
If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the | If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the | |||
arguments in the request are to be completely replaced by the | arguments in the request are to be completely replaced by the | |||
arguments in the response. | arguments in the response. | |||
If the intended action is to approve the authorization with no | If the intended action is to approve the authorization with no | |||
modifications, then the status should be set to | modifications, then the status is set to | |||
TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt should be set to 0. | TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt is set 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. | on the server. | |||
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. 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. | |||
skipping to change at page 27, line 9 ¶ | skipping to change at page 27, line 9 ¶ | |||
TACACS+ accounting is very similar to authorization. The packet | TACACS+ accounting is very similar to authorization. The packet | |||
format is also similar. There is a fixed portion and an extensible | format is also similar. There is a fixed portion and an extensible | |||
portion. The extensible portion uses all the same attribute-value | portion. The extensible portion uses all the same attribute-value | |||
pairs 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 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| port ... | | port ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| rem_addr ... | | rem_addr ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg 1 ... | | arg_1 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg 2 ... | | arg_2 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| ... | | ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg N ... | | arg_N ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
flags | flags | |||
This holds bitmapped flags. | This holds bitmapped flags. | |||
TAC_PLUS_ACCT_FLAG_START := 0x02 | TAC_PLUS_ACCT_FLAG_START := 0x02 | |||
TAC_PLUS_ACCT_FLAG_STOP := 0x04 | TAC_PLUS_ACCT_FLAG_STOP := 0x04 | |||
skipping to change at page 27, line 47 ¶ | skipping to change at page 27, line 47 ¶ | |||
All other fields are defined in the authorization and authentication | All other fields are defined in the authorization and authentication | |||
sections above and have the same semantics. | sections above and have the same semantics. | |||
See section 12 Accounting Attribute-value Pairs for the dictionary of | See section 12 Accounting Attribute-value Pairs for the dictionary of | |||
attributes relevant to accounting. | attributes relevant to accounting. | |||
6.2. The Accounting REPLY Packet Body | 6.2. The Accounting REPLY Packet Body | |||
The response to an accounting message is used to indicate that the | The response to an accounting message is used to indicate that the | |||
accounting function on the server has completed. The server should | accounting function on the server has completed. The server will | |||
reply with success only when the record has been committed to the | reply with success only when the record has been committed to the | |||
required level of security, relieving the burden on the client from | required level of security, relieving the burden on the client from | |||
ensuring any better form of accounting is required. | ensuring any better form of accounting is required. | |||
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 | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| server_msg len | data len | | | server_msg len | data_len | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| status | server_msg ... | | status | server_msg ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| data ... | | data ... | |||
+----------------+ | +----------------+ | |||
status | status | |||
This is the return status. Values are: | This is the return status. Values are: | |||
TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 | TAC_PLUS_ACCT_STATUS_SUCCESS := 0x01 | |||
TAC_PLUS_ACCT_STATUS_ERROR := 0x02 | TAC_PLUS_ACCT_STATUS_ERROR := 0x02 | |||
TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 | TAC_PLUS_ACCT_STATUS_FOLLOW := 0x21 | |||
server_msg | server_msg, server_msg_len | |||
This is a US-ASCII string that may be presented to the user. The | This is a US-ASCII string that may be presented to the user. The | |||
decision to present this message is client specific. | decision to present this message is client specific. The | |||
server_msg_len MUST indicate the length of the server_msg field, in | ||||
bytes. | ||||
data | data, data_len | |||
This is a US-ASCII string that may be presented on an administrative | This is a US-ASCII string that may be presented on an administrative | |||
display, console or log. The decision to present this message is | display, console or log. The decision to present this message is | |||
client specific. | client specific. The data_len MUST indicate the length of the data | |||
field, in bytes. | ||||
When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions | When the status equals TAC_PLUS_ACCT_STATUS_FOLLOW, then the actions | |||
to be taken and the contents of the data field are identical to the | to be taken and 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. | |||
The server MUST terminate the session after sending a REPLY. | The server MUST terminate the session after sending a REPLY. | |||
The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start | The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start | |||
accounting message. Start messages should only be sent once when a | accounting message. Start messages will only be sent once when a | |||
task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is | task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is | |||
a stop record and that the task has terminated. The | a stop record and that the task has terminated. The | |||
TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. | TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. | |||
Update records are sent at the client's discretion when the task is | Update records are sent at the client's discretion when the task is | |||
still running. | still running. | |||
Summary of Accounting Packets | Summary of Accounting Packets | |||
+----------+-------+-------+-------------+-------------------------+ | +----------+-------+-------+-------------+-------------------------+ | |||
| Watchdog | Stop | Start | Flags & 0xE | Meaning | | | Watchdog | Stop | Start | Flags & 0xE | Meaning | | |||
+----------+-------+-------+-------------+-------------------------+ | +----------+-------+-------+-------------+-------------------------+ | |||
skipping to change at page 29, line 42 ¶ | skipping to change at page 29, line 42 ¶ | |||
attributes when supporting the corresponding use cases. | attributes when supporting the corresponding use cases. | |||
All numeric values in an attribute-value string are provided as | All numeric values in an attribute-value string are provided as | |||
decimal US-ASCII numbers, unless otherwise stated. | decimal US-ASCII numbers, unless otherwise stated. | |||
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 are specified in seconds since the epoch, 12:00am Jan | |||
12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone | 1 1970. The timezone MUST be UTC unless a timezone attribute is | |||
attribute is specified. | specified. | |||
Attributes may be submitted with no value, in which case they consist | Attributes 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 attribute "cmd" which has no value is transmitted as a string of | the attribute "cmd" which has no value is transmitted as a string of | |||
4 characters "cmd=" | 4 characters "cmd=" | |||
7.1. Authorization Attributes | 7.1. Authorization Attributes | |||
service | service | |||
skipping to change at page 31, line 8 ¶ | skipping to change at page 31, line 8 ¶ | |||
zonelist | zonelist | |||
A numeric zonelist value. (Applicable to AppleTalk only). | A numeric zonelist value. (Applicable to AppleTalk only). | |||
addr | addr | |||
a network address | a network address | |||
addr-pool | addr-pool | |||
The identifier of an address pool from which the client should assign | The identifier of an address pool from which the client can assign an | |||
an address. | address. | |||
routing | routing | |||
A boolean. Specifies whether routing information is to be propagated | A boolean. Specifies whether routing information is to be propagated | |||
to, and accepted from this interface. | to, and accepted from this interface. | |||
route | route | |||
Indicates a route that is to be applied to this interface. Values | Indicates a route that is to be applied to this interface. Values | |||
MUST be of the form "<dst_address> <mask> [<routing_addr>]". If a | MUST be of the form "<dst_address> <mask> [<routing_addr>]". If a | |||
<routing_addr> is not specified, the resulting route should be via | <routing_addr> is not specified, the resulting route is via the | |||
the requesting peer. | requesting peer. | |||
timeout | timeout | |||
an absolute timer for the connection (in minutes). A value of zero | an absolute timer for the connection (in minutes). A value of zero | |||
indicates no timeout. | indicates no timeout. | |||
idletime | idletime | |||
an idle-timeout for the connection (in minutes). A value of zero | an idle-timeout for the connection (in minutes). A value of zero | |||
indicates no timeout. | indicates no timeout. | |||
skipping to change at page 32, line 21 ¶ | skipping to change at page 32, line 21 ¶ | |||
and host information to enable rhost style authorization. The | and host information to enable rhost style authorization. The | |||
response may request that a privilege level be set for the user. | response may request that a privilege level be set for the user. | |||
remote_host | remote_host | |||
remote host (authen_method must have the value | remote host (authen_method must have the value | |||
TAC_PLUS_AUTHEN_METH_RCMD) | TAC_PLUS_AUTHEN_METH_RCMD) | |||
callback-dialstring | callback-dialstring | |||
Indicates that callback should be done. Value is NULL, or a | Indicates that callback is to be done. Value is NULL, or a | |||
dialstring. A NULL value indicates that the service MAY choose to | dialstring. A NULL value indicates that the service MAY choose to | |||
get the dialstring through other means. | get the dialstring through other means. | |||
callback-line | callback-line | |||
The line number to use for a callback. | The line number to use for a callback. | |||
callback-rotary | callback-rotary | |||
The rotary number to use for a callback. | The rotary number to use for a callback. | |||
nocallback-verify | nocallback-verify | |||
Do not require authentication after callback. | Do not require authentication after callback. | |||
7.2. Accounting Attributes | 7.2. Accounting Attributes | |||
The following new attributes are defined for TACACS+ accounting only. | The following new attributes are defined for TACACS+ accounting only. | |||
When these attribute-value pairs are included in the argument list, | When these attribute-value pairs are included in the argument list, | |||
they should precede any attribute-value pairs that are defined in the | they will precede any attribute-value pairs that are defined in the | |||
authorization section (Section 5) above. | authorization section (Section 5) above. | |||
task_id | task_id | |||
Start and stop records for the same event MUST have matching task_id | Start and stop records for the same event MUST have matching task_id | |||
attribute values. The client must not reuse a specific task_id in a | attribute values. The client must not reuse a specific task_id in a | |||
start record until it has sent a stop record for that task_id. | start record until it has sent a stop record for that task_id. | |||
start_time | start_time | |||
skipping to change at page 35, line 5 ¶ | skipping to change at page 35, line 5 ¶ | |||
- In the packet headers for Authentication, Authorization and | - In the packet headers for Authentication, Authorization and | |||
Accounting. The privilege level in the header is primarily | Accounting. The privilege level in the header is primarily | |||
significant in the Authentication phase for enable authentication | significant in the Authentication phase for enable authentication | |||
where a different privilege level is required. | where a different privilege level is required. | |||
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, but it is in | commands and resources is not mandatory for clients, but it is in | |||
common use so SHOULD be supported by servers. | common use so SHOULD be supported by servers. | |||
9. References | 9. TACACS+ Security Considerations | |||
The protocol described in this document has been in widespread use | ||||
since specified in "The Draft" (1998). However it does not meet | ||||
modern security standards, and faces vulnerabilities with privacy and | ||||
authenticity. | ||||
For current deployments, it is recommended: | ||||
To separate the TACACS+ management traffic from the regular | ||||
network access traffic. | ||||
To use IPsec where available. | ||||
Because of the security issues with TACACS+, the authors intend to | ||||
follow up this document with an enhanced specification of the | ||||
protocol employing modern security mechanisms. | ||||
10. References | ||||
[TheDraft] | [TheDraft] | |||
Carrel, D. and L. Grant, "The TACACS+ Protocol Version | Carrel, D. and L. Grant, "The TACACS+ Protocol Version | |||
1.78", June 1997, <https://tools.ietf.org/html/draft- | 1.78", June 1997, <https://tools.ietf.org/html/draft- | |||
grant-tacacs-02>. | grant-tacacs-02>. | |||
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |||
April 1992. | April 1992. | |||
[RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", | [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", | |||
End of changes. 99 change blocks. | ||||
150 lines changed or deleted | 180 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/ |