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