3.2 Based on some questions from a developer in my team, it may be beneficial to explicitly state that earlier versions of TLS MUST NOT be supported. I think the text implies it but explicitly stating it may stop someone also adding support for earlier versions.
TBD
3.2.1 Cipher Requirements: "The cipher suites offered or accepted SHOULD be configurable so that operators can adapt." It is slightly unclear what the operators are adapting. Is this meant to be "The cipher suites offered or accepted SHOULD be configurable by operators" or is there a subtlety I'm missing?
and hands the string over to OpenSSL, which does it's magic. This lets the admin use "DEFAULT" in most cases. But if the admin needs to change that, it's simple to do so. }}}
TBD
3.3 TLS identification: There does not appear to be any network location based validation methods in section 5.2 of RFC5425. Is it meant to be a reference to the using a wildcard with a domain?
FYI: Response from Alan: {{{
I would agree that implementations should support IP-layer filtering by network. The TACACS+ server may be accessible on a management network, but perhaps only part of that network contains edge devices which will connect via TACACS+.
As a result, it is useful to have a configuration which can say "allow network FOO, forbid network BAR". This would be in addition to any TLS layer filtering.
}}}
TBD
6.1 TLS Use: "Unsecure Connections would be better served by separate Servers from the TLS Servers." It is not immediately obvious to me why this would be better than a good implementation on a single server that successfully manages TLS and unsecure connections in a way that prevents downgrade attacks. Some more context would be useful so that this sentence is interpreted as intended. If a recommendation is being made, perhaps "would be better served by" should be replaced by something with "MAY" in it.
ADRESSES, POSSIBLY.
TYPOS AND CLARITY
2.3 Peer: Change "the peer is the TACACS+ Server is the Client" to "the peer of the TACACS+ Server is the Client".
ADDRESSED
3 2. Peer Authentication: "The use of shared keys to add and remove the MD5 obfuscation..." in unclear.
ADDRESSED
3.2 TLS Connection: Missing full stop at end of third paragraph.
ADDRESSED
3.2.2.1 TLS Certificate Path Verification:
Change "Path" to "path" in first sentence.
ADDRESSED
Change "entire chain of the remote's certificate is stored on the local Peer" to "entire chain of the remote Peer's certificate is stored on the local Peer."
ADDRESSED
Arguably the second paragraph is an operations consideration and should be removed or replaced by a reference to "6.4 Unreachable Certificate Authority (CA)". Alternatively, a cross reference could be added to the existing text.
TBD
6.1 TLS Use: "Redundant lists" and "Server lists" are undefined and used inconsistently. Possible rephrasing is: "When introducing TLS to TACACS+ within a network, there is likely to be a period where there is a mixture of TACACS+ servers and/or port combination that support TLS and those that do not. During this period, a mixture of the two types of servers in a single list of TACACS+ servers configured on a client SHOULD be minimised. After migration, the production deployment SHOULD NOT mix the two types of servers within a list configured on a client."
ADDRESSES, POSSIBLY
6.3. Downgrade attacks in TLS: missing "... in" after "options".
REMOVED, THIS SECTION REVERTED
Discussion on Separate port vs Negotiated TLS: Change "it allows easy blocking the unobfuscated" to "it allows easy blocking of the unobfuscated".
ADDRESSED.
ISSUES THAT CAUSED CONFUSION
3.2 Based on some questions from a developer in my team, it may be beneficial to explicitly state that earlier versions of TLS MUST NOT be supported. I think the text implies it but explicitly stating it may stop someone also adding support for earlier versions. TBD
3.2.1 Cipher Requirements: "The cipher suites offered or accepted SHOULD be configurable so that operators can adapt." It is slightly unclear what the operators are adapting. Is this meant to be "The cipher suites offered or accepted SHOULD be configurable by operators" or is there a subtlety I'm missing?
FYI: Response from Alan: {{{
The implementation should expose enough TLS configuration that the administrator can change the cipher list if necessary. For example: https://github.com/FreeRADIUS/freeradius-server/blob/release_3_2_3/raddb/mods-available/eap#L407
That just takes configuration:
and hands the string over to OpenSSL, which does it's magic. This lets the admin use "DEFAULT" in most cases. But if the admin needs to change that, it's simple to do so. }}} TBD
3.3 TLS identification: There does not appear to be any network location based validation methods in section 5.2 of RFC5425. Is it meant to be a reference to the using a wildcard with a domain?
FYI: Response from Alan: {{{ I would agree that implementations should support IP-layer filtering by network. The TACACS+ server may be accessible on a management network, but perhaps only part of that network contains edge devices which will connect via TACACS+.
As a result, it is useful to have a configuration which can say "allow network FOO, forbid network BAR". This would be in addition to any TLS layer filtering.
}}} TBD
6.1 TLS Use: "Unsecure Connections would be better served by separate Servers from the TLS Servers." It is not immediately obvious to me why this would be better than a good implementation on a single server that successfully manages TLS and unsecure connections in a way that prevents downgrade attacks. Some more context would be useful so that this sentence is interpreted as intended. If a recommendation is being made, perhaps "would be better served by" should be replaced by something with "MAY" in it. ADRESSES, POSSIBLY.
TYPOS AND CLARITY
2.3 Peer: Change "the peer is the TACACS+ Server is the Client" to "the peer of the TACACS+ Server is the Client". ADDRESSED
3 2. Peer Authentication: "The use of shared keys to add and remove the MD5 obfuscation..." in unclear. ADDRESSED
3.2 TLS Connection: Missing full stop at end of third paragraph. ADDRESSED
3.2.2.1 TLS Certificate Path Verification:
6.1 TLS Use: "Redundant lists" and "Server lists" are undefined and used inconsistently. Possible rephrasing is: "When introducing TLS to TACACS+ within a network, there is likely to be a period where there is a mixture of TACACS+ servers and/or port combination that support TLS and those that do not. During this period, a mixture of the two types of servers in a single list of TACACS+ servers configured on a client SHOULD be minimised. After migration, the production deployment SHOULD NOT mix the two types of servers within a list configured on a client." ADDRESSES, POSSIBLY
6.3. Downgrade attacks in TLS: missing "... in" after "options". REMOVED, THIS SECTION REVERTED