The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model
Extracted elements (24)
AES in CFB mode was chosen (over CBC, ECB, OFB, or CTR) because it supports streaming encryption without requiring padding for the final block, which fits variable-length SNMP scopedPDUs. The S=128 parameter matches the block size for maximum efficiency.
Key localization (deriving per-engine keys from a single user password) was inherited from RFC 3414 to ensure that compromise of one SNMP engine's key does not expose communications with other engines.
If the authentication protocol for a user at authoritative engine E is one of those defined in RFC 3414, key localization MUST follow the two-step process in RFC 3414 section 2.6; this ensures the localized key mechanism is consistent across USM implementations.
The CFB128-AES-128 protocol is designed to be completely interchangeable with existing USM authentication and privacy protocols (CBC-DES, HMAC-MD5-96, HMAC-SHA-96), requiring no changes to the overall SNMP message structure.
A user's password or non-localized key MUST NOT be stored on a managed device/node; instead, only the localized key SHALL be stored (if at all) to limit the blast radius of device compromise.
If the privParameters field in an incoming message is not an 8-octet OCTET STRING, a decryptionError indication MUST be returned to the calling module.
Password length SHOULD be at least 12 octets, password sharing SHOULD be prohibited, and implementations SHOULD support randomly generated passwords.
The AES-based privacy protocol MUST be used with one of the authentication protocols defined in RFC 3414 or an algorithm/protocol providing equivalent functionality, because CFB encryption mode does not detect ciphertext modifications.
The encryption protocol defined in this memo MUST be used with an authentication protocol that generates a localized key with at least 128 bits.
The <privKey> length MUST be greater than or equal to 128 bits (16 octets).
AES is used in CFB mode with the feedback parameter S set to 128 bits, requiring an IV equal in size to the 128-bit AES block size. Ten rounds of encryption are used.
Data decryption uses the IV as the first input block; subsequent ciphertext blocks feed the forward cipher to produce output blocks that are XORed with ciphertext to recover plaintext.
Data encryption uses CFB mode: plaintext is divided into 128-bit blocks (last block may be shorter with no padding required), and the IV is used as the first input block for the forward cipher operation.
The 128-bit Initialization Vector (IV) is constructed by concatenating the 32-bit snmpEngineBoots, the 32-bit snmpEngineTime, and a locally maintained 64-bit integer (salt), all in Most Significant Byte first order.
The 64-bit salt integer is initialized to a pseudo-random value at boot time and SHOULD be incremented by one for each subsequent message until it wraps, ensuring unique IVs per key.
The CFB128-AES-128 privacy protocol (usmAesCfb128Protocol) is defined as an alternative privacy protocol for SNMP's User-based Security Model, identified by OID snmpPrivProtocols 4. It uses AES in CFB mode with 128-bit keys and a 128-bit feedback parameter.
The decryptData abstract service primitive takes decryptKey (16 octets), privParameters (64-bit salt), and encryptedData, returning the decrypted scopedPDU in plain text.
The encryptData abstract service primitive takes encryptKey (16 octets) and dataToEncrypt (scopedPDU), and returns encryptedData and privParameters as an OCTET STRING.
The snmpUsmAesMIB MODULE-IDENTITY is defined under snmpModules 20, and usmAesCfb128Protocol OBJECT-IDENTITY is defined under snmpPrivProtocols 4.
IANA assigned OID 20 for the snmpUsmAesMIB module under snmpModules, and OID 4 for usmAesCfb128Protocol under snmpPrivProtocols as defined in RFC 3411.
CFB encryption mode does not detect ciphertext modifications, so the AES privacy protocol MUST always be paired with an authentication protocol (e.g., HMAC-MD5-96 or HMAC-SHA-96 from RFC 3414) to provide message integrity.
CFB mode security critically depends on IV uniqueness per key; a duplicate IV allows a cryptanalyst to recover corresponding plaintext. The salt-based IV construction minimizes but does not eliminate duplication risk when multiple managers share one authoritative engine.
The encryptKey and decryptKey passed to the AES privacy module MUST be 16 octets (128 bits), taken from the first 128 bits of the user's localized key Kul.
The msgPrivacyParameters field carries the salt as a serialized OCTET STRING of exactly 8 octets, encoding the 64-bit integer used to construct the IV.