Re: [OPSAWG] Alexey Melnikov's Discuss on draft-ietf-opsawg-tacacs-13: (with DISCUSS and COMMENT)

[Warren Kumari <[e-mail]>]

On Thu, Feb 13, 2020 at 10:49 AM Alexey Melnikov <[e-mail]> wrote:
>
> Hi Warren,
> I am getting to the bottom of my ToDo list, so I should be getting to this soon.

Any updates? Your DISCUSS is from 2019-05-16 for version -13, and the
document is now at version -17.

I'd dearly love to get this shipped,
W


>
> 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)
> > <dcmgash=[e-mail]> 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
> > > [e-mail]
> > > 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
> >



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