draft-ietf-opsawg-tacacs-08.txt | draft-ietf-opsawg-tacacs-09.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: August 23, 2018 D. Medway Gash | Expires: September 22, 2018 D. Medway Gash | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
D. Carrel | D. Carrel | |||
vIPtela, Inc. | vIPtela, Inc. | |||
L. Grant | L. Grant | |||
February 19, 2018 | March 21, 2018 | |||
The TACACS+ Protocol | The TACACS+ Protocol | |||
draft-ietf-opsawg-tacacs-08 | draft-ietf-opsawg-tacacs-09 | |||
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 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 August 23, 2018. | This Internet-Draft will expire on September 22, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||
skipping to change at page 3, line 22 ¶ | skipping to change at page 3, line 22 ¶ | |||
9.6. TACACS+ Client Implementation Recommendations . . . . . . 40 | 9.6. TACACS+ Client Implementation Recommendations . . . . . . 40 | |||
9.7. TACACS+ Server Implementation Recommendations . . . . . . 41 | 9.7. TACACS+ Server Implementation Recommendations . . . . . . 41 | |||
9.8. TACACS+ Security and Operational Concerns . . . . . . . . 41 | 9.8. TACACS+ Security and Operational Concerns . . . . . . . . 41 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
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 | conceived initially 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, attention is drawn to | document will conform to `The Draft'. However, attention is drawn to | |||
the following specific adjustments of the protocol specification from | the following specific adjustments of the protocol specification from | |||
'The Draft': | '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 has been removed, however, the required | |||
enumerations are kept. | enumerations are kept. | |||
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 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, to support future authentication | content authentication exchanges, to support future authentication | |||
mechanisms. It is extensible to provide for site customization and | mechanisms. It is extensible to provide for site customization and | |||
future development features, and it uses TCP to ensure reliable | future development features, and it uses TCP to ensure reliable | |||
skipping to change at page 4, line 15 ¶ | skipping to change at page 4, line 15 ¶ | |||
component of that request. | component of that request. | |||
The separation of authentication, authorization and accounting was a | The separation of authentication, authorization and accounting was a | |||
key element of the design of TACACS+ protocol. Essentially it makes | key element of the design of TACACS+ protocol. Essentially it makes | |||
TACACS+ a suite of three protocols. This document will address each | TACACS+ a suite of three protocols. This document will address each | |||
one in separate sections. Although TACACS+ defines all three, but an | one in separate sections. Although TACACS+ defines all three, but an | |||
implementation or configuration is not required to employ all three. | implementation or configuration is not required to employ all three. | |||
Separating the elements is useful for Device Administration use case, | Separating the elements is useful for Device Administration use case, | |||
specifically, for authorization of individual commands in a session. | specifically, for authorization of individual commands in a session. | |||
Note that there is no provision made at the protocol level for | Note that there is no provision made at the protocol level for | |||
association of an authentication to each authroization request. | association of an authentication to each authorization request. | |||
This document restricts itself to a description of the protocol that | This document restricts itself to a description of the protocol that | |||
is used by TACACS+. It does not cover deployment or best practices. | is used by TACACS+. It does not cover deployment or best practices. | |||
2. Technical Definitions | 2. Technical Definitions | |||
This section provides a few basic definitions that are applicable to | This section provides a few basic definitions that are applicable to | |||
this document | this document | |||
Client | Client | |||
skipping to change at page 5, line 47 ¶ | skipping to change at page 5, line 47 ¶ | |||
The flag is only relevant for the first two packets on a connection, | The flag is only relevant for the first two packets on a connection, | |||
to allow the client and server to establish Single Connection Mode. | to allow the client and server to establish Single Connection Mode. | |||
No provision is made for changing Single Connection Mode after the | No provision is made for changing Single Connection Mode after the | |||
first two packets: the client and server MUST ignore the flag after | first two packets: the client and server MUST ignore the flag after | |||
the second packet on a connection. | the second packet on a connection. | |||
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 | may be configured to time out a Single Connection Mode TCP Connection | |||
after a specific period of inactivity to preserve its resources. The | after a specific period of inactivity to preserve its resources. The | |||
client MUST accommodate such closures on a TCP session even after | client MUST accommodate such closures on a TCP session even after | |||
Single Connection Mode has been established. | Single Connection Mode has been established. | |||
3.4. Session Completion | 3.4. Session Completion | |||
skipping to change at page 6, line 26 ¶ | skipping to change at page 6, line 26 ¶ | |||
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 can not apply the result | |||
and it MUST behave as if the server could not be connected to. For | and it MUST behave as if the server could not be connected to. For | |||
example, the client try 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 4.4.3) on Aborting Authentication | Refer to the section (Section 4.4.3) on Aborting Authentication | |||
Sessions for details on handling additional status options. | Sessions for 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: | |||
skipping to change at page 7, line 9 ¶ | skipping to change at page 7, line 9 ¶ | |||
connection issues (such as an incorrect secret, see section | connection issues (such as an incorrect secret, see section | |||
(Section 3.7) ), then any further new sessions MUST NOT be accepted | (Section 3.7) ), then any further new sessions MUST NOT be accepted | |||
on the connection. If there are any sessions that have already been | on the connection. If there are any sessions that have already been | |||
established then they MAY be completed. Once all active sessions are | established then they MAY be completed. Once all active sessions are | |||
completed then the connection MUST be closed. | completed then 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 implmentation 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 | |||
client should close the connection after a configurable timeout. | client should close the connection after a configurable timeout. | |||
3.5. Treatment of Enumerated Protocol Values | 3.5. Treatment of Enumerated Protocol Values | |||
This document describes various enumerated values in the packet | This document describes various enumerated values in the packet | |||
header and the headers for specific packet types. for example in the | header and the headers for specific packet types. For example in the | |||
Authentication start packet type, this document defines the action | Authentication start packet type, this document defines the action | |||
field with three values TAC_PLUS_AUTHEN_LOGIN, TAC_PLUS_AUTHEN_CHPASS | field with three values TAC_PLUS_AUTHEN_LOGIN, TAC_PLUS_AUTHEN_CHPASS | |||
and TAC_PLUS_AUTHEN_SENDAUTH. | and TAC_PLUS_AUTHEN_SENDAUTH. | |||
If the server does not implement one of the defined options in a | If the server does not implement one of the defined options in a | |||
packet that it receives, or it encounters an option that is not | packet that it receives, or it encounters an option that is not | |||
listed in this document for a header field, then it should respond | listed in this document for a header field, then it should respond | |||
with a ERROR and terminate the session. This will allow the client | with a ERROR and terminate the session. This will allow the client | |||
to try a different option. | to try a different option. | |||
skipping to change at page 7, line 43 ¶ | skipping to change at page 7, line 43 ¶ | |||
returned to indicate an error. | returned to indicate an error. | |||
3.6. Text Encoding | 3.6. Text Encoding | |||
All text fields in TACACS+ MUST be printable US-ASCII, excepting | All text fields in TACACS+ MUST be printable US-ASCII, excepting | |||
special consideration given to user field and data fields used for | special consideration given to user field and data fields used for | |||
passwords. | passwords. | |||
To ensure interoperability of current deployments, the TACACS+ client | To ensure interoperability of current deployments, the TACACS+ client | |||
and server MUST handle user fields and those data fields used for | and server MUST handle user fields and those data fields used for | |||
passwords as 8 bit octet strings. The deployment operator MUST | passwords as 8-bit octet strings. The deployment operator MUST | |||
ensure that consistent character encoding is applied from the end | ensure that consistent character encoding is applied from the end | |||
client to the server. The encoding SHOULD be UTF-8, and other | client to the server. The encoding SHOULD be UTF-8, and other | |||
encodings outside printable US-ASCII SHOULD be deprecated. | encodings outside printable US-ASCII SHOULD be deprecated. | |||
3.7. Data Obfuscation | 3.7. Data Obfuscation | |||
The body of packets may be obfuscated. The following sections | The body of packets may be obfuscated. The following sections | |||
describe the obfuscation method that is supported in the protocol. | describe the obfuscation method that is supported in the protocol. | |||
In 'The Draft' this process was actually referred to as Encryption, | In 'The Draft' this process was actually referred to as Encryption, | |||
but the algorithm would not meet modern standards, and so will not be | but the algorithm would not meet modern standards, and so will not be | |||
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. This document | value that is known to both the client and the server. This document | |||
does not discuss the management and storage of those keys, other than | does not discuss the management and storage of those keys, other than | |||
to require that the secret keys MUST remain secret. | to require that the 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 every client. It is a site dependent decision as to | associated with every 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 may be set 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 | In this case, the packet body is obfuscated by XOR-ing it byte-wise | |||
with a pseudo random pad. | 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 9, line 11 ¶ | skipping to change at page 9, line 11 ¶ | |||
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 (Section 3.4) | handling on ERROR, refer to section (Section 3.4) | |||
TAC_PLUS_UNENCRYPTED_FLAG == 0x1 | TAC_PLUS_UNENCRYPTED_FLAG == 0x1 | |||
In this case, the entire packet body is in cleartext. Obfuscation | In this case, the entire packet body is in cleartext. Obfuscation | |||
and de-obfuscation are null operations. This method should be | and de-obfuscation are null operations. This method should be | |||
avoided unless absolutely required for debug purposes, when tooling | avoided unless absolutely required for debug purposes, when tooling | |||
does not permit de-obfuscation. | does not permit de-obfuscation. | |||
If deployment is configured for obfuscating a connection then the | If deployment is configured for obfuscating a connection then the | |||
request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. | request MUST be dropped if TAC_PLUS_UNENCRYPTED_FLAG is set to true. | |||
skipping to change at page 9, line 34 ¶ | skipping to change at page 9, line 34 ¶ | |||
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 3.4) | handling on ERROR, refer to section (Section 3.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. | |||
3.8. The TACACS+ Packet Header | 3.8. The TACACS+ Packet Header | |||
All TACACS+ packets begin with the following 12 byte header. The | All TACACS+ packets begin with the following 12-byte header. The | |||
header describes the remainder of the packet: | header describes the remainder of the 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 | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
|major | minor | | | | | |major | minor | | | | | |||
|version| version| type | seq_no | flags | | |version| version| type | seq_no | flags | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| | | | | | |||
| session_id | | | session_id | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
skipping to change at page 13, line 49 ¶ | skipping to change at page 13, line 49 ¶ | |||
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 indicates regular login (as | The TAC_PLUS_AUTHEN_SVC_LOGIN option indicates 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 | The TAC_PLUS_AUTHEN_SVC_ENABLE option identifies the ENABLE | |||
authen_service, which refers to a service requesting authentication | authen_service, which refers to a service requesting authentication | |||
in order to grant the user different privileges. This is comparable | in order to grant the user different privileges. This is comparable | |||
to the Unix "su(1)" command. An authen_service value of NONE is only | to the Unix "su(1)" command, which substitutes the current user's | |||
to be used when none of the other authen_service values are | identity with another. An authen_service value of NONE is only to be | |||
appropriate. ENABLE may be requested independently, no requirements | used when none of the other authen_service values are appropriate. | |||
for previous authentications or authorizations are imposed by the | ||||
protocol. | ENABLE may be requested independently, no requirements for previous | |||
authentications or authorizations are imposed by the protocol. | ||||
Other options are included for legacy/backwards compatibility. | Other options are included for legacy/backwards compatibility. | |||
user, user_len | user, user_len | |||
The username is optional in this packet, depending upon the class of | The username is optional in this packet, depending upon the class of | |||
authentication. If it is absent, the client MUST set user_len to 0. | authentication. If it is absent, the client MUST set user_len to 0. | |||
If included, the user_len indicates the length of the user field, in | If included, the user_len indicates the length of the user field, in | |||
bytes. | bytes. | |||
skipping to change at page 19, line 23 ¶ | skipping to change at page 19, line 23 ¶ | |||
field and the data field is a concatenation of the PPP id, the | field and the data field is a concatenation of the PPP id, the | |||
challenge and the response. | challenge and the response. | |||
The length of the challenge value can be determined from the length | The length of the challenge value can be determined from the length | |||
of the data field minus the length of the id (always 1 octet) and the | of the data field minus the length of the id (always 1 octet) and the | |||
length of the response field (always 16 octets). | length of the response field (always 16 octets). | |||
To perform the authentication, the server calculates the PPP hash as | To perform the authentication, the server calculates the PPP hash as | |||
defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then | defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then | |||
compare that value with the response. The MD5 algorithm option is | compare that value with the response. The MD5 algorithm option is | |||
alays used. The REPLY from the server MUST be a PASS, FAIL or ERROR. | always used. The REPLY from the server MUST be a PASS, FAIL or | |||
ERROR. | ||||
In cases where the client conducts the exchange with the endstation | In cases where the client conducts the exchange with the endstation | |||
and then sends the resulting materials (challenge and responsee) to | and then sends the resulting materials (challenge and response) to | |||
the server, the selection of the challenge and its length are not an | the server, the selection of the challenge and its length are not an | |||
aspect of the TACACS+ protocol. However, it is strongly recommended | aspect of the TACACS+ protocol. However, it is strongly recommended | |||
that the client/endstation interaction is configured with a secure | that the client/endstation interaction is configured with a secure | |||
challenge. The TACACS+ server can help by rejecting authentications | challenge. The TACACS+ server can help by rejecting authentications | |||
where the challenge is below a minimum length (Minimum recommended is | where the challenge is below a minimum length (Minimum recommended is | |||
8 bytes). | 8 bytes). | |||
In cases where the TACACS+ Server generates the challenge then it | In cases where the TACACS+ Server generates the challenge then it | |||
MUST change for every request and MUST be derived from a strong | MUST change for every request and MUST be derived from a strong | |||
cryptographic source. | cryptographic source. | |||
skipping to change at page 20, line 15 ¶ | skipping to change at page 20, line 15 ¶ | |||
The length of the challenge value can be determined from the length | The length of the challenge value can be determined from the length | |||
of the data field minus the length of the id (always 1 octet) and the | of the data field minus the length of the id (always 1 octet) and the | |||
length of the response field (always 49 octets). | length of the response field (always 49 octets). | |||
To perform the authentication, the server will use a combination of | To perform the authentication, the server will use a combination of | |||
MD4 and DES on the user's secret and the challenge, as defined in RFC | MD4 and DES on the user's secret and the challenge, as defined in RFC | |||
2433 [RFC2433] and then compare the resulting value with the | 2433 [RFC2433] and then compare the resulting value with the | |||
response. The REPLY from the server MUST be a PASS or FAIL. | response. The REPLY from the server MUST be a PASS or FAIL. | |||
For best practices, please refer to RFC 2433 [RFC2433] . The TACACS+ | For best practices, please refer to RFC 2433 [RFC2433] . The TACACS+ | |||
server MUST rejects authentications where the challenge deviates from | server MUST reject authentications where the challenge deviates from | |||
8 bytes as defined in the RFC. | 8 bytes as defined in the RFC. | |||
4.4.2.5. MS-CHAP v2 login | 4.4.2.5. MS-CHAP v2 login | |||
action = TAC_PLUS_AUTHEN_LOGIN | action = TAC_PLUS_AUTHEN_LOGIN | |||
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 | authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 | |||
minor_version = 0x1 | minor_version = 0x1 | |||
The entire exchange MUST consist of a single START packet and a | The entire exchange MUST consist of a single START packet and a | |||
single REPLY. The START packet MUST contain the username in the user | single REPLY. The START packet MUST contain the username in the user | |||
skipping to change at page 21, line 34 ¶ | skipping to change at page 21, line 34 ¶ | |||
TAC_PLUS_AUTHEN_STATUS_GETDATA. | TAC_PLUS_AUTHEN_STATUS_GETDATA. | |||
4.4.3. Aborting an Authentication Session | 4.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 an ASCII | flag is set, the data portion of the message may contain an ASCII | |||
message explaining the reason for the abort. This information will | message explaining the reason for the abort. This information will | |||
be handled by the server according to the requirements of the | be handled by the server according to the requirements of the | |||
deployment. The session is terminated, for more details about | deployment. The session is terminated, for more details about | |||
session temrination, oplease refer to section (Section 3.4) | session termination, refer to section (Section 3.4) | |||
In the case of PALL, FAIL or ERROR, the server can insert a message | In the case of PALL, FAIL or ERROR, the server can insert a message | |||
into server_msg to be displayed to the user. | into 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 22, line 30 ¶ | skipping to change at page 22, line 30 ¶ | |||
authorization, though it is not mandatory that a client use the same | authorization, though it is not mandatory that a client use the same | |||
service for authentication that it will use for authorization. An | service for authentication that it will use for authorization. An | |||
authorization request may indicate that the user is not authenticated | authorization request may indicate that the user is not authenticated | |||
(we don't know who they are). In this case it is up to the server to | (we don't know who they are). In this case it is up to the server to | |||
determine, according to its configuration, if an unauthenticated user | determine, according to its configuration, if an unauthenticated user | |||
is allowed the services in question. | is allowed the services in question. | |||
Authorization does not merely provide yes or no answers, but it may | Authorization does not merely provide yes or no answers, but it may | |||
also customize the service for the particular user. A common use of | also customize the service for the particular user. A common use of | |||
authorization is to provision a shell session when a user first logs | authorization is to provision a shell session when a user first logs | |||
in to a device to administer it. The TACACS+ server might respond to | into a device to administer it. The TACACS+ server might respond to | |||
the request by allowing the service, but placing a time restriction | the request by allowing the service, but placing a time restriction | |||
on the login shell. For a list of common attributes used in | on the login shell. For a list of common attributes used in | |||
authorization, see the Authorization Attributes section (Section 7.2) | authorization, see the Authorization Attributes section (Section 7.2) | |||
. | . | |||
In the TACACS+ protocol an authorization is always a single pair of | In the TACACS+ protocol an authorization is always a single pair of | |||
messages: a REQUEST from the client followed by a REPLY from the | messages: a REQUEST from the client followed by a REPLY from the | |||
server. | server. | |||
The authorization REQUEST message contains a fixed set of fields that | The authorization REQUEST message contains a fixed set of fields that | |||
indicate how the user was authenticated and a variable set of | indicate how the user was authenticated and a variable set of | |||
arguments that describe the services and options for which | arguments that describe the services and options for which | |||
authorization is requested. | authorization is requested. | |||
The REPLY contains a variable set of response arguments (attribute- | The REPLY contains a variable set of response arguments (attribute- | |||
value pairs) that can restrict or modify the clients actions. | value pairs) that can restrict or modify the client's actions. | |||
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 | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
skipping to change at page 24, line 26 ¶ | skipping to change at page 24, line 26 ¶ | |||
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 corrsponds to the authen_type field in the authentication | This field coresponds to 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 will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. | client will set authen_type to: TAC_PLUS_AUTHEN_TYPE_NOT_SET := 0x00. | |||
This value is valid only in authorization and accounting requests. | This value is valid only in authorization and accounting requests. | |||
authen_service | authen_service | |||
This field is the same as the authen_service field in the | This field is the same as the authen_service field in the | |||
authentication section (Section 4) above. It indicates the service | authentication section (Section 4) above. It indicates the service | |||
through which the user authenticated. | through which the user authenticated. | |||
skipping to change at page 25, line 43 ¶ | skipping to change at page 25, line 43 ¶ | |||
Optional arguments are ones that may be disregarded by either client | Optional arguments are ones that may be disregarded by either client | |||
or server. Mandatory arguments require that the receiving side can | or server. Mandatory arguments require that the receiving side can | |||
handle the attribute, that is: its implementation and configuration | handle the attribute, that is: its implementation and configuration | |||
includes the details of how to act on it. If the client receives a | includes the details of how to act on it. If the client receives a | |||
mandatory argument that it cannot handle, it MUST consider the | mandatory argument that it cannot handle, it MUST consider the | |||
authorization to have failed. It is legal to send an attribute-value | authorization to have failed. It is legal to send an attribute-value | |||
pair with a zero length value. | pair with a zero length value. | |||
Attribute-value strings are not NULL terminated, rather their length | Attribute-value strings are not NULL terminated, rather their length | |||
value indicates their end. The maximum length of an attribute-value | value indicates their end. The maximum length of an attribute-value | |||
string is 255 characters. The minimum is two characters (one name | string is 255 characters. The minimum is two characters (one name- | |||
value character and the separator) | value character and the separator) | |||
Though the attributes allow extensibility, a common core set of | Though the attributes allow extensibility, a common core set of | |||
authorization attributes SHOULD be supported by clients and servers, | authorization attributes SHOULD be supported by clients and servers, | |||
these are listed in the Authorization Attributes (Section 7.2) | these are listed in the Authorization Attributes (Section 7.2) | |||
section below. | section below. | |||
5.2. The Authorization REPLY Packet Body | 5.2. The Authorization REPLY 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 | |||
skipping to change at page 30, line 31 ¶ | skipping to change at page 30, line 31 ¶ | |||
| 0 | 1 | 1 | 6 | INVALID | | | 0 | 1 | 1 | 6 | INVALID | | |||
| 1 | 0 | 0 | 8 | Watchdog, no update | | | 1 | 0 | 0 | 8 | Watchdog, no update | | |||
| 1 | 0 | 1 | A | Watchdog, with update | | | 1 | 0 | 1 | A | Watchdog, with update | | |||
| 1 | 1 | 0 | C | INVALID | | | 1 | 1 | 0 | C | INVALID | | |||
| 1 | 1 | 1 | E | INVALID | | | 1 | 1 | 1 | E | INVALID | | |||
+----------+-------+-------+-------------+-------------------------+ | +----------+-------+-------+-------------+-------------------------+ | |||
The START and STOP flags are mutually exclusive. | The START and STOP flags are mutually exclusive. | |||
The WATCHDOG flag is used by the client to communicate ongoing status | The WATCHDOG flag is used by the client to communicate ongoing status | |||
of a long running task. Update records are sent at the client's | of a long-running task. Update records are sent at the client's | |||
discretion. The frequency of the update depends upon the intended | discretion. The frequency of the update depends upon the intended | |||
application: A watchdog to provide progress indication will require | application: A watchdog to provide progress indication will require | |||
higher frequency than a daily keep-alive. When the WATCHDOG flag is | higher frequency than a daily keep-alive. When the WATCHDOG flag is | |||
set along with the START flag, it indicates that the update record | set along with the START flag, it indicates that the update record | |||
provides additional or updated arguments from the original START | provides additional or updated arguments from the original START | |||
record. If the START flag is not set, then this indicates only that | record. If the START flag is not set, then this indicates only that | |||
task is still running, and no new information is provided (servers | task is still running, and no new information is provided (servers | |||
MUST ignore any arguments). The STOP flag MUST NOT be set in | MUST ignore any arguments). The STOP flag MUST NOT be set in | |||
conjunction with the WATCHDOG flag. | conjunction with the WATCHDOG flag. | |||
skipping to change at page 33, line 44 ¶ | skipping to change at page 33, line 44 ¶ | |||
authorization. | authorization. | |||
noescape (Boolean) | noescape (Boolean) | |||
Prevents user from using an escape character. Applicable only to | Prevents user from using an escape character. Applicable only to | |||
session-based shell authorization. | session-based shell authorization. | |||
nohangup (Boolean) | nohangup (Boolean) | |||
Boolean. Do not disconnect after an automatic command. Applicable | Boolean. Do not disconnect after an automatic command. Applicable | |||
only to session-based shell authorization.y. | only to session-based shell authorization. | |||
priv-lvl (Numeric) | priv-lvl (Numeric) | |||
privilege level to be assigned. Please refer to the Privilege Level | privilege level to be assigned. Please refer to the Privilege Level | |||
section (Section 8) below. | section (Section 8) below. | |||
remote_user (String) | remote_user (String) | |||
remote userid (authen_method must have the value | remote userid (authen_method must have the value | |||
TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the | TAC_PLUS_AUTHEN_METH_RCMD). In the case of rcmd authorizations, the | |||
authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the | authen_method will be set to TAC_PLUS_AUTHEN_METH_RCMD and the | |||
skipping to change at page 34, line 50 ¶ | skipping to change at page 34, line 50 ¶ | |||
The elapsed time in seconds for the action. | The elapsed time in seconds for the action. | |||
timezone (String) | timezone (String) | |||
The timezone abbreviation for all timestamps included in this packet. | The timezone abbreviation for all timestamps included in this packet. | |||
event (String) | event (String) | |||
Used only when "service=system". Current values are "net_acct", | Used only when "service=system". Current values are "net_acct", | |||
"cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". | "cmd_acct", "conn_acct", "shell_acct" "sys_acct" and "clock_change". | |||
These indicate system level changes. The flags field SHOULD indicate | These indicate system-level changes. The flags field SHOULD indicate | |||
whether the service started or stopped. | whether the service started or stopped. | |||
reason (String) | reason (String) | |||
Accompanies an event attribute. It describes why the event occurred. | Accompanies an event attribute. It describes why the event occurred. | |||
bytes (Numeric) | bytes (Numeric) | |||
The number of bytes transferred by this action | The number of bytes transferred by this action | |||
skipping to change at page 35, line 46 ¶ | skipping to change at page 35, line 46 ¶ | |||
err_msg (String) | err_msg (String) | |||
A printable US-ASCII string describing the status of the action. | A printable US-ASCII string describing the status of the action. | |||
8. Privilege Levels | 8. Privilege Levels | |||
The TACACS+ Protocol supports flexible authorization schemes through | The TACACS+ Protocol supports flexible authorization schemes through | |||
the extensible attributes. | the extensible attributes. | |||
One scheme is built in to the protocol and has been extensively used | One scheme is built into the protocol and has been extensively used | |||
for Session-based shell authorization: Privilege Levels. Privilege | for Session-based shell authorization: Privilege Levels. Privilege | |||
Levels are ordered values from 0 to 15 with each level being a | Levels are ordered values from 0 to 15 with each level being a | |||
superset of the next lower value. Configuration and implementation | superset of the next lower value. Configuration and implementation | |||
of the client will map actions ()such as the permission to execute of | of the client will map actions (such as the permission to execute of | |||
specific commands) to different privilege levels. Pre-defined values | specific commands) to different privilege levels. Pre-defined values | |||
are: | are: | |||
TAC_PLUS_PRIV_LVL_MAX := 0x0f | TAC_PLUS_PRIV_LVL_MAX := 0x0f | |||
TAC_PLUS_PRIV_LVL_ROOT := 0x0f | TAC_PLUS_PRIV_LVL_ROOT := 0x0f | |||
TAC_PLUS_PRIV_LVL_USER := 0x01 | TAC_PLUS_PRIV_LVL_USER := 0x01 | |||
TAC_PLUS_PRIV_LVL_MIN := 0x00 | TAC_PLUS_PRIV_LVL_MIN := 0x00 | |||
A Privilege level can be assigned to a shell (EXEC) session when it | A Privilege level can be assigned to a shell (EXEC) session when it | |||
starts starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will | starts (for example, TAC_PLUS_PRIV_LVL_USER). The client will permit | |||
permit the actions associated with this level to be executed. This | the actions associated with this level to be executed. This | |||
privilege level is returned by the Server in a session-based shell | privilege level is returned by the Server in a session-based shell | |||
authorization (when "service" equals "shell" and "cmd" is empty). | authorization (when "service" equals "shell" and "cmd" is empty). | |||
When a user required to perform actions that are mapped to a higher | When a user required to perform actions that are mapped to a higher | |||
privilege level, then an ENABLE type reuthentication can be initiated | privilege level, then an ENABLE type reauthentication can be | |||
by the client, in a way similar to su in unix. The client will | initiated by the client. The client will insert the required | |||
insert the required privilege level into the authentication header | privilege level into the authentication header for enable | |||
for enable authentication request. | 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, and | |||
so it is no longer mandatory for clients to use it. However, it is | so it is no longer mandatory for clients to use it. However, it is | |||
still common enough that it SHOULD be supported by servers. | still common enough that it SHOULD be supported by servers. | |||
9. TACACS+ Security Considerations | 9. TACACS+ Security Considerations | |||
skipping to change at page 36, line 51 ¶ | skipping to change at page 36, line 51 ¶ | |||
Multiple implementations of the protocol described in the draft[1] | Multiple implementations of the protocol described in the draft[1] | |||
have been deployed. As the protocol was never standardised, current | have been deployed. As the protocol was never standardised, current | |||
implementations may be incompatible in non-obvious ways, giving rise | implementations may be incompatible in non-obvious ways, giving rise | |||
to additional security risks about which authors might not be aware | to additional security risks about which authors might not be aware | |||
of. This section does not claim to enumerate all possible security | of. This section does not claim to enumerate all possible security | |||
vulnerabilities. | vulnerabilities. | |||
9.1. General Security of The Protocol | 9.1. General Security of The Protocol | |||
TACACS+ protocol does not include a security mechanism that would | TACACS+ protocol does not include a security mechanism that would | |||
meet modern day requirements. Support for MD5-based crypto pad | meet modern-day requirements. Support for MD5-based crypto pad | |||
encryption fails to provide any kind of transport integrity, which | encryption fails to provide any kind of transport integrity, which | |||
presents at least the following risks: | presents at least the following risks: | |||
Accounting information may be modified by the man-in-the-middle | Accounting information may be modified by the man-in-the-middle | |||
attacker, making such logs unsuitable and untrustable for auditing | attacker, making such logs unsuitable and untrustable for auditing | |||
purposes. | purposes. | |||
Only the body of the request is encrypted which leaves all header | Only the body of the request is encrypted which leaves all header | |||
fields open to trivial modification by the man-in-the-middle | fields open to trivial modification by the man-in-the-middle | |||
attacker. | attacker. | |||
skipping to change at page 37, line 46 ¶ | skipping to change at page 37, line 46 ¶ | |||
information is available that it is best referred to as "obfuscation" | information is available that it is best referred to as "obfuscation" | |||
and not "encryption". | and not "encryption". | |||
For example, a "session_id" can be replaced by an alternate one, | For example, a "session_id" can be replaced by an alternate one, | |||
which could allow an unprivileged administrator to "steal" the | which could allow an unprivileged administrator to "steal" the | |||
authorization from a session for a privileged administrator. An | authorization from a session for a privileged administrator. An | |||
attacker could also update the "flags" field to indicate that one or | attacker could also update the "flags" field to indicate that one or | |||
the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG, | the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG, | |||
which would subvert the obfuscation mechanism. | which would subvert the obfuscation mechanism. | |||
For this reasons, users deploying TACACS+ protocol in their | For these reasons, users deploying TACACS+ protocol in their | |||
environments MUST limit access to known clients and MUST control the | environments MUST limit access to known clients and MUST control the | |||
security of the entire transmission path. Attacks who can guess the | security of the entire transmission path. Attacks who can guess the | |||
key or otherwise break the obfuscation will gain unrestricted and | key or otherwise break the obfuscation will gain unrestricted and | |||
undetected access to all TACACS+ traffic. The security risk of such | undetected access to all TACACS+ traffic. The security risk of such | |||
attack succeeding against a centralised AAA system like TACACS+ | attack succeeding against a centralised AAA system like TACACS+ | |||
cannot be overstated. | cannot be overstated. | |||
The following parts of this section enumerate only the session- | The following parts of this section enumerate only the session- | |||
specific risks which are in addition to general risk associated with | specific risks which are in addition to general risk associated with | |||
bare obfuscation and lack of integrity checking. | bare obfuscation and lack of integrity checking. | |||
9.2. Security of Authentication Sessions | 9.2. Security of Authentication Sessions | |||
Authentication sessions SHOULD NOT be used via unsecure transport as | Authentication sessions SHOULD NOT be used via insecure transport as | |||
the man-in-the-middle attack may completely subvert them. Even CHAP, | the man-in-the-middle attack may completely subvert them. Even CHAP, | |||
which may me considered resistant to password interception, is unsafe | which may be considered resistant to password interception, is unsafe | |||
as it does not protect the username from a trivial man-in-the-middle | as it does not protect the username from a trivial man-in-the-middle | |||
attack. | attack. | |||
Section 4.4.3 permits the redirection of a session to another server | Section 4.4.3 permits the redirection of a session to another server | |||
via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this | via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this | |||
process, the secret key for a new server can be sent to the client. | process, the secret key for a new server can be sent to the client. | |||
This public exchange of secret keys means that once one session is | This public exchange of secret keys means that once one session is | |||
broken, it may be possible to leverage that key to attacking | broken, it may be possible to leverage that key to attacking | |||
connections to other servers. This option MUST NOT be used outside a | connections to other servers. This option MUST NOT be used outside a | |||
secured deployment of protocol clients or outside of secure | secured deployment of protocol clients or outside of secure | |||
skipping to change at page 40, line 4 ¶ | skipping to change at page 40, line 4 ¶ | |||
unknown clients. | unknown clients. | |||
Due to the security deficiencies of the protocol, it is critical that | Due to the security deficiencies of the protocol, it is critical that | |||
it be deployed in a secure manner. The following recommendations are | it be deployed in a secure manner. The following recommendations are | |||
made for those deploying and configuring TACACS+ as a solution for | made for those deploying and configuring TACACS+ as a solution for | |||
device administration: | device administration: | |||
Secure the Deployment: TACACS+ MUST BE deployed over networks | Secure the Deployment: TACACS+ MUST BE deployed over networks | |||
which ensure an appropriate privacy and integrity of the | which ensure an appropriate privacy and integrity of the | |||
communication. Definition of an appropriate level of privacy and | communication. Definition of an appropriate level of privacy and | |||
integrity is organisation-dependent What is apropriate level of | integrity is organisation-dependent What is appropriate level of | |||
The way this is ensured will depend upon the organisational means: | The way this is ensured will depend upon the organisational means: | |||
a dedicated and secure management network where available in | a dedicated and secure management network where available in | |||
enterprise deployments, or IPsec where dedicated networks are not | enterprise deployments, or IPsec where dedicated networks are not | |||
available. | available. | |||
Always set a secret key (recommended minimum 14 characters) on the | Always set a secret key (recommended minimum 14 characters) on the | |||
client and server when configuring the connection between them. | client and server when configuring the connection between them. | |||
Servers MUST be configured with a list of known clients. Servers | Servers MUST be configured with a list of known clients. Servers | |||
MUST be configured to reject requests from clients not on the | MUST be configured to reject requests from clients not on the | |||
skipping to change at page 40, line 31 ¶ | skipping to change at page 40, line 31 ¶ | |||
Restrict to TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type where | Restrict to TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type where | |||
possible. Use other options only when unavoidable due to | possible. Use other options only when unavoidable due to | |||
requirements of identity/password systems. | requirements of identity/password systems. | |||
Servers SHOULD be restricted to requiring TACACS+ authentication | Servers SHOULD be restricted to requiring TACACS+ authentication | |||
for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS | for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS | |||
is used). | is used). | |||
Avoid the use of the redirection mechanism. | Avoid the use of the redirection mechanism. | |||
TAC_PLUS_AUTHEN_STATUS_FOLLOW, specifically avoid the option to | TAC_PLUS_AUTHEN_STATUS_FOLLOW, specifically avoid the option to | |||
send send secret keys in the server list. | send secret keys in the server list. | |||
Take case when applying extensions to the dictionary of | Take case when applying extensions to the dictionary of | |||
authorization/accounting arguments. Ensure that the client and | authorization/accounting arguments. Ensure that the client and | |||
server use of new argument names are consistent. | server use of new argument names are consistent. | |||
9.6. TACACS+ Client Implementation Recommendations | 9.6. TACACS+ Client Implementation Recommendations | |||
When implementing TACACS+ Clients it is recommended: | When implementing TACACS+ Clients it is recommended: | |||
Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks | Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks | |||
End of changes. 38 change blocks. | ||||
48 lines changed or deleted | 50 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |