draft-ietf-opsawg-tacacs-11.txt | draft-ietf-opsawg-tacacs-12.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: March 16, 2019 D. Medway Gash | Expires: June 5, 2019 D. Medway Gash | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
D. Carrel | D. Carrel | |||
vIPtela, Inc. | vIPtela, Inc. | |||
L. Grant | L. Grant | |||
September 12, 2018 | December 2, 2018 | |||
The TACACS+ Protocol | The TACACS+ Protocol | |||
draft-ietf-opsawg-tacacs-11 | draft-ietf-opsawg-tacacs-12 | |||
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 March 16, 2019. | This Internet-Draft will expire on June 5, 2019. | |||
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 2, line 24 ¶ | skipping to change at page 2, line 24 ¶ | |||
Without obtaining an adequate license from the person(s) controlling | Without obtaining an adequate license from the person(s) controlling | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 4 | 3. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 5 | |||
3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Single Connection Mode . . . . . . . . . . . . . . . . . 5 | 4.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4. Session Completion . . . . . . . . . . . . . . . . . . . 6 | 4.3. Single Connection Mode . . . . . . . . . . . . . . . . . 5 | |||
3.5. Treatment of Enumerated Protocol Values . . . . . . . . . 7 | 4.4. Session Completion . . . . . . . . . . . . . . . . . . . 6 | |||
3.6. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 7 | 4.5. Treatment of Enumerated Protocol Values . . . . . . . . . 7 | |||
3.7. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 7 | 4.6. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.8. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 9 | 4.7. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 8 | |||
3.9. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 11 | 4.8. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 9 | |||
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.9. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 11 | |||
4.1. The Authentication START Packet Body . . . . . . . . . . 12 | 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
4.2. The Authentication REPLY Packet Body . . . . . . . . . . 14 | 5.1. The Authentication START Packet Body . . . . . . . . . . 12 | |||
4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 16 | 5.2. The Authentication REPLY Packet Body . . . . . . . . . . 15 | |||
4.4. Description of Authentication Process . . . . . . . . . . 16 | 5.3. The Authentication CONTINUE Packet Body . . . . . . . . . 16 | |||
4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 | 5.4. Description of Authentication Process . . . . . . . . . . 17 | |||
4.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 | 5.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 | |||
4.4.3. Aborting an Authentication Session . . . . . . . . . 21 | 5.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 | |||
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 | 5.4.3. Aborting an Authentication Session . . . . . . . . . 21 | |||
5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 22 | 6. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
5.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 | 6.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23 | |||
6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 | |||
6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 | 7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 | 7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 | |||
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 | 7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 | |||
7.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 | 8. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 | |||
7.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 | 8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 | |||
7.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 | 8.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 | |||
8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 | 8.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 | |||
9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 | 9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 | |||
9.1. General Security of the Protocol . . . . . . . . . . . . 36 | 10. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 | |||
9.2. Security of Authentication Sessions . . . . . . . . . . . 38 | 10.1. General Security of the Protocol . . . . . . . . . . . . 37 | |||
9.3. Security of Authorization Sessions . . . . . . . . . . . 38 | 10.2. Security of Authentication Sessions . . . . . . . . . . 38 | |||
9.4. Security of Accounting Sessions . . . . . . . . . . . . . 39 | 10.3. Security of Authorization Sessions . . . . . . . . . . . 38 | |||
9.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39 | 10.4. Security of Accounting Sessions . . . . . . . . . . . . 39 | |||
9.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39 | 10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39 | |||
9.5.2. Connections and Obfuscation . . . . . . . . . . . . . 40 | 10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39 | |||
9.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41 | 10.5.2. Connections and Obfuscation . . . . . . . . . . . . 40 | |||
9.5.4. Authorization . . . . . . . . . . . . . . . . . . . . 41 | 10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41 | |||
9.5.5. Redirection Mechanism . . . . . . . . . . . . . . . . 42 | 10.5.4. Authorization . . . . . . . . . . . . . . . . . . . 41 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 | 10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 42 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
1. Introduction | 1. Introduction | |||
Terminal Access Controller Access-Control System Plus (TACACS+) was | Terminal Access Controller Access-Control System Plus (TACACS+) was | |||
conceived initially 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. | |||
skipping to change at page 4, line 12 ¶ | skipping to change at page 4, line 13 ¶ | |||
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 | |||
delivery. The protocol allows the TACACS+ client to request very | delivery. The protocol allows the TACACS+ client to request very | |||
fine-grained access control and allows the server to respond to each | fine-grained access control and allows the server to respond to each | |||
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, 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 authorization request. | association of an authentication to each authorization request. | |||
This document restricts itself to a description of the protocol that | 2. Conventions | |||
is used by TACACS+. It does not cover deployment or best practices. | ||||
2. Technical Definitions | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in RFC2119 [RFC2119] | ||||
3. 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 | |||
The client is any device, (often a Network Access Server) that | The client is any device, (often a Network Access Server) that | |||
provides access services. The clients usually provide a character | provides access services. The clients usually provide a character | |||
mode front end and then allow the user to telnet or rlogin to another | mode front end and then allow the user to telnet or rlogin to another | |||
host. | host. | |||
skipping to change at page 4, line 45 ¶ | skipping to change at page 5, line 5 ¶ | |||
The server receives TACACS+ protocol requests, and replies according | The server receives TACACS+ protocol requests, and replies according | |||
to its business model, in accordance with the flows defined in this | to its business model, in accordance with the flows defined in this | |||
document. | document. | |||
Packet | Packet | |||
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 | 4. TACACS+ Connections and Sessions | |||
3.1. Connection | 4.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.2. Session | 4.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 | |||
TACACS+ client and server. It does not necessarily correspond to a | TACACS+ client and server. It does not necessarily correspond to a | |||
given user or user action. | given user or user action. | |||
3.3. Single Connection Mode | 4.3. Single Connection Mode | |||
Single Connection Mode is intended to improve performance by allowing | Single Connection Mode is intended to improve performance by allowing | |||
a client to multiplex multiple session on a single TCP connection. | a client to multiplex multiple session on a single TCP connection. | |||
The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by | The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by | |||
the client and server to negotiate the use of Single Connect Mode. | the client and server to negotiate the use of Single Connect Mode. | |||
The client sets this flag, to indicate that it supports multiplexing | The client sets this flag, to indicate that it supports multiplexing | |||
TACACS+ sessions over a single TCP connection. The client MUST NOT | TACACS+ sessions over a single TCP connection. The client MUST NOT | |||
send a second packet on a connection until single-connect status has | send a second packet on a connection until single-connect status has | |||
skipping to change at page 6, line 9 ¶ | skipping to change at page 6, line 16 ¶ | |||
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 | 4.4. Session Completion | |||
The REPLY packets defined for the packets types in the sections below | The REPLY packets defined for the packets types in the sections below | |||
(Authentication, Authorization and Accounting) contain a status | (Authentication, Authorization and Accounting) contain a status | |||
field. The complete set of options for this field depend upon the | field. The complete set of options for this field depend upon the | |||
packet type, but all three REPLY packet types define values | packet type, but all three REPLY packet types define values | |||
representing PASS, ERROR and FAIL, which indicate the last packet of | representing PASS, ERROR and FAIL, which indicate the last packet of | |||
a regular session (one which is not aborted). | a regular session (one which is not aborted). | |||
The server responds with a PASS or a FAIL to indicate that the | The server responds with a PASS or a FAIL to indicate that the | |||
processing of the request completed and the client can apply the | processing of the request completed and the client can apply the | |||
skipping to change at page 6, line 31 ¶ | skipping to change at page 6, line 38 ¶ | |||
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 tries alternative methods, if they are available, | example, the client tries alternative methods, if they are available, | |||
such as sending the request to a backup server, or using local | such as sending the request to a backup server, or using local | |||
configuration to determine whether the action which prompted the | configuration to determine whether the action which prompted the | |||
request should be executed. | request should be executed. | |||
Refer to the section (Section 4.4.3) on Aborting Authentication | Refer to the section (Section 5.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: | |||
If Single Connection Mode was not negotiated, then the connection | If Single Connection Mode was not negotiated, then the connection | |||
should be closed | should be closed | |||
If Single Connection Mode was enabled, then the connection SHOULD be | If Single Connection Mode was enabled, then the connection SHOULD be | |||
left open (see section (Section 3.3) ), but may still be closed after | left open (see section (Section 4.3) ), but may still be closed after | |||
a timeout period to preserve deployment resources | a timeout period to preserve deployment resources | |||
If Single Connection Mode was enabled, but an ERROR occurred due to | If Single Connection Mode was enabled, but an ERROR occurred due to | |||
connection issues (such as an incorrect secret, see section | connection issues (such as an incorrect secret, see section | |||
(Section 3.7) ), then any further new sessions MUST NOT be accepted | (Section 4.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 implementation specific. | will be implementation specific. | |||
The client should manage connections and handle the case of a server | The client should manage connections and handle the case of a server | |||
which establishes a connection, but does not respond. The exact | which establishes a connection, but does not respond. The exact | |||
behavior is implementation specific. It is recommended that the | behavior is implementation specific. It is recommended that the | |||
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 | 4.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. | |||
If an error occurs but the type of the incoming packet cannot be | If an error occurs but the type of the incoming packet cannot be | |||
determined, a packet with the identical cleartext header but with a | determined, a packet with the identical cleartext header but with a | |||
sequence number incremented by one and the length set to zero MUST be | sequence number incremented by one and the length set to zero MUST be | |||
returned to indicate an error. | returned to indicate an error. | |||
3.6. Text Encoding | 4.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 | 4.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. The secret | |||
does not discuss the management and storage of those keys, other than | 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 | |||
skipping to change at page 9, line 11 ¶ | skipping to change at page 9, line 17 ¶ | |||
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 3.4) | handling on ERROR, refer to section (Section 4.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. | |||
After a packet body is de-obfuscated, the lengths of the component | After a packet body is de-obfuscated, the lengths of the component | |||
values in the packet are summed. If the sum is not identical to the | values in the packet are summed. If the sum is not identical to the | |||
cleartext datalength value from the header, the packet MUST be | cleartext datalength value from the header, the packet MUST be | |||
discarded, and an ERROR signaled. For details of TCP connection | discarded, and an ERROR signaled. For details of TCP connection | |||
handling on ERROR, refer to section (Section 3.4) | handling on ERROR, refer to section (Section 4.4) | |||
Commonly such failures are seen when the keys are mismatched between | Commonly such failures are seen when the keys are mismatched between | |||
the client and the TACACS+ server. | the client and the TACACS+ server. | |||
3.8. The TACACS+ Packet Header | 4.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 | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| | | | | | |||
skipping to change at page 10, line 47 ¶ | skipping to change at page 11, line 15 ¶ | |||
flags | flags | |||
This field contains various bitmapped flags. | This field contains various bitmapped flags. | |||
The flag bit: | The flag bit: | |||
TAC_PLUS_UNENCRYPTED_FLAG := 0x01 | TAC_PLUS_UNENCRYPTED_FLAG := 0x01 | |||
This flag indicates that the sender did not obfuscate the body of the | This flag indicates that the sender did not obfuscate the body of the | |||
packet. The application of this flag will be covered in the security | packet. The application of this flag will be covered in the security | |||
section (Section 9) . | section (Section 10) . | |||
This flag SHOULD be clear in all deployments. Modern network traffic | This flag SHOULD be clear in all deployments. Modern network traffic | |||
tools support encrypted traffic when configured with the shared | tools support encrypted traffic when configured with the shared | |||
secret (see section below), so obfuscated mode can and SHOULD be used | secret (see section below), so obfuscated mode can and SHOULD be used | |||
even during test. | even during test. | |||
The single-connection flag: | The single-connection flag: | |||
TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 | TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 | |||
skipping to change at page 11, line 24 ¶ | skipping to change at page 11, line 41 ¶ | |||
The Id for this TACACS+ session. This field does not change for the | The Id for this TACACS+ session. This field does not change for the | |||
duration of the TACACS+ session. This number MUST be generated by a | duration of the TACACS+ session. This number MUST be generated by a | |||
cryptographically strong random number generation method. Failure to | cryptographically strong random number generation method. Failure to | |||
do so will compromise security of the session. For more details | do so will compromise security of the session. For more details | |||
refer to RFC 1750 [RFC1750] | refer to RFC 1750 [RFC1750] | |||
length | length | |||
The total length of the packet body (not including the header). | The total length of the packet body (not including the header). | |||
3.9. The TACACS+ Packet Body | 4.9. The TACACS+ Packet Body | |||
The TACACS+ body types are defined in the packet header. The next | The TACACS+ body types are defined in the packet header. The next | |||
sections of this document will address the contents of the different | sections of this document will address the contents of the different | |||
TACACS+ bodies. The following general rules apply to all TACACS+ | TACACS+ bodies. The following general rules apply to all TACACS+ | |||
body types: | body types: | |||
- To signal that any variable length data fields are unused, their | - To signal that any variable length data fields are unused, their | |||
length value is set to zero. Such fields MUST be ignored, and | length value is set to zero. Such fields MUST be ignored, and | |||
treated as if not present. | treated as if not present. | |||
- the lengths of data and message fields in a packet are specified | - the lengths of data and message fields in a packet are specified | |||
by their corresponding length fields, (and are not null | by their corresponding length fields, (and are not null | |||
terminated.) | terminated.) | |||
- All length values are unsigned and in network byte order. | - All length values are unsigned and in network byte order. | |||
4. Authentication | 5. Authentication | |||
Authentication is the action of determining who a user (or entity) | Authentication is the action of determining who a user (or entity) | |||
is. Authentication can take many forms. Traditional authentication | is. Authentication can take many forms. Traditional authentication | |||
employs a name and a fixed password. However, fixed passwords are | employs a name and a fixed password. However, fixed passwords are | |||
vulnerable security, so many modern authentication mechanisms utilize | vulnerable security, so many modern authentication mechanisms utilize | |||
"one-time" passwords or a challenge-response query. TACACS+ is | "one-time" passwords or a challenge-response query. TACACS+ is | |||
designed to support all of these, and be flexible enough to handle | designed to support all of these, and be flexible enough to handle | |||
any future mechanisms. Authentication generally takes place when the | any future mechanisms. Authentication generally takes place when the | |||
user first logs in to a machine or requests a service of it. | user first logs in to a 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. | |||
4.1. The Authentication START Packet Body | 5.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 ... | |||
skipping to change at page 12, line 45 ¶ | skipping to change at page 13, line 14 ¶ | |||
TAC_PLUS_AUTHEN_LOGIN := 0x01 | TAC_PLUS_AUTHEN_LOGIN := 0x01 | |||
TAC_PLUS_AUTHEN_CHPASS := 0x02 | TAC_PLUS_AUTHEN_CHPASS := 0x02 | |||
TAC_PLUS_AUTHEN_SENDAUTH := 0x04 | TAC_PLUS_AUTHEN_SENDAUTH := 0x04 | |||
priv_lvl | priv_lvl | |||
This indicates the privilege level that the user is authenticating | This indicates the privilege level that the user is authenticating | |||
as. Please refer to the Privilege Level section (Section 8) below. | as. Please refer to the Privilege Level section (Section 9) below. | |||
authen_type | authen_type | |||
The type of authentication. Legal values are: | The type of authentication. Legal values are: | |||
TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 | TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01 | |||
TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 | TAC_PLUS_AUTHEN_TYPE_PAP := 0x02 | |||
TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 | TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03 | |||
TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) | TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated) | |||
TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 | TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05 | |||
TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 | TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06 | |||
skipping to change at page 14, line 40 ¶ | skipping to change at page 15, line 9 ¶ | |||
network address if the user is connected via a network, a caller ID | network address if the user is connected via a network, a caller ID | |||
is the user is connected via ISDN or a POTS, or any other remote | is the user is connected via ISDN or a POTS, or any other remote | |||
location information that is available. This field is optional | location information that is available. This field is optional | |||
(since the information may not be available). The rem_addr_len | (since the information may not be available). The rem_addr_len | |||
indicates the length of the user field, in bytes. | indicates the length of the user field, in bytes. | |||
data, data_len | 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) . The data_len indicates the | Authentication flows (Section 5.4.2) . The data_len indicates the | |||
length of the data field, in bytes. | length of the data field, in bytes. | |||
4.2. The Authentication REPLY Packet Body | 5.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. | REPLY packet) to the client. | |||
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 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
skipping to change at page 15, line 51 ¶ | skipping to change at page 16, line 15 ¶ | |||
server_msg, server_msg_len | server_msg, server_msg_len | |||
A message to be displayed to the user. This field is optional. The | A message to be displayed to the user. This field is optional. The | |||
printable US-ASCII charset MUST be used. The server_msg_len | printable US-ASCII charset MUST be used. The server_msg_len | |||
indicates the length of the server_msg field, in bytes. | indicates the length of the server_msg field, in bytes. | |||
data, data_len | 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. Examples of its use | and is intended for the client, not the user. Examples of its use | |||
are shown in the section Common Authentication flows (Section 4.4.2) | are shown in the section Common Authentication flows (Section 5.4.2) | |||
. The data_len indicates the length of the data field, in bytes. | . The data_len indicates the length of the data field, in bytes. | |||
4.3. The Authentication CONTINUE Packet Body | 5.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 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
skipping to change at page 16, line 40 ¶ | skipping to change at page 17, line 5 ¶ | |||
below. The data_len indicates the length of the data field, in | below. The data_len indicates the length of the data field, in | |||
bytes. | 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 | 5.4. Description of Authentication Process | |||
The action, authen_type and authen_service fields (described above) | The action, authen_type and authen_service fields (described above) | |||
combine to indicate what kind of authentication is to be performed. | combine to indicate what kind of authentication is to be performed. | |||
Every 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. | |||
This document defines a core set of authentication flows to be | This document defines a core set of authentication flows to be | |||
supported by TACACS+. Each authentication flow consists of a START | supported by TACACS+. Each authentication flow consists of a START | |||
packet. The server responds either with a request for more | packet. The server responds either with a request for more | |||
skipping to change at page 17, line 27 ¶ | skipping to change at page 17, line 40 ¶ | |||
request for more information to flexibly support future requirements. | request for more information to flexibly support future requirements. | |||
If the information being requested by the server form the client is | If the information being requested by the server form the client is | |||
sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO | sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO | |||
flag. When the client queries the user for the information, the | flag. When the client queries the user for the information, the | |||
response MUST NOT be echoed as it is entered. | response MUST NOT be echoed as it is entered. | |||
The data field is only used in the REPLY where explicitly defined | The data field is only used in the REPLY where explicitly defined | |||
below. | below. | |||
4.4.1. Version Behaviour | 5.4.1. Version Behaviour | |||
The TACACS+ protocol is versioned to allow revisions while | The TACACS+ protocol is versioned to allow revisions while | |||
maintaining backwards compatibility. The version number is in every | maintaining backwards compatibility. The version number is in every | |||
packet header. The changes between minor_version 0 and 1 apply only | packet header. The changes between minor_version 0 and 1 apply only | |||
to the authentication process, and all deal with the way that CHAP | to the authentication process, and all deal with the way that CHAP | |||
and PAP authentications are handled. minor_version 1 may only be used | and PAP authentications are handled. minor_version 1 may only be used | |||
for authentication kinds that explicitly call for it in the table | for authentication kinds that explicitly call for it in the table | |||
below: | below: | |||
LOGIN CHPASS SENDAUTH | LOGIN CHPASS SENDAUTH | |||
skipping to change at page 18, line 8 ¶ | skipping to change at page 18, line 23 ¶ | |||
All authorisation and accounting and ASCII authentication use | All authorisation and accounting and ASCII authentication use | |||
minor_version number of 0. | minor_version number of 0. | |||
PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange | PAP, CHAP and MS-CHAP login use minor_version 1. The normal exchange | |||
is a single START packet from the client and a single REPLY from the | is a single START packet from the client and a single REPLY from the | |||
server. | server. | |||
The removal of SENDPASS was prompted by security concerns, and is no | The removal of SENDPASS was prompted by security concerns, and is no | |||
longer considered part of the TACACS+ protocol. | longer considered part of the TACACS+ protocol. | |||
4.4.2. Common Authentication Flows | 5.4.2. Common Authentication Flows | |||
This section describes common authentication flows. If the server | This section describes common authentication flows. If the server | |||
does not implement an option, it MUST respond with | does not implement an option, it MUST respond with | |||
TAC_PLUS_AUTHEN_STATUS_FAIL. | TAC_PLUS_AUTHEN_STATUS_FAIL. | |||
4.4.2.1. ASCII Login | 5.4.2.1. 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. If the user does not include the username then | contain the username. If the user does not include the username then | |||
the server MUST obtain it from the client with a CONTINUE | the server MUST obtain it from the client with a CONTINUE | |||
TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user does not provide a | TAC_PLUS_AUTHEN_STATUS_GETUSER. If the user does not provide a | |||
username then the server can send another | username then the server can send another | |||
skipping to change at page 18, line 36 ¶ | skipping to change at page 19, line 5 ¶ | |||
number of retries that are permitted, recommended limit is three | number of retries that are permitted, recommended limit is three | |||
attempts. When the server has the username, it will obtain the | attempts. When the server has the username, it will obtain the | |||
password using a continue with TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII | password using a continue with TAC_PLUS_AUTHEN_STATUS_GETPASS. ASCII | |||
login uses the user_msg field for both the username and password. | login uses the user_msg field for both the username and password. | |||
The data fields in both the START and CONTINUE packets are not used | The data fields in both the START and CONTINUE packets are not used | |||
for ASCII logins, any content MUST be ignored. The session is | for ASCII logins, any content MUST be ignored. The session is | |||
composed of a single START followed by zero or more pairs of REPLYs | composed of a single START followed by zero or more pairs of REPLYs | |||
and CONTINUEs, followed by a final REPLY indicating PASS, FAIL or | and CONTINUEs, followed by a final REPLY indicating PASS, FAIL or | |||
ERROR. | ERROR. | |||
4.4.2.2. PAP Login | 5.4.2.2. PAP Login | |||
action = TAC_PLUS_AUTHEN_LOGIN | action = TAC_PLUS_AUTHEN_LOGIN | |||
authen_type = TAC_PLUS_AUTHEN_TYPE_PAP | authen_type = TAC_PLUS_AUTHEN_TYPE_PAP | |||
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 a username and the data | single REPLY. The START packet MUST contain a username and the data | |||
field MUST contain the PAP ASCII password. A PAP authentication only | field MUST contain the PAP ASCII password. A PAP authentication only | |||
consists of a username and password RFC 1334 [RFC1334] . The REPLY | consists of a username and password RFC 1334 [RFC1334] . The REPLY | |||
from the server MUST be either a PASS, FAIL or ERROR. | from the server MUST be either a PASS, FAIL or ERROR. | |||
4.4.2.3. CHAP login | 5.4.2.3. CHAP login | |||
action = TAC_PLUS_AUTHEN_LOGIN | action = TAC_PLUS_AUTHEN_LOGIN | |||
authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP | authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP | |||
minor_version = 0x1 | minor_version = 0x1 | |||
The entire exchange MUST consist of a single START packet and a | The entire exchange MUST consist of a single START packet and a | |||
single REPLY. The START packet MUST contain the username in the user | single REPLY. The START packet MUST contain the username in the user | |||
field and the data field 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. | |||
skipping to change at page 19, line 32 ¶ | skipping to change at page 19, line 44 ¶ | |||
compare that value with the response. The MD5 algorithm option is | compare that value with the response. The MD5 algorithm option is | |||
always used. The REPLY from the server MUST be a PASS, FAIL or | always used. The REPLY from the server MUST be a PASS, FAIL or | |||
ERROR. | ERROR. | |||
The selection of the challenge and its length are not an aspect of | The selection of the challenge and its length are not an aspect of | |||
the TACACS+ protocol. However, it is strongly recommended that the | the TACACS+ protocol. However, it is strongly recommended that the | |||
client/endstation interaction is configured with a secure challenge. | client/endstation interaction is configured with a secure challenge. | |||
The TACACS+ server can help by rejecting authentications where the | The TACACS+ server can help by rejecting authentications where the | |||
challenge is below a minimum length (Minimum recommended is 8 bytes). | challenge is below a minimum length (Minimum recommended is 8 bytes). | |||
4.4.2.4. MS-CHAP v1 login | 5.4.2.4. MS-CHAP v1 login | |||
action = TAC_PLUS_AUTHEN_LOGIN | action = TAC_PLUS_AUTHEN_LOGIN | |||
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP | authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP | |||
minor_version = 0x1 | minor_version = 0x1 | |||
The entire exchange MUST consist of a single START packet and a | The entire exchange MUST consist of a single START packet and a | |||
single REPLY. The START packet MUST contain the username in the user | single REPLY. The START packet MUST contain the username in the user | |||
field and the data field will be a concatenation of the PPP id, the | field and the data field will be a concatenation of the PPP id, the | |||
MS-CHAP challenge and the MS-CHAP response. | MS-CHAP challenge and the MS-CHAP response. | |||
skipping to change at page 20, line 9 ¶ | skipping to change at page 20, line 23 ¶ | |||
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 reject 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 | 5.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 | |||
field and the data field will be a concatenation of the PPP id, the | field and the data field will be a concatenation of the PPP id, the | |||
MS-CHAP challenge and the MS-CHAP response. | MS-CHAP challenge and the MS-CHAP response. | |||
skipping to change at page 20, line 33 ¶ | skipping to change at page 20, line 47 ¶ | |||
To perform the authentication, the server will use the algorithm | To perform the authentication, the server will use the algorithm | |||
specified RFC 2759 [RFC2759] on the user's secret and challenge and | specified RFC 2759 [RFC2759] on the user's secret and challenge and | |||
then compare the resulting value with the response. The REPLY from | then compare the resulting value with the response. The REPLY from | |||
the server MUST be a PASS or FAIL. | the server MUST be a PASS or FAIL. | |||
For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] | For best practices for MS-CHAP v2, please refer to RFC2759 [RFC2759] | |||
. The TACACS+ server MUST rejects authentications where the challenge | . The TACACS+ server MUST rejects authentications where the challenge | |||
deviates from 16 bytes as defined in the RFC. | deviates from 16 bytes as defined in the RFC. | |||
4.4.2.6. Enable Requests | 5.4.2.6. Enable Requests | |||
action = TAC_PLUS_AUTHEN_LOGIN | action = TAC_PLUS_AUTHEN_LOGIN | |||
priv_lvl = implementation dependent | priv_lvl = implementation dependent | |||
authen_type = not used | authen_type = not used | |||
service = TAC_PLUS_AUTHEN_SVC_ENABLE | service = TAC_PLUS_AUTHEN_SVC_ENABLE | |||
This is an ENABLE request, used to change the current running | This is an ENABLE request, used to change the current running | |||
privilege level of a user. The exchange MAY consist of multiple | privilege level of a user. 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 ASCII login (Section 4.4.2.1) . | exchange is very similar to an ASCII login (Section 5.4.2.1) . | |||
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 authen_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. | |||
4.4.2.7. ASCII change password request | 5.4.2.7. 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. | |||
It is very similar to an ASCII login. The status value | It is very similar to an ASCII login. The status value | |||
TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the | TAC_PLUS_AUTHEN_STATUS_GETPASS MUST only be used when requesting the | |||
"new" password. It MAY be sent multiple times. When requesting the | "new" password. It MAY be sent multiple times. When requesting the | |||
"old" password, the status value MUST be set to | "old" password, the status value MUST be set to | |||
TAC_PLUS_AUTHEN_STATUS_GETDATA. | TAC_PLUS_AUTHEN_STATUS_GETDATA. | |||
4.4.3. Aborting an Authentication Session | 5.4.3. Aborting an Authentication Session | |||
The client may prematurely terminate a session by setting the | The client may prematurely terminate a session by setting the | |||
TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this | TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this | |||
flag is set, the data portion of the message may contain 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 termination, refer to section (Section 3.4) | session termination, refer to section (Section 4.4) | |||
In the case of PALL, FAIL or ERROR, the server can insert a message | In cases of PASS, FAIL or ERROR, the server can insert a message into | |||
into server_msg to be displayed to the user. | server_msg to be displayed to the user. | |||
The Draft `The Draft' [TheDraft] defined a mechanism to direct | The Draft `The Draft' [TheDraft] defined a mechanism to direct | |||
authentication requests to an alternative server. This mechanism is | authentication requests to an alternative server. This mechanism is | |||
regarded as insecure, is deprecated, and not covered here. The | regarded as insecure, is deprecated, and not covered here. The | |||
client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as | client should treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as | |||
TAC_PLUS_AUTHEN_STATUS_FAIL | TAC_PLUS_AUTHEN_STATUS_FAIL | |||
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 will proceed as if that host could not be contacted. | authentication will proceed as if that host could not be contacted. | |||
skipping to change at page 22, line 9 ¶ | skipping to change at page 22, line 24 ¶ | |||
authentication sequence is restarted with a new START packet from the | authentication sequence is restarted with a new START packet from the | |||
client, with new session Id, and seq_no set to 1. This REPLY packet | client, with new session Id, and seq_no set to 1. This REPLY packet | |||
indicates that the current authen_type value (as specified in the | indicates that the current authen_type value (as specified in the | |||
START packet) is not acceptable for this session. The client may try | START packet) is not acceptable for this session. The client may try | |||
an alternative authen_type. | an alternative authen_type. | |||
If a client does not implement TAC_PLUS_AUTHEN_STATUS_RESTART option, | If a client does not implement TAC_PLUS_AUTHEN_STATUS_RESTART option, | |||
then it MUST process the response as if the status was | then it MUST process the response as if the status was | |||
TAC_PLUS_AUTHEN_STATUS_FAIL. | TAC_PLUS_AUTHEN_STATUS_FAIL. | |||
5. Authorization | 6. Authorization | |||
In the TACACS+ Protocol, authorization is the action of determining | In the TACACS+ Protocol, authorization is the action of determining | |||
what a user is allowed to do. Generally authentication precedes | what a user is allowed to do. Generally authentication precedes | |||
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 | |||
into 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 8.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 client's actions. | value pairs) that can restrict or modify the client's actions. | |||
5.1. The Authorization REQUEST Packet Body | 6.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 ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
skipping to change at page 24, line 21 ¶ | skipping to change at page 24, line 25 ¶ | |||
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. | protocols from Berkeley Unix. | |||
priv_lvl | priv_lvl | |||
This field is used in the same way as the priv_lvl field in | This field is used in the same way as the priv_lvl field in | |||
authentication request and is described in the Privilege Level | authentication request and is described in the Privilege Level | |||
section (Section 8) below. It indicates the users current privilege | section (Section 9) below. It indicates the users current privilege | |||
level. | level. | |||
authen_type | authen_type | |||
This field coresponds 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 5) 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 5) above. It indicates the service | |||
through which the user authenticated. | through which the user authenticated. | |||
user, user_len | user, user_len | |||
This field contains the user's account name. The user_len MUST | This field contains the user's account name. The user_len MUST | |||
indicate the length of the user field, in bytes. | indicate the length of the user field, in bytes. | |||
port, port_len | 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. The port_len indicates the length of the port | (Section 5) above. The port_len indicates the length of the port | |||
field, in bytes. | field, in bytes. | |||
rem_addr, rem_addr_len | 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. The rem_addr_len indicates the length of the port | (Section 5) above. The rem_addr_len indicates the length of the port | |||
field, in bytes. | field, in bytes. | |||
arg_cnt | arg_cnt | |||
The number of authorization arguments to follow | The number of authorization arguments to follow | |||
arg_1 ... arg_N, arg_1_len .... arg_N_len | arg_1 ... arg_N, arg_1_len .... arg_N_len | |||
The arguments are the primary elements of the authorization | The arguments are the primary elements of the authorization | |||
interaction. In the request packet they describe the specifics of | interaction. In the request packet they describe the specifics of | |||
skipping to change at page 25, line 48 ¶ | skipping to change at page 25, line 51 ¶ | |||
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 8.2) | |||
section below. | section below. | |||
5.2. The Authorization REPLY Packet Body | 6.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 | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| status | arg_cnt | server_msg len | | | status | arg_cnt | server_msg len | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
+ data_len | arg_1_len | arg_2_len | | + data_len | arg_1_len | arg_2_len | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| ... | arg_N_len | server_msg ... | | ... | arg_N_len | server_msg ... | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| data ... | | data ... | |||
skipping to change at page 27, line 10 ¶ | skipping to change at page 27, line 10 ¶ | |||
message is client specific. The data_len indicates the length of the | message is client specific. The data_len indicates the length of the | |||
data field, in bytes. | data field, in bytes. | |||
arg_cnt | arg_cnt | |||
The number of authorization arguments to follow. | The number of authorization arguments to follow. | |||
arg_1 ... arg_N, arg_1_len .... arg_N_len | arg_1 ... arg_N, arg_1_len .... arg_N_len | |||
The arguments describe the specifics of the authorization that is | The arguments describe the specifics of the authorization that is | |||
being requested. For details of the content of the args, refer to: | being requested. For details of the content of the args, refer to: | |||
Authorization Attributes (Section 7.2) section below. Each argument | Authorization Attributes (Section 8.2) section below. Each argument | |||
is encoded in the packet as a single arg field (arg_1... arg_N) with | is encoded in the packet as a single arg field (arg_1... arg_N) with | |||
a corresponding length fields (which indicates the length of each | a corresponding length fields (which indicates the length of each | |||
argument in bytes). | argument in bytes). | |||
If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested | If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested | |||
authorization MUST be denied. | authorization MUST be denied. | |||
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 MUST be applied according to the rules described | in the response MUST be applied according to the rules described | |||
skipping to change at page 27, line 33 ¶ | skipping to change at page 27, line 33 ¶ | |||
If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client | If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client | |||
MUST use the authorization attribute-value pairs (if any) in the | MUST use the authorization attribute-value pairs (if any) in the | |||
response, instead of the authorization attribute-value pairs from the | response, instead of the authorization attribute-value pairs from the | |||
request. | request. | |||
To approve the authorization with no modifications, the server sets | To approve the authorization with no modifications, the server sets | |||
the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. | the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt to 0. | |||
A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred | A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred | |||
on the server. For the differences between ERROR and FAIL, refer to | on the server. For the differences between ERROR and FAIL, refer to | |||
section Session Completion (Section 3.4) . None of the arg values | section Session Completion (Section 4.4) . None of the arg values | |||
have any relevance if an ERROR is set, and must be ignored. | have any relevance if an ERROR is set, and must be ignored. | |||
When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the | When the status equals TAC_PLUS_AUTHOR_STATUS_FOLLOW, then the | |||
arg_cnt MUST be 0. In that case, the actions to be taken and the | arg_cnt MUST be 0. In that case, the actions to be taken and the | |||
contents of the data field are identical to the | contents of the data field are identical to the | |||
TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. | TAC_PLUS_AUTHEN_STATUS_FOLLOW status for Authentication. | |||
6. Accounting | 7. Accounting | |||
Accounting is typically the third action after authentication and | Accounting is typically the third action after authentication and | |||
authorization. But again, neither authentication nor authorization | authorization. But again, neither authentication nor authorization | |||
is required. Accounting is the action of recording what a user is | is required. Accounting is the action of recording what a user is | |||
doing, and/or has done. Accounting in TACACS+ can serve two | doing, and/or has done. Accounting in TACACS+ can serve two | |||
purposes: It may be used as an auditing tool for security services. | purposes: It may be used as an auditing tool for security services. | |||
It may also be used to account for services used, such as in a | It may also be used to account for services used, such as in a | |||
billing environment. To this end, TACACS+ supports three types of | billing environment. To this end, TACACS+ supports three types of | |||
accounting records. Start records indicate that a service is about | accounting records. Start records indicate that a service is about | |||
to begin. Stop records indicate that a service has just terminated, | to begin. Stop records indicate that a service has just terminated, | |||
and Update records are intermediate notices that indicate that a | and Update records are intermediate notices that indicate that a | |||
service is still being performed. TACACS+ accounting records contain | service is still being performed. TACACS+ accounting records contain | |||
all the information used in the authorization records, and also | all the information used in the authorization records, and also | |||
contain accounting specific information such as start and stop times | contain accounting specific information such as start and stop times | |||
(when appropriate) and resource usage information. A list of | (when appropriate) and resource usage information. A list of | |||
accounting attributes is defined in the accounting section | accounting attributes is defined in the accounting section | |||
(Section 6) . | (Section 7) . | |||
6.1. The Account REQUEST Packet Body | 7.1. The Account 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 | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| flags | authen_method | priv_lvl | authen_type | | | flags | authen_method | priv_lvl | authen_type | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| authen_service | user_len | port_len | rem_addr_len | | | authen_service | user_len | port_len | rem_addr_len | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg_cnt | arg_1_len | arg_2_len | ... | | | arg_cnt | arg_1_len | arg_2_len | ... | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
| arg_N_len | user ... | | arg_N_len | user ... | |||
skipping to change at page 29, line 8 ¶ | skipping to change at page 29, line 8 ¶ | |||
TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 | TAC_PLUS_ACCT_FLAG_WATCHDOG := 0x08 | |||
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. They provide details for | sections above and have the same semantics. They provide details for | |||
the conditions on the client, and authentication context, so that | the conditions on the client, and authentication context, so that | |||
these details may be logged for accounting purposes. | these details may be logged for accounting purposes. | |||
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 | 7.2. The Accounting REPLY Packet Body | |||
The purpose of accounting is to record the action that has occurred | The purpose of accounting is to record the action that has occurred | |||
on the client. The server MUST reply with success only when the | on the client. The server MUST reply with success only when the | |||
accounting request has been recorded. If the server did not record | accounting request has been recorded. If the server did not record | |||
the accounting request then it MUST reply with ERROR. | the accounting request then it MUST reply with ERROR. | |||
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 | | |||
+----------------+----------------+----------------+----------------+ | +----------------+----------------+----------------+----------------+ | |||
skipping to change at page 30, line 45 ¶ | skipping to change at page 30, line 45 ¶ | |||
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. | |||
The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client | The Server MUST respond with TAC_PLUS_ACCT_STATUS_ERROR if the client | |||
requests an INVALID option. | requests an INVALID option. | |||
7. Attribute-Value Pairs | 8. Attribute-Value Pairs | |||
TACACS+ is intended to be an extensible protocol. The attributes | TACACS+ is intended to be an extensible protocol. The attributes | |||
used in Authorization and Accounting are not limited by this | used in Authorization and Accounting are not limited by this | |||
document. Some attributes are defined below for common use cases, | document. Some attributes are defined below for common use cases, | |||
clients MUST use these attributes when supporting the corresponding | clients MUST use these attributes when supporting the corresponding | |||
use cases. | use cases. | |||
7.1. Value Encoding | 8.1. Value Encoding | |||
All attribute values are encoded as printable US-ASCII strings. The | All attribute values are encoded as printable US-ASCII strings. The | |||
following type representations SHOULD be followed | following type representations SHOULD be followed | |||
Numeric | Numeric | |||
All numeric values in an attribute-value string are provided as | All numeric values in an attribute-value string are provided as | |||
decimal printable US-ASCII numbers, unless otherwise stated. | decimal printable US-ASCII numbers, unless otherwise stated. | |||
Boolean | Boolean | |||
All boolean attributes are encoded as printable US-ASCII with values | All boolean attributes are encoded as printable US-ASCII with values | |||
"true" or "false". | "true" or "false". | |||
IP-Address | IP-Address | |||
It is recommended that hosts be specified as a IP address so as to | It is recommended that hosts be specified as a IP address so as to | |||
avoid any ambiguities. IPV4 address are specified as US-ASCII octet | avoid any ambiguities. IPV4 address are specified as US-ASCII octet | |||
numerics separated by dots ('.'), IPV6 address text representation | numerics separated by dots ('.'), IPV6 address text representation | |||
defined in RFC 4291. | defined in RFC 4291 [RFC4291] | |||
Date Time | Date Time | |||
Absolute date/times are specified in seconds since the epoch, 12:00am | Absolute date/times are specified in seconds since the epoch, 12:00am | |||
Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is | Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is | |||
specified. Stardate is canonically inconsistent and so SHOULD NOT be | specified. Stardate is canonically inconsistent and so SHOULD NOT be | |||
used. | used. | |||
String | String | |||
Many values have no specific type representation and so are | Many values have no specific type representation and so are | |||
interpreted as plain strings. | interpreted as plain strings. | |||
Empty Values | Empty Values | |||
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 | |||
four characters "cmd=" | four characters "cmd=" | |||
7.2. Authorization Attributes | 8.2. Authorization Attributes | |||
service (String) | service (String) | |||
The primary service. Specifying a service attribute indicates that | The primary service. Specifying a service attribute indicates that | |||
this is a request for authorization or accounting of that service. | this is a request for authorization or accounting of that service. | |||
For example: "shell", "tty-server", "connection", "system" and | For example: "shell", "tty-server", "connection", "system" and | |||
"firewall". This attribute MUST always be included. | "firewall". This attribute MUST always be included. | |||
protocol (String) | protocol (String) | |||
skipping to change at page 33, line 16 ¶ | skipping to change at page 33, line 16 ¶ | |||
The identifier of an address pool from which the client can assign an | The identifier of an address pool from which the client can assign an | |||
address. | address. | |||
routing (Boolean) | routing (Boolean) | |||
Specifies whether routing information is to be propagated to, and | Specifies whether routing information is to be propagated to, and | |||
accepted from this interface. | accepted from this interface. | |||
route (String) | route (String) | |||
Indicates a route that is to be applied to this interface. Values | Indicates an IPv4 route that is to be applied to this interface. | |||
MUST be of the form "<dst_address> <mask> [<routing_addr>]". If a | Values MUST be of the form "<dst_address> <mask> [<routing_addr>]". | |||
<routing_addr> is not specified, the resulting route is via the | If a <routing_addr> is not specified, the resulting route is via the | |||
requesting peer. | requesting peer. | |||
timeout (Numeric) | timeout (Numeric) | |||
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 (Numeric) | idletime (Numeric) | |||
an idle-timeout for the connection (in minutes). A value of zero | an idle-timeout for the connection (in minutes). A value of zero | |||
skipping to change at page 33, line 49 ¶ | skipping to change at page 33, line 49 ¶ | |||
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. | 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 9) 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 | |||
remote_user and remote_host attributes will provide the remote user | remote_user and remote_host attributes will provide the remote user | |||
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 (String) | remote_host (String) | |||
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) | |||
7.3. Accounting Attributes | 8.3. Accounting Attributes | |||
The following attributes are defined for TACACS+ accounting only. | The following attributes are defined for TACACS+ accounting only. | |||
They MUST precede any attribute-value pairs that are defined in the | They MUST precede any attribute-value pairs that are defined in the | |||
authorization section (Section 5) above. | authorization section (Section 6) above. | |||
task_id (String) | task_id (String) | |||
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 ensure that active task_ids are | attribute values. The client MUST ensure that active task_ids are | |||
not duplicated: a client MUST NOT reuse a task_id a start record | not duplicated: a client MUST NOT reuse a task_id a start record | |||
until it has sent a stop record for that task_id. Servers MUST not | until it has sent a stop record for that task_id. Servers MUST not | |||
make assumptions about the format of a task_id. | make assumptions about the format of a task_id. | |||
start_time (Date Time) | start_time (Date Time) | |||
skipping to change at page 34, line 45 ¶ | skipping to change at page 34, line 45 ¶ | |||
The time the action stopped (in seconds since the epoch.) | The time the action stopped (in seconds since the epoch.) | |||
elapsed_time (Numeric) | elapsed_time (Numeric) | |||
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. | |||
A database of timezones is maintained here: TZDB [TZDB] | ||||
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 41 ¶ | skipping to change at page 35, line 44 ¶ | |||
paks_out (Numeric) | paks_out (Numeric) | |||
The number of output packets transferred by this action from the | The number of output packets transferred by this action from the | |||
client port to the endstation. | client port to the endstation. | |||
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 | 9. 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 into 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 | |||
skipping to change at page 36, line 32 ¶ | skipping to change at page 36, line 35 ¶ | |||
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 | 10. TACACS+ Security Considerations | |||
The original TACACS+ Draft[1] from 1998 did not address all of the | The original TACACS+ Draft `The Draft' [TheDraft] from 1998 did not | |||
key security concerns which are considered when designing modern | address all of the key security concerns which are considered when | |||
standards. This section addresses known limitations and concerns | designing modern standards. This section addresses known limitations | |||
which will impact overall security of the protocol and systems where | and concerns which will impact overall security of the protocol and | |||
this protocol is deployed to manage central authentication, | systems where this protocol is deployed to manage central | |||
authorization or accounting for network device administration. | authentication, authorization or accounting for network device | |||
administration. | ||||
Multiple implementations of the protocol described in the draft[1] | Multiple implementations of the protocol described in the original | |||
have been deployed. As the protocol was never standardized, current | TACACS+ Draft `The Draft' [TheDraft] have been deployed. As the | |||
implementations may be incompatible in non-obvious ways, giving rise | protocol was never standardized, current implementations may be | |||
to additional security risks. This section does not claim to | incompatible in non-obvious ways, giving rise to additional security | |||
enumerate all possible security vulnerabilities. | risks. This section does not claim to enumerate all possible | |||
security vulnerabilities. | ||||
9.1. General Security of the Protocol | 10.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 obfuscated which leaves all header | Only the body of the request is obfuscated 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. For this reason, deployments SHOULD NOT use connections | attacker. For this reason, deployments SHOULD NOT use connections | |||
with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the | with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the Best Practices | |||
recommendations section. | section (Section 10.5) . | |||
Invalid or misleading values may be inserted by the man-in-the- | Invalid or misleading values may be inserted by the man-in-the- | |||
middle attacker in various fields at known offsets to try and | middle attacker in various fields at known offsets to try and | |||
circumvent the authentication or authorization checks even inside | circumvent the authentication or authorization checks even inside | |||
the obfuscated body. | the obfuscated body. | |||
While the protocol provides some measure of transport privacy, it is | While the protocol provides some measure of transport privacy, it is | |||
vulnerable to at least the following attacks: | vulnerable to at least the following attacks: | |||
Brute force attacks exploiting increased efficiency of MD5 digest | Brute force attacks exploiting increased efficiency of MD5 digest | |||
skipping to change at page 38, line 5 ¶ | skipping to change at page 38, line 9 ¶ | |||
the key or otherwise break the obfuscation will gain unrestricted and | the key or otherwise break the obfuscation will gain unrestricted and | |||
undetected access to all TACACS+ traffic. Ensuring that a | undetected access to all TACACS+ traffic. Ensuring that a | |||
centralized AAA system like TACACS+ is deployed on a secured | centralized AAA system like TACACS+ is deployed on a secured | |||
transport is essential to managing the security risk of such an | transport is essential to managing the security risk of such an | |||
attack. | attack. | |||
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 | 10.2. Security of Authentication Sessions | |||
Authentication sessions SHOULD be used via a secure transport as the | Authentication sessions SHOULD be used via a secure transport (see | |||
man-in-the-middle attack may completely subvert them. Even CHAP, | Best Practices section (Section 10.5) ) as the man-in-the-middle | |||
which may be considered resistant to password interception, is unsafe | attack may completely subvert them. Even CHAP, which may be | |||
as it does not protect the username from a trivial man-in-the-middle | considered resistant to password interception, is unsafe as it does | |||
attack. | not protect the username from a trivial man-in-the-middle attack. | |||
This document deprecates the redirection mechanism using the | This document deprecates the redirection mechanism using the | |||
TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the | TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the | |||
original draft. As part of this process, the secret key for a new | original draft. As part of this process, the secret key for a new | |||
server was sent to the client. This public exchange of secret keys | server was sent to the client. This public exchange of secret keys | |||
means that once one session is broken, it may be possible to leverage | means that once one session is broken, it may be possible to leverage | |||
that key to attacking connections to other servers. This mechanism | that key to attacking connections to other servers. This mechanism | |||
SHOULD NOT be used in modern deployments. It MUST NOT be used | SHOULD NOT be used in modern deployments. It MUST NOT be used | |||
outside a secured deployment. | outside a secured deployment. | |||
9.3. Security of Authorization Sessions | 10.3. Security of Authorization Sessions | |||
Authorization sessions SHOULD be used via a secure transport as it's | Authorization sessions SHOULD be used via a secure transport (see | |||
trivial to execute a successful man-in-the-middle attacks that | Best Practices section (Section 10.5) ) as it's trivial to execute a | |||
changes well-known plaintext in either requests or responses. | successful man-in-the-middle attacks that changes well-known | |||
plaintext in either requests or responses. | ||||
As an example, take the field "authen_method". It's not unusual in | As an example, take the field "authen_method". It's not unusual in | |||
actual deployments to authorize all commands received via the device | actual deployments to authorize all commands received via the device | |||
local serial port (a console port) as that one is usually considered | local serial port (a console port) as that one is usually considered | |||
secure by virtue of the device located in a physically secure | secure by virtue of the device located in a physically secure | |||
location. If an administrator would configure the authorization | location. If an administrator would configure the authorization | |||
system to allow all commands entered by the user on a local console | system to allow all commands entered by the user on a local console | |||
to aid in troubleshooting, that would give all access to all commands | to aid in troubleshooting, that would give all access to all commands | |||
to any attacker that would be able to change the "authen_method" from | to any attacker that would be able to change the "authen_method" from | |||
TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In | TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In | |||
skipping to change at page 39, line 5 ¶ | skipping to change at page 39, line 9 ¶ | |||
changed without either side detecting the change. | changed without either side detecting the change. | |||
Known plaintext means that an attacker would know with certainty | Known plaintext means that an attacker would know with certainty | |||
which octet is the target of the attack (in this case, 1st octet | which octet is the target of the attack (in this case, 1st octet | |||
after the header). | after the header). | |||
In combination with known plaintext, the attacker can determine | In combination with known plaintext, the attacker can determine | |||
with certainty the value of the crypto-pad octet used to obfuscate | with certainty the value of the crypto-pad octet used to obfuscate | |||
the original octet. | the original octet. | |||
9.4. Security of Accounting Sessions | 10.4. Security of Accounting Sessions | |||
Accounting sessions are not directly involved in authentication or | Accounting sessions are not directly involved in authentication or | |||
authorizing operations on the device. However, man-in-the-middle | authorizing operations on the device. However, man-in-the-middle | |||
attacker may do any of the following: | attacker may do any of the following: | |||
Replace accounting data with new valid or garbage which prevents | Replace accounting data with new valid or garbage which prevents | |||
to provide distraction or hide information related to their | to provide distraction or hide information related to their | |||
authentication and/or authorization attack attempts. | authentication and/or authorization attack attempts. | |||
Try and poison accounting log with entries designed to make | Try and poison accounting log with entries designed to make | |||
systems behave in unintended ways (which includes TACACS+ server | systems behave in unintended ways (which includes TACACS+ server | |||
and any other systems that would manage accounting entries). | and any other systems that would manage accounting entries). | |||
In addition to these direct manipulations, different client | In addition to these direct manipulations, different client | |||
implementations pass different fidelity of accounting data. Some | implementations pass different fidelity of accounting data. Some | |||
vendors have been observed in the wild that pass sensitive data like | vendors have been observed in the wild that pass sensitive data like | |||
passwords, encryption keys and similar as part of the accounting log. | passwords, encryption keys and similar as part of the accounting log. | |||
Due to lack of strong encryption with perfect forward secrecy, this | Due to lack of strong encryption with perfect forward secrecy, this | |||
data may be revealed in future, leading to a security incident. | data may be revealed in future, leading to a security incident. | |||
9.5. TACACS+ Best Practices | 10.5. TACACS+ Best Practices | |||
With respect to the observations about the security issues described | With respect to the observations about the security issues described | |||
above, a network administrator MUST NOT rely on the obfuscation of | above, a network administrator MUST NOT rely on the obfuscation of | |||
the TACACS+ protocol and TACACS+ MUST be deployed over networks which | the TACACS+ protocol and TACACS+ MUST be deployed over networks which | |||
ensure privacy and integrity of the communication. TACACS+ MUST be | ensure privacy and integrity of the communication. TACACS+ MUST be | |||
used within a secure deployment. Failure to do so will impact | used within a secure deployment. Failure to do so will impact | |||
overall network security. | overall network security. | |||
TACACS+ SHOULD be deployed over a network which is separated from | ||||
other traffic. | ||||
The following recommendations impose restrictions on how the protocol | The following recommendations impose restrictions on how the protocol | |||
is applied. These restrictions were not imposed in the original | is applied. These restrictions were not imposed in the original | |||
draft. New implementations, and upgrades of current implementations, | draft. New implementations, and upgrades of current implementations, | |||
MUST implement these recommendations. | MUST implement these recommendations. | |||
9.5.1. Shared Secrets | 10.5.1. Shared Secrets | |||
TACACS+ servers and clients MUST treat shared secrets as sensitive | TACACS+ servers and clients MUST treat shared secrets as sensitive | |||
data to be managed securely, as would be expected for other sensitive | data to be managed securely, as would be expected for other sensitive | |||
data such as identity credential information. TACACS+ servers MUST | data such as identity credential information. TACACS+ servers MUST | |||
not leak sensitive data. For example, TACACS+ servers should not | not leak sensitive data. For example, TACACS+ servers should not | |||
expose shared secrets in logs. | expose shared secrets in logs. | |||
TACACS+ servers MUST allow a dedicated secret key to be defined for | TACACS+ servers MUST allow a dedicated secret key to be defined for | |||
each client. | each client. | |||
TACACS+ servers SHOULD warn administrators if secret keys are not | TACACS+ servers SHOULD warn administrators if secret keys are not | |||
unique per client. | unique per client. | |||
TACACS+ server administrators SHOULD always define a secret for each | TACACS+ server administrators SHOULD always define a secret for each | |||
client. | client. | |||
TACACS+ servers and clients MUST support shared keys that are at | TACACS+ servers and clients MUST support shared keys that are at | |||
least 32 characters long. | least 32 characters long. | |||
TACACS+ servers MUST support policy to define minimum complexity for | ||||
shared keys. | ||||
TACACS+ clients SHOULD NOT allow servers to be configured without | TACACS+ clients SHOULD NOT allow servers to be configured without | |||
shared secret key, or shared key that is less than 16 characters | shared secret key, or shared key that is less than 16 characters | |||
long. | long. | |||
TACACS+ server administrators SHOULD configure secret keys of minimum | TACACS+ server administrators SHOULD configure secret keys of minimum | |||
16 characters length. | 16 characters length. | |||
TACACS+ server administrators SHOULD change secret keys at regular | TACACS+ server administrators SHOULD change secret keys at regular | |||
intervals. | intervals. | |||
9.5.2. Connections and Obfuscation | 10.5.2. Connections and Obfuscation | |||
TACACS+ servers MUST allow the definition of individual clients. The | TACACS+ servers MUST allow the definition of individual clients. The | |||
servers MUST only accept network connection attempts from these | servers MUST only accept network connection attempts from these | |||
defined, known clients. | defined, known clients. | |||
TACACS+ servers MUST reject connections with | TACACS+ servers MUST reject connections with | |||
TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on | TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on | |||
the server for the client requesting the connection. | the server for the client requesting the connection. | |||
If an invalid shared secret is detected when processing packets for a | If an invalid shared secret is detected when processing packets for a | |||
skipping to change at page 41, line 7 ¶ | skipping to change at page 41, line 19 ¶ | |||
the response packet was received from the server configured not to | the response packet was received from the server configured not to | |||
use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not | use obfuscation, but the packet has TAC_PLUS_UNENCRYPTED_FLAG not | |||
set. | set. | |||
then the TACACS+ client MUST close TCP session, and process the | then the TACACS+ client MUST close TCP session, and process the | |||
response in the same way that a TAC_PLUS_AUTHEN_STATUS_FAIL | response in the same way that a TAC_PLUS_AUTHEN_STATUS_FAIL | |||
(authentication sessions) or TAC_PLUS_AUTHOR_STATUS_FAIL | (authentication sessions) or TAC_PLUS_AUTHOR_STATUS_FAIL | |||
(authorization sessions) was received. | (authorization sessions) was received. | |||
9.5.3. Authentication | 10.5.3. Authentication | |||
To allow TACACS+ administraots to select the stronger authentication | To help TACACS+ administraots select the stronger authentication | |||
options, TACACS+ servers MUST allow the administrator to configure | options, TACACS+ servers MUST allow the administrator to configure | |||
the server to only accept challenge/response options for | the server to only accept challenge/response options for | |||
authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or | authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or | |||
TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for | TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for | |||
authen_type). | authen_type). | |||
TACACS+ server administrators SHOULD enable the option mentioned in | TACACS+ server administrators SHOULD enable the option mentioned in | |||
the previous paragraph. TACACS+ Server deployments SHOULD ONLY | the previous paragraph. TACACS+ Server deployments SHOULD ONLY | |||
enable other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or | enable other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or | |||
TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of | TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of | |||
skipping to change at page 41, line 35 ¶ | skipping to change at page 41, line 47 ¶ | |||
challenge-based authen_type options as the insecurity of the latter | challenge-based authen_type options as the insecurity of the latter | |||
will compromise the security of the former. | will compromise the security of the former. | |||
TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options | TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options | |||
mentioned in the original draft SHOULD not be used, due to their | mentioned in the original draft SHOULD not be used, due to their | |||
security implications. TACACS+ servers SHOULD NOT implement them. | security implications. TACACS+ servers SHOULD NOT implement them. | |||
If they must be implemented, the servers MUST default to the options | If they must be implemented, the servers MUST default to the options | |||
being disabled and MUST warn the administrator that these options are | being disabled and MUST warn the administrator that these options are | |||
not secure. | not secure. | |||
9.5.4. Authorization | 10.5.4. Authorization | |||
The authorization and accounting features are intended to provide | The authorization and accounting features are intended to provide | |||
extensibility and flexibility. There is a base dictionary defined in | extensibility and flexibility. There is a base dictionary defined in | |||
this document, but it may be extended in deployments by using new | this document, but it may be extended in deployments by using new | |||
attribute names. The cost of the flexibility is that administrators | attribute names. The cost of the flexibility is that administrators | |||
and implementors MUST ensure that the attribute and value pairs | and implementors MUST ensure that the attribute and value pairs | |||
shared between the clients and servers have consistent | shared between the clients and servers have consistent | |||
interpretation. | interpretation. | |||
TACACS+ clients that receive an unrecognised mandatory attribute MUST | TACACS+ clients that receive an unrecognised mandatory attribute MUST | |||
evaluate server response as if they received | evaluate server response as if they received | |||
TAC_PLUS_AUTHOR_STATUS_FAIL. | TAC_PLUS_AUTHOR_STATUS_FAIL. | |||
9.5.5. Redirection Mechanism | 10.5.5. Redirection Mechanism | |||
The original draft described a redirection mechanism | The original draft described a redirection mechanism | |||
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to | (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to | |||
secure. The option to send secret keys in the server list is | secure. The option to send secret keys in the server list is | |||
particularly insecure, as it can reveal client shared secrets. | particularly insecure, as it can reveal client shared secrets. | |||
TACACS+ servers SHOULD deprecate the redirection mechanism. | TACACS+ servers SHOULD deprecate the redirection mechanism. | |||
If the redirection mechanism is implemented then TACACS+ servers MUST | If the redirection mechanism is implemented then TACACS+ servers MUST | |||
disable it by default, and MUST warn TACACS+ server administrators | disable it by default, and MUST warn TACACS+ server administrators | |||
that it must only be enabled within a secure deployment due to the | that it must only be enabled within a secure deployment due to the | |||
risks of revealing shared secrets. | risks of revealing shared secrets. | |||
TACACS+ clients SHOULD deprecate this feature by treating | TACACS+ clients SHOULD deprecate this feature by treating | |||
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. | TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. | |||
10. Acknowledgements | 11. Acknowledgements | |||
The authors would like to thank the following reviewers whose | The authors would like to thank the following reviewers whose | |||
comments and contributions made considerable improvements to the | comments and contributions made considerable improvements to the | |||
document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch, | document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch, | |||
Robert Drake, among many others. | Robert Drake, among many others. | |||
The authors would particularly like to thank Alan DeKok, who provided | The authors would particularly like to thank Alan DeKok, who provided | |||
significant insights and recommendations on all aspects of the | significant insights and recommendations on all aspects of the | |||
document and the protocol. Alan DeKok has dedicated considerable | document and the protocol. Alan DeKok has dedicated considerable | |||
time and effort to help improve the document, identifying weaknesses | time and effort to help improve the document, identifying weaknesses | |||
and providing remediation. | and providing remediation. | |||
The authors would also like to thanks the support from the OPSAWG | The authors would also like to thanks the support from the OPSAWG | |||
Chairs and advisors. | Chairs and advisors. | |||
11. References | 12. References | |||
[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", | |||
RFC 1334, DOI 10.17487/RFC1334, October 1992, | RFC 1334, DOI 10.17487/RFC1334, October 1992, | |||
<http://www.rfc-editor.org/info/rfc1334>. | <http://www.rfc-editor.org/info/rfc1334>. | |||
[RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, | [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, | |||
"Randomness Recommendations for Security", RFC 1750, | "Randomness Recommendations for Security", RFC 1750, | |||
DOI 10.17487/RFC1750, December 1994, | DOI 10.17487/RFC1750, December 1994, | |||
<http://www.rfc-editor.org/info/rfc1750>. | <http://www.rfc-editor.org/info/rfc1750>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, | ||||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", | [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", | |||
RFC 2433, DOI 10.17487/RFC2433, October 1998, | RFC 2433, DOI 10.17487/RFC2433, October 1998, | |||
<http://www.rfc-editor.org/info/rfc2433>. | <http://www.rfc-editor.org/info/rfc2433>. | |||
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", | [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", | |||
RFC 2759, DOI 10.17487/RFC2759, January 2000, | RFC 2759, DOI 10.17487/RFC2759, January 2000, | |||
<http://www.rfc-editor.org/info/rfc2759>. | <http://www.rfc-editor.org/info/rfc2759>. | |||
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | ||||
Architecture", RFC 4291, DOI 10.17487/RFC4291, February | ||||
2006, <https://www.rfc-editor.org/info/rfc4291>. | ||||
[TheDraft] | [TheDraft] | |||
Carrel, D. and L. Grant, "The TACACS+ Protocol Version | Carrel, D. and L. Grant, "The TACACS+ Protocol Version | |||
1.78", June 1997, | 1.78", June 1997, | |||
<https://tools.ietf.org/html/draft-grant-tacacs-02>. | <https://tools.ietf.org/html/draft-grant-tacacs-02>. | |||
[TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and | ||||
Daylight Saving Time Data", 1987, | ||||
<https://www.iana.org/time-zones>. | ||||
Authors' Addresses | Authors' Addresses | |||
Thorsten Dahm | Thorsten Dahm | |||
Google Inc | Google Inc | |||
1600 Amphitheatre Parkway | 1600 Amphitheatre Parkway | |||
Mountain View, CA 94043 | Mountain View, CA 94043 | |||
US | US | |||
EMail: thorstendlux@google.com | EMail: thorstendlux@google.com | |||
Andrej Ota | Andrej Ota | |||
Google Inc | Google Inc | |||
1600 Amphitheatre Parkway | 1600 Amphitheatre Parkway | |||
Mountain View, CA 94043 | Mountain View, CA 94043 | |||
US | US | |||
EMail: andrej@ota.si | EMail: andrej@ota.si | |||
Douglas C. Medway Gash | Douglas C. Medway Gash | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
End of changes. 101 change blocks. | ||||
157 lines changed or deleted | 184 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |