The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol
draft-ietf-opsawg-tacacs-18

Received changes through RFC Editor sync (created alias RFC 8907, changed title to 'The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol', changed abstract to 'This document describes the Terminal Access Controller Access-Control System Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers.', changed pages to 41, changed standardization level to Informational, changed state to RFC, added RFC published event at 2020-09-30, changed IESG state to RFC Published)

[Ballot discuss]
(I have incorporated DISCUSS portion of Alissa's DISCUSS, see DISCUSS points #7-#9)

I appreciate that this is documenting an existing protocol and I am very glad that it is being documented.
However there are several things which are still not documented well enough/not in enough details to implement.
So I would like to discuss these issues before recommending approval of this document:

1) Resolved

2) In 5.1:

  The printable US-ASCII name of the client port on which the
  authentication is taking place,

This doesn't mean anything. Is there a registry? It doesn't look like you are using transport service name registry for this.
Is it a fixed list?

  and its length in bytes.  The value
  of this field is client specific.  (For example, Cisco uses "tty10"
  to denote the tenth tty line and "Async10" to denote the tenth async
  interface).  The port_len indicates the length of the port field, in
  bytes.

3) Addressed

4) Addressed

5) KRB5 and KRB4 need normative references.

6) Does this document need to obsolete RFC 1492?

7) Addressed

8) Addressed

9) Addressed

[Ballot discuss]
(I have incorporated DISCUSS portion of Alissa's DISCUSS, see DISCUSS points #7-#9)

I appreciate that this is documenting an existing protocol and I am very glad that it is being documented.
However there are several things which are still not documented well enough/not in enough details to implement.
So I would like to discuss these issues before recommending approval of this document:

1) Resolved

2) In 5.1:

  The printable US-ASCII name of the client port on which the
  authentication is taking place,

This doesn't mean anything. Is there a registry? It doesn't look like you are using transport service name registry for this.
Is it a fixed list?

  and its length in bytes.  The value
  of this field is client specific.  (For example, Cisco uses "tty10"
  to denote the tenth tty line and "Async10" to denote the tenth async
  interface).  The port_len indicates the length of the port field, in
  bytes.

3) Addressed

4) In 5.4:

  If the information being requested by the server form the client is
  sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
  flag.  When the client queries the user for the information, the
  response MUST NOT be echoed as it is entered.

What does the last sentence mean? (When is it ever echoed?) Are you missing a forward reference or some explanation of echoing?

5) KRB5 and KRB4 need normative references.

6) Does this document need to obsolete RFC 1492?

7) The Gen-ART reviewer Stewart Bryant (SB) asked the following:

    TAC_PLUS_PRIV_LVL_MAX := 0x0f

    TAC_PLUS_PRIV_LVL_ROOT := 0x0f

    TAC_PLUS_PRIV_LVL_USER := 0x01

    TAC_PLUS_PRIV_LVL_MIN := 0x00

SB> Where are these defined?

Please define the semantics of these values.

8) Stewart also noted the following:

    TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01

    TAC_PLUS_AUTHEN_TYPE_PAP := 0x02

    TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03

    TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)

    TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05

    TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06

SB> There are lots of lists similar to the above.
SB> I have not checked them all, but a number of the types
SB> in this and subsequent parts of the design don't seem
SB> to be defined or have a definitive reference

The way I would say this is that the document seems to be written for people who have already deployed this protocol, and elides details that would make it comprehensible to a new implementor. But it also contemplates the prospect of new implementations. If new implementations are actually expected (which I was surprised about, but can believe), I agree with Stewart that each of the field values need a definition that explains its semantic. If new implementations are not expected, then the reference to new implementations should be removed.

9) How is "secure deployment" defined? Since this is used as a restriction in several places, I think it needs to be defined precisely.

[Ballot discuss]
(I have incorporated DISCUSS portion of Alissa's DISCUSS, see DISCUSS points #7-#9)

I appreciate that this is documenting an existing protocol and I am very glad that it is being documented.
However there are several things which are still not documented well enough/not in enough details to implement.
So I would like to discuss these issues before recommending approval of this document:

1) Resolved

2) In 5.1:

  The printable US-ASCII name of the client port on which the
  authentication is taking place,

This doesn't mean anything. Is there a registry? It doesn't look like you are using transport service name registry for this.
Is it a fixed list?

  and its length in bytes.  The value
  of this field is client specific.  (For example, Cisco uses "tty10"
  to denote the tenth tty line and "Async10" to denote the tenth async
  interface).  The port_len indicates the length of the port field, in
  bytes.

3) Later in 5.1:

  A printable US-ASCII string indicating the remote location from which
  the user has connected to the client.  It is intended to hold a
  network address

What are the allowed formats for IPv4 and IPv6? Or is this just human readable?

  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
  location information that is available.

4) In 5.4:

  If the information being requested by the server form the client is
  sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
  flag.  When the client queries the user for the information, the
  response MUST NOT be echoed as it is entered.

What does the last sentence mean? (When is it ever echoed?) Are you missing a forward reference or some explanation of echoing?

5) KRB5 and KRB4 need normative references.

6) Does this document need to obsolete RFC 1492?

7) The Gen-ART reviewer Stewart Bryant (SB) asked the following:

    TAC_PLUS_PRIV_LVL_MAX := 0x0f

    TAC_PLUS_PRIV_LVL_ROOT := 0x0f

    TAC_PLUS_PRIV_LVL_USER := 0x01

    TAC_PLUS_PRIV_LVL_MIN := 0x00

SB> Where are these defined?

Please define the semantics of these values.

8) Stewart also noted the following:

    TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01

    TAC_PLUS_AUTHEN_TYPE_PAP := 0x02

    TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03

    TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)

    TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05

    TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06

SB> There are lots of lists similar to the above.
SB> I have not checked them all, but a number of the types
SB> in this and subsequent parts of the design don't seem
SB> to be defined or have a definitive reference

