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?
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
