idnits 2.17.1 draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2015) is 3355 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: 3 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: August 22, 2015 BSI 6 February 18, 2015 8 HMAC-SHA-2 Authentication Protocols in USM for SNMP 9 draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 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 August 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 . . 9 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 76 1. Introduction 78 This memo defines a portion of the Management Information Base (MIB) 79 for use with network management protocols. In particular it defines 80 additional authentication protocols for the User-based Security Model 81 (USM) for version 3 of the Simple Network Management Protocol 82 (SNMPv3) specified in RFC 3414 [RFC3414]. 84 In RFC 3414, two different authentication protocols, HMAC-MD5-96 and 85 HMAC-SHA-96, are defined based on the hash functions MD5 and SHA-1, 86 respectively. This memo specifies new HMAC-SHA-2 authentication 87 protocols for USM using an HMAC based on the SHA-2 family of hash 88 functions [SHA] and truncated to 128 bits for SHA-224, to 192 bits 89 for SHA-256, to 256 bits for SHA-384, and to 384 bits for SHA-512. 90 These protocols are straightforward adaptations of the authentication 91 protocols HMAC-MD5-96 and HMAC-SHA-96 to the SHA-2 based HMAC. 93 2. The Internet-Standard Management Framework 95 For a detailed overview of the documents that describe the current 96 Internet-Standard Management Framework, please refer to section 7 of 97 RFC 3410 [RFC3410]. 99 Managed objects are accessed via a virtual information store, termed 100 the Management Information Base or MIB. MIB objects are generally 101 accessed through the Simple Network Management Protocol (SNMP). 102 Objects in the MIB are defined using the mechanisms defined in the 103 Structure of Management Information (SMI). This memo specifies a MIB 104 module that is compliant to the SMIv2, which is described in STD 58, 105 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 106 [RFC2580]. 108 3. Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in BCP 14, RFC 2119 113 [RFC2119]. 115 4. The HMAC-SHA-2 Authentication Protocols 117 This section describes the HMAC-SHA-2 authentication protocols. They 118 use the SHA-2 hash functions, which are described in [SHA] and 119 [RFC6234], in HMAC mode described in [RFC2104] and [RFC6234], 120 truncating the output to 128 bits for SHA-224, 192 bits for SHA-256, 121 256 bits for SHA-384, and 384 bits for SHA-512. [RFC6234] also 122 provides source code for all the SHA-2 algorithms and HMAC (without 123 truncation). It also includes test harness and standard test vectors 124 for all the defined hash functions and HMAC examples. 126 The following protocols are defined: 128 usmHMAC128SHA224AuthProtocol: uses SHA-224 and truncates the 129 output to 128 bits (16 octets); 131 usmHMAC192SHA256AuthProtocol: uses SHA-256 and truncates the 132 output to 192 bits (24 octets); 134 usmHMAC256SHA384AuthProtocol: uses SHA-384 and truncates the 135 output to 256 bits (32 octets); 137 usmHMAC384SHA512AuthProtocol: uses SHA-512 and truncates the 138 output to 384 bits (48 octets). 140 Implementations conforming to this specification MUST support 141 usmHMAC192SHA256AuthProtocol and SHOULD support 142 usmHMAC384SHA512AuthProtocol. The protocols 143 usmHMAC128SHA224AuthProtocol and usmHMAC256SHA384AuthProtocol are 144 OPTIONAL. 146 4.1. Deviations from the HMAC-SHA-96 Authentication Protocol 148 All the HMAC-SHA-2 authentication protocols are straightforward 149 adaptations of the HMAC-MD5-96 and HMAC-SHA-96 authentication 150 protocols. Precisely, they differ from the HMAC-MD5-96 and HMAC- 151 SHA-96 authentication protocols in the following aspects: 153 o The SHA-2 hash function is used to compute the message digest in 154 the HMAC computation according to [RFC2104] and [RFC6234], as 155 opposed to the MD5 hash function [RFC1321] and SHA-1 hash function 156 [SHA] used in HMAC-MD5-96 and HMAC-SHA-96, respectively. 157 Consequently, the length of the message digest prior to truncation 158 is 224 bits for SHA-224 based protocol, 256 bits for SHA-256 based 159 protocol, 384 bits for SHA-384 based protocol, and 512 bits for 160 SHA-512 based protocol. 162 o The resulting message digest (output of HMAC) is truncated to 164 * 16 octets for usmHMAC128SHA224AuthProtocol 166 * 24 octets for usmHMAC192SHA256AuthProtocol 168 * 32 octets for usmHMAC256SHA384AuthProtocol 170 * 48 octets for usmHMAC384SHA512AuthProtocol 172 as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC- 173 SHA-96. 175 o The user's secret key to be used when calculating a digest MUST 176 be: 178 * 28 octets long and derived with SHA-224 for the SHA-224 based 179 protocol usmHMAC128SHA224AuthProtocol 181 * 32 octets long and derived with SHA-256 for the SHA-256 based 182 protocol usmHMAC192SHA256AuthProtocol 184 * 48 octets long and derived with SHA-384 for the SHA-384 based 185 protocol usmHMAC256SHA384AuthProtocol 187 * 64 octets long and derived with SHA-512 for the SHA-512 based 188 protocol usmHMAC384SHA512AuthProtocol 190 as opposed to the keys being 16 and 20 octets long in HMAC-MD5-96 191 and HMAC-SHA-96, respectively. 193 4.2. Processing 195 This section describes the procedures for the HMAC-SHA-2 196 authentication protocols. The descriptions are based on the 197 definition of services and data elements defined for HMAC-SHA-96 in 198 RFC 3414 [RFC3414] with the deviations listed in Section 4.1. 200 4.2.1. Processing an Outgoing Message 202 Values of constants M (the length of the secret key in octets) and N 203 (the length of the MAC output in octets) used below, are: 205 usmHMAC128SHA224AuthProtocol: M=28, N=16; 207 usmHMAC192SHA256AuthProtocol: M=32, N=24; 209 usmHMAC256SHA384AuthProtocol: M=48, N=32; 211 usmHMAC384SHA512AuthProtocol: M=64, N=48. 213 correspondingly. 215 This section describes the procedure followed by an SNMP engine 216 whenever it must authenticate an outgoing message using one of the 217 authentication protocols defined above. 219 1. The msgAuthenticationParameters field is set to serialization, 220 according to the rules in [RFC3417], of an OCTET STRING 221 containing N zero octets. 223 2. From the secret authKey of M octets, calculate the HMAC-SHA-2 224 digest over it according to [RFC6234]. Take the first N octets 225 of the final digest - this is the Message Authentication Code 226 (MAC). 228 3. Replace the msgAuthenticationParameters field with the MAC 229 obtained in the previous step. 231 4. The authenticatedWholeMsg is then returned to the caller together 232 with statusInformation indicating success. 234 4.2.2. Processing an Incoming Message 236 Values of the constants M and N are the same as in Section 4.2.1, and 237 are selected based on which authentication protocol is configured for 238 the given USM usmUser Table entry. 240 This section describes the procedure followed by an SNMP engine 241 whenever it must authenticate an incoming message using one of the 242 HMAC-SHA-2 authentication protocols. 244 1. If the digest received in the msgAuthenticationParameters field 245 is not N octets long, then an failure and an errorIndication 246 (authenticationError) is returned to the calling module. 248 2. The MAC received in the msgAuthenticationParameters field is 249 saved. 251 3. The digest in the msgAuthenticationParameters field is replaced 252 by the N zero octets. 254 4. Using the secret authKey, the HMAC is calculated over the 255 wholeMsg. 257 5. N first octets of the above HMAC are taken as the computed MAC 258 value. 260 6. The msgAuthenticationParameters field is replaced with the MAC 261 value that was saved in step 2. 263 7. The newly calculated MAC is compared with the MAC saved in step 264 2. If they do not match, then a failure and an errorIndication 265 (authenticationFailure) are returned to the calling module. 267 8. The authenticatedWholeMsg and statusInformation indicating 268 success are then returned to the caller. 270 5. Key Localization and Key Change 272 For any of the protocols defined in Section 4, key localization and 273 key change SHALL be performed according to RFC 3414 [RFC3414] using 274 the SHA-2 hash function applied in the respective protocol. 276 6. Structure of the MIB Module 278 The MIB module specified in this memo does not define any managed 279 objects, subtrees, notifications or tables, but only object 280 identities (for authentication protocols) under a subtree of an 281 existing MIB. 283 7. Relationship to Other MIB Modules 285 7.1. Relationship to SNMP-USER-BASED-SM-MIB 287 RFC 3414 [RFC3414] specifies the MIB for the User-based Security 288 Model (USM) for SNMPv3 (SNMP-USER-BASED-SM-MIB), which defines 289 authentication protocols for USM based on the hash functions MD5 and 290 SHA-1, respectively. The following MIB module defines new HMAC-SHA2 291 authentication protocols for USM based on the SHA-2 hash functions 292 [SHA]. The use of the HMAC-SHA2 authentication protocols requires 293 the usage of the objects defined in the SNMP-USER-BASED-SM-MIB. 295 7.2. Relationship to SNMP-FRAMEWORK-MIB 297 RFC 3411 [RFC3411] specifies the The SNMP Management Architecture MIB 298 (SNMP-FRAMEWORK-MIB), which defines a subtree snmpAuthProtocols for 299 SNMP authentication protocols. The following MIB module defines new 300 authentication protocols in the snmpAuthProtocols subtree. 301 Therefore, the use of the HMAC-SHA2 authentication protocols requires 302 the usage of the objects defined in the SNMP-FRAMEWORK-MIB. 304 7.3. MIB modules required for IMPORTS 306 The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578] 307 and SNMP-FRAMEWORK-MIB [RFC3411]. 309 8. Definitions 311 SNMP-USM-HMAC-SHA2-MIB DEFINITIONS ::= BEGIN 312 IMPORTS 313 MODULE-IDENTITY, OBJECT-IDENTITY, 314 snmpModules FROM SNMPv2-SMI -- [RFC2578] 315 snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411] 317 snmpUsmHmacSha2MIB MODULE-IDENTITY 318 LAST-UPDATED "201501150000Z" -- 25 January 2015, midnight 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 331 Co-Editor: Manfred Lochter 332 Bundesamt fuer Sicherheit in der 333 Informationstechnik (BSI) 334 postal: Postfach 200363 335 D-53133 Bonn 336 Germany 337 phone: +49 228 9582 5643 338 email: manfred.lochter@bsi.bund.de" 340 DESCRIPTION "Definitions of Object Identities needed 341 for the use of HMAC-SHA2 by SNMP's User-based 342 Security Model. 344 Copyright (C) The Internet Society (2015). 346 This version of this MIB module is part of RFC TBD; 347 see the RFC itself for full legal notices. 348 Supplementary information may be available on 349 http://www.ietf.org/copyrights/ianamib.html." 350 -- RFC Ed.: replace TBD with actual RFC number & remove this line 352 REVISION "201501150000Z" 353 DESCRIPTION "Initial version, published as RFC TBD" 354 -- RFC Ed.: replace TBD with actual RFC number & remove this line 356 ::= { snmpModules nn } -- nn to be assigned by IANA 357 -- RFC Ed.: replace nn with actual number assigned by IANA & remove 358 -- this comment 360 usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY 361 STATUS current 362 DESCRIPTION "The Authentication Protocol usmHMAC128SHA224AuthProtocol 363 uses HMAC-SHA-224 and truncates output to 128 bits." 364 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 365 Keyed-Hashing for Message Authentication, RFC 2104. 366 - National Institute of Standards and Technology, 367 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 368 ::= { snmpAuthProtocols aa } -- aa to be assigned by IANA 369 -- RFC Ed.: replace aa with actual number assigned by IANA & remove 370 -- this comment 372 usmHMAC192SHA256AuthProtocol OBJECT-IDENTITY 373 STATUS current 374 DESCRIPTION "The Authentication Protocol usmHMAC192SHA256AuthProtocol 375 uses HMAC-SHA-256 and truncates output to 192 bits." 376 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 378 Keyed-Hashing for Message Authentication, RFC 2104. 379 - National Institute of Standards and Technology, 380 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 381 ::= { snmpAuthProtocols bb } -- bb to be assigned by IANA 382 -- RFC Ed.: replace bb with actual number assigned by IANA & remove 383 -- this comment 385 usmHMAC256SHA384AuthProtocol OBJECT-IDENTITY 386 STATUS current 387 DESCRIPTION "The Authentication Protocol usmHMAC256SHA384AuthProtocol 388 uses HMAC-SHA-384 and truncates output to 256 bits." 389 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 390 Keyed-Hashing for Message Authentication, RFC 2104. 391 - National Institute of Standards and Technology, 392 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 393 ::= { snmpAuthProtocols cc } -- cc to be assigned by IANA 394 -- RFC Ed.: replace cc with actual number assigned by IANA & remove 395 this comment 397 usmHMAC384SHA12AuthProtocol OBJECT-IDENTITY 398 STATUS current 399 DESCRIPTION "The Authentication Protocol usmHMAC384SHA512AuthProtocol 400 uses HMAC-SHA-512 and truncates output to 384 bits." 401 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 402 Keyed-Hashing for Message Authentication, RFC 2104. 403 - National Institute of Standards and Technology, 404 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 405 ::= { snmpAuthProtocols dd } -- dd to be assigned by IANA 406 -- RFC Ed.: replace dd with actual number assigned by IANA & remove 407 this comment 409 END 411 9. Security Considerations 413 9.1. Use of the HMAC-SHA-2 authentication protocols in USM 415 The security considerations of [RFC3414] also apply to the use of all 416 the HMAC-SHA-2 authentication protocols in USM. 418 9.2. Cryptographic strength of the authentication protocols 420 At the time of this writing, all of the HMAC-SHA-2 authentication 421 protocols provide a very high level of security. The security of 422 each HMAC-SHA-2 authentication protocol depends on the parameters 423 used in the corresponding HMAC computation, which are the length of 424 the key (if the key has maximum entropy), the size of the hash 425 function's internal state, and the length of the truncated MAC. For 426 the HMAC-SHA-2 authentication protocols these values are as follows 427 (values are given in bits). 429 +------------------------------+---------+----------------+---------+ 430 | Protocol | Key | Size of | MAC | 431 | | length | internal state | length | 432 +------------------------------+---------+----------------+---------+ 433 | usmHMAC128SHA224AuthProtocol | 224 | 256 | 128 | 434 | usmHMAC192SHA256AuthProtocol | 256 | 256 | 192 | 435 | usmHMAC256SHA384AuthProtocol | 384 | 512 | 256 | 436 | usmHMAC384SHA512AuthProtocol | 512 | 512 | 384 | 437 +------------------------------+---------+----------------+---------+ 439 Table 1: HMAC parameters of the HMAC-SHA-2 authentication protocols 441 The security of the HMAC scales with both the key length and the size 442 of the internal state: longer keys render key guessing attacks more 443 difficult, and a larger internal state decreases the success 444 probability of MAC forgeries based on internal collisions of the hash 445 function. 447 The role of the truncated output length is more complicated: 448 according to [BCK], there is a trade-off in that "by outputting less 449 bits the attacker has less bits to predict in a MAC forgery but, on 450 the other hand, the attacker also learns less about the output of the 451 compression function from seeing the authentication tags computed by 452 legitimate parties"; thus, truncation weakens the HMAC against 453 forgery by guessing, but at the same time strengthens it against 454 chosen message attacks aiming at MAC forgery based on internal 455 collisions or at key guessing. [RFC2104] and [BCK] allow truncation 456 to any length that is not less than half the size of the internal 457 state. 459 Further discussion of the security of the HMAC construction is given 460 in [RFC2104]. 462 9.3. Derivation of keys from passwords 464 If secret keys to be used for HMAC-SHA-2 authentication protocols are 465 derived from passwords, the derivation SHOULD be performed using the 466 password-to-key algorithm from Appendix A.1 of RFC 3414 with MD5 467 being replaced by the SHA-2 hash function H used in the HMAC-SHA-2 468 authentication protocol. Specifically, the password is converted 469 into the required secret key by the following steps: 471 o forming a string of length 1,048,576 octets by repeating the value 472 of the password as often as necessary, truncating accordingly, and 473 using the resulting string as the input to the hash function H. 474 The resulting digest, termed "digest1", is used in the next step. 476 o a second string is formed by concatenating digest1, the SNMP 477 engine's snmpEngineID value, and digest1. This string is used as 478 input to the hash function H. 480 9.4. Access to the SNMP-USM-HMAC-SHA2-MIB 482 The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values 483 for use in other MIB modules. It does not define any objects that 484 can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by 485 itself, have any effect on the security of the Internet. 487 The values defined in this module are expected to be used with the 488 usmUserTable defined in the SNMP-USER-BASED-SM-MIB [RFC3414]. The 489 considerations in Section 11.5 of [RFC3414] should be taken into 490 account. 492 10. IANA Considerations 494 IANA is requested to assign an OID for 496 +--------------------+-------------------------+ 497 | Descriptor | OBJECT IDENTIFIER value | 498 +--------------------+-------------------------+ 499 | snmpUsmHmacSha2MIB | { snmpModules nn } | 500 +--------------------+-------------------------+ 502 Table 2: OID of MIB 504 with nn appearing in the MIB module definition in Section 8. 506 Furthermore, IANA is requested to assign a value in the 507 SnmpAuthProtocols registry for each of the following protocols. 509 +------------------------------+-------+-----------+ 510 | Description | Value | Reference | 511 +------------------------------+-------+-----------+ 512 | usmHMAC128SHA224AuthProtocol | aa | RFC YYYY | 513 | usmHMAC192SHA256AuthProtocol | bb | RFC YYYY | 514 | usmHMAC256SHA384AuthProtocol | cc | RFC YYYY | 515 | usmHMAC384SHA512AuthProtocol | dd | RFC YYYY | 516 +------------------------------+-------+-----------+ 518 Table 3: Code points assigned to HMAC-SHA-2 authentication protocols 520 -- RFC Ed.: replace YYYY with actual RFC number and remove this line 522 with aa, bb, cc, etc. appearing in the MIB module definition in 523 Section 8. 525 11. References 527 11.1. Normative References 529 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 530 Hashing for Message Authentication", RFC 2104, February 531 1997. 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 537 Schoenwaelder, Ed., "Structure of Management Information 538 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 540 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 541 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 542 58, RFC 2579, April 1999. 544 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 545 "Conformance Statements for SMIv2", STD 58, RFC 2580, 546 April 1999. 548 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 549 (USM) for version 3 of the Simple Network Management 550 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 552 [SHA] National Institute of Standards and Technology, "Secure 553 Hash Standard (SHS)", FIPS PUB 180-4, March 2012. 555 [RFC6234] Eastlate 3rd, D. and T. Hansen, "US Secure Hash Algorithms 556 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 558 11.2. Informative References 560 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 561 April 1992. 563 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 564 "Introduction and Applicability Statements for Internet- 565 Standard Management Framework", RFC 3410, December 2002. 567 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 568 Architecture for Describing Simple Network Management 569 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 570 December 2002. 572 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 573 Management Protocol (SNMP)", STD 62, RFC 3417, December 574 2002. 576 [BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keyed Hash 577 Functions for Message Authentication", Advances in 578 Cryptology - CRYPTO 99, Lecture Notes in Computer Science 579 1109, Springer Verlag, 1996. 581 Authors' Addresses 583 Johannes Merkle (editor) 584 Secunet Security Networks 585 Mergenthaler Allee 77 586 65760 Eschborn 587 Germany 589 Phone: +49 201 5454 3091 590 EMail: johannes.merkle@secunet.com 592 Manfred Lochter 593 BSI 594 Postfach 200363 595 53133 Bonn 596 Germany 598 Phone: +49 228 9582 5643 599 EMail: manfred.lochter@bsi.bund.de