draft-ietf-opsawg-tacacs-00.txt   draft-ietf-opsawg-tacacs-01.txt 
Operations T. Dahm Operations T. Dahm
Internet-Draft A. Ota Internet-Draft A. Ota
Intended status: Standards Track Google Inc Intended status: Informational Google Inc
Expires: June 18, 2016 D. Medway Gash Expires: September 9, 2016 D. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
D. Carrel D. Carrel
vIPtela, Inc.
L. Grant L. Grant
December 16, 2015 March 8, 2016
The TACACS+ Protocol The TACACS+ Protocol
draft-ietf-opsawg-tacacs-00 draft-ietf-opsawg-tacacs-01
Abstract Abstract
TACACS+ provides access control for routers, network access servers TACACS+ provides Device Administration for routers, network access
and other networked computing devices via one or more centralized servers and other networked computing devices via one or more
servers. TACACS+ provides separate authentication, authorization and centralized servers. This document describes the protocol that is
accounting services. This document describes the protocol that is
used by TACACS+. used by TACACS+.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 June 18, 2016. This Internet-Draft will expire on September 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 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. Technical Definitions . . . . . . . . . . . . . . . . . . . . 3
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.1.2. TLS Cypher Requirements . . . . . . . . . . . . . . . 6 3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Session . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 6
3.3. Single Connect Mode . . . . . . . . . . . . . . . . . . . 7 3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 6
3.4. The TACACS+ Packet Header . . . . . . . . . . . . . . . . 8 3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 8
3.5. The TACACS+ Packet Body . . . . . . . . . . . . . . . . . 10 3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Encryption . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.1. Body Encryption . . . . . . . . . . . . . . . . . . . 9
3.6.1. Legacy Body Encryption . . . . . . . . . . . . . . . 10 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 10
4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. The Authentication START Packet Body . . . . . . . . . . 10
4.1. The Authentication START Packet Body . . . . . . . . . . 12 4.2. The Authentication REPLY Packet Body . . . . . . . . . . 13
4.2. The Authentication REPLY Packet Body . . . . . . . . . . 14 4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 14
4.3. The Authentication CONTINUE Packet Body . . . . . . . . . 15 4.4. Description of Authentication Process . . . . . . . . . . 15
4.4. Description of Authentication Process . . . . . . . . . . 16 4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 15
4.4.1. Version Behaviour . . . . . . . . . . . . . . . . . . 17 4.4.2. Common Authentication Flows . . . . . . . . . . . . . 16
4.4.2. Common Authentication Flows . . . . . . . . . . . . . 18 4.4.3. Aborting an Authentication Session . . . . . . . . . 19
4.4.3. Aborting an Authentication Session . . . . . . . . . 20 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 21
5.1. The Authorization REQUEST Packet Body . . . . . . . . . . 22 5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 23
5.2. The Authorization RESPONSE Packet Body . . . . . . . . . 25 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 25
6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 27 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 26
6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 28 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 28
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 29 7.1. Authorization Attributes . . . . . . . . . . . . . . . . 28
7.1. Authorization Attributes . . . . . . . . . . . . . . . . 30 7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 31
7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 32 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 33
8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
A wide range of TACACS+ clients and servers are already deployed in A wide range of TACACS+ clients and servers are already deployed in
the field. The TACACS+ protocol they are based on is defined in a the field. The TACACS+ protocol they are based on is defined in a
draft document that was originally intended for IETF publication. draft document that was originally intended for IETF publication.
This document is known as `The Draft' [TheDraft] . This document is known as `The Draft' [TheDraft] .
This specification is essentially a refactoring of the draft with It is intended that all implementations which conform to this
some minor additions. The definitions in the draft should map onto document will conform to 'The Draft'. However, some options have
this document, such that any implementations based on the draft will been removed. This document officially removes SENDPASS for security
be compliant with this document. Chief changes between the reasons. The normative description of Legacy features such as ARAP
documents: and outbound authentication have been removed, however the required
enumerations are kept.
- This document introduces a TLS encryption option
- This document supports MS-CHAPv2
- This document officially removes SENDPASS for security reasons.
This option was still documented as 'deprecated' in 'The Draft'
- This document deprecates description of legacy features such as
ARAP and outbound authentication. The required enumerations are
kept, but related normative description is removed.
The TACACS+ protocol is the latest generation of TACACS. It The TACACS+ protocol separates the functions of Authentication,
separates the functions of Authentication, Authorization and Authorization and Accounting. It allows for arbitrary length and
Accounting. It allows for arbitrary length and content content authentication exchanges, which will support any
authentication exchanges, which will support any authentication authentication mechanism to be utilized with TACACS+ clients. It is
mechanism to be utilized with TACACS+ clients. It is extensible to extensible to provide for site customization and future development
provide for site customization and future development features, and features, and it uses TCP to ensure reliable delivery. The protocol
it uses TCP to ensure reliable delivery. The protocol allows the allows the TACACS+ client to request very fine-grained access control
TACACS+ client to request very fine-grained access control and allows and allows the server to respond to each component of that request.
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
fundamental component of the design of TACACS+. The distinction fundamental component of the design of TACACS+. The distinction
between them is very important so this document will address each one between them is very important so this document will address each one
separately. It is important to note that TACACS+ provides for all separately. It is important to note that TACACS+ provides for all
three, but an implementation or configuration is not required to three, but an implementation or configuration is not required to
employ all three. Each one serves a unique purpose that alone is employ all three. Each one serves a unique purpose that alone is
useful, and together can be quite powerful. A very important benefit useful, and together can be quite powerful.
to separating authentication from authorization is that authorization
(and per-user profiles) can be a dynamic process. Instead of a one- TACACS+ is primarily used for Device Administration. In addition to
shot user profile, TACACS+ can be integrated with other negotiations, authenticating access to network devices, it provides central
such as a PPP negotiation, for far greater flexibility. The authorization of operations, and audit of those operations
accounting portion can serve to provide security auditing or
accounting/ billing services.
2. Technical Definitions 2. Technical Definitions
This section provides a few basic definitions that are applicable to This section provides a few basic definitions that are applicable to
this document this document
Authentication Authentication
Authentication is the action of determining who a user (or entity) Authentication is the action of determining who a user (or entity)
is. Authentication can take many forms. Traditional authentication is. Authentication can take many forms. Traditional authentication
skipping to change at page 5, line 48 skipping to change at page 5, line 32
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 3. TACACS+ Connections and Sessions
3.1. Connection 3.1. Connection
TACACS+ uses TCP for its transport. Server port [TBD] is allocated TACACS+ uses TCP for its transport. Server port 49 is allocated for
for Transport encrypted TACACS+ traffic. Server port 49 is allocated TACACS+ traffic.
for non Transport encrypted TACACS+ traffic.
3.1.1. Security Considerations 3.1.1. Security Considerations
Transport encryption SHOULD be used in deployments when both the The encryption mechanism specified by 'The Draft' would be regarded
clients and servers support it. Servers that support Transport as obfuscation. It will be referred to here as Body Encryption. A
encryption MAY be configured to allow Legacy Body Encryption when transport based scheme will be specified in a separate document
Transport encryption is not supported by the client.
It is NOT recommended to deploy TACACS+ without Transport or Legacy
Body encryption, other than for test environments.
3.1.2. TLS Cypher Requirements
TACACS+ Servers supporting Transport encryption MUST utilise the TLS
options described in the following sections.
3.1.2.1. TLS Protocol Version
TACACS+ Servers supporting TLS encryption MUST implement at least TLS
version 1.2. They MAY implement higher TLS versions.
3.1.2.2. Mandatory Cipher Suites
TLS 1.2 RFC 5246 [RFC5246] allows specifying application profiles
prescribing which cipher suites to implement for interoperability
purposes. To maintain simplicity of current TACACS+ configuration
using preshared secrets, the server implementation MUST implement:
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA
Client MUST implement at least one of cipher suites which are
implemented on the server, and it MAY implement all of them.
Both clients and servers MAY implement other cipher suites, but their
interoperability is not guaranteed and their implementation is
outside of scope of this document.
3.1.2.3. PSK Identity Requirements
Because determining a correct PSK value on the server side is a
computationally intensive operation requiring multiple round trips, a
mechanism for hitless key change must be defined. During TLS
handshake, a client MUST use PSK identity as defined in RFC 4279
[RFC4279] to signal to the server which PSK value to use. If server
does not recognize PSK identity it MUST respond with decrypt_error
alert and MUST NOT respond with unknown_psk_identity. Process to
change preshared keys on server and client is then:
1. Add new key with new PSK identity on the server.
2. Add new key with new PSK identity on the client.
3. Remove old key with old PSK identity from the client.
4. Remove old key with old PSK identity from the server.
Note: PSK identity is transmitted in clear text and must not contain It is NOT recommended to deploy TACACS+ without Body encryption,
information which could aid an attacker who can eavesdrop on the other than for test environments.
connection.
3.2. Session 3.2. Session
The concept of a session is used throughout this document. A TACACS+ The concept of a session is used throughout this document. A TACACS+
session is a single authentication sequence, a single authorization session is a single authentication sequence, a single authorization
exchange, or a single accounting exchange. exchange, or a single accounting exchange.
An accounting and authorization session will consist of a single pair An accounting and authorization session will consist of a single pair
of packets (the request and its reply). An authentication session of packets (the request and its reply). An authentication session
may involve an arbitrary number of packets being exchanged. The may involve an arbitrary number of packets being exchanged. The
skipping to change at page 9, line 28 skipping to change at page 8, line 14
flags flags
This field contains various bitmapped flags. This field contains various bitmapped flags.
The unencrypted flag bit says whether encryption is being used on the The unencrypted flag bit says whether encryption is being used on the
body of the packet (the entire portion after the header). body of the packet (the entire portion after the header).
TAC_PLUS_UNENCRYPTED_FLAG := 0x01 TAC_PLUS_UNENCRYPTED_FLAG := 0x01
If this flag is set, then legacy body encryption is not used. If If this flag is set, then body encryption is not used. If this flag
this flag is cleared, the packet is encrypted. Unencrypted packets is cleared, the packet is encrypted. Unencrypted packets are
are intended for testing, and are not recommended for normal use. intended for testing, and are not recommended for normal use.
The single-connection flag: The single-connection flag:
TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04
This flag is used to allow a client and server to agree whether This flag is used to allow a client and server to agree whether
multiple sessions may be multiplexed onto a single connection. multiple sessions may be multiplexed onto a single connection.
session_id session_id
skipping to change at page 10, line 27 skipping to change at page 9, line 12
- 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. Legacy Body 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 legacy encryption mechanism that is supported to enable describe the encryption mechanism that is supported to enable
backwards compatibility with 'The Draft'. backwards compatibility with 'The Draft'.
When the encryption mechanism relies on a secret key, it is referring When the encryption mechanism relies on a secret key, it is referring
to a shared secret value that is known to both the client and the to a shared secret value that is known to both the client and the
server. This document does not discuss the management and storage of server. This document does not discuss the management and storage of
those keys. It is an implementation detail of the server and client, those keys. It is an implementation detail of the server and client,
as to whether they will maintain only one key, or a different key for as to whether they will maintain only one key, or a different key for
each client or server with which they communicate. For security each client or server with which they communicate. For security
reasons, the latter options should be available, but it is a site reasons, the latter options should be available, but it is a site
dependent decision as to whether the use of separate keys is dependent decision as to whether the use of separate keys is
skipping to change at page 35, line 36 skipping to change at page 34, line 25
<http://www.rfc-editor.org/info/rfc1750>. <http://www.rfc-editor.org/info/rfc1750>.
[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>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
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
skipping to change at page 36, line 28 skipping to change at page 35, line 4
EMail: aota@google.com EMail: aota@google.com
Douglas C. Medway Gash Douglas C. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +44 0208 8244508 Phone: +44 0208 8244508
EMail: dcmgash@cisco.com EMail: dcmgash@cisco.com
David Carrel David Carrel
vIPtela, Inc.
1732 North First St.
San Jose, CA 95112
US
EMail: dcarrel@viptela.com
Lol Grant Lol Grant
 End of changes. 22 change blocks. 
150 lines changed or deleted 76 lines changed or added

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