Subject: [OPSAWG] quick review of draft-sdanda-localauth-mib-00

From: "David Harrington" <[email-masked]>
Date: Thu, 26 Sep 2013 10:26:41 -0400

Hi,

I spotted this document announcement and thought I'd take a quick look. I
have some comments.

--- Technical comments ---

1) I have a concern about making authenticated usernames accessible via a
MIB. This would be very valuable information to an attacker.
Most login mechanisms requiring a username/password pair don't identify when
the username matches but the password doesn't, to avoid giving an attacker
an indication they found a valid username. 
The Security Considerations section has only boilerplate text, with no real
discussion of the security vulnerabilities from publishing such
authentication information in a MIB. 

The Security Considerations section doesn't follow the guidelines described
at https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security.
The MIB module contains information that is potentially sensitive, and those
tables and objects should be listed with a description of why they are
sensitive.

The need for a standards-track module for locally authenticated users is
described in one or two sentences. I think the need should be justified with
discussion of applicable environments and use cases.

I think this is the single most important point in my comments. All the rest
of my comments are immaterial if the need of such a standards-track MIB
module cannot be justified.

2) Terminology (section 3) adopts the definitions from an Experimental
document [RFC2903] "Generic AAA Architecture" . This document was written by
an IRTF WG. I am not aware that this document and its definitions and
mechanisms have been adopted by the IETF. It is Experimental and not an IETF
standards-track document. 
draft-sdanda-localauth-mib has an Intended Status of standards track. This
normative dependence on an Experimental draft might be problematic. It would
be helpful to at least identify which terminology from RFC2903 is adopted by
this document. That way, eaders/reviewers might be able to recommend a
different document to use for terminology.

3) For compatibility with RFC4181 " Guidelines for Authors and Reviewers of
MIB Documents", Appendix C, I recommend naming the module "LOCAL-AUTH-MIB",
and using an object naming prefix of localAuth rather than lau. This would
also help object name expansions such as lauUserName =>
localAuthUserUserName.

4) Part of the description of this module states " it is useful collect
Authentication logs at the network element". Logging has some issues
associated with it, such as privacy and the relation to wiretapping
[RFC2804], and this document doesn't touch upon those issues. If the primary
use case is for logging, it would be good to include such a discussion, or
to mention the issues and point to other documents that include discussion
of the issues. Such discussions have been had in the syslog WG, and are
currently being discussed in the behave WG regarding CGN logging.

5) I think this document could use a good RFC4181 review by the authors. On
quick look, I see some usages I would question, such as 
5a) lauUserLoginSuccessCount OBJECT-TYPE
       SYNTAX          Unsigned32
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
           "This object indicates the number of times, the user
           logged-in successfully."
       ::= { lauUserEntry 6 }

If this is counting, why not use a counter32?

5b) To make a standards-rack module useful across vendors/models, etc.,
descriptions should describe or recommend what information should be
included in a field.
lauUserDescription OBJECT-TYPE
       SYNTAX          OCTET STRING
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
           "This object indicates the description of the local user."
       ::= { lauUserEntry 12 }

So is this where we should put descriptions of the user like ugly,
attractive, tall, short, fat, skinny. And so on? ;-)
What type of information should operators put into this field?
How should an NMS or operator expect to use the information found in this
field?
(and if it isn't useable by an NMS or operator, why are we publishing it in
a MIB?)

5c) lauUserPasswordLifetime OBJECT-TYPE
       SYNTAX          Unsigned32
       MAX-ACCESS      read-only
       STATUS          current
       DESCRIPTION
           "This object indicates the expiry duration of the
           password of the local user."
       ::= { lauUserEntry 13 }

Are implementers free to choose the UNITS? Or should this be standardized?

--- Editorial comments ---

1) This draft could use a good review for its English. Some of the sentences
are difficult to understand.

2) " Comments should be made directly to the WSPA mailing list at
[email-masked]." - what is the WSPA mailing list? I don't think
[email-masked] is the WSPA mailing list.

3) The description clause of the MODULE-IDENTITY includes a GLOSSARY; this
doesn't seem the right place for a glossary. The glossary here contains only
two terms, but the description also uses terms like SSH and dot1x. 

David Harrington
[email-masked]
+1-603-828-1401