idnits 2.17.1 draft-blumenthal-aes-usm-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 700 has weird spacing: '...must be follo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 November 2003) is 7441 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2578' is defined on line 641, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-MODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-AES' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft U. Blumenthal 3 Lucent Technologies 4 F. Maino 5 Andiamo Systems, Inc. 6 K. McCloghrie 7 Cisco Systems, Inc. 9 14 November 2003 11 The AES Cipher Algorithm in the SNMP User-based Security Model 13 draft-blumenthal-aes-usm-08.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC 2026. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft 31 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes a symmetric encryption protocol that supplements 38 the protocols described in the User-based Security Model (USM), which is 39 a Security Subsystem for version 3 of the Simple Network Management 40 Protocol for use in the SNMP Architecture. The symmetric encryption 41 protocol described in this document is based on the AES cipher 42 algorithm, used in Cipher FeedBack Mode (CFB), with a key size of 128 43 bits. 45 Table of Contents 47 1 Introduction .................................................... 3 48 1.1 Goals and Constraints ......................................... 3 49 1.2 Key Localization .............................................. 3 50 1.3 Password Entropy and Storage .................................. 4 51 2 Definitions ..................................................... 4 52 3 CFB128-AES-128 Symmetric Encryption Protocol .................... 6 53 3.1 Mechanisms .................................................... 6 54 3.1.1 The AES-based Symmetric Encryption Protocol ................. 6 55 3.1.2 Localized Key, AES Encryption Key and Initialization Vector . 7 56 3.1.3 Data Encryption ............................................. 8 57 3.1.4 Data Decryption ............................................. 9 58 3.2 Elements of the AES Privacy Protocol .......................... 9 59 3.2.1 Users ....................................................... 9 60 3.2.2 msgAuthoritativeEngineID .................................... 10 61 3.2.3 SNMP Messages Using this Privacy Protocol ................... 10 62 3.2.4 Services provided by the AES Privacy Modules ................ 10 63 3.3 Elements of Procedure ......................................... 12 64 3.3.1 Processing an Outgoing Message .............................. 12 65 3.3.2 Processing an Incoming Message .............................. 13 66 4 Security Considerations ......................................... 13 67 5 Intellectual Property Rights Statement .......................... 14 68 6 IANA Considerations ............................................. 14 69 7 Acknowledgements ................................................ 15 70 8 References ...................................................... 15 71 8.1 Normative References .......................................... 15 72 8.2 Informative References ........................................ 16 73 9 Authors' Addresses .............................................. 16 74 10 Full Copyright Statement ....................................... 16 75 1. Introduction 77 Within the Architecture for describing Internet Management Frameworks 78 [RFC3411], the User-based Security Model (USM) [RFC3414] for SNMPv3 is 79 defined as a Security Subsystem within an SNMP engine. RFC 3414 80 describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the initial 81 authentication protocols and the use of CBC-DES as the initial privacy 82 protocol. The User-based Security Model, however, allows for other such 83 protocols to be used instead of or concurrently with these protocols. 85 This memo describes the use of CFB128-AES-128 as an alternative privacy 86 protocol for the User-based Security Model. The key words "MUST", "MUST 87 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 88 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 89 interpreted as described in [RFC2119]. 91 1.1. Goals and Constraints 93 The main goal of this memo is to provide a new privacy protocol for the 94 USM based on the Advanced Encryption Standard (AES) [FIPS-AES]. 96 The major constraint is to maintain a complete interchangeability of the 97 new protocol defined in this memo with existing authentication and 98 privacy protocols already defined in USM. 100 For a given user, the AES-based privacy protocol MUST be used with one 101 of the authentication protocols defined in RFC 3414 or an 102 algorithm/protocol providing equivalent functionality. 104 1.2. Key Localization 106 As defined in [RFC3414], a localized key is a secret key shared between 107 a user U and one authoritative SNMP engine E. Even though a user may 108 have only one pair of authentication and privacy passwords (and 109 consequently only one pair of keys) for the whole network, the actual 110 secrets shared between the user and each authoritative SNMP engine will 111 be different. This is achieved by key localization. 113 If the authentication protocol defined for a user U at the authoritative 114 SNMP engine E is one of the authentication protocols defined in 115 [RFC3414], the key localization is performed according to the two-step 116 process described in section 2.6 of [RFC3414]. 118 1.3. Password Entropy and Storage 120 The security of various cryptographic functions lies both in the 121 strength of the functions themselves against various forms of attack, 122 and also, perhaps more importantly, in the keying material that is used 123 with them. While theoretical attacks against cryptographic functions 124 are possible, it is vastly more probable that key guessing is the main 125 threat. 127 The following are recommended in regard to user passwords: 129 - Password length SHOULD be at least 12 octets. 130 - Password sharing SHOULD be prohibited so that passwords aren't 131 shared among multiple SNMP users. 132 - Implementations SHOULD support the use of randomly generated 133 passwords as a stronger form of security. 135 It is worth remembering that, as specified in [RFC3414], if a user's 136 password or a non-localized key is disclosed, then key localization will 137 not help and network security may be compromised. Therefore a user's 138 password or non-localized key MUST NOT be stored on a managed 139 device/node. Instead the localized key SHALL be stored (if at all), so 140 that, in case a device does get compromised, no other managed or 141 managing devices get compromised. 143 2. Definitions 145 SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN 146 IMPORTS 147 MODULE-IDENTITY, OBJECT-IDENTITY, 148 snmpModules FROM SNMPv2-SMI 149 snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; 151 snmpUsmAesMIB MODULE-IDENTITY 152 LAST-UPDATED "200304020000Z" 153 ORGANIZATION "IETF" 154 CONTACT-INFO "Uri Blumenthal 155 Lucent Technologies / Bell Labs 156 67 Whippany Rd. 157 14D-318 158 Whippany, NJ 07981, USA 159 973-386-2163 160 uri@bell-labs.com 162 Fabio Maino 163 Andiamo Systems, Inc. 164 375 East Tasman Drive 165 San Jose, CA 95134, USA 166 408-853-7530 167 fmaino@andiamo.com 169 Keith McCloghrie 170 Cisco Systems, Inc. 171 170 West Tasman Drive 172 San Jose, CA 95134-1706, USA 174 408-526-5260 175 kzm@cisco.com" 176 DESCRIPTION "Definitions of Object Identities needed for 177 the use of AES by SNMP's User-based Security 178 Model. 180 Copyright (C) The Internet Society (2003). 182 This version of this MIB module is part of RFC yyyy; 183 see the RFC itself for full legal notices. 184 Supplementary information may be available on 185 http://www.ietf.org/copyrights/ianamib.html." 187 -- RFC Ed.: replace yyyy with actual RFC number & remove this line 189 REVISION "200304020000Z" 190 DESCRIPTION "Initial version, published as RFCnnnn" 192 ::= { snmpModules nn } -- nn to be assigned by IANA 194 usmAesCfb128Protocol OBJECT-IDENTITY 195 STATUS current 196 DESCRIPTION "The CFB128-AES-128 Privacy Protocol." 197 REFERENCE "- Specification for the ADVANCED ENCRYPTION 198 STANDARD. Federal Information Processing 199 Standard (FIPS) Publication 197. 200 (November 2001). 202 - Dworkin, M., NIST Recommendation for Block 203 Cipher Modes of Operation, Methods and 204 Techniques. NIST Special Publication 800-38A 205 (December 2001). 206 " 207 ::= { snmpPrivProtocols mm } -- mm to be assigned by IANA 209 END 210 3. CFB128-AES-128 Symmetric Encryption Protocol 212 This section describes a Symmetric Encryption Protocol based on the AES 213 cipher algorithm [FIPS-AES], used in Cipher Feedback Mode as described 214 in [AES-MODE], using encryption keys with a size of 128 bits. 216 This protocol is identified by usmAesCfb128PrivProtocol. 218 The protocol usmAesCfb128PrivProtocol is an alternative to the privacy 219 protocol defined in [RFC3414]. 221 3.1. Mechanisms 223 In support of data confidentiality, an encryption algorithm is required. 224 An appropriate portion of the message is encrypted prior to being 225 transmitted. The User-based Security Model specifies that the scopedPDU 226 is the portion of the message that needs to be encrypted. 228 A secret value is shared by all SNMP engines which can legitimately 229 originate messages on behalf of the appropriate user. This secret value 230 in combination with a timeliness value and a 64-bit integer is used to 231 create the (localized) en/decryption key and the initialization vector. 233 3.1.1. The AES-based Symmetric Encryption Protocol 235 The Symmetric Encryption Protocol defined in this memo provides support 236 for data confidentiality. The designated portion of an SNMP message is 237 encrypted and included as part of the message sent to the recipient. 239 The AES (Advanced Encryption Standard) is the symmetric cipher algorithm 240 that the NIST (National Institute of Standards and Technology) has 241 selected in a four-year competitive process as Replacement for DES (Data 242 Encryption Standard). 244 The AES homepage, http://www.nist.gov/aes, contains a wealth of 245 information on AES including the Federal Information Processing Standard 246 [FIPS-AES] that fully specifies the Advanced Encryption Standard. 248 The following subsections contain descriptions of the relevant 249 characteristics of the AES ciphers used in the symmetric encryption 250 protocol described in this memo. 252 3.1.1.1. Mode of operation 254 The NIST Special Publication 800-38A [AES-MODE] recommends five 255 confidentiality modes of operation for use with AES: Electronic Codebook 256 (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output 257 Feedback (OFB), and Counter (CTR). 259 The symmetric encryption protocol described in this memo uses AES in CFB 260 mode with the parameter S (number of bits fed back) set to 128 according 261 to the definition of CFB mode given in [AES-MODE]. This mode requires an 262 Initialization Vector (IV) that is the same size as the block size of 263 the cipher algorithm. 265 3.1.1.2. Key Size 267 In the encryption protocol described by this memo AES is used with a key 268 size of 128 bits, as recommended in [AES-MODE]. 270 3.1.1.3. Block Size and Padding 272 The block size of the AES cipher algorithms used in the encryption 273 protocol described by this memo is 128 bits, as recommended in [AES- 274 MODE]. 276 3.1.1.4. Rounds 278 This parameter determines how many times a block is encrypted. The 279 encryption protocol described in this memo uses 10 rounds, as 280 recommended in [AES-MODE]. 282 3.1.2. Localized Key, AES Encryption Key and Initialization Vector 284 The size of the Localized Key (Kul) of an SNMP user, as described in 285 [RFC3414], depends on the authentication protocol defined for that user 286 U at the authoritative SNMP engine E. 288 The encryption protocol defined in this memo MUST be used with an 289 authentication protocol that generates a localized key with at least 128 290 bits. The authentication protocols described in [RFC3414] satisfy this 291 requirement. 293 3.1.2.1. AES Encryption Key and IV 295 The first 128 bits of the localized key Kul are used as the AES 296 encryption key. The 128-bit IV is obtained as the concatenation of the 297 authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP engine's 298 32-bit snmpEngineTime, and a local 64-bit integer. The 64-bit integer is 299 initialized to a pseudo-random value at boot time. 301 The IV is concatenated as follows: the 32-bit snmpEngineBoots is 302 converted to the first 4 octets (Most Significant Byte first), the 303 32-bit snmpEngineTime is converted to the subsequent 4 octets (Most 304 Significant Byte first), and the 64-bit integer is then converted to the 305 last 8 octets (Most Significant Byte first). The 64-bit integer is then 306 put into the msgPrivacyParameters field encoded as an OCTET STRING of 307 length 8 octets. The integer is then modified for the subsequent 308 message. We recommend that it is incremented by one until it reaches its 309 maximum value at which time it is wrapped. 311 An implementation can use any method to vary the value of the local 312 64-bit integer providing the chosen method never generates a duplicate 313 IV for the same key. 315 A duplicated IV can result in the very unlikely event that multiple 316 managers, communicating with a single authoritative engine, both 317 accidentally select the same 64-bit integer within a second. The 318 probability of such an event is very low, and doesn't affect 319 significantly the robustness of the mechanisms proposed. 321 The 64-bit integer must be placed in the privParameters field to enable 322 the receiving entity to compute the correct IV and to decrypt the 323 message. This 64-bit value is called the "salt" in this document. 325 Note that the sender and receiver must use the same IV value, i.e., they 326 must both use the same values of the individual components used to 327 create the IV. In particular, both sender and receiver must use the 328 values of snmpEngineBoots, snmpEngineTime and the 64-bit integer which 329 are contained in the relevant message (in the 330 msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime and 331 privParameters fields respectively). 333 3.1.3. Data Encryption 335 The data to be encrypted is treated as a sequence of octets. 337 The data is encrypted in Cipher Feedback mode with the parameter s set 338 to 128 according to the definition of CFB mode given in Section 6.3 of 339 [AES-MODE]. A clear diagram of the encryption and decryption process is 340 given in Figure 3 of [AES-MODE]. 342 The plaintext is divided into 128-bit blocks. The last block may have 343 fewer than 128 bits, and no padding is required. 345 The first input block is the IV, and the forward cipher operation is 346 applied to the IV to produce the first output block. The first 347 ciphertext block is produced by exclusive-ORing the first plaintext 348 block with the first output block. The ciphertext block is also used as 349 the input block for the subsequent forward cipher operation. 351 The process is repeated with the successive input blocks until a 352 ciphertext segment is produced from every plaintext segment. 354 The last ciphertext block is produced by exclusive-ORing the last 355 plaintext segment of r bits (r is less than or equal to 128) with the 356 segment of the r most significant bits of the last output block. 358 3.1.4. Data Decryption 360 In CFB decryption, the IV is the first input block, the first ciphertext 361 is used for the second input block, the second ciphertext is used for 362 the third input block, etc. The forward cipher function is applied to 363 each input block to produce the output blocks. The output blocks are 364 exclusive-ORed with the corresponding ciphertext blocks to recover the 365 plaintext blocks. 367 The last ciphertext block (whose size r is less than or equal to 128) is 368 exclusive-ORed with the segment of the r most significant bits of the 369 last output block to recover the last plaintext block of r bits. 371 3.2. Elements of the AES Privacy Protocol 373 This section contains definitions required to realize the privacy 374 modules defined by this memo. 376 3.2.1. Users 378 Data en/decryption using this Symmetric Encryption Protocol makes use of 379 a defined set of userNames. For any user on whose behalf a message must 380 be en/decrypted at a particular SNMP engine, that SNMP engine must have 381 knowledge of that user. An SNMP engine that needs to communicate with 382 another SNMP engine must also have knowledge of a user known to that 383 SNMP engine, including knowledge of the applicable attributes of that 384 user. 386 A user and its attributes are defined as follows: 388 389 An octet string representing the name of the user. 391 392 The algorithm used to protect messages generated on behalf of the 393 user from disclosure. 395 396 The user's secret key to be used as input to the generation of the 397 localized key for encrypting/decrypting messages generated on 398 behalf of the user. The length of this key MUST be greater than or 399 equal to 128 bits (16 octets). 401 402 The algorithm used to authenticate messages generated on behalf of 403 the user, which is also used to generate the localized version of 404 the secret key. 406 3.2.2. msgAuthoritativeEngineID 408 The msgAuthoritativeEngineID value contained in an authenticated message 409 specifies the authoritative SNMP engine for that particular message (see 410 the definition of SnmpEngineID in the SNMP Architecture document 411 [RFC3411]). 413 The user's (private) privacy key is different at each authoritative SNMP 414 engine and so the snmpEngineID is used to select the proper key for the 415 en/decryption process. 417 3.2.3. SNMP Messages Using this Privacy Protocol 419 Messages using this privacy protocol carry a msgPrivacyParameters field 420 as part of the msgSecurityParameters. For this protocol, the 421 privParameters field is the serialized OCTET STRING representing the 422 "salt" that was used to create the IV. 424 3.2.4. Services provided by the AES Privacy Modules 426 This section describes the inputs and outputs that the AES Privacy 427 module expects and produces when the User-based Security module invokes 428 one of the AES Privacy modules for services. 430 3.2.4.1. Services for Encrypting Outgoing Data 432 The AES privacy protocol assumes that the selection of the privKey is 433 done by the caller, and that the caller passes the localized secret key 434 to be used. 436 Upon completion the privacy module returns statusInformation and, if the 437 encryption process was successful, the encryptedPDU and the 438 msgPrivacyParameters encoded as an OCTET STRING. The abstract service 439 primitive is: 441 statusInformation = -- success or failure 442 encryptData( 443 IN encryptKey -- secret key for encryption 444 IN dataToEncrypt -- data to encrypt (scopedPDU) 445 OUT encryptedData -- encrypted data (encryptedPDU) 446 OUT privParameters -- filled in by service provider 447 ) 449 The abstract data elements are: 451 statusInformation 452 An indication of the success or failure of the encryption 453 process. In case of failure, it is an indication of the error. 454 encryptKey 455 The secret key to be used by the encryption algorithm. 456 The length of this key MUST be 16 octets. 457 dataToEncrypt 458 The data that must be encrypted. 459 encryptedData 460 The encrypted data upon successful completion. 461 privParameters 462 The privParameters encoded as an OCTET STRING. 464 3.2.4.2. Services for Decrypting Incoming Data 466 This AES privacy protocol assumes that the selection of the privKey is 467 done by the caller and that the caller passes the localized secret key 468 to be used. 470 Upon completion the privacy module returns statusInformation and, if the 471 decryption process was successful, the scopedPDU in plain text. The 472 abstract service primitive is: 474 statusInformation = 475 decryptData( 476 IN decryptKey -- secret key for decryption 477 IN privParameters -- as received on the wire 478 IN encryptedData -- encrypted data (encryptedPDU) 479 OUT decryptedData -- decrypted data (scopedPDU) 480 ) 482 The abstract data elements are: 484 statusInformation 485 An indication whether the data was successfully decrypted 486 and if not an indication of the error. 487 decryptKey 488 The secret key to be used by the decryption algorithm. 489 The length of this key MUST be 16 octets. 490 privParameters 491 The 64-bit integer to be used to calculate the IV. 492 encryptedData 493 The data to be decrypted. 494 decryptedData 495 The decrypted data. 497 3.3. Elements of Procedure 499 This section describes the procedures for the AES privacy protocol for 500 SNMP's User-based Security Model. 502 3.3.1. Processing an Outgoing Message 504 This section describes the procedure followed by an SNMP engine whenever 505 it must encrypt part of an outgoing message using the 506 usmAesCfb128PrivProtocol. 508 1) The secret encryptKey is used to construct the AES encryption key, 509 as described in section 3.1.2.1. 511 2) The privParameters field is set to the serialization according to 512 the rules in [RFC3417] of an OCTET STRING representing the 64-bit 513 integer that will be used in the IV as described in section 514 3.1.2.1. 516 3) The scopedPDU is encrypted (as described in section 3.1.3) and the 517 encrypted data is serialized according to the rules in [RFC3417] as 518 an OCTET STRING. 520 4) The serialized OCTET STRING representing the encrypted scopedPDU 521 together with the privParameters and statusInformation indicating 522 success is returned to the calling module. 524 3.3.2. Processing an Incoming Message 526 This section describes the procedure followed by an SNMP engine whenever 527 it must decrypt part of an incoming message using the 528 usmAesCfb128PrivProtocol. 530 1) If the privParameters field is not an 8-octet OCTET STRING, then an 531 error indication (decryptionError) is returned to the calling 532 module. 534 2) The 64-bit integer is extracted from the privParameters field. 536 3) The secret decryptKey and the 64-bit integer are then used to 537 construct the AES decryption key and the IV that is computed as 538 described in section 3.1.2.1. 540 4) The encryptedPDU is then decrypted (as described in section 3.1.4). 542 5) If the encryptedPDU cannot be decrypted, then an error indication 543 (decryptionError) is returned to the calling module. 545 6) The decrypted scopedPDU and statusInformation indicating success 546 are returned to the calling module. 548 4. Security Considerations 550 The security of the cryptographic functions defined in this document 551 lies both in the strength of the functions themselves against various 552 forms of attack, and also, perhaps more importantly, in the keying 553 material that is used with them. The recommendations in Section 1.3 554 SHOULD be followed to ensure maximum entropy to the selected passwords, 555 and to protect the passwords while stored. 557 The security of the CFB mode relies upon the use of a unique IV for each 558 message encrypted with the same key [CRYPTO-B]. If the IV is not 559 unique, a cryptanalyst can recover the corresponding plaintext. 561 Section 3.1.2.1 defines a procedure to derive the IV from a local 64-bit 562 integer (the salt) initialized to a pseudo-random value at boot time. 563 An implementation can use any method to vary the value of the local 564 64-bit integer providing the chosen method never generates a duplicate 565 IV for the same key. 567 The procedure of section 3.1.2.1 suggests a method to vary the local 568 64-bit integer value that generates unique IVs for every message. This 569 method can result in a duplicated IV in the very unlikely event that 570 multiple managers, communicating with a single authoritative engine, 571 both accidentally select the same 64-bit integer within a second. The 572 probability of such an event is very low, and doesn't affect 573 significantly the robustness of the mechanisms proposed. 575 This AES-based privacy protocol MUST be used with one of the 576 authentication protocols defined in RFC 3414 or with an 577 algorithm/protocol providing equivalent functionality (including 578 integrity), because CFB encryption mode does not detect ciphertext 579 modifications. 581 For further security considerations, the reader is encouraged to read 582 [RFC3414], and the documents that describe the actual cipher algorithms. 584 5. Intellectual Property Rights Statement 586 The IETF takes no position regarding the validity or scope of any 587 intellectual property or other rights that might be claimed to pertain 588 to the implementation or use of the technology described in this 589 document or the extent to which any license under such rights might or 590 might not be available; neither does it represent that it has made any 591 effort to identify any such rights. Information on the IETF's 592 procedures with respect to rights in standards-track and standards 593 related documentation can be found in BCP-11. Copies of claims of rights 594 made available for publication and any assurances of licenses to be made 595 available, or the result of an attempt made to obtain a general license 596 or permission for the use of such proprietary rights by implementers or 597 users of this specification can be obtained from the IETF Secretariat. 599 The IETF invites any interested party to bring to its attention any 600 copyrights, patents or patent applications, or other proprietary rights, 601 which may cover technology that may be required to practice this 602 standard. Please address the information to the IETF Executive 603 Director. 605 6. IANA Considerations 607 IANA is requested to assign an OID for the snmpUsmAesMIB module under 608 the snmpModules subtree, maintained in the registry at 609 http://www.iana.org/assignments/smi-numbers. The suggested value is 20. 611 IANA is requested to assign an OID for the usmAesCfb128Protocol under 612 the snmpPrivProtocols registration point, as defined in RFC 3411 613 [RFC3411]. The suggested value is 4. 615 7. Acknowledgements 617 Portions of this text, as well as its general structure, were 618 unabashedly lifted from [RFC3414]. The authors are grateful to many of 619 the SNMPv3 WG members for their help, especially Wes Hardaker, Steve 620 Moulton, Randy Presuhn, David Town, Bert Wijnen. Security discussions 621 with Steve Bellovin helped to streamline this protocol. 623 8. References 625 8.1. Normative References 627 [AES-MODE] 628 Dworkin, M., "NIST Recommendation for Block Cipher Modes of 629 Operation, Methods and Techniques", NIST Special Publication 630 800-38A, December 2001. 632 [FIPS-AES] 633 "Specification for the ADAVANCED ENCRYPTION STANDARD (AES)", 634 Federal Information Processing Standard (FIPS) Publication 197, 635 November 2001. 637 [RFC2119] 638 Bradner, S., "Key words for use in RFCs to Indicate Requirement 639 Levels", BCP 14, RFC 2119, March 1997. 641 [RFC2578] 642 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. 643 and S. Waldbusser, "Structure of Management Information Version 2 644 (SMIv2)", STD 58, RFC 2578, April 1999. 646 [RFC3411] 647 Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 648 Describing Simple Network Management Protocol (SNMP) Management 649 Frameworks", STD 62, RFC 3411, December 2002. 651 [RFC3414] 652 Blumenthal, U. and B. Wijnen, "User-based Security Model(USM) for 653 version 3 of the Simple Network Management Protocol (SNMPv3)", STD 654 62, RFC 3414, December 2002. 656 [RFC3417] 657 Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 658 "Transport Mappings for the Simple Network Management Protocol 659 (SNMP)", STD 62, RFC 3417, December 2002. 661 8.2. Informative References 663 [CRYPTO-B] 664 Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security 665 Protocols", Proceedings of the Symposium on Network and Distributed 666 System Security, San Diego, CA, pp. 155-160, February 1997. 668 9. Authors' Addresses 670 Uri Blumenthal 671 Lucent Technologies / Bell Labs 672 67 Whippany Rd. Phone: +1-973-386-2163 673 14D-318 Email: uri@bell-labs.com 674 Whippany, NJ 07981, USA 676 Fabio Maino 677 Andiamo Systems, Inc. 678 375 East Tasman Drive Phone: +1-408-853-7530 679 San Jose, CA. 95134 USA Email: fmaino@andiamo.com 681 Keith McCloghrie 682 Cisco Systems, Inc. 683 170 East Tasman Drive Phone: +1-408-526-5260 684 San Jose, CA. 95134-1706 USA Email: kzm@cisco.com 686 10. Full Copyright Statement 688 Copyright (C) The Internet Society (2003). All Rights Reserved. 690 This document and translations of it may be copied and furnished to 691 others, and derivative works that comment on or otherwise explain it or 692 assist in its implementation may be prepared, copied, published and 693 distributed, in whole or in part, without restriction of any kind, 694 provided that the above copyright notice and this paragraph are included 695 on all such copies and derivative works. However, this document itself 696 may not be modified in any way, such as by removing the copyright notice 697 or references to the Internet Society or other Internet organizations, 698 except as needed for the purpose of developing Internet standards in 699 which case the procedures for copyrights defined in the Internet 700 Standards process must be followed, or as required to translate it into 701 languages other than English. 703 The limited permissions granted above are perpetual and will not be 704 revoked by the Internet Society or its successors or assigns. 706 This document and the information contained herein is provided on an "AS 707 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 708 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 709 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 710 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTAB