Forum Discussion

Cole_McDonald's avatar
Cole_McDonald
Icon for Professor rankProfessor
12 months ago
Solved

SNMPv3 Password Character Set Restrictions?

I’m working on adding a hundred or so Long Strong SNMPv3 passwords into a class of device we’re going to start monitoring.  I’m can walk the snmp locally, from a linux neighbor, but not from LM.  I’m getting a password error.  I assume the issue is that the password is being encoded for storage/delivery.  Has anyone else experienced this?  If my assumption is correct, what is the restricted character set when pairing LM with Linux SNMP?

LM ticket #424608 for internal reference.

  • Hi @Stuart Weenig !

    Perhaps I’m misunderstanding the question, but everyone from Oracle to Cisco to IBM advises that a a privacy password  “must contain exactly 8 characters in length and include any combination of alphanumeric characters (uppercase letters, lowercase letters, and numbers)”. Actually, it may just be Oracle that says “exactly” 8 because IBM and others indicate 8-32. it is my understanding that the length is determined by the level of the encryption algo used, so AES would require less characters than AES128 or 256, etc. 

     https://docs.oracle.com/cd/E37444_01/html/E37449/gpqnr.html

    I can’t say if this information is outdated or not. The current RFC standard is here: https://www.rfc-editor.org/rfc/rfc3411 I have not had time to comb through this for info, though.

8 Replies

  • Hi @Stuart Weenig !

    Perhaps I’m misunderstanding the question, but everyone from Oracle to Cisco to IBM advises that a a privacy password  “must contain exactly 8 characters in length and include any combination of alphanumeric characters (uppercase letters, lowercase letters, and numbers)”. Actually, it may just be Oracle that says “exactly” 8 because IBM and others indicate 8-32. it is my understanding that the length is determined by the level of the encryption algo used, so AES would require less characters than AES128 or 256, etc. 

     https://docs.oracle.com/cd/E37444_01/html/E37449/gpqnr.html

    I can’t say if this information is outdated or not. The current RFC standard is here: https://www.rfc-editor.org/rfc/rfc3411 I have not had time to comb through this for info, though.

  • I’ve used 21 char priv/auth tokens for Linux servers successfully in LM many times, and likely for appliances too, but I do avoid using symbols. I would try replacing the symbols with alphanumeric to see if that works. If so, it might be an encoding thing. Replace one symbol at a time until it break, etc.

  • Hey there, not sure if this is your problem but I ran into a similar issue with SNMPv3 but only on my Linux devices. We had the same v3 cred working fine on network devices. May wanna see if any special characters are not being accepted and test. In my case, it was a pesky $. Hope this helps and good luck.

  • the length is determined by the level of the encryption algo used

    That may be the key. Cole, what’s the encryption depth you’re telling LM to use?

  • Hi Cole!

    According to the multiple industry sources as well as our internal docs, snmp v3 requires a password the length of 8 bytes/characters only and exactly. So if you’re trying with a longer value for snmp.privToken, this may be the issue.

    Hope this helps!

  • Hi Cole!

    According to the multiple industry sources as well as our internal docs, snmp v3 requires a password the length of 8 bytes/characters only and exactly. So if you’re trying with a longer value for snmp.privToken, this may be the issue.

    Hope this helps!

    I doubt this as well, I’ve used SNMPv3 passwords that were much longer. What’s your source?

  • the length is determined by the level of the encryption algo used

    That may be the key. Cole, what’s the encryption depth you’re telling LM to use?

    AES… which seems to default it to AES128 when I perform the SNMP diagnose from a debug.  LM support was able to get special characters to work by pre-escaping them when creating them on the Linux device… but I’m able to use the existing password from other linux devices, so I don't think that’s a workable solution that I’m going to pursue.  Espacially since we have a need to deploy SNMP accounts at scale.  I’ve also pulled LM’s java our of the troubleshooting mix by calling the SNMP tools they use directly from Windows and that also fails.  Mathematically, I want to keep the length and character set as big as possible to make it harder to crack… even if it’s only read only.