mixing TLS and non-TLS

[haussli]

The recent changes to the organisation & text have perverted this warning about mixing TLS and non-TLS connections, IMO.

This text
" In order to prevent downgrade attacks, Servers SHOULD keep separate and disjoint lists of clients supporting TLS and Unsecure Connections."

Is this conflating the warning about mixing TLS & non-TLS on clients and servers with the warning about the pitfalls of the servers or clients maintaining a learned list of clients/servers that support (or do not support) TLS[1]. Instead, it should just say that oil and water do not mix.

Perhaps it should be rewritten roughly as
" In order to prevent downgrade attacks, Servers SHOULD NOT offer both TLS and non-TLS connections on the same server [intentionally not capitalised; meaning "host"] and Clients should not configure both TLS and non-TLS Servers."

Later, the "lists" term is used in this text
"When Migrating from legacy service to TLS, any mixture of Unsecure Connected Servers and TLS-Protected Servers in the same redundant lists on clients SHOULD be minimised." and
" After migration, the production deployment SHOULD NOT mix Legacy and TLS-Protected Servers within Server lists configured on clients."

So, perhaps the previous use of the term "lists" is not referring to the warning about "learned lists". Either way, "lists" seems to be too vague. I do not have a good suggestion to make it clearer ATM.

[1] removed text was: "Servers and Clients could maintain a cache of Peers that have engaged in TACACS+ TLS connections and demand TLS from that point forward. ...."

[dcmgashcisco]

Agreed, the term "List" is too vague, and used in two different contexts that may cause confusion. I'll look to eliminate this.

The approach I'd have in mind is the following, LMK if this covers your concerns.

1. In the field for non-TLS currently, A TACACS+ Client always defines a TACACS+ Server with both an Address and a Port. AFAIK, no TACACS+ server in the field listens on all ports. By default, for Non TLS, we use port 49, so it is legitimate (though I think not recommended) for a client to specify just an IP address and then the default port 49 would be assumed, but we can say that this is still an implicit server port config.

2. I think for TLS we can mandate the same, but make it more explicit. A TACACS+ Server for TLS is defined by both the address and port. So the server 10.1.1.34:490 is not the same TACACS+ server as 10.1.1.34:49

3. A TACACS+ Server (i.e. the Address:port combination ) MUST not support both TLS and non-TLS. This is the sensible approach. I had in mind that we might want to support migration on one IP/Port combo and hence the need for a list to ensure that a client could not use both during migration, but could use the same server, this is not worthwhile and I'll withdraw that. That will eliminate one of the "lists".

4. On the same vein, as a T+ Server (Address:port combination) cannot support TLS and non TLS, then the learned lists would not be needed (which is good as this state is not something that I'd like to encouraged)

5. This still leaves the question: can multiple T+ Servers on the same address (but different ports) have a mixture of TLS and non TLS, with the thought that it can it lead to a downgrade attack. With the above mandate that a TACACS+ server must be specified with address and port, and each address:port combination cannot mix traffic types, then I'm not quite sure how it could be a downgrade attack any more than having a TLS and non TLS on different addresses.

So, I'd propose:

1. I'll tighten up the definition of a T+ Server instnce to indicate its defintion requires both address and port
2. define that a T+ Server can support TLS or non TLS, but not both
3. remove " In order to prevent downgrade attacks, Servers SHOULD keep separate and disjoint lists of clients supporting TLS and Unsecure Connections."
4. tidy up the migration part based on 1-3.

Regarding the downgrade attack, I will re-add that, if we think it is still relevant with the above proposal. Please LMK if you think it is.