Some comments on the latest draft:
2.1. Obfuscation
... The algorithm is categorized as Obfuscation in Section 10.5.2 of
[RFC8907]. The term should be interpreted to mean "plaintext"
I wouldn't call it "plaintext", as it's not. Perhaps instead just drop the
"interpreted to mean plaintext" portion.
2.2
... using unsecure TACACS+ authentication and obfuscation
"insecure" instead of "unsecure".
3.1
... All data exchanged by TACACS+ peers MUST be encrypted,
Perhaps explicitly say that TLS cipher suites with NULL encryption are banned.
This is a little more quantitative.
... they will be deployed on different ports. Due to the widespread use
of default port number settings in numerous existing TACACS+ client
configurations, a well-known system TCP/IP port number will be requested from
IANA.
Perhaps just say "uses port TBD", and leave the IANA instructions in a
separate IANA section.
i.e. the final RFC doesn't need to contain text on "port will be requested
from IANA"
3.2
... Why it closed has no bearing on TLS resumption, unless closed by a
TLS error, in which case the ticket might be invalidated.
"might" seems wrong here. If there is a TLS error, the server generally
should discard any session tickets. While RFC 8446 doesn't say this, I'm not
clear if there are any use-cases for resuming sessions which (for example) had
previously failed with fatal TLS errors.
3.2.2.
Are there any considerations for which CA to use, or what kind of CA to use?
4
[RFC8907] describes the obfuscation mechanism, documented in Section
5.2 of [RFC5425].
The reference to 5425 seems wrong.
5.1.1.1
... Non-TLS connections should not be used for new TACACS+ deployments.
Maybe SHOULD NOT?
... It is NOT RECOMMENDED to deploy TACACS+ wi
I think this should be a MUST NOT
5.1.5
... If TLS Encrypted Client Hello becomes standardized and applicable
to TLS 1.3, then it SHOULD be included in Secure TACACS+ implementation.
I think it's safe to leave that for any TLS spec. I'm not sure why it would
be added to an application specification.
5.3
This is all good text, but I think the general attitude has been to avoid
STARTTLS for many years. This document could just define TLS, and ignore any
issues of STARTTLS.
i..e. is it important to an implementor to explain why STARTTLS is not used?
If not, then the text is not necessary.
... perhaps using separate servers for Non-TLS connections and TLS.
"separate servers" means different IPs? Different ports? They're already
using different ports.
6.
... it is useful for the impatient to direct particular attention to Sec
perhaps use text of "short summary" instead of "impatient"
Perhaps also discuss issues of IP address filtering? If the client has
correct TLS credentials, does it really matter what IP it comes from?
i.e. will the move to TLS still have servers identify clients by IP address?
Servers could also be configured to limit connections by source IP, as an
additional layer of security.
Alan DeKok.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
