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

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

 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)."