Hi David, Thanks a lot for your time in reviewing the initial draft and your valuable comments. Taken care all your comments and incorporated in the following updated draft. Please find answers in line with [Satya] for each of the comments you had and let us know if you have further comments on the same.
http://www.ietf.org/internet-drafts/draft-sdanda-localauth-mib-01.txt Thanks Satya -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Harrington Sent: Thursday, September 26, 2013 7:57 PM To: [email protected] Subject: [OPSAWG] quick review of draft-sdanda-localauth-mib-00 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. [Satya] Username as an identity in the network transport would mostly be a clear test. If it is not via MIB, they might do it via packet capture or any other means. With knowing username, we can mitigate the risk from an attacker by enforcing strong password encryption schemes. We have mentioned the same under 'Security considerations' section. 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. [Satya] We have incorporated the changes as per the guidelines. 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. [Satya] We have updated the applicable environment and uses-cases. The applicable environment is the Central controller where Information provided by this MIB is used to manage Local authentication information on the controller. One of the use-cases would be to monitor user access on multiple vendor devices like - user login/logout notifications - user account lifetime expiry notifications - User account creation/deletion notifications 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, readers/reviewers might be able to recommend a different document to use for terminology. [Satya] We wanted to refer 'Authentication' which is relevant for this MIB. Please let us know if something else can be referred for the same. 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. [Satya] Corrected this in the new version of the draft. 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. [Satya] Thanks for pointing this, we feel this is not relevant and hence removed the same from the draft. 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? [Satya] Yes, changed and updated in the new version of the draft. 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?) [Satya] Agree, it doesn't make much sense to NMS applications about knowing the description of the user account and hence removed in the updated version of the draft. 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? [Satya] the minimum value for an user account lifetime could be in Secs. Hence we would recommend the UNITS in Secs as the metric to use for this object. --- Editorial comments --- 1) This draft could use a good review for its English. Some of the sentences are difficult to understand. [Satya] Rephrased the sentences where ever there is a possible confusion of understanding. 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. [Satya] Corrected this to reflect the right Working Group alias. 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. [Satya] We have added description of SSH and DOT1x in the Glossary section of the updated draft. David Harrington [email protected] +1-603-828-1401 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
