On May 3, 2022, at 12:23 AM, heasley <[email protected]> wrote: >> 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.
The point is to suggest that it can be done. i.e. It's acceptable for people to manually configure both client and server as both (a) TLS, and (b) using port 49. i.e. just drop the use of legacy TACACS+ entirely. > We also question if suggesting the use of 49/tcp will incite its use and > therefore the pitfalls described in S8.2?. Allowing a new port just for TLS is fine, too. But I do agree that STARTTLS is not useful. >> 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. It's possible for tickets to be omitted. We checked this in EMU with EAP updates for TLS 1.3. > 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. TLS allows for session tickets with opaque data, under the control of the server. So the session ticket can be encrypted with a key shared by multiple servers. Which means load balancing, etc. works just fine with session resumption. This was checked when we did the updates for EMU. > 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. OK. > 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. That's likely not necessary. EMU checked that. >> 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. I would say that adding SNI has large value, and only small downsides. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
