Hi Alan,
Many thanks for your feedback, as ever, we appreciate your valuable time and
insights. We have added your comments as issues for tracking and resolution in
the next version.
Please see inline for some initial response:
From: Alan DeKok <al...@deployingradius.com>
Date: Friday, 29 December 2023 at 01:15
To: Douglas Gash (dcmgash) <dcmg...@cisco.com>
Cc: opsawg@ietf.org <opsawg@ietf.org>, John Heasly <h...@shrubbery.net>, Andrej
Ota <and...@ota.si>
Subject: Re: [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)
On Dec 22, 2023, at 11:53 AM, Douglas Gash (dcmgash)
<dcmgash=40cisco....@dmarc.ietf.org> wrote:
> Some brief notes regarding the broader topics raised in v3, all items of
> course, are open for re-aligning as the group sees fit.
>
> • Regarding the allocation of a specific port, a key motivation
> concerns the pervasive use of default ports in current configurations.
> Ensuring the client implementations work correctly with default ports now TLS
> is introduced, to minimise burden for operators whilst avoiding wrinkles with
> downgrade attacks does require said new default port to be allocated, and we
> will explicitly mention this in a new section in the new doc. We hope this
> should help account for our request for an allocated port.
I think it's reasonable to allow use of the old port. I would add a section
explaining why this choice was made. Perhaps also adding some text on how
packet inspection systems / firewalls can distinguish the two protocols over
the same port.
For example, it may be useful for firewalls to allow TACACS+ traffic, but
only if it's encrypted.
The non-TLS TACAC+ connections have the first octet as 0xc0 or 0xc1, and the
second octet is 0x01, 0x02, or 0x03. Whereas TLS begins with a TLS handshake
0x16, followed by the TLS major version 0x03.
I think it would be sufficient to just check the first octet. If it's 0xc0
... 0xcf, it's unlikely to be TLS and could be blocked. Those values are
unassigned in the TLS ContentType registry, and are likely to remain unassigned
for the foreseeable future.
I suspect that by the time those values are assigned for TLS ContentType, all
uses of non-TLS TACACS+ would be long deprecated.
One of the main factors we have in mind regarding config the Secured T+
deployment, including port recommendations, is to try to do whatever we can to
prevent unintended accidental mixing of secured and unsecured T+ traffic during
migration of fleets of client devices, likely from different vendors with
potentially different handling of default ports. In that context, we though a
separate well defined port would offer advantages over re-using the original. A
deployment can always override the defaults to get around a local challenge,
but it wouldn’t be recommended.
> • RFC9325 does look a timely reference, and we have tried to delegate
> what we can from the new TACACS+ doc to it.
> • Tracking the discussion on the deprecation of obfuscation option
> inside TLS, our current reading is that:
> • All TLS traffic must NOT use obfuscation.
I would phrase that as "TACACS+ application data sent inside of a TLS tunnel
MUST NOT use obfuscation".
> • Setting the non-obfuscation option (TACACS has a flag for
> unencrypted) is mandatory for all TLS TACACS+ traffic.
Yes.
> • The aim is to avoid any ambiguity and to remove MD5
> operations from this level of the protocol.
It would be good to give some explanation as to why MD5 is being removed.
Issue Tracking #14
In the document we say merely: “The MD5 Obfuscation specified in the original
protocol definition is not fit for purpose,”
We’ll provide some reference as to why.
> • We hope we have addressed the raised issues nits and ambiguities.
It's looking good.
Some additional nits on the new version:
* Section 2
I would suggest some modifications to the terms. Perhaps:
Historic TACACS+: as defined in RFC 8907
The intention here is to say also that it's not just "TACACS+ without TLS",
but it's *historic* and should not be used.
TACACS+TLS: TLS transport with TACACS+ as the application data
Issue Tracking #15 "Terms Cleanup"
Agreed
* Section 3
Perhaps "TACACS+ over TLS" instead of "TLS for TACACS+" ?
Added to Issue Tracking #15 "Terms Cleanup"
I don't think it's necessary for the first paragraph to re-explain how TACAC+
connections work.
Perhaps also explain that TACACS+TLS is little more than a TLS wrapper around
un-obfuscated TLS. i.e. could it be implemented simply with stunnel + a
historic TLS client/server?
Issue Tracking #16
We will rationalise the summary on T+, there are some restrictions on using a
pure old server. Will clarify.
* Section 3.1
Perhaps explain why the same port is being (or could be) used.
Well, as discussed above, we may have a divergence here 😉 What we actually say
in the doc is: “where a different well-known system TCP/IP port is
assigned by IANA,” so we do specify a different port. So I think we’d rather
explain why a different port should be used. LMK if we have a conflict that
requires resolution here, after we close that, I’ll raise appropriate ticket.
"Therefore, TLS Hello MUST be initiated ..."
What's a "Hello" ? Perhaps just say instead that the connection begins with
TLS, and leave it at that.
"This document favors the predictable use of TLS security for a deployment"
I'm not sure what that means. Maybe "prefers" or "mandates" the use of TLS?
I find the phrasing to be confusing.
Issue Tracking #17
Agreed.
* Section 3.2.2
It may be useful to move the TLS-PSK discussion from 5.1.3 to here.
Though the RADEXT WG recently went through a long process of defining TLS-PSK
for RADIUS. It wasn't trivial. See
https://datatracker.ietf.org/doc/draft-ietf-radext-tls-psk/
If the document is going to say "TLS-PSK is possible" but nothing more, then
I would suggest just forbidding it. There are a lot of details to get right
with TLS-PSK.
Issue Tracking #18
Thanks for the reference, we will attempt digestion the doc you kindly referred
to, and optimise the doc structure to incorporate the elements we can extract.
* Section 3.4
ALPN needs to have ALPN strings defined. There's a similar (and long)
discussion in https://datatracker.ietf.org/doc/draft-ietf-radext-radiusv11/
TACACS+TLS doesn't need that level of complexity. The RADEXT document is
trying to be compatible with historic RADIUS, which is hard. So it's a good
idea to require the use of ALPN now.
Perhaps for TACACS+TLS, just say that the client and server MUST use a
particular ALPN string. Maybe "tacacs+/12.1", which could mean both 12.0 and
12.1 versions of TACACS+,
Agreed. The doc is written on the assumption that we will negotiate a String
(just like with the new port).
Over all, I'd like to see more content in the document. Right now it outlines
how TACACS+TLS should work, but gives very little guidance to implementors or
operators. I'd suggest reading the RADEXT TLS-PSK and ALPN documents linked
above. They go into exhaustive detail about how every little bit is supposed
to work. I've found that documenting the protocol in such detail greatly
improves the quality of the implementations, and is more likely to result in
interoperation between the implementations.
We’ll Absorb that doc. I would prefer to defer raising an issue for tracking of
the doc until we can determine the specifics to fix, and will forward details
of the specific issues when we get there.
Regarding the TLS specifications and crypto choices, we have attempted as far
as possible to defer to actual TLS specs docs and TLS best practices docs, such
as RFC 9325. We have tried to restrict details of T+ to RFC8907, unless changes
are required.
However, we do believe it is essential to help implementors and operators as
much as we can at this point and will certainly be keen to leverage your
experience with the docs you mention.
Many thanks as ever, please LMK on any of the answers above and regarding our
potential divergence of our intent to recommend a different port.
Best Regards,
The Authors.
Alan DeKok.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