The way I would say this is that the document seems to be written for people who have already deployed this protocol, and elides details that would make it comprehensible to a new implementor. But it also contemplates the prospect of new implementations. If new implementations are actually expected (which I was surprised about, but can believe), I agree with Stewart that each of the field values need a definition that explains its semantic. If new implementations are not expected, then the reference to new implementations should be removed.

9) How is "secure deployment" defined? Since this is used as a restriction in several places, I think it needs to be defined precisely.

[Ballot comment]
Thanks for addressing my DISCUSS and COMMENT points; and finding a middle ground in this draft by documenting the as-is, but highlight the issues.

[Ballot comment]
Thanks for addressing my DISCUSS and COMMENT points; and finding a middle ground in this document by document the as-is, but highlight the issues.

2020-01-27 - Warren Kumari became responsible AD - email sent to WG to try rebuild state / understand where we are in the process.

[WK Note: I'm trying to use the DT comment feature to better track / organize my documents - expect to see updates in this field ]

[Ballot comment]
Thanks for posting version -15.  It resolves my DISCUSS issues with respect to character encoding, though it adds a couple of oddities -- not at the level of DISCUSS, but worthy of comment, which I ask that you consider:

1. Three times in the new Section 3.7 you refer to "byte arrays":

  original draft intended that these strings would be treated as byte
  arrays where each byte would represent a US-ASCII character.

  Where specifically mentioned, data fields contain arrays of arbitrary
  bytes as required for protocol processing.

  All other text fields in TACACS+ MUST be treated as printable byte
  arrays of US-ASCII

I'm sort of OK with the use of "arrays of arbitrary bytes" in the second case, as you're not talking about character strings, though we usually reserve "array" to refer to a particular data structure with a particular mechanism of access.  But I won't quibble about that.  In the other two cases, it seems an odd distraction, and I wish you would use "strings" instead of "arrays".

2. In many places in the document you have added a space after ")" or "]".  For example, "For IPv6 address text representation defined please see RFC 5952 [RFC5952] ." and "For more details please refer to security section (Section 10) ."  Why did you do that?  The RFC Editor will only have to take them back out, so I recommend that you take them out now, instead.

Again, thanks for the update and for addressing my DISCUSS.

[Ballot comment]
My DISCUSS moved to Alexey's ballot. My original comment is below:

I agree with Deborah's comment, and would further suggest that the lack of modern security mechanisms in this protocol needs to be called out in the introduction, with a reference to Section 10.

Please respond to the Gen-ART review, which makes several suggestions for needed clarifications.

In Section 2, please use the RFC 8174 boilerplate.

[Ballot discuss]
(I have incorporated DISCUSS portion of Alissa's DISCUSS, see DISCUSS points #7-#9)

I appreciate that this is documenting an existing protocol and I am very glad that it is being documented.
However there are several things which are still not documented well enough/not in enough details to implement.
So I would like to discuss these issues before recommending approval of this document:

1) 4.6.  Text Encoding

  All text fields in TACACS+ MUST be printable US-ASCII, excepting

Please add a reference to RFC 20 (for US-ASCII) here. Without out it "printable" has no meaning.

  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 fields and those data fields used for
  passwords as 8-bit octet strings.  The deployment operator MUST
  ensure that consistent character encoding is applied from the end
  client to the server.  The encoding SHOULD be UTF-8, and other

Please add Normative RFC 3629 reference here for UTF-8.

  encodings outside printable US-ASCII SHOULD be deprecated.

I am not sure what this mean. You didn't define allowed encoding (really you mean charsets).

2) In 5.1:

  The printable US-ASCII name of the client port on which the
  authentication is taking place,

This doesn't mean anything. Is there a registry? It doesn't look like you are using transport service name registry for this.
Is it a fixed list?

  and its length in bytes.  The value
  of this field is client specific.  (For example, Cisco uses "tty10"
  to denote the tenth tty line and "Async10" to denote the tenth async
  interface).  The port_len indicates the length of the port field, in
  bytes.

3) Later in 5.1:

  A printable US-ASCII string indicating the remote location from which
  the user has connected to the client.  It is intended to hold a
  network address

What are the allowed formats for IPv4 and IPv6? Or is this just human readable?

  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
  location information that is available.

4) In 5.4:

  If the information being requested by the server form the client is
  sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
  flag.  When the client queries the user for the information, the
  response MUST NOT be echoed as it is entered.

What does the last sentence mean? (When is it ever echoed?) Are you missing a forward reference or some explanation of echoing?

5) KRB5 and KRB4 need normative references.

6) Does this document need to obsolete RFC 1492?

7) The Gen-ART reviewer Stewart Bryant (SB) asked the following:

    TAC_PLUS_PRIV_LVL_MAX := 0x0f

    TAC_PLUS_PRIV_LVL_ROOT := 0x0f

    TAC_PLUS_PRIV_LVL_USER := 0x01

    TAC_PLUS_PRIV_LVL_MIN := 0x00

SB> Where are these defined?

Please define the semantics of these values.

8) Stewart also noted the following:

    TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01

    TAC_PLUS_AUTHEN_TYPE_PAP := 0x02

    TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03

    TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)

    TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05

    TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06

SB> There are lots of lists similar to the above.
SB> I have not checked them all, but a number of the types
SB> in this and subsequent parts of the design don't seem
SB> to be defined or have a definitive reference

The way I would say this is that the document seems to be written for people who have already deployed this protocol, and elides details that would make it comprehensible to a new implementor. But it also contemplates the prospect of new implementations. If new implementations are actually expected (which I was surprised about, but can believe), I agree with Stewart that each of the field values need a definition that explains its semantic. If new implementations are not expected, then the reference to new implementations should be removed.

9) How is "secure deployment" defined? Since this is used as a restriction in several places, I think it needs to be defined precisely.

[Ballot discuss]
(One small addition to my earlier comments, see new DISCUSS point 6)

