Is there any merit to the RFC 3414 (SNMPv3 User Security Model) password-to-key method?

Question

RFC 3414 (published 2002) specifies a method of generating keys based on password in its Appendix, which essentially takes any "passphrase", and keeps on repeating it until there is a 1MB string, at which point it takes either the SHA1 or MD5 of that data to use as the key:

  /**********************************************/
  /* Use while loop until we've done 1 Megabyte */
  /**********************************************/
  while (count < 1048576) {
     cp = password_buf;
     for (i = 0; i < 64; i++) {
         /*************************************************/
         /* Take the next octet of the password, wrapping */
         /* to the beginning of the password as necessary.*/
         /*************************************************/
         *cp++ = password[password_index++ % passwordlen];
     }
     SHAUpdate (&SH, password_buf, 64);
     count += 64;
  }
  SHAFinal (key, &SH);          /* tell SHA we're done */

It also states a minimum length security requirement:

SNMP implementations (and SNMP configuration applications) must ensure that passwords are at least 8 characters in length.

And then makes the observation:

Please note that longer passwords with repetitive strings may result in exactly the same key. For example, a password 'bertbert' will result in exactly the same key as password 'bertbertbert'.

It seems to be a well known "workaround" to the 8 character minimum to just repeat your input: If you want to use the password a, just enter aaaaaaaa. In fact, in either case it will actually be converted to a repeated 1048576 times (1MB), and then hashed. If you are trying to brute force the password, the passwords a, aa, aaa and aaaaaa....aaaaaa are all identical (and you don't need to try all of the variations).

---

Everything I understand about password security and hashing tells me this is not only a stupid design, but actually undermines the hash algorithm and lowers security. Is there actually a benefit to this method of key generation? How the heck did this get into an RFC explicitly concerned with security?

Answer 1

Everything I understand about password security and hashing tells me this is not only a stupid design, but actually undermines the hash algorithm and lowers security.

Special Publication 800-63B on Digital Identity Guidelines suggests passwords need not be long and complex but rather has the following to say about passwords:

• A minimum of eight characters and a maximum length of at least 64 characters

• The ability to use all special characters but no special requirement to use them

• Restrict sequential and repetitive characters (e.g. 12345 or aaaaaa)

• Restrict context specific passwords (e.g. the name of the site, etc.)

• Restrict commonly used passwords (e.g. p@ssw0rd, etc.) and dictionary words

• Restrict passwords obtained from previous breach corpuses

I would say that rfc3414 does not inhibit these guidelines and an implementation could provide additional guidelines for password generation. Section 11.2 seems to plead for implementers to encourage good passwords. It should also be noted that the wording in 11.2 seems to indicate the algorithm is an example, and not the requirement.

Is there actually a benefit to this method of key generation?

In section 2.6 a key localization technique is described The example in the appendix has the additional (third) argument of engineID which is specific to the authoritative SNMP engine.

void password_to_key_md5(
      u_char *password,    /* IN */
      u_int   passwordlen, /* IN */
      u_char *engineID,    /* IN  - pointer to snmpEngineID  */
      u_int   engineLength,/* IN  - length of snmpEngineID */
      u_char *key)         /* OUT - pointer to caller 16-octet buffer */

So essentially the password is salted.

How the heck did this get into an RFC explicitly concerned with security?

Keep in mind that this was written not too long after the time when password hashing in Windows was:

MD4(UTF-16-LE(password))