doc: Add RFC documents

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]
+