I appreciate that this is documenting an existing protocol and I am very glad that it is being documented.
However there are several things which are still not documented well enough/not in enough details to implement.
So I would like to discuss these issues before recommending approval of this document:

1) 4.6.  Text Encoding

  All text fields in TACACS+ MUST be printable US-ASCII, excepting

Please add a reference to RFC 20 (for US-ASCII) here. Without out it "printable" has no meaning.

  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 fields and those data fields used for
  passwords as 8-bit octet strings.  The deployment operator MUST
  ensure that consistent character encoding is applied from the end
  client to the server.  The encoding SHOULD be UTF-8, and other

Please add Normative RFC 3629 reference here for UTF-8.

  encodings outside printable US-ASCII SHOULD be deprecated.

I am not sure what this mean. You didn't define allowed encoding (really you mean charsets).

2) In 5.1:

  The printable US-ASCII name of the client port on which the
  authentication is taking place,

This doesn't mean anything. Is there a registry? It doesn't look like you are using transport service name registry for this.
Is it a fixed list?

  and its length in bytes.  The value
  of this field is client specific.  (For example, Cisco uses "tty10"
  to denote the tenth tty line and "Async10" to denote the tenth async
  interface).  The port_len indicates the length of the port field, in
  bytes.

3) Later in 5.1:

  A printable US-ASCII string indicating the remote location from which
  the user has connected to the client.  It is intended to hold a
  network address

What are the allowed formats for IPv4 and IPv6? Or is this just human readable?

  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
  location information that is available.

4) In 5.4:

  If the information being requested by the server form the client is
  sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
  flag.  When the client queries the user for the information, the
  response MUST NOT be echoed as it is entered.

What does the last sentence mean? (When is it ever echoed?) Are you missing a forward reference or some explanation of echoing?

5) KRB5 and KRB4 need normative references.

6) Does this document need to obsolete RFC 1492?

[Ballot discuss]
Thanks to everyone who has worked on documenting the TACACS+ protocol
as it is used today.

I understand the desire to publish this document as a status other than
Historic, as the protocol remains in use today. However, the shortcomings
cited in the "Security Considerations" section are quite profound, and
really bear highlighting in the document way before we get into what is
fundamentally end material.

I have serious misgivings about publishing this document as anything
other than Historic without some prominent text early in the document
(e.g., in the Introduction section) that warns implementors of the
several caveats detailed in section 10 and its subsections. They don't
need to be explained here, but some language along the lines of the
following really needs to be present in order to scope the document:

  Note that the original TACACS+ implementations did not address all of the
  baseline security concerns which are considered when designing modern
  protocols.  This document does not change this situation, and implementors
  should use caution when evaluating the suitability of TACACS+ for any given
  use.  Please see section 10 for additional details.

---------------------------------------------------------------------------

§4.6:

>  To ensure interoperability of current deployments, the TACACS+ client
>  and server MUST handle user fields and those data fields used for
>  passwords as 8-bit octet strings.  The deployment operator MUST
>  ensure that consistent character encoding is applied from the end
>  client to the server.  The encoding SHOULD be UTF-8, and other
>  encodings outside printable US-ASCII SHOULD be deprecated.

Without specification of preparation profiles for usernames and passwords,
this is an incomplete specification of how to transmit non-ASCII
usernames and passwords. While there are other solutions, the easy
way to address this is to normatively reference RFC 7613, and select
one of its username preparation profiles, and indicate its password
preparation profile.

The most basic problem here is that I might create a username and/or password
on a machine that uses one mapping for a non-ASCII character, and later try to
log in on a machine that uses a different, but semantically equivalent,
mapping for that same character. This is a clear interop issue.

[Ballot comment]

ID Nits reports:

  ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994)

---------------------------------------------------------------------------

§2:

>  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 RFC 2119 RFC2119
>  [RFC2119].

Please use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§4.3:

>  The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by
>  the client and server to negotiate the use of Single Connect Mode.

This is a bit jarring, as the document hasn't yet established the existence
of a packet header, or of flag in that header. It might be better to pull
section 4.8 earlier in the document -- at least before this sentence --
so that readers have some context for understanding what's going on.

---------------------------------------------------------------------------

§4.7:

>  Server implementations MUST allow a unique secret key to be
>  associated with every client.

Nit: "...with each client."

---------------------------------------------------------------------------

§5.1:

>  network address if the user is connected via a network, a caller ID
>  is the user is connected via ISDN or a POTS

Nit: "...if the user..."

---------------------------------------------------------------------------

§5.4.2.1:

Is the intention here to limit the characters in the user name and the
password to be only those in the ASCII range? Section 4.6 would seem to
indicate that this isn't the case, but the title of this section throws
that into doubt. If the text in 4.6 is the guiding text here, perhaps
section 5.4.2.1 should indicate that the term "ASCII" is used only for
historical reasons, and that both usernames and passwords can contain
UTF-8-encoded character strings.

---------------------------------------------------------------------------

§5.4.2.2:

>  the data
>  field MUST contain the PAP ASCII password.

Same comment as for section 5.4.2.1, above.

---------------------------------------------------------------------------

§5.4.2.3:

>  defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then
>  compare that value with the response.

Nit: "...and then compares..."

---------------------------------------------------------------------------

§5.4.2.7.  ASCII change password request

Same comment as for section 5.4.2.1.

---------------------------------------------------------------------------

§5.4.3:

>  If this
>  flag is set, the data portion of the message may contain an ASCII
>  message explaining the reason for the abort.

Does this mean "ASCII" or does it mean "UTF-8"? If it actually means
"ASCII," then localization -- especially to localities that use
non-latin-based alphabets -- will be incredibly challenging.

---------------------------------------------------------------------------

§6.2 and §7.2:

>  server_msg, server_msg_len
>
>  This is a printable US-ASCII string that may be presented to the
>  user.
>
>  data, data_len
>
>  This is a printable US-ASCII string that may be presented on an
>  administrative display, console or log

Same comment as for section 5.4.3.

