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

["Douglas Gash (dcmgash)" <[e-mail]>]

Many thanks for the comments.

Please see responses from authors inline, marked “TA”. Action items from this mail to update the document are marked: [AI-TA] to mean: “action item for the authors”.

On 16/05/2019, 7:21, "Alexey Melnikov via Datatracker" <[e-mail]> wrote:

    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.

TA> Agreed,  will update as advised  [AI-TA]
    
       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]
       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]

    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> We’d be grateful if you could clarify, is your concern here relating to the charset or the  content? If it regards the content then this is not constrained, as below it is client specific. The servicer must accommodate the free-format content.
    
       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]
    
       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]
    
    5) KRB5 and KRB4 need normative references.
TA> Agreed, will add [AI-TA]
    
    6) Does this document need to obsolete RFC 1492?
TA> That could well be sensible, would follow WG consensus here.
    
    ----------------------------------------------------------------------
    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]
    
    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]
       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]

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

    
    Later in the same section:
    
       remote_host (String)
    
    What is the syntax of this field?
TA>  Will elaborate.  [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]
    
          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]
    
    10.5.3.  Authentication
    
       To help TACACS+ administraots select the stronger authentication
    
    Typo: administrators.
TA> Thanks, will correct. [AI-TA]