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 protected]." - what is the WSPA mailing list? I don't think [email protected] 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 protected] +1-603-828-1401 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