---------------------------------------------------------------------------

§8.1:

>  All attribute values are encoded as printable US-ASCII strings.  The
>  following type representations SHOULD be followed
...
>  String
>
>  Many values have no specific type representation and so are
>  interpreted as plain strings.

Same comment as for section 5.4.3.

---------------------------------------------------------------------------

§8.3:

>  err_msg (String)
>
>  A printable US-ASCII string describing the status of the action.

Same comment as for section 5.4.3.

---------------------------------------------------------------------------

§10.5.3:

>  To help TACACS+ administraots select the stronger authentication

Nit: "...administrators..."

---------------------------------------------------------------------------

[Ballot discuss]
I support the DISCUSS ballots by Alexey and Roman, as well as the comments by Deborah and Alissa that more text be in the introduction about the status and limitations here.

I also need to add to Alexey’s DISCUSS on 4.6, Text Encoding:

  To ensure interoperability of current deployments, the TACACS+ client
  and server MUST handle user fields and those data fields used for
  passwords as 8-bit octet strings.  The deployment operator MUST
  ensure that consistent character encoding is applied from the end
  client to the server.

This is a mine field.  Treating passwords as raw octets without concern for encoding and normalization can cause authentication failures and can be used to attack systems where non-ASCII passwords are in use.

Suppose I enter “crème brûlée” as my password. How that’s represented in UTF-8 depends upon my input device, as there are at least two valid representations of each accented vowel.  Without normalization/canonicalization, passwords entered on different input devices might not match, blocking my access.  And we haven’t touched on bidirectional issues (mixing, say, Hebrew and English characters).

The precis framework has detailed explanations of how to deal with usernames and passwords — see RFC 8265 (and, for the overall precis framework, RFC 8264).

  The encoding SHOULD be UTF-8, and other
  encodings outside printable US-ASCII SHOULD be deprecated.”

This doesn’t make sense with respect to how we use “deprecated”.  You need to say “are deprecated”, meaning that we recommend against using them.  There’s no BCP 14 “SHOULD” involved here.

[Ballot comment]
I am recusing myself as I was the WG chair when this document was initially being worked on, and, for various reasons, feel it would be inappropriate of me to ballot.

[Ballot comment]
* Section 8.1.

"IPV6 address text representation defined in RFC 4291 [RFC4291]"

I would much prefer using RFC5952 here as it tightens rules a bit over RFC4291 and cuts down the flexibility to make text comparisons easier.

"Stardate is canonically inconsistent and so SHOULD NOT be used."

as in "Acting Captain's log, Stardate 2258.42. We have had no word from Captain Pike..."? I agree that it is canonically inconsistent but this will be very confusing for non-Trekkies. Is this really needed here?

[Ballot comment]
Thanks for the work everyone has put into this document. I have some comments and some nits. I also support most of the other comments issued by the IESG members.

And, I appreciate the time taken to document a protocol that I used in the mid 90's ;-) it took sometime to document it... I also appreciate the use of 'obfuscation' in section 4.7.

== COMMENTS ==
- section 1, I am unsure whether the 'today' in 'It is primarily used today...' still stands in 2019.
- a little late to ask, but, is there any reason why draft-dahm-opsawg-tacacs does not refer to 'The Draft' in the datatracker?
- section 4.8, the flag values are 0x01 and 0x04, but what about the other bits? Should they be considered as 0 and ignored on reception?
- section 5.1, should TAC_PLUS_AUTHEN_SVC_ARAP := 0x04 also be deprecated ?
- section 5.4.2.1 about 'ASCII login' while I understand that years ago it was ASCII only hence the name of the value but the text is unclear whether UTF-8 could be used (assuming that the network devices support this character set)
- section 8.2, the route attribute is defined only for IPv4 while the T+ can send IPv6 addresses to the client. Is it sensible?


== NITS ==
- abstract TACACS is an acronym which should be expanded in the abstract
- section 3 could be updated esp around "character mode front end and then allow the user to telnet"
- section 4.1 add that the port 49 has been allocated by the IANA ?
- section 4.3 talks about flags but the packet format is also presented in section . Not a logical flow
- section 8.1 s/IPV6 address text representation defined/IPv6 address text representation is defined/ (lower case V as well)
- section 8.2, please clarify the inacl value, is it an ACL name or an ASCII representation of the list of ACL entries?

[Ballot discuss]
(1) I appreciate the deliberate and thoughtful attempt in this section to enumerate the possible risks/attacks and mitigations of the protocol as is.  In addition to the top-level risks in Section 10.1, I can see the value of maintaining symmetry between Sections 5+10.2; 6+10.3 and 7+10.4.  In the spirit of the middle ground this draft is trying to realize (document the as-is, but highlight the issues), I have the following feedback:

