Thu, Jun 30, 2022 at 03:05:33PM +0000, Joe Clarke (jclarke): > See below. > > > > Section 3.2 > > > > You make reference to the proper "TACACS+ Session", but there is no > > reference either in your terminology section or to the T+ RFC. I feel a > > reference is needed here. > > This is defined in rfc8907 S3.5 and S2 of the draft refers to 8907 S3. Is > this not an acceptable way to do this? > > [JC] It struck me as warranting a 2.x sub-section.
Do you mean repeat the definitions or have a subsection saying X, Y, Z defs are from 8907 S3? We were trying to avoid duplication. > > Section 4 > > > > "The TACACS+ server or client receiving TACACS+ Packets MUST process > > the packet as if TAC_PLUS_UNENCRYPTED_FLAG was set. The actual value > > of TAC_PLUS_UNENCRYPTED_FLAG flag in the TACACS+ header MUST be > > ignored." > > > > But what if the flag isn’t set and obfuscation is used? That’s an error, > > and MUST result in the termination of the Session (at least that’s what I > > would think). This should be clarified, > > The sections says that the flag MUST be ignored on receipt and SHOULD set > on transmission. I will attempt to make it clearer. > > This seems like a common way to deprecate a flag. Do you still think that > the unset flag on receipt should be an error? > > [JC] I personally do as it could be that obfuscation is being done and this > will ultimately lead to the inability to process the PDU. That said, I’m > more in favor of a strong obsolescence of the obfuscation. ok. > > Overall, I think this document warrants an Operators Considerations section > > to describe interoperability with legacy T+. That is, thoughts around > > configuring a fallback legacy T+ server along side a tacacss server (or > > servers); thoughts on migrating from a shared key to certificate-based > > validation; etc. > > > > You address some of this in different parts of the document where you talk > > about PSKs, mixing legacy and tacacss on a single server, and the need to > > provide some port flexibility, but I think a centralized section might help > > bring focus to those migrating to this. > > Sure, completely reasonable. But I don't want to expend that effort unless > this will be adopted. Seems like that could lead to quite a bit of > rearrangement. > > > Additionally, if there are working or PoC implementations of this, some > > lessons learned (perhaps in an appendix) could be useful. > > There are none that I know of. I would not make that effort unless there is > adoption or at least a commitment to adopt the draft. > > [JC] As chair, I will call for adoption of this work by the WG. I read > Alan’s recent reply and understand how he feels concerning this approach to > more of a straight TLS encap around T+. I would like to hear what others in > the WG think.</chair> Speaking for myself only; I might have misunderstood this point of Alan's and will have to review that email. I think that the approach is straight-forward; start tls, once established, start tacacs, tacacs, end tacacs, end tls. How much easier could it be. We did specify a few TLS constraints, that Alan questioned. We're open to discussing those details, but I think we need input from more tls experts and believe this can occur after adoption. IIRC, that was our response at the beginning of May when the composite draft was submitted. Prost _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
