Hi Warren, I am getting to the bottom of my ToDo list, so I should be getting to this soon.
Best Regards, Alexey On Thu, Feb 6, 2020, at 4:04 PM, Warren Kumari wrote: > Hey Alexey, > > I recently took over this document from Igans - it has been stuck in > 'IESG Evaluation::AD Followup' for 266 days (at version -13). > This is an informational document, describing an existing, and widely > deployed protocol -- the intent was that, once this is published, > there would be a new document largely saying "... great, now take > RFCxxxx, and throw it over TLS. Done!" (as you can guess, there is > much history here as to why it had to happen in two documents instead > of one :-)) > > The authors have made significant updates > (https://www.ietf.org/rfcdiff?url1=draft-ietf-opsawg-tacacs-13&url2=draft-ietf-opsawg-tacacs-16), > and believe that they have now addressed all open comments. > > I'd really like to get this document out the door soon - would you > mind prioritizing checking if these changes address your concerns? > W > > On Mon, Jan 27, 2020 at 3:28 PM Douglas Gash (dcmgash) > <[email protected]> wrote: > > > > Hi, > > > > I hope that in the last few versions we have updated the document to > > sufficiently answer the concerns raised, please let me know if any concerns > > remain, many thanks. > > > > The majority of the issues were responded to initially last summer, but the > > balance should be by the latest version recently uploaded. > > > > Please see the point-by point descriptions of changes or responses. > > > > Many thanks, > > > > > > 1) 4.6. Text Encoding > > > > All text fields in TACACS+ MUST be printable US-ASCII, excepting > > > > Please add a reference to RFC 20 (for US-ASCII) here. Without out it > > "printable" has no meaning. > > > > TA> Agreed, will update as advised [AI=TA] > > > > Specifically: > > > > "3.7. Treatment of Text Strings > > > > The TACACS+ protocol makes extensive use of text strings. The > > original draft intended that these strings would be treated as byte > > arrays where each byte would represent a US-ASCII character. > > > > More recently, server implementations have been extended to interwork > > with external identity services, and so a more nuanced approach is > > needed. Usernames MUST be encoded and handled using the > > UsernameCasePreserved Profile specified in RFC 8265 [RFC8265]. The > > security considerations in Section 8 of that RFC apply. > > > > Where specifically mentioned, data fields contain arrays of arbitrary > > bytes as required for protocol processing. These are not intended to > > be made visible through user interface to users. > > > > All other text fields in TACACS+ MUST be treated as printable byte > > arrays of US-ASCII as defined by RFC 20 [RFC0020]. The term > > "printable" used here means the fields MUST exclude the "Control > > Characters" defined in section 5.2 of RFC 20 [RFC0020]." > > > > > > > > special consideration given to user field and data fields used for > > passwords. > > > > To ensure interoperability of current deployments, the TACACS+ client > > and server MUST handle user fields and those data fields used for > > passwords as 8-bit octet strings. The deployment operator MUST > > ensure that consistent character encoding is applied from the end > > client to the server. The encoding SHOULD be UTF-8, and other > > > > Please add Normative RFC 3629 reference here for UTF-8. > > > > TA> Agreed, will update as advised [AI=TA] > > Specifically: Have removed all references to UTF-8. > > > > > > encodings outside printable US-ASCII SHOULD be deprecated. > > > > I am not sure what this mean. You didn't define allowed encoding > > (really you > > mean charsets). > > > > TA> Agreed, will update as advised [AI=TA] > > Specifically: removed UTF-8, pleasee see ref to sectipn 3.7 above. > > > > 2) In 5.1: > > > > The printable US-ASCII name of the client port on which the > > authentication is taking place, > > > > This doesn't mean anything. Is there a registry? It doesn't look like > > you are > > using transport service name registry for this. Is it a fixed list? > > > > TA> Please see new sectin 3.7 above. > > > > and its length in bytes. The value > > of this field is client specific. (For example, Cisco uses "tty10" > > to denote the tenth tty line and "Async10" to denote the tenth async > > interface). The port_len indicates the length of the port field, in > > bytes. > > > > 3) Later in 5.1: > > > > A printable US-ASCII string indicating the remote location from which > > the user has connected to the client. It is intended to hold a > > network address > > > > What are the allowed formats for IPv4 and IPv6? Or is this just human > > readable? > > TA> Current practice the field is normally MAC address or IP. Will > > recommend that if IP is used, it SHOULD conform to RFC5952 [AI=TA] > > Specifcially, added text: " For IPv6 address text > > representation defined please see RFC 5952 [RFC5952]." > > > > > > if the user is connected via a network, a caller ID > > is the user is connected via ISDN or a POTS, or any other remote > > location information that is available. > > > > 4) In 5.4: > > > > If the information being requested by the server form the client is > > sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO > > flag. When the client queries the user for the information, the > > response MUST NOT be echoed as it is entered. > > > > What does the last sentence mean? (When is it ever echoed?) Are you > > missing a > > forward reference or some explanation of echoing? > > > > TA> Agreed, this requires clarification in document to indicate that the > > data entered should not be reflected in the user interface. [AI=TA] > > Specifically: > > Section 5.4., paragraph 5: > > OLD: > > > > If the information being requested by the server form the client is > > sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO > > flag. When the client queries the user for the information, the > > response MUST NOT be echoed as it is entered. > > > > NEW: > > > > If the information being requested by the server form the client is > > sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO > > flag. When the client queries the user for the information, the > > response MUST NOT be reflected in the user interface as it is > > entered. > > > > > > 5) KRB5 and KRB4 need normative references. > > TA> The KRB5 and KRB4 are not specifically used in this document, rather, > > there is one field with an option that the client uses to indicate how it > > authenticated, and these are option. This is not verifiable, so it is > > recomended in the documen tnot to use this field for policy.For this > > reason, it is not really useful to provide a normative reference, but it is > > required for the document to explai this. So have added:[AI+TA] > > > > > > 6) Does this document need to obsolete RFC 1492? > > TA> That could well be sensible, would follow WG consensus here. > > After review, the differences between TACACS and TACACS+indicated that the > > protocols were sufficiently different that TACACS+ does not directly > > obsoltere plain TACACS, > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > In 4.8: > > > > 4.8. The TACACS+ Packet Header > > > > The total length of the packet body (not including the header). > > > > In network byte order? There is some text about that in 4.9, but > > readers don't > > know that yet. > > TA> Agreed, will clarify [AI=TA] > > Specifcially in 4.1: > > " The following general rules apply to all TACACS+ packet types: > > > > - To signal that any variable length data fields are unused, their > > length value is set to zero. Such fields MUST be ignored, and > > treated as if not present. > > > > - the lengths of data and message fields in a packet are specified > > by their corresponding length fields, (and are not null > > terminated.) > > > > - All length values are unsigned and in network byte order." > > > > In 6.1: > > > > The arguments are the primary elements of the authorization > > interaction. In the request packet they describe the specifics of > > the authorization that is being requested. Each argument is encoded > > in the packet as a single arg filed (arg_1... arg_N) with a > > > > Typo: filed --> field. > > TA> Thanks, will correct. [AI=TA] > > "Section 6.1., paragraph 29: > > OLD: > > > > The arguments are the primary elements of the authorization > > interaction. In the request packet they describe the specifics of > > the authorization that is being requested. Each argument is encoded > > in the packet as a single arg filed (arg_1... arg_N) with a > > corresponding length fields (which indicates the length of each > > argument in bytes). > > > > NEW: > > > > The arguments are the primary elements of the authorization > > interaction. In the request packet, they describe the specifics of > > the authorization that is being requested. Each argument is encoded > > in the packet as a single arg field (arg_1... arg_N) with a > > corresponding length fields (which indicates the length of each > > argument in bytes)." > > > > > > corresponding length fields (which indicates the length of each > > argument in bytes). > > > > Later in the same section: > > > > Optional arguments are ones that may be disregarded by either client > > or server. Mandatory arguments require that the receiving side can > > handle the attribute, that is: its implementation and configuration > > includes the details of how to act on it. If the client receives a > > mandatory argument that it cannot handle, it MUST consider the > > authorization to have failed. It is legal to send an attribute-value > > pair with a zero length value. > > > > Last sentence: do you just mean that the value can be empty? > > TA> Yes, this definition evolved, also had query about the use of the word > > “legal” in this round of review. > > Will change to “The value part of an attribute-value pair may be empty, > > that is, the length of the value may be zero.” [AI=TA] > > Specifically: > > Section 6.1., paragraph 32: > > OLD: > > > > Optional arguments are ones that may be disregarded by either client > > or server. Mandatory arguments require that the receiving side can > > handle the attribute, that is: its implementation and configuration > > includes the details of how to act on it. If the client receives a > > mandatory argument that it cannot handle, it MUST consider the > > authorization to have failed. It is legal to send an attribute-value > > pair with a zero length value. > > > > NEW: > > > > Optional arguments are ones that may be disregarded by either client > > or server. Mandatory arguments require that the receiving side can > > handle the argument, that is: its implementation and configuration > > includes the details of how to act on it. If the client receives a > > mandatory argument that it cannot handle, it MUST consider the > > authorization to have failed. The value part of an argument-value > > pair may be empty, that is: the length of the value may be zero. > > > > > > > > In 8.1: > > > > Date Time > > > > Absolute date/times are specified in seconds since the epoch, 12:00am > > Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is > > specified. Stardate is canonically inconsistent and so SHOULD NOT be > > used. > > > > I am not sure what the last sentence means. > > TA> Agree, will be removed [AI=TA] > > > > In 8.2: > > > > 8.2. Authorization Attributes > > > > For example: "shell", "tty-server", "connection", "system" and > > "firewall". This attribute MUST always be included. > > > > Is this a full list or is there a registry? > > TA> This is not a full list, it is just for example. In order to prevent > > interpretation that it is a full list, will change to [AI=TA]: > > “The primary service. Specifying a service attribute indicates that > > this is a request for authorization or accounting of that service. > > For example: "shell". This attribute MUST always be included.” > > > > Specifically: > > > > Section 8.1., paragraph 15: > > OLD: > > > > The primary service. Specifying a service attribute indicates that > > this is a request for authorization or accounting of that service. > > > > For example: "shell", "tty-server", "connection", "system" and > > "firewall". This attribute MUST always be included. > > > > NEW: > > > > The primary service. Specifying a service argument indicates that > > this is a request for authorization or accounting of that service. > > For example: "shell", "tty-server", "connection", "system" and > > "firewall", others may be chosen for the required application. This > > argument MUST always be included. > > > > > > > > Later in the same section: > > > > remote_host (String) > > > > What is the syntax of this field? > > TA> Will remove this definition. [AI=TA] > > > > 10.4. Security of Accounting Sessions > > > > Replace accounting data with new valid or garbage which prevents > > to provide distraction > > > > "prevents to provide distraction" doesn't read well. > > TA> Agreed, will attempt to translate into readable language! [AI=TA] > > Specifcially: > > "Section 10.4., paragraph 2: > > OLD: > > > > Replace accounting data with new valid or garbage which prevents > > to provide distraction or hide information related to their > > authentication and/or authorization attack attempts. > > > > NEW: > > > > Replace accounting data with new valid or garbage which can > > confuse auditors or hide information related to their > > authentication and/or authorization attack attempts. > > " > > > > or hide information related to their > > authentication and/or authorization attack attempts. > > > > In 10.5.1: > > > > TACACS+ server administrators SHOULD change secret keys at regular > > intervals. > > > > Humans are very bad at this. So I think it would be better if this is > > changed > > to add a requirement on management UIs. > > TA> That is sensible. Will discuss options with WG. [AI=TA] > > Generlised the advise for the section, i.e. added: "Vendors SHOULD provide > > mechanisms to assist the administrator to achieve these best > > practices." > > > > 10.5.3. Authentication > > > > To help TACACS+ administraots select the stronger authentication > > > > Typo: administrators. > > TA> Thanks, will correct. [AI=TA] > > Specifically: > > > > "Section 10.5.3., paragraph 1: > > OLD: > > > > To help TACACS+ administraots select the stronger authentication > > options, TACACS+ servers MUST allow the administrator to configure > > the server to only accept challenge/response options for > > authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or > > TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for > > authen_type). > > > > NEW: > > > > To help TACACS+ administrators select less weak authentication > > options, TACACS+ servers MUST allow the administrator to configure > > the server to only accept challenge/response options for > > authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or > > TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for > > authen_type)." > > > > > > _______________________________________________ > > OPSAWG mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