(a) Section 10.1.  I recommend replacing the first three paragraphs of Section 10.1 (“TACACS+ protocol does not …”, “While the protocol …”, and “Even though …”) with the following text synthesized from Joe Salowey’s LC review (https://mailarchive.ietf.org/arch/msg/secdir/rsqrNbVEKph1RdWh836Ard73pHs) and the current introduction:

TACACS+ protocol does not include a security mechanism that would meet modern-day requirements.  These security mechanisms would be best referred to as “obfuscation” and not “encryption” since they provide no meaningful integrity, privacy or replay protection.  An attacker with access to the data stream should be assumed to be able to read and modify all TACACS+ packets. Without mitigation, a range of risks such as the following are possible:

Accounting information may be modified by the man-in-the-middle attacker, making such logs unsuitable and untrustable for auditing purposes.

Invalid or misleading values may be inserted by the man-in-the-middle attacker in various fields at known offsets to try and circumvent the authentication or authorization checks even inside the obfuscated body.

(b) I recommend finding an alternative home and strengthening the text “For this reason, deployments SHOULD NOT use connections with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the Best Practices section (Section 10.5)”.  It seemed odd to mix deployment guidance in a list of risks as currently written.  I take Andrej Ota’s point from https://mailarchive.ietf.org/arch/msg/secdir/UgtsSfh1RaauNoMRi87FRqtI0YI that there is no harm in requiring the obfuscation, such as it is.  Furthermore, why couldn’t this be MUST NOT use?

(c) Section 10.5.3.  I concur with the SECDIR recommendation and the follow-up discussion with Andrej Ota per https://mailarchive.ietf.org/arch/msg/secdir/UgtsSfh1RaauNoMRi87FRqtI0YI which would:
s/stronger authentication/less weak/

(2) Section 10.2.  I’m confused by the deprecation of TAC_PLUS_AUTHEN_STATUS_FOLLOW but a seemingly weaker “SHOULD NOT be used in modern deployments”.  I was expecting a MUST NOT.

(3) Section 10.4.  Why shouldn’t accounting sessions also use secure transport per 10.5 (like 10.3 and 10.4) given the risks outlined in the text?  I was expecting to see this section open with “Accounting Session SHOULD be used via a secure transport (see Best Practices section (Section 10.5))".

[Ballot discuss]
(1) I appreciate the deliberate and thoughtful attempt in this section to enumerate the possible risks/attacks and mitigations of the protocol as is.  In addition to the top-level risks in Section 10.1, I can see the value of maintaining symmetry between Sections 5+10.2; 6+10.3 and 7+10.4.  In the spirit of the middle ground this draft is trying to realize (document the as-is, but highlight the issues), I have the following feedback:

(a) Section 10.1.  I recommend replacing the first three paragraphs of Section 10.1 (“TACACS+ protocol does not …”, “While the protocol …”, and “Even though …”) with the following text partially synthesized from Joe Salowey’s review (https://mailarchive.ietf.org/arch/msg/secdir/rsqrNbVEKph1RdWh836Ard73pHs) with the current introduction:

TACACS+ protocol does not include a security mechanism that would meet modern-day requirements.  These security mechanisms would be best referred to as “obfuscation” and not “encryption” since they provide no meaningful integrity, privacy or replay protection.  An attacker with access to the data stream should be assumed to be able to read and modify all TACACS+ packets. Without mitigation, a range of risks such as the following are possible:

Accounting information may be modified by the man-in-the-middle attacker, making such logs unsuitable and untrustable for auditing purposes.

Invalid or misleading values may be inserted by the man-in-the-middle attacker in various fields at known offsets to try and circumvent the authentication or authorization checks even inside the obfuscated body.

(b) I recommend finding an alternative home and strengthening the text “For this reason, deployments SHOULD NOT use connections with TAC_PLUS_UNENCRYPTED_FLAG, as mentioned in the Best Practices section (Section 10.5)”.  It seemed odd to mix deployment guidance in a list of risks as currently written.  I take Andrej Ota’s point from https://mailarchive.ietf.org/arch/msg/secdir/UgtsSfh1RaauNoMRi87FRqtI0YI that there is no harm in requiring the obfuscation, such as it is.  Furthermore, why couldn’t this be MUST NOT use?

(c) Section 10.5.3.  I concur with the SECDIR recommendation and the follow-up discussion with Andrej Ota per https://mailarchive.ietf.org/arch/msg/secdir/UgtsSfh1RaauNoMRi87FRqtI0YI which would:
s/stronger authentication/less weak/

(2) Section 10.2.  I’m confused by the deprecation of TAC_PLUS_AUTHEN_STATUS_FOLLOW but a seemingly weaker “SHOULD NOT be used in modern deployments”.  I was expecting a MUST NOT.

(3) Section 10.4.  Why shouldn’t accounting sessions also use secure transport per 10.5 (like 10.3 and 10.4) given the risks outlined in the text?  I was expecting to see this section open with “Accounting Session SHOULD be used via a secure transport (see Best Practices section (Section 10.5))".

[Ballot comment]
(1) Editorial Nits:

** Section 10.5.3.  Typo.  s/administraots/administrators/
** Global.  Various places in the document have an extra space between the end of a reference and the closing period.  Recommend: s/] ./]./g

(2) I endorse Mirja and Deborah’s point that strong text is needed in Section 1 to state that this document is describing the current deployment of the protocol which has serious security issues.

[Ballot discuss]
(1) The Gen-ART reviewer Stewart Bryant (SB) asked the following:

    TAC_PLUS_PRIV_LVL_MAX := 0x0f

    TAC_PLUS_PRIV_LVL_ROOT := 0x0f

    TAC_PLUS_PRIV_LVL_USER := 0x01

    TAC_PLUS_PRIV_LVL_MIN := 0x00

SB> Where are these defined?

Please define the semantics of these values.

(2) Stewart also noted the following:

    TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01

    TAC_PLUS_AUTHEN_TYPE_PAP := 0x02

    TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03

    TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)

    TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05

    TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06

SB> There are lots of lists similar to the above.
SB> I have not checked them all, but a number of the types
SB> in this and subsequent parts of the design don't seem
SB> to be defined or have a definitive reference

The way I would say this is that the document seems to be written for people who have already deployed this protocol, and elides details that would make it comprehensible to a new implementor. But it also contemplates the prospect of new implementations. If new implementations are actually expected (which I was surprised about, but can believe), I agree with Stewart that each of the field values need a definition that explains its semantic. If new implementations are not expected, then the reference to new implementations should be removed.

(3) How is "secure deployment" defined? Since this is used as a restriction in several places, I think it needs to be defined precisely.

[Ballot comment]
I agree with Deborah's comment, and would further suggest that the lack of modern security mechanisms in this protocol needs to be called out in the introduction, with a reference to Section 10.

Please respond to the Gen-ART review, which makes several suggestions for needed clarifications.

In Section 2, please use the RFC 8174 boilerplate.

[Ballot discuss]
I appreciate that this is documenting an existing protocol and I am very glad that it is being documented.
However there are several things which are still not documented well enough/not in enough details to implement.
So I would like to discuss these issues before recommending approval of this document:

