Tue, Apr 05, 2022 at 05:15:21PM -0400, Alan DeKok: > This is a quick review based on first impressions.
Hi. Thanks for the cursory review and again for your comments prior to submission. I'll try to address your remaining points. > It may be good to have a note that the existing TACACS+ port can be used > for TLS, if both ends are configured to require TLS. That means systems can > use existing firewall rules, etc. for TACACS+TLS. We discussed this and question whether this needs to be discussed in the (any) document, because it is not unlike any other service, which may be configured by the admin to use any port they wish. We also question if suggesting the use of 49/tcp will incite its use and therefore the pitfalls described in S8.2?. > Section 3.2 says: > > the resumption ticket_lifetime SHOULD be configurable, including a zero > seconds lifetime. > > I'm not sure what a "zero-seconds lifetime" would mean. It may be better > to just omit the ticket in that case. It means discard the ticket. See rfc 8446 S4.6.1. If I (not speaking for the other authors) understand the TLS 1.3 spec correctly, it might not be possible to omit the ticket. Also, IIRC, we discussed resumption in the context of an anycast or load-balanced deployment, where there is no guarantee that the same physical server would answer a request and there is no standard mechanism to distribute tickets among servers, so both client and server likely want the option to disable tickets. An attempt by a client to resume with a server that does not have the given ticket can recover, but it takes time. We also had a concern about 0-RTT, which we mention in S8.1.2. I think that 0-RTT is only possible with resumption - no ticket, no resumption, and either side could enforce that. Tell me if I'm wrong. Else, if adopted, we would ask one of the TLS experts to review and expect that they can help address resumption tickets and 0-RTT. Russ Housley had made many helpful comments prior to adding these text to the draft, but we have not yet asked that he review it again. > It would be good to mention that TLS Server Name Indication (SNI) SHOULD be > supported (https://datatracker.ietf.org/doc/html/rfc6066#section-3). That > way one server can act as the TACACS+ host for multiple domains, and switch > between them using SNI. > We had discussed this in the same context prior to submission. We concluded it was not necessary, and that less (text) is more. I believe that data in tacacs itself can be used to achieve this too. We are not opposed to adding it and suspect there is some utility we are missing. We'd like more input and if there is interest, add it after adoption. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
