idnits 2.17.1 draft-ietf-opsawg-hmac-sha-2-usm-snmp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2015) is 3292 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG J. Merkle, Ed. 3 Internet-Draft Secunet Security Networks 4 Intended status: Standards Track M. Lochter 5 Expires: October 22, 2015 BSI 6 April 20, 2015 8 HMAC-SHA-2 Authentication Protocols in USM for SNMPv3 9 draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 11 Abstract 13 This memo specifies new HMAC-SHA-2 authentication protocols for the 14 User-based Security Model (USM) for SNMPv3 defined in RFC 3414. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 22, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. The Internet-Standard Management Framework . . . . . . . . . 3 52 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. The HMAC-SHA-2 Authentication Protocols . . . . . . . . . . . 3 54 4.1. Deviations from the HMAC-SHA-96 Authentication 55 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2.1. Processing an Outgoing Message . . . . . . . . . . . 5 58 4.2.2. Processing an Incoming Message . . . . . . . . . . . 6 59 5. Key Localization and Key Change . . . . . . . . . . . . . . . 6 60 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 6 61 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 62 7.1. Relationship to SNMP-USER-BASED-SM-MIB . . . . . . . . . 7 63 7.2. Relationship to SNMP-FRAMEWORK-MIB . . . . . . . . . . . 7 64 7.3. MIB modules required for IMPORTS . . . . . . . . . . . . 7 65 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 9.1. Use of the HMAC-SHA-2 authentication protocols in USM . . 10 68 9.2. Cryptographic strength of the authentication protocols . 10 69 9.3. Derivation of keys from passwords . . . . . . . . . . . . 11 70 9.4. Access to the SNMP-USM-HMAC-SHA2-MIB . . . . . . . . . . 11 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 11.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 This memo defines a portion of the Management Information Base (MIB) 80 for use with network management protocols. In particular it defines 81 additional authentication protocols for the User-based Security Model 82 (USM) for version 3 of the Simple Network Management Protocol 83 (SNMPv3) specified in RFC 3414 [RFC3414]. 85 In RFC 3414, two different authentication protocols, HMAC-MD5-96 and 86 HMAC-SHA-96, are defined based on the hash functions MD5 and SHA-1, 87 respectively. This memo specifies new HMAC-SHA-2 authentication 88 protocols for USM using an HMAC based on the SHA-2 family of hash 89 functions [SHA] and truncated to 128 bits for SHA-224, to 192 bits 90 for SHA-256, to 256 bits for SHA-384, and to 384 bits for SHA-512. 91 These protocols are straightforward adaptations of the authentication 92 protocols HMAC-MD5-96 and HMAC-SHA-96 to the SHA-2 based HMAC. 94 2. The Internet-Standard Management Framework 96 For a detailed overview of the documents that describe the current 97 Internet-Standard Management Framework, please refer to section 7 of 98 RFC 3410 [RFC3410]. 100 Managed objects are accessed via a virtual information store, termed 101 the Management Information Base or MIB. MIB objects are generally 102 accessed through the Simple Network Management Protocol (SNMP). 103 Objects in the MIB are defined using the mechanisms defined in the 104 Structure of Management Information (SMI). This memo specifies a MIB 105 module that is compliant to the SMIv2, which is described in STD 58, 106 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 107 [RFC2580]. 109 3. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in BCP 14, RFC 2119 114 [RFC2119]. 116 4. The HMAC-SHA-2 Authentication Protocols 118 This section describes the HMAC-SHA-2 authentication protocols. They 119 use the SHA-2 hash functions, which are described in FIPS PUB 180-4 120 [SHA] and RFC 6234 [RFC6234], in HMAC mode described in RFC 2104 121 [RFC2104] and RFC 6234, truncating the output to 128 bits for SHA- 122 224, 192 bits for SHA-256, 256 bits for SHA-384, and 384 bits for 123 SHA-512. RFC 6234 also provides source code for all the SHA-2 124 algorithms and HMAC (without truncation). It also includes test 125 harness and standard test vectors for all the defined hash functions 126 and HMAC examples. 128 The following protocols are defined: 130 usmHMAC128SHA224AuthProtocol: uses SHA-224 and truncates the 131 output to 128 bits (16 octets); 133 usmHMAC192SHA256AuthProtocol: uses SHA-256 and truncates the 134 output to 192 bits (24 octets); 136 usmHMAC256SHA384AuthProtocol: uses SHA-384 and truncates the 137 output to 256 bits (32 octets); 139 usmHMAC384SHA512AuthProtocol: uses SHA-512 and truncates the 140 output to 384 bits (48 octets). 142 Implementations conforming to this specification MUST support 143 usmHMAC192SHA256AuthProtocol and SHOULD support 144 usmHMAC384SHA512AuthProtocol. The protocols 145 usmHMAC128SHA224AuthProtocol and usmHMAC256SHA384AuthProtocol are 146 OPTIONAL. 148 4.1. Deviations from the HMAC-SHA-96 Authentication Protocol 150 All the HMAC-SHA-2 authentication protocols are straightforward 151 adaptations of the HMAC-MD5-96 and HMAC-SHA-96 authentication 152 protocols. Precisely, they differ from the HMAC-MD5-96 and HMAC- 153 SHA-96 authentication protocols in the following aspects: 155 o The SHA-2 hash function is used to compute the message digest in 156 the HMAC computation according to RFC 2104 and RFC 6234, as 157 opposed to the MD5 hash function [RFC1321] and SHA-1 hash function 158 [SHA] used in HMAC-MD5-96 and HMAC-SHA-96, respectively. 159 Consequently, the length of the message digest prior to truncation 160 is 224 bits for SHA-224 based protocol, 256 bits for SHA-256 based 161 protocol, 384 bits for SHA-384 based protocol, and 512 bits for 162 SHA-512 based protocol. 164 o The resulting message digest (output of HMAC) is truncated to 166 * 16 octets for usmHMAC128SHA224AuthProtocol 168 * 24 octets for usmHMAC192SHA256AuthProtocol 170 * 32 octets for usmHMAC256SHA384AuthProtocol 172 * 48 octets for usmHMAC384SHA512AuthProtocol 174 as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC- 175 SHA-96. 177 o The user's secret key to be used when calculating a digest MUST 178 be: 180 * 28 octets long and derived with SHA-224 for the SHA-224 based 181 protocol usmHMAC128SHA224AuthProtocol 183 * 32 octets long and derived with SHA-256 for the SHA-256 based 184 protocol usmHMAC192SHA256AuthProtocol 186 * 48 octets long and derived with SHA-384 for the SHA-384 based 187 protocol usmHMAC256SHA384AuthProtocol 189 * 64 octets long and derived with SHA-512 for the SHA-512 based 190 protocol usmHMAC384SHA512AuthProtocol 192 as opposed to the keys being 16 and 20 octets long in HMAC-MD5-96 193 and HMAC-SHA-96, respectively. 195 4.2. Processing 197 This section describes the procedures for the HMAC-SHA-2 198 authentication protocols. The descriptions are based on the 199 definition of services and data elements defined for HMAC-SHA-96 in 200 RFC 3414 with the deviations listed in Section 4.1. 202 4.2.1. Processing an Outgoing Message 204 Values of constants M (the length of the secret key in octets) and N 205 (the length of the MAC output in octets) used below, are: 207 usmHMAC128SHA224AuthProtocol: M=28, N=16; 209 usmHMAC192SHA256AuthProtocol: M=32, N=24; 211 usmHMAC256SHA384AuthProtocol: M=48, N=32; 213 usmHMAC384SHA512AuthProtocol: M=64, N=48. 215 correspondingly. 217 This section describes the procedure followed by an SNMP engine 218 whenever it must authenticate an outgoing message using one of the 219 authentication protocols defined above. 221 1. The msgAuthenticationParameters field is set to serialization, 222 according to the rules in RFC 3417 [RFC3417], of an OCTET STRING 223 containing N zero octets. 225 2. From the secret authKey of M octets, calculate the HMAC-SHA-2 226 digest over it according to RFC 6234. Take the first N octets of 227 the final digest - this is the Message Authentication Code (MAC). 229 3. Replace the msgAuthenticationParameters field with the MAC 230 obtained in the previous step. 232 4. The authenticatedWholeMsg is then returned to the caller together 233 with statusInformation indicating success. 235 4.2.2. Processing an Incoming Message 237 Values of the constants M and N are the same as in Section 4.2.1, and 238 are selected based on which authentication protocol is configured for 239 the given USM usmUser Table entry. 241 This section describes the procedure followed by an SNMP engine 242 whenever it must authenticate an incoming message using one of the 243 HMAC-SHA-2 authentication protocols. 245 1. If the digest received in the msgAuthenticationParameters field 246 is not N octets long, then an failure and an errorIndication 247 (authenticationError) is returned to the calling module. 249 2. The MAC received in the msgAuthenticationParameters field is 250 saved. 252 3. The digest in the msgAuthenticationParameters field is replaced 253 by the N zero octets. 255 4. Using the secret authKey, the HMAC is calculated over the 256 wholeMsg. 258 5. N first octets of the above HMAC are taken as the computed MAC 259 value. 261 6. The msgAuthenticationParameters field is replaced with the MAC 262 value that was saved in step 2. 264 7. The newly calculated MAC is compared with the MAC saved in step 265 2. If they do not match, then a failure and an errorIndication 266 (authenticationFailure) are returned to the calling module. 268 8. The authenticatedWholeMsg and statusInformation indicating 269 success are then returned to the caller. 271 5. Key Localization and Key Change 273 For any of the protocols defined in Section 4, key localization and 274 key change SHALL be performed according to RFC 3414 using the SHA-2 275 hash function applied in the respective protocol. 277 6. Structure of the MIB Module 279 The MIB module specified in this memo does not define any managed 280 objects, subtrees, notifications or tables, but only object 281 identities (for authentication protocols) under a subtree of an 282 existing MIB. 284 7. Relationship to Other MIB Modules 286 7.1. Relationship to SNMP-USER-BASED-SM-MIB 288 RFC 3414 specifies the MIB module for the User-based Security Model 289 (USM) for SNMPv3 (SNMP-USER-BASED-SM-MIB), which defines 290 authentication protocols for USM based on the hash functions MD5 and 291 SHA-1, respectively. The following MIB module defines new HMAC-SHA2 292 authentication protocols for USM based on the SHA-2 hash functions 293 [SHA]. The use of the HMAC-SHA2 authentication protocols requires 294 the usage of the objects defined in the SNMP-USER-BASED-SM-MIB. 296 7.2. Relationship to SNMP-FRAMEWORK-MIB 298 RFC 3411 [RFC3411] specifies the SNMP-FRAMEWORK-MIB, which defines a 299 subtree snmpAuthProtocols for SNMP authentication protocols. The 300 following MIB module defines new authentication protocols in the 301 snmpAuthProtocols subtree. 303 7.3. MIB modules required for IMPORTS 305 The following MIB module IMPORTS definitions from SNMPv2-SMI 306 [RFC2578] and SNMP-FRAMEWORK-MIB [RFC3411]. 308 8. Definitions 310 SNMP-USM-HMAC-SHA2-MIB DEFINITIONS ::= BEGIN 311 IMPORTS 312 MODULE-IDENTITY, OBJECT-IDENTITY, 313 snmpModules FROM SNMPv2-SMI -- [RFC2578] 314 snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411] 316 snmpUsmHmacSha2MIB MODULE-IDENTITY 317 LAST-UPDATED "201503090000Z" -- 9th Mar 2015, midnight 318 -- RFC Ed.: replace with publication date & remove this line 319 ORGANIZATION "SNMPv3 Working Group" 320 CONTACT-INFO "WG email: OPSAWG@ietf.org 321 Subscribe: 322 https://www.ietf.org/mailman/listinfo/opsawg 323 Editor: Johannes Merkle 324 secunet Security Networks 325 postal: Mergenthaler Allee 77 326 D-65760 Eschborn 327 Germany 328 phone: +49 20154543091 329 email: johannes.merkle@secunet.com 330 Co-Editor: Manfred Lochter 331 Bundesamt fuer Sicherheit in der 332 Informationstechnik (BSI) 333 postal: Postfach 200363 334 D-53133 Bonn 335 Germany 336 phone: +49 228 9582 5643 337 email: manfred.lochter@bsi.bund.de" 339 DESCRIPTION "Definitions of Object Identities needed 340 for the use of HMAC-SHA2 by SNMP's User-based 341 Security Model. 343 Copyright (c) 2014 IETF Trust and the persons identified 344 as authors of the code. All rights reserved. 346 Redistribution and use in source and binary forms, with 347 or without modification, is permitted pursuant to, and 348 subject to the license terms contained in, the Simplified 349 BSD License set forth in Section 4.c of the IETF Trust's 350 Legal Provisions Relating to IETF Documents 351 (http://trustee.ietf.org/license-info)." 353 REVISION "201503090000Z" -- 9th Mar 2015, midnight 354 -- RFC Ed.: replace with publication date & remove this line 355 DESCRIPTION "Initial version, published as RFC TBD" 356 -- RFC Ed.: replace TBD with actual RFC number & remove this line 358 ::= { snmpModules nn } -- nn to be assigned by IANA 359 -- RFC Ed.: replace nn with actual number assigned by IANA & remove 360 -- this comment 362 usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY 363 STATUS current 364 DESCRIPTION "The Authentication Protocol 365 usmHMAC128SHA224AuthProtocol uses HMAC-SHA-224 and 366 truncates output to 128 bits." 367 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 368 Keyed-Hashing for Message Authentication, RFC 2104. 369 - National Institute of Standards and Technology, 370 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 371 ::= { snmpAuthProtocols aa } -- aa to be assigned by IANA 372 -- RFC Ed.: replace aa with actual number assigned by IANA & remove 373 -- this comment 375 usmHMAC192SHA256AuthProtocol OBJECT-IDENTITY 376 STATUS current 377 DESCRIPTION "The Authentication Protocol 378 usmHMAC192SHA256AuthProtocol uses HMAC-SHA-256 and 379 truncates output to 192 bits." 380 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 381 Keyed-Hashing for Message Authentication, RFC 2104. 382 - National Institute of Standards and Technology, 383 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 384 ::= { snmpAuthProtocols bb } -- bb to be assigned by IANA 385 -- RFC Ed.: replace bb with actual number assigned by IANA & remove 386 -- this comment 388 usmHMAC256SHA384AuthProtocol OBJECT-IDENTITY 389 STATUS current 390 DESCRIPTION "The Authentication Protocol 391 usmHMAC256SHA384AuthProtocol uses HMAC-SHA-384 and 392 truncates output to 256 bits." 393 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 394 Keyed-Hashing for Message Authentication, RFC 2104. 395 - National Institute of Standards and Technology, 396 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 397 ::= { snmpAuthProtocols cc } -- cc to be assigned by IANA 398 -- RFC Ed.: replace cc with actual number assigned by IANA & remove 399 -- this comment 401 usmHMAC384SHA512AuthProtocol OBJECT-IDENTITY 402 STATUS current 403 DESCRIPTION "The Authentication Protocol 404 usmHMAC384SHA512AuthProtocol uses HMAC-SHA-512 and 405 truncates output to 384 bits." 406 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 407 Keyed-Hashing for Message Authentication, RFC 2104. 408 - National Institute of Standards and Technology, 409 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 410 ::= { snmpAuthProtocols dd } -- dd to be assigned by IANA 411 -- RFC Ed.: replace dd with actual number assigned by IANA & remove 412 -- this comment 414 END 416 9. Security Considerations 417 9.1. Use of the HMAC-SHA-2 authentication protocols in USM 419 The security considerations of RFC 3414 also apply to the HMAC-SHA-2 420 authentication protocols defined in this document. 422 9.2. Cryptographic strength of the authentication protocols 424 At the time of publication of this document, all of the HMAC-SHA-2 425 authentication protocols provide a very high level of security. The 426 security of each HMAC-SHA-2 authentication protocol depends on the 427 parameters used in the corresponding HMAC computation, which are the 428 length of the key (if the key has maximum entropy), the size of the 429 hash function's internal state, and the length of the truncated MAC. 430 For the HMAC-SHA-2 authentication protocols these values are as 431 follows (values are given in bits). 433 +------------------------------+---------+----------------+---------+ 434 | Protocol | Key | Size of | MAC | 435 | | length | internal state | length | 436 +------------------------------+---------+----------------+---------+ 437 | usmHMAC128SHA224AuthProtocol | 224 | 256 | 128 | 438 | usmHMAC192SHA256AuthProtocol | 256 | 256 | 192 | 439 | usmHMAC256SHA384AuthProtocol | 384 | 512 | 256 | 440 | usmHMAC384SHA512AuthProtocol | 512 | 512 | 384 | 441 +------------------------------+---------+----------------+---------+ 443 Table 1: HMAC parameters of the HMAC-SHA-2 authentication protocols 445 The security of the HMAC scales with both the key length and the size 446 of the internal state: longer keys render key guessing attacks more 447 difficult, and a larger internal state decreases the success 448 probability of MAC forgeries based on internal collisions of the hash 449 function. 451 The role of the truncated output length is more complicated: 452 according to [BCK], there is a trade-off in that "by outputting less 453 bits the attacker has less bits to predict in a MAC forgery but, on 454 the other hand, the attacker also learns less about the output of the 455 compression function from seeing the authentication tags computed by 456 legitimate parties"; thus, truncation weakens the HMAC against 457 forgery by guessing, but at the same time strengthens it against 458 chosen message attacks aiming at MAC forgery based on internal 459 collisions or at key guessing. RFC 2104 and [BCK] allow truncation 460 to any length that is not less than half the size of the internal 461 state. 463 Further discussion of the security of the HMAC construction is given 464 in RFC 2104. 466 9.3. Derivation of keys from passwords 468 If secret keys to be used for HMAC-SHA-2 authentication protocols are 469 derived from passwords, the derivation SHOULD be performed using the 470 password-to-key algorithm from Appendix A.1 of RFC 3414 with MD5 471 being replaced by the SHA-2 hash function H used in the HMAC-SHA-2 472 authentication protocol. Specifically, the password is converted 473 into the required secret key by the following steps: 475 o forming a string of length 1,048,576 octets by repeating the value 476 of the password as often as necessary, truncating accordingly, and 477 using the resulting string as the input to the hash function H. 478 The resulting digest, termed "digest1", is used in the next step. 480 o a second string is formed by concatenating digest1, the SNMP 481 engine's snmpEngineID value, and digest1. This string is used as 482 input to the hash function H. 484 9.4. Access to the SNMP-USM-HMAC-SHA2-MIB 486 The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values 487 for use in other MIB modules. It does not define any objects that 488 can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by 489 itself, have any effect on the security of the Internet. 491 The values defined in this module are expected to be used with the 492 usmUserTable defined in the SNMP-USER-BASED-SM-MIB [RFC3414]. The 493 considerations in Section 11.5 of RFC 3414 should be taken into 494 account. 496 10. IANA Considerations 498 IANA is requested to assign an OID for 500 +--------------------+-------------------------+ 501 | Descriptor | OBJECT IDENTIFIER value | 502 +--------------------+-------------------------+ 503 | snmpUsmHmacSha2MIB | { snmpModules nn } | 504 +--------------------+-------------------------+ 506 Table 2: OID of MIB 508 with nn appearing in the MIB module definition in Section 8. 510 Furthermore, IANA is requested to assign a value in the 511 SnmpAuthProtocols registry for each of the following protocols. 513 +------------------------------+-------+-----------+ 514 | Description | Value | Reference | 515 +------------------------------+-------+-----------+ 516 | usmHMAC128SHA224AuthProtocol | aa | RFC YYYY | 517 | usmHMAC192SHA256AuthProtocol | bb | RFC YYYY | 518 | usmHMAC256SHA384AuthProtocol | cc | RFC YYYY | 519 | usmHMAC384SHA512AuthProtocol | dd | RFC YYYY | 520 +------------------------------+-------+-----------+ 522 Table 3: Code points assigned to HMAC-SHA-2 authentication protocols 524 -- RFC Ed.: replace YYYY with actual RFC number and remove this line 526 with aa, bb, cc, etc. appearing in the MIB module definition in 527 Section 8. 529 11. References 531 11.1. Normative References 533 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 534 Hashing for Message Authentication", RFC 2104, February 535 1997. 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 541 Schoenwaelder, Ed., "Structure of Management Information 542 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 544 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 545 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 546 58, RFC 2579, April 1999. 548 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 549 "Conformance Statements for SMIv2", STD 58, RFC 2580, 550 April 1999. 552 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 553 (USM) for version 3 of the Simple Network Management 554 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 556 [SHA] National Institute of Standards and Technology, "Secure 557 Hash Standard (SHS)", FIPS PUB 180-4, March 2012. 559 [RFC6234] Eastlate 3rd, D. and T. Hansen, "US Secure Hash Algorithms 560 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 562 11.2. Informative References 564 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 565 April 1992. 567 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 568 "Introduction and Applicability Statements for Internet- 569 Standard Management Framework", RFC 3410, December 2002. 571 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 572 Architecture for Describing Simple Network Management 573 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 574 December 2002. 576 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 577 Management Protocol (SNMP)", STD 62, RFC 3417, December 578 2002. 580 [BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keyed Hash 581 Functions for Message Authentication", Advances in 582 Cryptology - CRYPTO 99, Lecture Notes in Computer Science 583 1109, Springer Verlag, 1996. 585 Authors' Addresses 587 Johannes Merkle (editor) 588 Secunet Security Networks 589 Mergenthaler Allee 77 590 65760 Eschborn 591 Germany 593 Phone: +49 201 5454 3091 594 EMail: johannes.merkle@secunet.com 596 Manfred Lochter 597 BSI 598 Postfach 200363 599 53133 Bonn 600 Germany 602 Phone: +49 228 9582 5643 603 EMail: manfred.lochter@bsi.bund.de