1) 4.6.  Text Encoding

  All text fields in TACACS+ MUST be printable US-ASCII, excepting

Please add a reference to RFC 20 (for US-ASCII) here. Without out it "printable" has no meaning.

  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 fields and those data fields used for
  passwords as 8-bit octet strings.  The deployment operator MUST
  ensure that consistent character encoding is applied from the end
  client to the server.  The encoding SHOULD be UTF-8, and other

Please add Normative RFC 3629 reference here for UTF-8.

  encodings outside printable US-ASCII SHOULD be deprecated.

I am not sure what this mean. You didn't define allowed encoding (really you mean charsets).

2) In 5.1:

  The printable US-ASCII name of the client port on which the
  authentication is taking place,

This doesn't mean anything. Is there a registry? It doesn't look like you are using transport service name registry for this.
Is it a fixed list?

  and its length in bytes.  The value
  of this field is client specific.  (For example, Cisco uses "tty10"
  to denote the tenth tty line and "Async10" to denote the tenth async
  interface).  The port_len indicates the length of the port field, in
  bytes.

3) Later in 5.1:

  A printable US-ASCII string indicating the remote location from which
  the user has connected to the client.  It is intended to hold a
  network address

What are the allowed formats for IPv4 and IPv6? Or is this just human readable?

  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
  location information that is available.

4) In 5.4:

  If the information being requested by the server form the client is
  sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
  flag.  When the client queries the user for the information, the
  response MUST NOT be echoed as it is entered.

What does the last sentence mean? (When is it ever echoed?) Are you missing a forward reference or some explanation of echoing?

5) KRB5 and KRB4 need normative references.

[Ballot comment]
In 4.8:

4.8.  The TACACS+ Packet Header

  The total length of the packet body (not including the header).

In network byte order? There is some text about that in 4.9, but readers don't know that yet.

In 6.1:

  The arguments are the primary elements of the authorization
  interaction.  In the request packet they describe the specifics of
  the authorization that is being requested.  Each argument is encoded
  in the packet as a single arg filed (arg_1...  arg_N) with a

Typo: filed --> field.

  corresponding length fields (which indicates the length of each
  argument in bytes).

Later in the same section:

  Optional arguments are ones that may be disregarded by either client
  or server.  Mandatory arguments require that the receiving side can
  handle the attribute, that is: its implementation and configuration
  includes the details of how to act on it.  If the client receives a
  mandatory argument that it cannot handle, it MUST consider the
  authorization to have failed.  It is legal to send an attribute-value
  pair with a zero length value.

Last sentence: do you just mean that the value can be empty?

In 8.1:

  Date Time

  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
  specified.  Stardate is canonically inconsistent and so SHOULD NOT be
  used.

I am not sure what the last sentence means.

In 8.2:

8.2.  Authorization Attributes

  For example: "shell", "tty-server", "connection", "system" and
  "firewall".  This attribute MUST always be included.

Is this a full list or is there a registry?

Later in the same section:

  remote_host (String)

What is the syntax of this field?

10.4.  Security of Accounting Sessions

      Replace accounting data with new valid or garbage which prevents
      to provide distraction

"prevents to provide distraction" doesn't read well.

      or hide information related to their
      authentication and/or authorization attack attempts.

In 10.5.1:

  TACACS+ server administrators SHOULD change secret keys at regular
  intervals.

Humans are very bad at this. So I think it would be better if this is changed to add a requirement on management UIs.

10.5.3.  Authentication

  To help TACACS+ administraots select the stronger authentication

Typo: administrators.

[Ballot comment]
A couple of comments/question:

1) I would like to see it more explicitly mentioned in the title, abstract, and introduction that this is only documenting the protocol as deployed today. Usually we use titles like “Company X’s TACACS+ protocol”; this is probably not applicable here but maybe something like “Documentation of the TACACS+ Protocol” would work as well…?

2) If Single Connection Mode is used and the connection is idle for a while, it can be possible that some middlebox or the server lost state and the connection is actually not available anymore. I guess it could be good to explicit mention this case and say something like if a RST or timeout is encountered for a connection in Single Connection Mode, the client should try to open a new connection and resend the request immediately.

3) I would recommend to define the term “session” in section 3 (as it seems to a central term that is important to understand correctly).

4) Sec 10.5.1: “TACACS+ servers MUST NOT leak sensitive data.”
Not sure if that is an actionable requirement, as I would assume leaking is often done by accident.
Maybe “TACACS+ servers MUST store sensitive data securely.”… or something…? Not sure  how much better that is…
Actually the next sentence could probably be normative:
S/TACACS+ servers should not expose shared secrets in logs./TACACS+ servers MUST NOT expose shared secrets in logs./

5) One question regarding the unencrypted/non-obfuscated mode: Why was this mode (and TAC_PLUS_UNENCRYPTED_FLAG=1) not deprecated completely? You mention briefly somewhere that this is/was used for debugging but then later say that modern tools should also support debugging of obfuscated traffic.

6) Sec 10.5.5: “TACACS+ servers SHOULD deprecate the redirection mechanism.”
I believe you want to use a MUST here because you anyway only specify this for servers that follow or update to this spec; it will of course not change existing implementations…

[Ballot comment]
[Procedure Nit -- This is a comments for the Shepherd/Chairs/ADs]

It would be useful to tag this document (or draft-dahm-opsawg-tacacs) as Replacing "the draft". 

It seems clear to me from the explanation in the Introduction that tagging the documents that way is the appropriate thing to do.  I didn't do it myself in case the Shepherd/Chairs/AD know of a reason not to do it.

[Ballot comment]
While the status is an Informational document, not PS, I still would
prefer if earlier in the document it provided the reader with deployment
concerns e.g. the introduction.

