11.1. Recommended Practices

11.1. Recommended Practices

This section describes recommended practices for using the User-based Security Model to maximize security.

Password Selection

Passwords should be chosen to maximize security:

1. Length: Passwords SHOULD be at least 8 characters long. Longer passwords provide better security.

2. Complexity: Passwords SHOULD contain a mix of:

   • Uppercase letters
   • Lowercase letters
   • Digits
   • Special characters

3. Avoid Patterns: Passwords SHOULD NOT be:

   • Dictionary words
   • Simple patterns (e.g., "12345678", "password")
   • Personal information (names, birthdays, etc.)
   • Repetitive strings (e.g., "aaaaaaaa")

Key Management

1. Key Storage: Authentication and privacy keys MUST be stored securely and protected from unauthorized access.

2. Key Distribution: Initial key distribution SHOULD be performed through secure, out-of-band mechanisms.

3. Key Updates: Keys SHOULD be changed periodically. The frequency depends on the security requirements of the deployment.

4. Key Localization: Always use localized keys (keys specific to each SNMP engine) rather than global keys.

Time Synchronization

1. Initial Synchronization: Non-authoritative SNMP engines MUST perform time synchronization with authoritative engines before sending authenticated messages.

2. Clock Accuracy: SNMP engines SHOULD maintain reasonably accurate clocks. Large clock skew can cause legitimate messages to be rejected.

3. Boots Counter: The msgAuthoritativeEngineBoots counter MUST be incremented whenever an SNMP engine re-initializes. This counter MUST persist across reboots.

User Management

1. User Creation: When creating users, always specify both authentication and privacy protocols, even if privacy will not be used immediately.

2. User Deletion: When deleting users, ensure that all associated keys and configuration data are securely erased.

3. Template Users: Use template users (users configured at the authoritative engine) for cloning to create new users at non-authoritative engines.

Message Security Levels

Choose the appropriate security level for each message:

1. noAuthNoPriv: Only for discovery messages or non-sensitive information. Not recommended for operational use.

2. authNoPriv: Provides authentication but not privacy. Suitable when confidentiality is not required but message integrity and origin authentication are needed.

3. authPriv: Provides both authentication and privacy. Recommended for all sensitive operations.

Implementation Considerations

1. Random Number Generation: Implementations MUST use cryptographically strong random number generators for generating keys and initialization vectors.

2. Clock Synchronization: Implementations SHOULD provide mechanisms to synchronize with external time sources (e.g., NTP) to maintain accurate time.

3. Audit Logging: Implementations SHOULD log security-relevant events, including authentication failures and time synchronization failures.

4. Error Handling: Implementations MUST handle error conditions securely, avoiding information leakage that could aid attackers.