Some additional stray thoughts s.1 /Although TACACS+ defines all three, but an/ Although TACACS+ defines all three, an/
s.4.4.3 /In the case of PALL, FAIL or ERROR,/ In the case of PASS, FAIL or ERROR, RFC4291 is referenced but is not in the References s.7.2 IPv6 gets a passing mention but Values MUST be of the form "<dst_address> <mask> [<routing_addr>]". does not really cater for IPv6. s.7.3 The timezone abbreviation for all timestamps included in this packet. I would like to see a reference here - I do not think that there is currently one accepted abbreviation for timezones (e.g. see RFC4833, RFC7808) Tom Petch ----- Original Message ----- From: "t.petch" <[email protected]> Sent: Tuesday, October 09, 2018 11:00 AM > Stray thoughts > > s.1 'It does not cover deployment or best practices.' > seems at odds with > ' 9.5. TACACS+ Best Practices ' > > I see Normative language - MUST - but no reference to RFC2119 etc > > References are not split between Normative and Informative > > s.9 > > 'The original TACACS+ Draft[1]' > looks like a reference but there is no [1] in the refernces > > 'as mentioned in the recommendations section.' > a reference would help, perhaps 9.5.2 > > s.9.2 > ' Authentication sessions SHOULD be used via a secure transport ' > worth mentioning what transport you have in mind? I first think of TLS > but SSH might be more suitable. > > s.9.5.1 > references to lengths of character strings used for shared keys seems to > me incomplete without specifying the character set. Most systems I use > require me to include uppercase, digit, lowercase and punctuation, since > this makes dictionary and brute force attacks harder. I don't know of > an RFC that goes into this but then few current RFC talk of character > strings for shared keys. > > s.9.5.3 > ' To allow TACACS+ administraots to ...' > > I did wonder if TACACS had ever impinged on IANA and so would this I-D > become a reference but as far as I can see, it never did. > > Tom Petch > > > ----- Original Message ----- > From: "Joe Clarke" <[email protected]> > To: <[email protected]> > Sent: Friday, October 05, 2018 5:23 PM > > > With revision -11 of this document that addresses some of the security > > concerns that have arisen, and with a number of vendors chiming in on > > how their implementation conforms to what is described, it's time for > a > > WGLC. > > > > Again, the purpose of this document is to describe the TACACS+ > protocol > > as it is today. As such this is an informational draft. While not > > setting forth a proposed standard, the document does attempt to > > recommend some security measures to mitigate the inherent insecurity > in > > TACACS+ today. > > > > As part of the WGLC, please comment on the substance of the document > as > > well as any known deviations with existing implementations. > > > > This WGLC will last three weeks and will conclude on October 26. > > > > Joe (on behalf of the co-chairs) > > > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