The current introduction states a "wide range" of clients and servers
are already deployed. Not until section 10 is the reader informed
"Multiple implementations of the protocol described in the original
TACACS+ Draft `The Draft' [TheDraft] have been deployed.  As the
protocol was never standardized, current implementations may be
incompatible in non-obvious ways". And section 10.5 on Best
Practices which has the new restriction that it not be deployed
with other traffic. This information is needed much
earlier in the document to give context for the reader.

[Ballot comment]
While the status is an Informational document, not PS, I still would prefer
if earlier in the document it provided the reader with deployment
concerns e.g. the introduction.

The current introduction states a "wide range" of clients and servers
are already deployed. Not until section 10 is the reader informed
"Multiple implementations of the protocol described in the original
TACACS+ Draft `The Draft' [TheDraft] have been deployed.  As the
protocol was never standardized, current implementations may be
incompatible in non-obvious ways". And section 10.5 on Best
Practices which has the new restriction that it not be deployed
with other traffic. This information is needed much
earlier in the document to give context for the reader.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-opsawg-tacacs-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-23):

From: The IESG
To: IETF-Announce
CC: ibagdona@gmail.com, draft-ietf-opsawg-tacacs@ietf.org, jclarke@cisco.com, opsawg-chairs@ietf.org, Joe Clarke , opsawg@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The TACACS+ Protocol) to Informational RFC


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'The TACACS+
Protocol'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-04-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  TACACS+ provides Device Administration for routers, network access
  servers and other networked computing devices via one or more
  centralized servers.  This document describes the protocol that is
  used by TACACS+.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is intended to be an Informational RFC that describes the TACACS+ protocol the way it is implemented _today_.  This is an important point.  This document is not intending to change TACACS+ or address the security issues inherent within it.  It is setting the stage for enhancing the security of TACACS+, but it is only aimed at adding referential context on how TACACS+ is implemented currently.  As such Informational is the right status for this document.

The IESG should keep in mind that many operators use TACACS+ today, therefore documenting how it works is useful.  This is especially true given the desire of the authors to extend the protocol to address the security flaws in something that is so ubiquitous.

The intended Informational status is clearly mentioned in the header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  TACACS+ provides Device Administration for routers, network access
  servers and other networked computing devices via one or more
  centralized servers.  This document describes the protocol that is
  used by TACACS+.  In particular, this document describes the TACACS+ protocol the way it is 
  currently implemented and does not attempt to modify any of its inherent security issues.

Working Group Summary

  Initially, this document described both the current TACACS+ protocol implementation plus extensions to allow for T+ over TLS.  The working group though this muddied the water too much, and it was desired to first document the TACACS+ protocol as it stands today as an informational document.  Once that document was ratified, a new document would be submitted for properly securing TACACS+ with TLS.

There was broad WG support for documenting TACACS+ as it is widely used and implemented in the industry.  However, there were some procedural issues with how this document evolved.  One WG member was particular vocal, initially in his objection to adding another AAA protocol, but then on how the document authorship was handled.  As mentioned, the WG saw value in documenting this given its ubiquity.  But the authorship of the document could have been handled better.

The problems included:

* The authors were slow to respond to comments initially
* The authors did no summarize changes revision-over-revision of the document
* A large amount of text was contributed by a working group member, but that member was not acknowledged in the text
* Some comments went a long while without being addressed

By the end of the process, all of these items had been addressed and author response had increased and improved.

Additionally, a section was added to the document to attempt to mitigate some of the known security issues by offering some best practices in terms of deployment.  These practices do not alter the protocol itself but can help mitigate potential security issues.

Finally, a call for implementations was done to confirm that known implementations in the wild adhere to this.  Numerous vendors and clients responded including Cisco, Huawei, Aviatnet, and FreeRADIUS that indicate their implementation adheres to this document with varying levels of support of various protocol options.

Document Quality

  It is strongly believed this document adequately and completely describes the TACACS+ protocol as it exists today.  See above with respect to known implementations that adhere to this document.

Personnel

  The document shepherd is Joe Clarke and the associated AD is Ignas Bogdonas.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have read this document and commented on it to the authors and WG.  I feel it is ready to go to the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I feel this document has been fully reviewed and has had multiple comments and corrections.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Obviously, security is going to be a sticking point.  But as I have mentioned above, the intent is to define the protocol as it exists currently.  It is known that there are security issues.  The document describes those and offers some suggestions to mitigate.  IESG members should keep this in mind.  The ultimate goal is to improve the security of TACACS+ in a new document to be defined after this one completes.

A deeper security review only insofar as any leading practices that might be missing may be warranted.  While the protocol itself cannot be modified, anything that could help one mitigate known issues with TACACS+ have been listed, and it might be desirable to list other steps as well.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I have no concerns with the document at this point.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, all authors have stated there is no known IPR.  I have not seen any contributors state that there is IPR on this draft.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

This document has reached consensus after much consternation from certain WG members.  Those members have provided substantive comments and have helped increase the integrity of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

I will send a separate email.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The IDNITS have been mostly cleared up.  There is one error flagged in that this document references PAP [RFC1334], which was obsoleted by CHAP.  However, PAP is actually valid since we are truly documenting the way TACACS+ protocol works today.  (Ultimately, the desire is to have a new draft that makes usage of PAP moot as TLS is intended.)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Not yet.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is intended to be an Informational RFC that describes the TACACS+ protocol the way it is implemented _today_.  This is an important point.  This document is not intending to change TACACS+ or address the security issues inherent within it.  It is setting the stage for enhancing the security of TACACS+, but it is only aimed at adding referential context on how TACACS+ is implemented currently.  As such Informational is the right status for this document.

The IESG should keep in mind that many operators use TACACS+ today, therefore documenting how it works is useful.  This is especially true given the desire of the authors to extend the protocol to address the security flaws in something that is so ubiquitous.

The intended Informational status is clearly mentioned in the header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  TACACS+ provides Device Administration for routers, network access
  servers and other networked computing devices via one or more
  centralized servers.  This document describes the protocol that is
  used by TACACS+.  In particular, this document describes the TACACS+ protocol the way it is 
  currently implemented and does not attempt to modify any of its inherent security issues.

