draft-ietf-opsawg-tacacs-03.txt   draft-ietf-opsawg-tacacs-04.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: December 22, 2016 D. Medway Gash Expires: January 9, 2017 D. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
D. Carrel D. Carrel
vIPtela, Inc. vIPtela, Inc.
L. Grant L. Grant
June 20, 2016 July 8, 2016
The TACACS+ Protocol The TACACS+ Protocol
draft-ietf-opsawg-tacacs-03 draft-ietf-opsawg-tacacs-04
Abstract Abstract
TACACS+ provides Device Administration for routers, network access TACACS+ provides Device Administration for routers, network access
servers and other networked computing devices via one or more servers and other networked computing devices via one or more
centralized servers. This document describes the protocol that is centralized servers. This document describes the protocol that is
used by TACACS+. used by TACACS+.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 22, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4 2. Technical Definitions . . . . . . . . . . . . . . . . . . . . 4
3. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 5 3. TACACS+ Connections and Sessions . . . . . . . . . . . . . . 5
3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Security Considerations . . . . . . . . . . . . . . . 6 3.1.1. Security Considerations . . . . . . . . . . . . . . . 5
3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 6 3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 6
3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 7 3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 7
3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 9 3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 8
3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9
3.6.1. Body Encryption . . . . . . . . . . . . . . . . . . . 9 3.7. Text Encoding . . . . . . . . . . . . . . . . . . . . . . 11
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. The Authentication START Packet Body . . . . . . . . . . 11 4.1. The Authentication START Packet Body . . . . . . . . . . 11
4.2. The Authentication REPLY Packet Body . . . . . . . . . . 13 4.2. The Authentication REPLY Packet Body . . . . . . . . . . 13
4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 15 4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 15
4.4. Description of Authentication Process . . . . . . . . . . 15 4.4. Description of Authentication Process . . . . . . . . . . 15
4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 16 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 16
4.4.2. Common Authentication Flows . . . . . . . . . . . . . 17 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 17
4.4.3. Aborting an Authentication Session . . . . . . . . . 20 4.4.3. Aborting an Authentication Session . . . . . . . . . 20
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 21 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 21
skipping to change at page 3, line 31 skipping to change at page 3, line 31
document will conform to `The Draft'. However, the following document will conform to `The Draft'. However, the following
specific adjustments of the protocol specification from 'The Draft' specific adjustments of the protocol specification from 'The Draft'
should be noted: should be noted:
This document officially removes SENDPASS for security reasons. This document officially removes SENDPASS for security reasons.
The normative description of Legacy features such as ARAP and The normative description of Legacy features such as ARAP and
outbound authentication have been removed, however the required outbound authentication have been removed, however the required
enumerations are kept. enumerations are kept.
Usernames and passwords are specifically mentioned as being
encoded in UTF-8 rather than plain US-ASCII. US-ASCII text is
valid UTF-8, and specification of UTF-8 specifically for username
and password fields enhances interoperability with external
identity systems.
The TACACS+ protocol separates the functions of Authentication, The TACACS+ protocol separates the functions of Authentication,
Authorization and Accounting. It allows for arbitrary length and Authorization and Accounting. It allows for arbitrary length and
content authentication exchanges, which will support any content authentication exchanges, which will support any
authentication mechanism to be utilized with TACACS+ clients. It is authentication mechanism to be utilized with TACACS+ clients. It is
extensible to provide for site customization and future development extensible to provide for site customization and future development
features, and it uses TCP to ensure reliable delivery. The protocol features, and it uses TCP to ensure reliable delivery. The protocol
allows the TACACS+ client to request very fine-grained access control allows the TACACS+ client to request very fine-grained access control
and allows the server to respond to each component of that request. and allows the server to respond to each component of that request.
The separation of authentication, authorization and accounting is a The separation of authentication, authorization and accounting is a
skipping to change at page 9, line 27 skipping to change at page 9, line 20
- All data and message fields in a packet MUST NOT be null - All data and message fields in a packet MUST NOT be null
terminated. terminated.
- All length values are unsigned and in network byte order. - All length values are unsigned and in network byte order.
- There should be no padding in any of the fields or at the end of - There should be no padding in any of the fields or at the end of
a packet. a packet.
3.6. Encryption 3.6. Encryption
3.6.1. Body Encryption
The body of packets may be encrypted. The following sections The body of packets may be encrypted. The following sections
describe the encryption mechanism that is supported to enable describe the encryption mechanism that is supported to enable
backwards compatibility with 'The Draft'. backwards compatibility with 'The Draft'.
When the encryption mechanism relies on a secret key, it is referring When the encryption mechanism relies on a secret key, it is referring
to a shared secret value that is known to both the client and the to a shared secret value that is known to both the client and the
server. This document does not discuss the management and storage of server. This document does not discuss the management and storage of
those keys. It is an implementation detail of the server and client, those keys. It is an implementation detail of the server and client,
as to whether they will maintain only one key, or a different key for as to whether they will maintain only one key, or a different key for
each client or server with which they communicate. For security each client or server with which they communicate. For security
skipping to change at page 11, line 12 skipping to change at page 11, line 5
datalength value from the header. Any packets which fail this check datalength value from the header. Any packets which fail this check
should be discarded and an error signalled. Commonly such failures should be discarded and an error signalled. Commonly such failures
may be expected to be seen when there are mismatched keys between the may be expected to be seen when there are mismatched keys between the
client and the TACACS+ server. client and the TACACS+ server.
If an error must be declared but the type of the incoming packet If an error must be declared but the type of the incoming packet
cannot be determined, a packet with the identical cleartext header cannot be determined, a packet with the identical cleartext header
but with a sequence number incremented by one and the length set to but with a sequence number incremented by one and the length set to
zero MUST be returned to indicate an error. zero MUST be returned to indicate an error.
3.7. Text Encoding
All text fields in TACACS+ MUST be US-ASCII, excepting special
consideration given to user field and data fields used for passwords.
To ensure interoperability of current deployments, the TACACS+ client
and server MUST handle user field and data fields used for passwords
as 8 bit octet strings. The deployment operator MUST ensure that
consistent character encoding is applied. The encoding SHOULD be
UTF-8, and other encodings outside US-ASCII SHOULD be deprecated.
4. Authentication 4. Authentication
4.1. The Authentication START Packet Body 4.1. The Authentication START Packet Body
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| action | priv_lvl | authen_type | authen_service | | action | priv_lvl | authen_type | authen_service |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
| user len | port len | rem_addr len | data len | | user len | port len | rem_addr len | data len |
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
skipping to change at page 13, line 17 skipping to change at page 13, line 17
the user different privileges. This is comparable to the Unix the user different privileges. This is comparable to the Unix
"su(1)" command. A service value of NONE should only be used when "su(1)" command. A service value of NONE should only be used when
none of the other service values are appropriate. ENABLE may be none of the other service values are appropriate. ENABLE may be
requested independently, no requirements for previous authentications requested independently, no requirements for previous authentications
or authorizations are imposed by the protocol. or authorizations are imposed by the protocol.
Other options are included for legacy/backwards compatibility. Other options are included for legacy/backwards compatibility.
user user
The username. It is encoded in [UTF-8]. It is optional in this The username. It is optional in this packet, depending upon the
packet, depending upon the class of authentication. class of authentication.
port port
The US-ASCII name of the client port on which the authentication is The US-ASCII name of the client port on which the authentication is
taking place. The value of this field is client specific. (For taking place. The value of this field is client specific. (For
example, Cisco uses "tty10" to denote the tenth tty line and example, Cisco uses "tty10" to denote the tenth tty line and
"Async10" to denote the tenth async interface). "Async10" to denote the tenth async interface).
rem_addr rem_addr
skipping to change at page 20, line 39 skipping to change at page 20, line 39
The protocol and key are optional, and apply only to host in the same The protocol and key are optional, and apply only to host in the same
row. The protocol can describe an alternate way of performing the row. The protocol can describe an alternate way of performing the
authentication, other than TACACS+. If the protocol is not present, authentication, other than TACACS+. If the protocol is not present,
then TACACS+ is assumed. then TACACS+ is assumed.
Protocols are ASCII numbers corresponding to the methods listed in Protocols are ASCII numbers corresponding to the methods listed in
the authen_method field of authorization packets (defined below). the authen_method field of authorization packets (defined below).
The host is specified as either a fully qualified domain name, or an The host is specified as either a fully qualified domain name, or an
ASCII numeric IPV4 address specified as octets separated by dots ASCII numeric IPV4 address specified as octets separated by dots
(`.'), or IPV6 ('.'), or IPV6 adress test representation defined in RFC 4291.
If a key is supplied, the client MAY use the key in order to If a key is supplied, the client MAY use the key in order to
authenticate to that host. The client may use a preconfigured key authenticate to that host. The client may use a preconfigured key
for the host if it has one. If not then the client may communicate for the host if it has one. If not then the client may communicate
with the host using unencrypted option. with the host using unencrypted option.
Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the Use of the hosts in a TAC_PLUS_AUTHEN_STATUS_FOLLOW packet is at the
discretion of the TACACS+ client. It may choose to use any one, all discretion of the TACACS+ client. It may choose to use any one, all
or none of these hosts. If it chooses to use none, then it MUST or none of these hosts. If it chooses to use none, then it MUST
treat the authentication as if the return status was treat the authentication as if the return status was
 End of changes. 12 change blocks. 
18 lines changed or deleted 21 lines changed or added

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