Re: [OPSAWG] Alissa Cooper'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 15/05/2019, 19:55, "Alissa Cooper via Datatracker" <[e-mail]> wrote:

    Alissa Cooper 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:
    ----------------------------------------------------------------------
    
    (1) The Gen-ART reviewer Stewart Bryant (SB) asked the following:
    
         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?
    
    Please define the semantics of these values.

TA> Agreed,  will add definition [AI-TA]
    
    (2) Stewart also noted the following:
    
         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
    
    The way I would say this is that the document seems to be written for people
    who have already deployed this protocol, and elides details that would make it
    comprehensible to a new implementor. But it also contemplates the prospect of
    new implementations. If new implementations are actually expected (which I was
    surprised about, but can believe), I agree with Stewart that each of the field
    values need a definition that explains its semantic. If new implementations are
    not expected, then the reference to new implementations should be removed.
    
TA> There  is  some coverage in  section: “5.4.2.  Common Authentication Flows”. The document does not help at all though as there is no reference from the enumeration to 5.4.2, we will add that. [AI-TA]


    (3) How is "secure deployment" defined? Since this is used as a restriction in
    several places, I think it needs to be defined precisely.
TA> Will define that early in the document. [AI-TA]
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    I agree with Deborah's comment, and would further suggest that the lack of
    modern security mechanisms in this protocol needs to be called out in the
    introduction, with a reference to Section 10.
TA> Agreed [AI-TA]

    Please respond to the Gen-ART review, which makes several suggestions for
    needed clarifications.
    
    In Section 2, please use the RFC 8174 boilerplate.
TA> Agreed [AI-TA]