Re: [OPSAWG] Alexey Melnikov's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
Hi Douglas, On Mon, Jan 27, 2020, at 8:28 PM, Douglas Gash (dcmgash) wrote: > 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] Please add Informative references for them then. If I decide to implement TACACS+ and don't know anything about Kerberos, I wouldn't know where to look. All your other changes are either good or I can at least live with them. Best Regards, Alexey ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Alexey Melnikov's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
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 > RFC, 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=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) > 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
[OPSAWG] Alexey Melnikov's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-opsawg-tacacs-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ -- DISCUSS: -- (One small addition to my earlier comments, see new DISCUSS point 6) I appreciate that this is documenting an existing protocol and I am very glad that it is being documented. However there are several things which are still not documented well enough/not in enough details to implement. So I would like to discuss these issues before recommending approval of this document: 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. 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. 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). 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? 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? 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? 5) KRB5 and KRB4 need normative references. 6) Does this document need to obsolete RFC 1492? -- 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. 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. 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? 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. In 8.2
[OPSAWG] Alexey Melnikov's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-opsawg-tacacs-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ -- DISCUSS: -- I appreciate that this is documenting an existing protocol and I am very glad that it is being documented. However there are several things which are still not documented well enough/not in enough details to implement. So I would like to discuss these issues before recommending approval of this document: 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. 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. 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). 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? 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? 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? 5) KRB5 and KRB4 need normative references. -- 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. 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. 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? 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. In 8.2: 8.2. Authorization Attributes For example: "shell", "tty-server", "connection", &quo
[OPSAWG] Alexey Melnikov's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-opsawg-mud-20: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ -- COMMENT: -- 3.6. systeminfo This is a textual UTF-8 description of the Thing to be connected. The intent is for administrators to be able to see a localized name associated with the Thing. systeminfo is provided by the manufacturer (or whoever generated the MUD file), right? Why would it be *localized* for the administrator? Think of a manufacturer from China and a sysadmin in Russia. 3.13. controller This URI specifies a value that a controller will register with the MUD controller. The node then is expanded to the set of hosts that are so registered. This node may also be a URN. In this case, the URN describes a well known service, such as DNS or NTP. You don't list the DNS/NTP URNs until much later in the document. Please either add a forward reference or list them here. As per response from Eliot, my earlier comments should have been addressed in editor's copy: 16.4. MIME Media-type Registration for MUD files The following media-type is defined for transfer of MUD file: o Type name: application o Subtype name: mud+json o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; application/mud+json values are represented as a JSON object; UTF-8 encoding SHOULD be employed. I am tempted to say "MUST be UTF-8 encoded". o Security considerations: See Security Considerations of this document. o Interoperability considerations: n/a o Published specification: this document Nit: IANA Media Type registration templates need to have fully qualified references. Use "[RFC]" instead of "this document" here, so that when the RFC is published, the registration template can be posted to IANA website and will have correct reference. o Applications that use this media type: MUD controllers as specified by this document. As above. o Fragment identifier considerations: n/a o Additional information: Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a o Person & email address to contact for further information: Eliot Lear <l...@cisco.com>, Ralph Droms <rdr...@cisco.com> I think Ralph's address is wrong in 2 places. o Intended usage: COMMON o Restrictions on usage: none o Author: Eliot Lear <l...@cisco.com> Ralph Droms <rdr...@cisco.com> o Change controller: IESG o Provisional registration? (standards tree only): No. UTF-8 needs to be a Normative reference (RFC 3629). ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Alexey Melnikov's No Record on draft-ietf-opsawg-mud-20: (with COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-opsawg-mud-20: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ -- COMMENT: -- I've only reviewed a part of the document, so sending you my current comments: 16.4. MIME Media-type Registration for MUD files The following media-type is defined for transfer of MUD file: o Type name: application o Subtype name: mud+json o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; application/mud+json values are represented as a JSON object; UTF-8 encoding SHOULD be employed. I am tempted to say "MUST be UTF-8 encoded". o Security considerations: See Security Considerations of this document. o Interoperability considerations: n/a o Published specification: this document Nit: IANA Media Type registration templates need to have fully qualified references. Use "[RFC]" instead of "this document" here, so that when the RFC is published, the registration template can be posted to IANA website and will have correct reference. o Applications that use this media type: MUD controllers as specified by this document. As above. o Fragment identifier considerations: n/a o Additional information: Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a o Person & email address to contact for further information: Eliot Lear <l...@cisco.com>, Ralph Droms <rdr...@cisco.com> I think Ralph's address is wrong in 2 places. o Intended usage: COMMON o Restrictions on usage: none o Author: Eliot Lear <l...@cisco.com> Ralph Droms <rdr...@cisco.com> o Change controller: IESG o Provisional registration? (standards tree only): No. UTF-8 needs to be a Normative reference (RFC 3629). ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Alexey Melnikov's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
Alexey Melnikov has entered the following ballot position for draft-mm-wg-effect-encrypt-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ -- COMMENT: -- This document is not perfect, but I found it to be generally useful. This version is much improved. When you talk about logging, maybe mentioning "protocol trace logging" or "PDU logging" as a useful tool for troubleshooting that can be provided by both client and server endpoints? DMARC (RFC 7489) should probably be mentioned in Section 5.1 where you mention ARF. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
