Re: [OPSAWG] Adam Roach'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:04, "Adam Roach via Datatracker" <[e-mail]> wrote:

    Adam Roach 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:
    ----------------------------------------------------------------------
    
    Thanks to everyone who has worked on documenting the TACACS+ protocol
    as it is used today.
    
    I understand the desire to publish this document as a status other than
    Historic, as the protocol remains in use today. However, the shortcomings
    cited in the "Security Considerations" section are quite profound, and
    really bear highlighting in the document way before we get into what is
    fundamentally end material.
    
    I have serious misgivings about publishing this document as anything
    other than Historic without some prominent text early in the document
    (e.g., in the Introduction section) that warns implementors of the
    several caveats detailed in section 10 and its subsections. They don't
    need to be explained here, but some language along the lines of the
    following really needs to be present in order to scope the document:
    
       Note that the original TACACS+ implementations did not address all of the
       baseline security concerns which are considered when designing modern
       protocols.  This document does not change this situation, and implementors
       should use caution when evaluating the suitability of TACACS+ for any given
       use.  Please see section 10 for additional details.

TA> Yes, there have been some comments  in this round about bring such warnings to the front of  the document, will action that.  [AI-TA]
    
    ---------------------------------------------------------------------------
    
    §4.6:
    
    >  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
    >  encodings outside printable US-ASCII SHOULD be deprecated.
    
    Without specification of preparation profiles for usernames and passwords,
    this is an incomplete specification of how to transmit non-ASCII
    usernames and passwords. While there are other solutions, the easy
    way to address this is to normatively reference RFC 7613, and select
    one of its username preparation profiles, and indicate its password
    preparation profile.
    
    The most basic problem here is that I might create a username and/or password
    on a machine that uses one mapping for a non-ASCII character, and later try to
    log in on a machine that uses a different, but semantically equivalent,
    mapping for that same character. This is a clear interop issue.

TA> Thanks, the suggestion to reference RFC 7613 looks very sensible, we will look to take advantage of that work  [AI-TA]
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    
    ID Nits reports:
    
      ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994)
 TA> Agreed, will update [AI-TA]
    ---------------------------------------------------------------------------
    
    §2:
    
    >  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    >  document are to be interpreted as described in RFC 2119 RFC2119
    >  [RFC2119].
    
    Please use the boilerplate from RFC 8174.
TA> Agreed, will update [AI-TA]
    ---------------------------------------------------------------------------
    
    §4.3:
    
    >  The packet header contains the TAC_PLUS_SINGLE_CONNECT_FLAG used by
    >  the client and server to negotiate the use of Single Connect Mode.
    
    This is a bit jarring, as the document hasn't yet established the existence
    of a packet header, or of flag in that header. It might be better to pull
    section 4.8 earlier in the document -- at least before this sentence --
    so that readers have some context for understanding what's going on.
TA> Agreed, will revise this section [AI-TA]
    ---------------------------------------------------------------------------
    
    §4.7:
    
    >  Server implementations MUST allow a unique secret key to be
    >  associated with every client.
    
    Nit: "...with each client."
TA> Agreed, will update [AI-TA]
    ---------------------------------------------------------------------------
    
    §5.1:
    
    >  network address if the user is connected via a network, a caller ID
    >  is the user is connected via ISDN or a POTS
    
    Nit: "...if the user..."
TA> Agreed, will update [AI-TA]
    ---------------------------------------------------------------------------
    
    §5.4.2.1:
    
    Is the intention here to limit the characters in the user name and the
    password to be only those in the ASCII range? Section 4.6 would seem to
    indicate that this isn't the case, but the title of this section throws
    that into doubt. If the text in 4.6 is the guiding text here, perhaps
    section 5.4.2.1 should indicate that the term "ASCII" is used only for
    historical reasons, and that both usernames and passwords can contain
    UTF-8-encoded character strings.
TA> Agreed, this is ambiguous, will clarify.[AI-TA]
    ---------------------------------------------------------------------------
    
    §5.4.2.2:
    
    >  the data
    >  field MUST contain the PAP ASCII password.
    
    Same comment as for section 5.4.2.1, above.
TA> As above  [AI-TA]
    ---------------------------------------------------------------------------
    
    §5.4.2.3:
    
    >  defined in the PPP Authentication RFC RFC 1334 [RFC1334] and then
    >  compare that value with the response.
    
    Nit: "...and then compares..."
TA> Agreed, will update [AI-TA]    
    ---------------------------------------------------------------------------
    
    §5.4.2.7.  ASCII change password request
    
    Same comment as for section 5.4.2.1.
TA>Agreed, As above  [AI-TA]    
    ---------------------------------------------------------------------------
    
    §5.4.3:
    
    >  If this
    >  flag is set, the data portion of the message may contain an ASCII
    >  message explaining the reason for the abort.
    
    Does this mean "ASCII" or does it mean "UTF-8"? If it actually means
    "ASCII," then localization -- especially to localities that use
    non-latin-based alphabets -- will be incredibly challenging.
TA> It is a good point, the original spec will cause  problems for localization. We have a decision to either continue the backward compatibility with original draft, or to call out that localization is not possible, will work with WG to find a consensus path. [AI-TA]  
    ---------------------------------------------------------------------------
    
    §6.2 and §7.2:
    
    >  server_msg, server_msg_len
    >
    >  This is a printable US-ASCII string that may be presented to the
    >  user.
    >
    >  data, data_len
    >
    >  This is a printable US-ASCII string that may be presented on an
    >  administrative display, console or log
    
    Same comment as for section 5.4.3.
TA>Agreed, As above  [AI-TA]       
    ---------------------------------------------------------------------------
    
    §8.1:
    
    >  All attribute values are encoded as printable US-ASCII strings.  The
    >  following type representations SHOULD be followed
    ...
    >  String
    >
    >  Many values have no specific type representation and so are
    >  interpreted as plain strings.
    
    Same comment as for section 5.4.3.
 TA>Agreed, As above  [AI-TA]       
    ---------------------------------------------------------------------------
    
    §8.3:
    
    >  err_msg (String)
    >
    >  A printable US-ASCII string describing the status of the action.
    
    Same comment as for section 5.4.3.
TA>Agreed, As above  [AI-TA]           
    ---------------------------------------------------------------------------
    
    §10.5.3:
    
    >  To help TACACS+ administraots select the stronger authentication
    
    Nit: "...administrators..."
 TA> Agreed, will update [AI-TA]       
    ---------------------------------------------------------------------------