summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3826.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3826.txt')
-rw-r--r--doc/rfc/rfc3826.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3826.txt b/doc/rfc/rfc3826.txt
new file mode 100644
index 0000000..79da73c
--- /dev/null
+++ b/doc/rfc/rfc3826.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group U. Blumenthal
+Request for Comments: 3826 Lucent Technologies
+Category: Standards Track F. Maino
+ Andiamo Systems, Inc.
+ K. McCloghrie
+ Cisco Systems, Inc.
+ June 2004
+
+
+ The Advanced Encryption Standard (AES) Cipher Algorithm
+ in the SNMP User-based Security Model
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document describes a symmetric encryption protocol that
+ supplements the protocols described in the User-based Security Model
+ (USM), which is a Security Subsystem for version 3 of the Simple
+ Network Management Protocol for use in the SNMP Architecture. The
+ symmetric encryption protocol described in this document is based on
+ the Advanced Encryption Standard (AES) cipher algorithm used in
+ Cipher FeedBack Mode (CFB), with a key size of 128 bits.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Goals and Constraints. . . . . . . . . . . . . . . . . 2
+ 1.2. Key Localization . . . . . . . . . . . . . . . . . . . 3
+ 1.3. Password Entropy and Storage . . . . . . . . . . . . . 3
+ 2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. CFB128-AES-128 Symmetric Encryption Protocol . . . . . . . . 5
+ 3.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1.1. The AES-based Symmetric Encryption Protocol . . 6
+ 3.1.2. Localized Key, AES Encryption Key and
+ Initialization Vector . . . . . . . . . . . . . 7
+ 3.1.3. Data Encryption . . . . . . . . . . . . . . . . 8
+ 3.1.4. Data Decryption . . . . . . . . . . . . . . . . 8
+
+
+
+Blumenthal, et al. Standards Track [Page 1]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+ 3.2. Elements of the AES Privacy Protocol . . . . . . . . . 9
+ 3.2.1. Users . . . . . . . . . . . . . . . . . . . . . 9
+ 3.2.2. msgAuthoritativeEngineID. . . . . . . . . . . . 9
+ 3.2.3. SNMP Messages Using this Privacy Protocol . . . 10
+ 3.2.4. Services provided by the AES Privacy Modules. . 10
+ 3.3. Elements of Procedure. . . . . . . . . . . . . . . . . 11
+ 3.3.1. Processing an Outgoing Message. . . . . . . . . 12
+ 3.3.2. Processing an Incoming Message. . . . . . . . . 12
+ 4. Security Considerations. . . . . . . . . . . . . . . . . . . 13
+ 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 13
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 7.1. Normative References . . . . . . . . . . . . . . . . . 14
+ 7.2. Informative References . . . . . . . . . . . . . . . . 14
+ 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
+ 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
+
+1. Introduction
+
+ Within the Architecture for describing Internet Management Frameworks
+ [RFC3411], the User-based Security Model (USM) [RFC3414] for SNMPv3
+ is defined as a Security Subsystem within an SNMP engine. RFC 3414
+ describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the initial
+ authentication protocols, and the use of CBC-DES as the initial
+ privacy protocol. The User-based Security Model, however, allows for
+ other such protocols to be used instead of, or concurrently with,
+ these protocols.
+
+ This memo describes the use of CFB128-AES-128 as an alternative
+ privacy protocol for the User-based Security Model. The key words
+ "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+ "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
+ are to be interpreted as described in [RFC2119].
+
+1.1. Goals and Constraints
+
+ The main goal of this memo is to provide a new privacy protocol for
+ the USM based on the Advanced Encryption Standard (AES) [FIPS-AES].
+
+ The major constraint is to maintain a complete interchangeability of
+ the new protocol defined in this memo with existing authentication
+ and privacy protocols already defined in USM.
+
+ For a given user, 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.
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 2]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+1.2. Key Localization
+
+ As defined in [RFC3414], a localized key is a secret key shared
+ between a user U and one authoritative SNMP engine E. Even though a
+ user may have only one pair of authentication and privacy passwords
+ (and consequently only one pair of keys) for the entire network, the
+ actual secrets shared between the user and each authoritative SNMP
+ engine will be different. This is achieved by key localization.
+
+ If the authentication protocol defined for a user U at the
+ authoritative SNMP engine E is one of the authentication protocols
+ defined in [RFC3414], the key localization is performed according to
+ the two-step process described in section 2.6 of [RFC3414].
+
+1.3. Password Entropy and Storage
+
+ The security of various cryptographic functions lies both in the
+ strength of the functions themselves against various forms of attack,
+ and also, perhaps more importantly, in the keying material that is
+ used with them. While theoretical attacks against cryptographic
+ functions are possible, it is more probable that key guessing is the
+ main threat.
+
+ The following are recommended in regard to user passwords:
+
+ - Password length SHOULD be at least 12 octets.
+ - Password sharing SHOULD be prohibited so that passwords are not
+ shared among multiple SNMP users.
+ - Implementations SHOULD support the use of randomly generated
+ passwords as a stronger form of security.
+
+ It is worth remembering that, as specified in [RFC3414], if a user's
+ password or a non-localized key is disclosed, then key localization
+ will not help and network security may be compromised. Therefore, a
+ user's password or non-localized key MUST NOT be stored on a managed
+ device/node. Instead, the localized key SHALL be stored (if at all)
+ so that, in case a device does get compromised, no other managed or
+ managing devices get compromised.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 3]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+2. Definitions
+
+ This MIB is written in SMIv2 [RFC2578].
+
+SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-IDENTITY,
+ snmpModules FROM SNMPv2-SMI -- [RFC2578]
+ snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411]
+
+snmpUsmAesMIB MODULE-IDENTITY
+ LAST-UPDATED "200406140000Z"
+ ORGANIZATION "IETF"
+ CONTACT-INFO "Uri Blumenthal
+ Lucent Technologies / Bell Labs
+ 67 Whippany Rd.
+ 14D-318
+ Whippany, NJ 07981, USA
+ 973-386-2163
+ uri@bell-labs.com
+
+ Fabio Maino
+ Andiamo Systems, Inc.
+ 375 East Tasman Drive
+ San Jose, CA 95134, USA
+ 408-853-7530
+ fmaino@andiamo.com
+
+ Keith McCloghrie
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706, USA
+
+ 408-526-5260
+ kzm@cisco.com"
+ DESCRIPTION "Definitions of Object Identities needed for
+ the use of AES by SNMP's User-based Security
+ Model.
+
+ Copyright (C) The Internet Society (2004).
+
+ This version of this MIB module is part of RFC 3826;
+ see the RFC itself for full legal notices.
+ Supplementary information may be available on
+ http://www.ietf.org/copyrights/ianamib.html."
+
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 4]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+ REVISION "200406140000Z"
+ DESCRIPTION "Initial version, published as RFC3826"
+
+ ::= { snmpModules 20 }
+
+usmAesCfb128Protocol OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The CFB128-AES-128 Privacy Protocol."
+ REFERENCE "- Specification for the ADVANCED ENCRYPTION
+ STANDARD. Federal Information Processing
+ Standard (FIPS) Publication 197.
+ (November 2001).
+
+ - Dworkin, M., NIST Recommendation for Block
+ Cipher Modes of Operation, Methods and
+ Techniques. NIST Special Publication 800-38A
+ (December 2001).
+ "
+ ::= { snmpPrivProtocols 4 }
+
+END
+
+3. CFB128-AES-128 Symmetric Encryption Protocol
+
+ This section describes a Symmetric Encryption Protocol based on the
+ AES cipher algorithm [FIPS-AES], used in Cipher Feedback Mode as
+ described in [AES-MODE], using encryption keys with a size of 128
+ bits.
+
+ This protocol is identified by usmAesCfb128PrivProtocol.
+
+ The protocol usmAesCfb128PrivProtocol is an alternative to the
+ privacy protocol defined in [RFC3414].
+
+3.1. Mechanisms
+
+ In support of data confidentiality, an encryption algorithm is
+ required. An appropriate portion of the message is encrypted prior
+ to being transmitted. The User-based Security Model specifies that
+ the scopedPDU is the portion of the message that needs to be
+ encrypted.
+
+ A secret value is shared by all SNMP engines which can legitimately
+ originate messages on behalf of the appropriate user. This secret
+ value, in combination with a timeliness value and a 64-bit integer,
+ is used to create the (localized) en/decryption key and the
+ initialization vector.
+
+
+
+
+Blumenthal, et al. Standards Track [Page 5]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+3.1.1. The AES-based Symmetric Encryption Protocol
+
+ The Symmetric Encryption Protocol defined in this memo provides
+ support for data confidentiality. The designated portion of an SNMP
+ message is encrypted and included as part of the message sent to the
+ recipient.
+
+ The AES (Advanced Encryption Standard) is the symmetric cipher
+ algorithm that the NIST (National Institute of Standards and
+ Technology) has selected in a four-year competitive process as
+ Replacement for DES (Data Encryption Standard).
+
+ The AES homepage, http://www.nist.gov/aes, contains a wealth of
+ information on AES including the Federal Information Processing
+ Standard [FIPS-AES] that fully specifies the Advanced Encryption
+ Standard.
+
+ The following subsections contain descriptions of the relevant
+ characteristics of the AES ciphers used in the symmetric encryption
+ protocol described in this memo.
+
+3.1.1.1. Mode of operation
+
+ The NIST Special Publication 800-38A [AES-MODE] recommends five
+ confidentiality modes of operation for use with AES: Electronic
+ Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB),
+ Output Feedback (OFB), and Counter (CTR).
+
+ The symmetric encryption protocol described in this memo uses AES in
+ CFB mode with the parameter S (number of bits fed back) set to 128
+ according to the definition of CFB mode given in [AES-MODE]. This
+ mode requires an Initialization Vector (IV) that is the same size as
+ the block size of the cipher algorithm.
+
+3.1.1.2. Key Size
+
+ In the encryption protocol described by this memo AES is used with a
+ key size of 128 bits, as recommended in [AES-MODE].
+
+3.1.1.3. Block Size and Padding
+
+ The block size of the AES cipher algorithms used in the encryption
+ protocol described by this memo is 128 bits, as recommended in [AES-
+ MODE].
+
+
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 6]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+3.1.1.4. Rounds
+
+ This parameter determines how many times a block is encrypted. The
+ encryption protocol described in this memo uses 10 rounds, as
+ recommended in [AES-MODE].
+
+3.1.2. Localized Key, AES Encryption Key, and Initialization Vector
+
+ The size of the Localized Key (Kul) of an SNMP user, as described in
+ [RFC3414], depends on the authentication protocol defined for that
+ user U at the authoritative SNMP engine E.
+
+ 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 authentication protocols described in [RFC3414]
+ satisfy this requirement.
+
+3.1.2.1. AES Encryption Key and IV
+
+ The first 128 bits of the localized key Kul are used as the AES
+ encryption key. The 128-bit IV is obtained as the concatenation of
+ the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP
+ engine's 32-bit snmpEngineTime, and a local 64-bit integer. The 64-
+ bit integer is initialized to a pseudo-random value at boot time.
+
+ The IV is concatenated as follows: the 32-bit snmpEngineBoots is
+ converted to the first 4 octets (Most Significant Byte first), the
+ 32-bit snmpEngineTime is converted to the subsequent 4 octets (Most
+ Significant Byte first), and the 64-bit integer is then converted to
+ the last 8 octets (Most Significant Byte first). The 64-bit integer
+ is then put into the msgPrivacyParameters field encoded as an OCTET
+ STRING of length 8 octets. The integer is then modified for the
+ subsequent message. We recommend that it is incremented by one until
+ it reaches its maximum value, at which time it is wrapped.
+
+ An implementation can use any method to vary the value of the local
+ 64-bit integer, providing the chosen method never generates a
+ duplicate IV for the same key.
+
+ A duplicated IV can result in the very unlikely event that multiple
+ managers, communicating with a single authoritative engine, both
+ accidentally select the same 64-bit integer within a second. The
+ probability of such an event is very low, and does not significantly
+ affect the robustness of the mechanisms proposed.
+
+
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 7]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+ The 64-bit integer must be placed in the privParameters field to
+ enable the receiving entity to compute the correct IV and to decrypt
+ the message. This 64-bit value is called the "salt" in this
+ document.
+
+ Note that the sender and receiver must use the same IV value, i.e.,
+ they must both use the same values of the individual components used
+ to create the IV. In particular, both sender and receiver must use
+ the values of snmpEngineBoots, snmpEngineTime, and the 64-bit integer
+ which are contained in the relevant message (in the
+ msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime, and
+ privParameters fields respectively).
+
+3.1.3. Data Encryption
+
+ The data to be encrypted is treated as a sequence of octets.
+
+ The data is encrypted in Cipher Feedback mode with the parameter s
+ set to 128 according to the definition of CFB mode given in Section
+ 6.3 of [AES-MODE]. A clear diagram of the encryption and decryption
+ process is given in Figure 3 of [AES-MODE].
+
+ The plaintext is divided into 128-bit blocks. The last block may
+ have fewer than 128 bits, and no padding is required.
+
+ The first input block is the IV, and the forward cipher operation is
+ applied to the IV to produce the first output block. The first
+ ciphertext block is produced by exclusive-ORing the first plaintext
+ block with the first output block. The ciphertext block is also used
+ as the input block for the subsequent forward cipher operation.
+
+ The process is repeated with the successive input blocks until a
+ ciphertext segment is produced from every plaintext segment.
+
+ The last ciphertext block is produced by exclusive-ORing the last
+ plaintext segment of r bits (r is less than or equal to 128) with the
+ segment of the r most significant bits of the last output block.
+
+3.1.4. Data Decryption
+
+ In CFB decryption, the IV is the first input block, the first
+ ciphertext is used for the second input block, the second ciphertext
+ is used for the third input block, etc. The forward cipher function
+ is applied to each input block to produce the output blocks. The
+ output blocks are exclusive-ORed with the corresponding ciphertext
+ blocks to recover the plaintext blocks.
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 8]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+ The last ciphertext block (whose size r is less than or equal to 128)
+ is exclusive-ORed with the segment of the r most significant bits of
+ the last output block to recover the last plaintext block of r bits.
+
+3.2. Elements of the AES Privacy Protocol
+
+ This section contains definitions required to realize the privacy
+ modules defined by this memo.
+
+3.2.1. Users
+
+ Data en/decryption using this Symmetric Encryption Protocol makes use
+ of a defined set of userNames. For any user on whose behalf a
+ message must be en/decrypted at a particular SNMP engine, that SNMP
+ engine must have knowledge of that user. An SNMP engine that needs
+ to communicate with another SNMP engine must also have knowledge of a
+ user known to that SNMP engine, including knowledge of the applicable
+ attributes of that user.
+
+ A user and its attributes are defined as follows:
+
+ <userName>
+ An octet string representing the name of the user.
+
+ <privAlg>
+ The algorithm used to protect messages generated on behalf of the
+ user from disclosure.
+
+ <privKey>
+ The user's secret key to be used as input to the generation of the
+ localized key for encrypting/decrypting messages generated on
+ behalf of the user. The length of this key MUST be greater than
+ or equal to 128 bits (16 octets).
+
+ <authAlg>
+ The algorithm used to authenticate messages generated on behalf of
+ the user, which is also used to generate the localized version of
+ the secret key.
+
+3.2.2. msgAuthoritativeEngineID
+
+ The msgAuthoritativeEngineID value contained in an authenticated
+ message specifies the authoritative SNMP engine for that particular
+ message (see the definition of SnmpEngineID in the SNMP Architecture
+ document [RFC3411]).
+
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 9]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+ The user's (private) privacy key is different at each authoritative
+ SNMP engine, and so the snmpEngineID is used to select the proper key
+ for the en/decryption process.
+
+3.2.3. SNMP Messages Using this Privacy Protocol
+
+ Messages using this privacy protocol carry a msgPrivacyParameters
+ field as part of the msgSecurityParameters. For this protocol, the
+ privParameters field is the serialized OCTET STRING representing the
+ "salt" that was used to create the IV.
+
+3.2.4. Services provided by the AES Privacy Modules
+
+ This section describes the inputs and outputs that the AES Privacy
+ module expects and produces when the User-based Security module
+ invokes one of the AES Privacy modules for services.
+
+3.2.4.1. Services for Encrypting Outgoing Data
+
+ The AES privacy protocol assumes that the selection of the privKey is
+ done by the caller, and that the caller passes the localized secret
+ key to be used.
+
+ Upon completion, the privacy module returns statusInformation and, if
+ the encryption process was successful, the encryptedPDU and the
+ msgPrivacyParameters encoded as an OCTET STRING. The abstract
+ service primitive is:
+
+ statusInformation = -- success or failure
+ encryptData(
+ IN encryptKey -- secret key for encryption
+ IN dataToEncrypt -- data to encrypt (scopedPDU)
+ OUT encryptedData -- encrypted data (encryptedPDU)
+ OUT privParameters -- filled in by service provider
+ )
+
+ The abstract data elements are:
+
+ statusInformation
+ An indication of the success or failure of the encryption process.
+ In case of failure, it is an indication of the error.
+
+ encryptKey
+ The secret key to be used by the encryption algorithm. The length
+ of this key MUST be 16 octets.
+
+ dataToEncrypt
+ The data that must be encrypted.
+
+
+
+Blumenthal, et al. Standards Track [Page 10]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+ encryptedData
+ The encrypted data upon successful completion.
+
+ privParameters
+ The privParameters encoded as an OCTET STRING.
+
+3.2.4.2. Services for Decrypting Incoming Data
+
+ This AES privacy protocol assumes that the selection of the privKey
+ is done by the caller and that the caller passes the localized secret
+ key to be used.
+
+ Upon completion the privacy module returns statusInformation and, if
+ the decryption process was successful, the scopedPDU in plain text.
+ The abstract service primitive is:
+
+ statusInformation =
+ decryptData(
+ IN decryptKey -- secret key for decryption
+ IN privParameters -- as received on the wire
+ IN encryptedData -- encrypted data (encryptedPDU)
+ OUT decryptedData -- decrypted data (scopedPDU)
+ )
+
+ The abstract data elements are:
+
+ statusInformation
+ An indication of whether the data was successfully decrypted, and
+ if not, an indication of the error.
+
+ decryptKey
+ The secret key to be used by the decryption algorithm. The length
+ of this key MUST be 16 octets.
+
+ privParameters
+ The 64-bit integer to be used to calculate the IV.
+
+ encryptedData
+ The data to be decrypted.
+
+ decryptedData
+ The decrypted data.
+
+3.3. Elements of Procedure
+
+ This section describes the procedures for the AES privacy protocol
+ for SNMP's User-based Security Model.
+
+
+
+
+Blumenthal, et al. Standards Track [Page 11]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+3.3.1. Processing an Outgoing Message
+
+ This section describes the procedure followed by an SNMP engine
+ whenever it must encrypt part of an outgoing message using the
+ usmAesCfb128PrivProtocol.
+
+ 1) The secret encryptKey is used to construct the AES encryption key,
+ as described in section 3.1.2.1.
+
+ 2) The privParameters field is set to the serialization according to
+ the rules in [RFC3417] of an OCTET STRING representing the 64-bit
+ integer that will be used in the IV as described in section
+ 3.1.2.1.
+
+ 3) The scopedPDU is encrypted (as described in section 3.1.3) and the
+ encrypted data is serialized according to the rules in [RFC3417]
+ as an OCTET STRING.
+
+ 4) The serialized OCTET STRING representing the encrypted scopedPDU
+ together with the privParameters and statusInformation indicating
+ success is returned to the calling module.
+
+3.3.2. Processing an Incoming Message
+
+ This section describes the procedure followed by an SNMP engine
+ whenever it must decrypt part of an incoming message using the
+ usmAesCfb128PrivProtocol.
+
+ 1) If the privParameters field is not an 8-octet OCTET STRING, then
+ an error indication (decryptionError) is returned to the calling
+ module.
+
+ 2) The 64-bit integer is extracted from the privParameters field.
+
+ 3) The secret decryptKey and the 64-bit integer are then used to
+ construct the AES decryption key and the IV that is computed as
+ described in section 3.1.2.1.
+
+ 4) The encryptedPDU is then decrypted (as described in section
+ 3.1.4).
+
+ 5) If the encryptedPDU cannot be decrypted, then an error indication
+ (decryptionError) is returned to the calling module.
+
+ 6) The decrypted scopedPDU and statusInformation indicating success
+ are returned to the calling module.
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 12]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+4. Security Considerations
+
+ The security of the cryptographic functions defined in this document
+ lies both in the strength of the functions themselves against various
+ forms of attack, and also, perhaps more importantly, in the keying
+ material that is used with them. The recommendations in Section 1.3
+ SHOULD be followed to ensure maximum entropy to the selected
+ passwords, and to protect the passwords while stored.
+
+ The security of the CFB mode relies upon the use of a unique IV for
+ each message encrypted with the same key [CRYPTO-B]. If the IV is
+ not unique, a cryptanalyst can recover the corresponding plaintext.
+
+ Section 3.1.2.1 defines a procedure to derive the IV from a local
+ 64-bit integer (the salt) initialized to a pseudo-random value at
+ boot time. An implementation can use any method to vary the value of
+ the local 64-bit integer, providing the chosen method never generates
+ a duplicate IV for the same key.
+
+ The procedure of section 3.1.2.1 suggests a method to vary the local
+ 64-bit integer value that generates unique IVs for every message.
+ This method can result in a duplicated IV in the very unlikely event
+ that multiple managers, communicating with a single authoritative
+ engine, both accidentally select the same 64-bit integer within a
+ second. The probability of such an event is very low, and does not
+ significantly affect the robustness of the mechanisms proposed.
+
+ This AES-based privacy protocol MUST be used with one of the
+ authentication protocols defined in RFC 3414 or with an
+ algorithm/protocol providing equivalent functionality (including
+ integrity), because CFB encryption mode does not detect ciphertext
+ modifications.
+
+ For further security considerations, the reader is encouraged to read
+ [RFC3414], and the documents that describe the actual cipher
+ algorithms.
+
+5. IANA Considerations
+
+ IANA has assigned OID 20 for the snmpUsmAesMIB module under the
+ snmpModules subtree, maintained in the registry at
+ http://www.iana.org/assignments/smi-numbers.
+
+ IANA has assigned OID 4 for the usmAesCfb128Protocol under the
+ snmpPrivProtocols registration point, as defined in RFC 3411
+ [RFC3411].
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 13]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+6. Acknowledgements
+
+ Portions of this text, as well as its general structure, were
+ unabashedly lifted from [RFC3414]. The authors are grateful to many
+ of the SNMPv3 WG members for their help, especially Wes Hardaker,
+ Steve Moulton, Randy Presuhn, David Town, and Bert Wijnen. Security
+ discussions with Steve Bellovin helped to streamline this protocol.
+
+7. References
+
+7.1. Normative References
+
+ [AES-MODE] Dworkin, M., "NIST Recommendation for Block Cipher Modes
+ of Operation, Methods and Techniques", NIST Special
+ Publication 800-38A, December 2001.
+
+ [FIPS-AES] "Specification for the ADVANCED ENCRYPTION STANDARD
+ (AES)", Federal Information Processing Standard (FIPS)
+ Publication 197, November 2001.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+ "Structure of Management Information Version 2 (SMIv2)",
+ STD 58, RFC 2578, April 1999.
+
+ [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
+ Architecture for Describing Simple Network Management
+ Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+ December 2002.
+
+ [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
+ (USM) for version 3 of the Simple Network Management
+ Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
+
+ [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple
+ Network Management Protocol (SNMP)", STD 62, RFC 3417,
+ December 2002.
+
+7.2. Informative References
+
+ [CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP
+ Security Protocols", Proceedings of the Symposium on
+ Network and Distributed System Security, San Diego, CA,
+ pp. 155-160, February 1997.
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 14]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+8. Authors' Addresses
+
+ Uri Blumenthal
+ Lucent Technologies / Bell Labs
+ 67 Whippany Rd.
+ 14D-318
+ Whippany, NJ 07981, USA
+
+ Phone: +1-973-386-2163
+ EMail: uri@bell-labs.com
+
+ Fabio Maino
+ Andiamo Systems, Inc.
+ 375 East Tasman Drive
+ San Jose, CA. 95134 USA
+
+ Phone: +1-408-853-7530
+ EMail: fmaino@andiamo.com
+
+ Keith McCloghrie
+ Cisco Systems, Inc.
+ 170 East Tasman Drive
+ San Jose, CA. 95134-1706 USA
+
+ Phone: +1-408-526-5260
+ EMail: kzm@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 15]
+
+RFC 3826 AES for SNMP's USM June 2004
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Blumenthal, et al. Standards Track [Page 16]
+