Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-tacacs-13

["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 13/05/2019, 13:54, "Stewart Bryant via Datatracker" <[e-mail]> wrote:

    Reviewer: Stewart Bryant
    Review result: Almost Ready
    
    I am the assigned Gen-ART reviewer for this draft. The General Area
    Review Team (Gen-ART) reviews all IETF documents being processed
    by the IESG for the IETF Chair. Please wait for direction from your
    document shepherd or AD before posting a new version of the draft.
    
    For more information, please see the FAQ at
    
    <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
    
    Document: draft-ietf-opsawg-tacacs-13
    Reviewer: Stewart Bryant
    Review Date: 2019-05-13
    IETF LC End Date: None
    IESG Telechat date: 2019-05-16
    
    Summary:
    
    There are a number of issues called out below that need addressing before publication.
    
    Someone needs to micro-check the text to make sure that all terms are defined and referenced.
    I picked up a few, but there were a lot I did not have time to check.
    
    Major issues:
    
    SB> The IANA section should ask IANA to point to this RFC as a reference
    SB> for port 49
    
    ============
    
    
       The first MD5 hash is generated by concatenating the session_id, the
       secret key, the version number and the sequence number and then
       running MD5 over that stream.  All of those input values are
       available in the packet header, except for the secret key which is a
       shared secret between the TACACS+ client and server.
    
    SB> MD5 make a good checksum, but I am surprised to see it used in this
    SB> application in a new protocol.

TA>  Agreed, however TACACS+ is not a new protocol  (This is an informational document)
    
    =============
    
       All TACACS+ packets begin with the following 12-byte header.  The
       header describes the remainder of the packet:
    
    SB> If ever there was an error in a long term session, how
    SB> how would you find in in the following packet structure?
    SB> Presumably from an incorrect major version and sequence number?

TA> Yes, sequence number tracking is essential. But TACACS+ sessions related to single AAA operations, they  do not extend to link multiple AAA sessions to track connectivity, for example.
    
    SB> Some details on the error cases and the unconditional "safety"
    SB> of the protocol would be useful.
    
TA> There is some general discussion of ERROR conditions within  the context of connectivity and aborting a transaction  in sections  “4.4  Session Completion”  and  “4.5.  Treatment of Enumerated Protocol Values”,  and section 10  contains some coverage  of security issues, please advise if there are other areas of error cases and safety  they  would be useful to be  covered.

    ==========
    
          TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01
    
          TAC_PLUS_AUTHEN_TYPE_PAP := 0x02
    
          TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03
    
          TAC_PLUS_AUTHEN_TYPE_ARAP := 0x04 (deprecated)
    
          TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05
    
          TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06
    
    SB> There are lots of lists similar to the above.
    SB> I have not checked them all, but a number of the types 
    SB> in this and subsequent parts of the design don't seem
    SB> to be defined or have a definitive reference
    
TA> Correct, the enumerations are listed without further details where it is assumed that the values provide understood meanings. In fact for the enumerations above, the imlications have  some coverage in  section: “5.4.2.  Common Authentication Flows”

    ===========
    
     The START packet MUST contain a username and the data
       field MUST contain the PAP ASCII password.  A PAP authentication only
       consists of a username and password RFC 1334 [RFC1334] . The REPLY
       from the server MUST be either a PASS, FAIL or ERROR.
    
    SB> Should there note be a note that RFC1334 is obsolete?

TA> Agreed [AI-TA]
    
    ===========
    
    Minor issues:
    
    The use of the term "packet" as a unit of data is confusing, since the protocol
    is carried over TCP which is a streaming protocol.
    
    They are really TACAS+ PDUs
    
TA> Agreed. There is  a  definition of packet:

“   Packet

   All uses of the word packet in this document refer to TACACS+
   protocol packets unless explicitly noted otherwise.”

However, of course the doc should be updated for the  correct terminology [AI-TA]

    =========
    
    (For example, Cisco uses "tty10"
       to denote the tenth tty line and "Async10" to denote the tenth async
       interface).  
    SB> Is it correct to quote a particular vendor in an RFC of this type?
    
TA> Likely not! Agreed [AI-TA]

    ========
    
          TAC_PLUS_PRIV_LVL_MAX := 0x0f
    
          TAC_PLUS_PRIV_LVL_ROOT := 0x0f
    
          TAC_PLUS_PRIV_LVL_USER := 0x01
    
          TAC_PLUS_PRIV_LVL_MIN := 0x00
    
    SB> Where are these defined?

TA>  They are not defined as yet. [AI-TA] 
    
    ========
    Nits/editorial comments:
    
          The normative description of Legacy features such as ARAP and
    SB> ARAP not expanded anywhere in document.
    
TA> Agreed. Though we have:

“The normative description of Legacy features such as ARAP and
      outbound authentication has been removed, however, the required
      enumerations are kept.”

Probably it is best to remove  the  enumerations as well.  [AI-TA]

    =====
    
    SB> telnet and rlogin need references
    
    =====
       is the user is connected via ISDN or a POTS, 
    SB> Are ISDN and POTS well known IETF terms?
    
TA> Agreed [AI-TA]

    =====
    
       It is not legal for an attribute name to contain either of the
       separators.  It is legal for attribute values to contain the
       separators.  
    SB> Is "legal" the correct term here?

TA> Agreed [AI-TA]