----- Original Message ----- From: "Douglas Gash (dcmgash)" <[email protected]> To: <[email protected]> Sent: Sunday, October 28, 2018 8:35 AM > > Hi Tom, > > Many thanks for your comments. Most will be resolved simply in next upload as a matter of course (see below), but would be good to clarify one point: > > 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. > Do you mean for allocation of port 49?
Yes, that is what I had in mind. I notice that IANA also has a reference to TACACS-DS which is not something I am familiar with. Tom Petch > > > > > > General summary of other comments > > s.1 > /Although TACACS+ defines all three, but an/ > Although TACACS+ defines all three, an/ > Corrected typo. > > s.4.4.3 > /In the case of PALL, FAIL or ERROR,/ > In the case of PASS, FAIL or ERROR, > Corrected typo. > > RFC4291 is referenced but is not in the References > Added Reference. > > 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. > Agreed, will detail the applicability of that attribute. > > 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) > Agreed. > > > s.1 'It does not cover deployment or best practices.' > seems at odds with > ' 9.5. TACACS+ Best Practices ' > Agreed, will remove the para in section, now that the doc ventures into this territory. > > > I see Normative language - MUST - but no reference to RFC2119 etc > Added Reference > > 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 > Fixed reference > > 'as mentioned in the recommendations section.' > a reference would help, perhaps 9.5.2 > Added reference > > 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. > So use of a dedicated network was included up until version 10, but this was replaced after discussion with: > > “TACACS+ MUST be deployed over networks which ensure privacy and integrity of the. TACACS+ MUST be used within a secure deployment. Failure to do so will impact overall network security.” > > I agree this is a little bland. We will re-introduce into the doc the more concrete option of the distinct management network, which is the main wy this is done in the field. but the intention is to follow up this document with a version specifying TLS extensions. > > 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. > I think that it might be too rigid to specify a complexity policy in detail, certainly it would be good to mention that one should be used, Updated document. > > > s.9.5.3 > ' To allow TACACS+ administraots to ...' > Fixed grammar. > > > 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. > TBD > > Tom Petch > > > > > > > > > > > > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