Working Group Summary

  Initially, this document described both the current TACACS+ protocol implementation plus extensions to allow for T+ over TLS.  The working group though this muddied the water too much, and it was desired to first document the TACACS+ protocol as it stands today as an informational document.  Once that document was ratified, a new document would be submitted for properly securing TACACS+ with TLS.

There was broad WG support for documenting TACACS+ as it is widely used and implemented in the industry.  However, there were some procedural issues with how this document evolved.  One WG member was particular vocal, initially in his objection to adding another AAA protocol, but then on how the document authorship was handled.  As mentioned, the WG saw value in documenting this given its ubiquity.  But the authorship of the document could have been handled better.

The problems included:

* The authors were slow to respond to comments initially
* The authors did no summarize changes revision-over-revision of the document
* A large amount of text was contributed by a working group member, but that member was not acknowledged in the text
* Some comments went a long while without being addressed

By the end of the process, all of these items had been addressed and author response had increased and improved.

Additionally, a section was added to the document to attempt to mitigate some of the known security issues by offering some best practices in terms of deployment.  These practices do not alter the protocol itself but can help mitigate potential security issues.

Finally, a call for implementations was done to confirm that known implementations in the wild adhere to this.  Numerous vendors and clients responded including Cisco, Huawei, Aviatnet, and FreeRADIUS that indicate their implementation adheres to this document with varying levels of support of various protocol options.

Document Quality

  It is strongly believed this document adequately and completely describes the TACACS+ protocol as it exists today.  See above with respect to known implementations that adhere to this document.

Personnel

  The document shepherd is Joe Clarke and the associated AD is Ignas Bogdonas.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have read this document and commented on it to the authors and WG.  I feel it is ready to go to the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I feel this document has been fully reviewed and has had multiple comments and corrections.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Obviously, security is going to be a sticking point.  But as I have mentioned above, the intent is to define the protocol as it exists currently.  It is known that there are security issues.  The document describes those and offers some suggestions to mitigate.  IESG members should keep this in mind.  The ultimate goal is to improve the security of TACACS+ in a new document to be defined after this one completes.

A deeper security review only insofar as any leading practices that might be missing may be warranted.  While the protocol itself cannot be modified, anything that could help one mitigate known issues with TACACS+ have been listed, and it might be desirable to list other steps as well.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I have no concerns with the document at this point.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, all authors have stated there is no known IPR.  I have not seen any contributors state that there is IPR on this draft.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

This document has reached consensus after much consternation from certain WG members.  Those members have provided substantive comments and have helped increase the integrity of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

I will send a separate email.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The IDNITS have been mostly cleared up.  There is one error flagged in that this document references PAP [RFC1334], which was obsoleted by CHAP.  However, PAP is actually valid since we are truly documenting the way TACACS+ protocol works today.  (Ultimately, the desire is to have a new draft that makes usage of PAP moot as TLS is intended.)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Not yet.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is intended to be an Informational RFC that describes the TACACS+ protocol the way it is implemented _today_.  This is an important point.  This document is not intending to change TACACS+ or address the security issues inherent within it.  It is setting the stage for enhancing the security of TACACS+, but it is only aimed at adding referential context on how TACACS+ is implemented currently.  As such Informational is the right status for this document.

The intended Informational status is clearly mentioned in the header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  TACACS+ provides Device Administration for routers, network access
  servers and other networked computing devices via one or more
  centralized servers.  This document describes the protocol that is
  used by TACACS+.  In particular, this document describes the TACACS+ protocol the way it is 
  currently implemented and does not attempt to modify any of its inherent security issues.

Working Group Summary

  Initially, this document described both the current TACACS+ protocol implementation plus extensions to allow for T+ over TLS.  The working group though this muddied the water too much, and it was desired to first document the TACACS+ protocol as it stands today as an informational document.  Once that document was ratified, a new document would be submitted for properly securing TACACS+ with TLS.

There was broad WG support for documenting TACACS+ as it is widely used and implemented in the industry.  However, there were some procedural issues with how this document evolved.  One WG member was particular vocal, initially in his objection to adding another AAA protocol, but then on how the document authorship was handled.  As mentioned, the WG saw value in documenting this given its ubiquity.  But the authorship of the document could have been handled better.

The problems included:

* The authors were slow to respond to comments initially
* The authors did no summarize changes revision-over-revision of the document
* A large amount of text was contributed by a working group member, but that member was not acknowledged in the text
* Some comments went a long while without being addressed

By the end of the process, all of these items had been addressed and author response had increased and improved.

Additionally, a section was added to the document to attempt to mitigate some of the known security issues by offering some best practices in terms of deployment.  These practices do not alter the protocol itself but can help mitigate potential security issues.

Finally, a call for implementations was done to confirm that known implementations in the wild adhere to this.  Numerous vendors and clients responded including Cisco, Huawei, Aviatnet, and FreeRADIUS that indicate their implementation adheres to this document with varying levels of support of various protocol options.

Document Quality

  It is strongly believed this document adequately and completely describes the TACACS+ protocol as it exists today.  See above with respect to known implementations that adhere to this document.

Personnel

  The document shepherd is Joe Clarke and the associated AD is Ignas Bogdonas.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have read this document and commented on it to the authors and WG.  I feel it is ready to go to the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I feel this document has been fully reviewed and has had multiple comments and corrections.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Obviously, security is going to be a sticking point.  But as I have mentioned above, the intent is to define the protocol as it exists currently.  It is known that there are security issues.  The document describes those and offers some suggestions to mitigate.  IESG members should keep this in mind.  The ultimate goal is to improve the security of TACACS+ in a new document to be defined after this one completes.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I have no concerns with the document at this point.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, all authors have stated there is no known IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

This document has reached consensus after much consternation from certain WG members.  Those members have provided substantive comments and have helped increase the integrity of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

I will send a separate email.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Not yet.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A