idnits 2.17.1 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04.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 (February 12, 2016) is 2995 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 ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' 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 Obsoletes: 7630 (if approved) M. Lochter 5 Intended status: Standards Track BSI 6 Expires: August 15, 2016 February 12, 2016 8 HMAC-SHA-2 Authentication Protocols in USM for SNMPv3 9 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04 11 Abstract 13 This document specifies several authentication protocols based on the 14 SHA-2 hash functions for the User-based Security Model (USM) for 15 SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIB 16 MODULE-IDENTITY value was incorrectly specified. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 15, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. The Internet-Standard Management Framework . . . . . . . . . 3 54 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. The HMAC-SHA-2 Authentication Protocols . . . . . . . . . . 3 56 4.1. Deviations from the HMAC-SHA-96 Authentication Protocol 4 57 4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2.1. Processing an Outgoing Message . . . . . . . . . . . 5 59 4.2.2. Processing an Incoming Message . . . . . . . . . . . 6 60 5. Key Localization and Key Change . . . . . . . . . . . . . . . 6 61 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 6 62 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 63 7.1. Relationship to SNMP-USER-BASED-SM-MIB . . . . . . . . . 7 64 7.2. Relationship to SNMP-FRAMEWORK-MIB . . . . . . . . . . . 7 65 7.3. MIB Modules Required for IMPORTS . . . . . . . . . . . . 7 66 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 9.1. Use of the HMAC-SHA-2 Authentication Protocols in USM . 9 69 9.2. Cryptographic Strength of the Authentication Protocols . 9 70 9.3. Derivation of Keys from Passwords . . . . . . . . . . . 10 71 9.4. Access to the SNMP-USM-HMAC-SHA2-MIB . . . . . . . . . . 10 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 11.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Within the Architecture for describing Simple Network Management 81 Protocol (SNMP) Management Frameworks [RFC3411], the User-based 82 Security Model (USM) [RFC3414] for SNMPv3 is defined as a Security 83 Subsystem within an SNMP engine. In RFC 3414, two different 84 authentication protocols, HMAC-MD5-96 and HMAC-SHA-96, are defined 85 based on the hash functions MD5 and SHA-1, respectively. 87 This memo specifies new HMAC-SHA-2 authentication protocols for USM 88 using a Hashed Message Authentication Code (HMAC) based on the SHA-2 89 family of hash functions [SHA] and truncated to 128 bits for SHA-224, 90 to 192 bits for SHA-256, to 256 bits for SHA-384, and to 384 bits for 91 SHA-512. These protocols are straightforward adaptations of the 92 authentication protocols HMAC-MD5-96 and HMAC-SHA-96 to the 93 SHA-2-based HMAC. 95 This document obsoletes RFC 7630, in which the MIB MODULE-IDENTITY 96 value was incorrectly specified. 98 2. The Internet-Standard Management Framework 100 For a detailed overview of the documents that describe the current 101 Internet-Standard Management Framework, please refer to section 7 of 102 [RFC3410]. 104 Managed objects are accessed via a virtual information store, termed 105 the Management Information Base or MIB. MIB objects are generally 106 accessed through the Simple Network Management Protocol (SNMP). 107 Objects in the MIB are defined using the mechanisms defined in the 108 Structure of Management Information (SMI). This memo specifies a MIB 109 module that is compliant to the SMIv2, which is described in 110 [RFC2578], [RFC2579], and [RFC2580]. 112 3. Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. 119 4. The HMAC-SHA-2 Authentication Protocols 121 This section describes the HMAC-SHA-2 authentication protocols, which 122 use the SHA-2 hash functions (described in FIPS PUB 180-4 [SHA] and 123 [RFC6234]) in the HMAC mode (described in [RFC2104] and RFC 6234), 124 truncating the output to 128 bits for SHA-224, 192 bits for SHA-256, 125 256 bits for SHA-384, and 384 bits for SHA-512. RFC 6234 also 126 provides source code for all the SHA-2 algorithms and HMAC (without 127 truncation). It also includes test harness and standard test vectors 128 for all the defined hash functions and HMAC examples. 130 The following protocols are defined: 132 usmHMAC128SHA224AuthProtocol: uses SHA-224 and truncates the 133 output to 128 bits (16 octets); 135 usmHMAC192SHA256AuthProtocol: uses SHA-256 and truncates the 136 output to 192 bits (24 octets); 138 usmHMAC256SHA384AuthProtocol: uses SHA-384 and truncates the 139 output to 256 bits (32 octets); 141 usmHMAC384SHA512AuthProtocol: uses SHA-512 and truncates the 142 output to 384 bits (48 octets). 144 Implementations conforming to this specification MUST support 145 usmHMAC192SHA256AuthProtocol and SHOULD support 146 usmHMAC384SHA512AuthProtocol. The protocols 147 usmHMAC128SHA224AuthProtocol and usmHMAC256SHA384AuthProtocol are 148 OPTIONAL. 150 4.1. Deviations from the HMAC-SHA-96 Authentication Protocol 152 All the HMAC-SHA-2 authentication protocols are straightforward 153 adaptations of the HMAC-MD5-96 and HMAC-SHA-96 authentication 154 protocols. Specifically, they differ from the HMAC-MD5-96 and HMAC- 155 SHA-96 authentication protocols in the following aspects: 157 o The SHA-2 hash function is used to compute the message digest in 158 the HMAC computation according to RFC 2104 and RFC 6234, as 159 opposed to the MD5 hash function [RFC1321] and SHA-1 hash function 160 [SHA] used in HMAC-MD5-96 and HMAC-SHA-96, respectively. 161 Consequently, the length of the message digest prior to truncation 162 is 224 bits for the SHA-224-based protocol, 256 bits for the 163 SHA-256-based protocol, 384 bits for the SHA-384-based protocol, 164 and 512 bits for the SHA-512-based protocol. 166 o The resulting message digest (output of HMAC) is truncated to 168 * 16 octets for usmHMAC128SHA224AuthProtocol 170 * 24 octets for usmHMAC192SHA256AuthProtocol 172 * 32 octets for usmHMAC256SHA384AuthProtocol 174 * 48 octets for usmHMAC384SHA512AuthProtocol 176 as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC- 177 SHA-96. 179 o The user's secret key to be used when calculating a digest MUST be 181 * 28 octets long and derived with SHA-224 for the SHA-224-based 182 protocol usmHMAC128SHA224AuthProtocol 184 * 32 octets long and derived with SHA-256 for the SHA-256-based 185 protocol usmHMAC192SHA256AuthProtocol 187 * 48 octets long and derived with SHA-384 for the SHA-384-based 188 protocol usmHMAC256SHA384AuthProtocol 190 * 64 octets long and derived with SHA-512 for the SHA-512-based 191 protocol usmHMAC384SHA512AuthProtocol 193 as opposed to the keys being 16 and 20 octets long in HMAC-MD5-96 194 and HMAC-SHA-96, respectively. 196 4.2. Processing 198 This section describes the procedures for the HMAC-SHA-2 199 authentication protocols. The descriptions are based on the 200 definition of services and data elements specified for HMAC-SHA-96 in 201 RFC 3414 with the deviations listed in Section 4.1. 203 Values of constants M (the length of the secret key in octets) and N 204 (the length of the Message Authentication Code (MAC) output in 205 octets), and the hash function H used below are: 207 usmHMAC128SHA224AuthProtocol: M=28, N=16, H=SHA-224; 209 usmHMAC192SHA256AuthProtocol: M=32, N=24, H=SHA-256; 211 usmHMAC256SHA384AuthProtocol: M=48, N=32, H=SHA-384; 213 usmHMAC384SHA512AuthProtocol: M=64, N=48, H=SHA-512. 215 4.2.1. Processing an Outgoing Message 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. Values of the constants M 220 and N, and the hash function H are as defined in Section 4.2 and are 221 selected based on which authentication protocol is configured for the 222 given USM usmUser Table entry. 224 1. The msgAuthenticationParameters field is set to the serialization 225 of an OCTET STRING containing N zero octets; it is serialized 226 according to the rules in [RFC3417]. 228 2. Using the secret authKey of M octets, the HMAC is calculated over 229 the wholeMsg according to RFC 6234 with hash function H. 231 3. The N first octets of the above HMAC are taken as the computed 232 MAC value. 234 4. The msgAuthenticationParameters field is replaced with the MAC 235 obtained in the previous step. 237 5. The authenticatedWholeMsg is then returned to the caller together 238 with the statusInformation indicating success. 240 4.2.2. Processing an Incoming Message 242 This section describes the procedure followed by an SNMP engine 243 whenever it must authenticate an incoming message using one of the 244 HMAC-SHA-2 authentication protocols. Values of the constants M and 245 N, and the hash function H are as defined in Section 4.2 and are 246 selected based on which authentication protocol is configured for the 247 given USM usmUser Table entry. 249 1. If the digest received in the msgAuthenticationParameters field 250 is not N octets long, then a failure and an errorIndication 251 (authenticationError) are returned to the calling module. 253 2. The MAC received in the msgAuthenticationParameters field is 254 saved. 256 3. The digest in the msgAuthenticationParameters field is replaced 257 by the N zero octets. 259 4. Using the secret authKey of M octets, the HMAC is calculated over 260 the wholeMsg according to RFC 6234 with hash function H. 262 5. The N first octets of the above HMAC are taken as the computed 263 MAC value. 265 6. The msgAuthenticationParameters field is replaced with the MAC 266 value that was saved in step 2. 268 7. The newly calculated MAC is compared with the MAC saved in step 269 2. If they do not match, then a failure and an errorIndication 270 (authenticationFailure) are returned to the calling module. 272 8. The authenticatedWholeMsg and statusInformation indicating 273 success are then returned to the caller. 275 5. Key Localization and Key Change 277 For any of the protocols defined in Section 4, key localization and 278 key change SHALL be performed according to [RFC3414] using the same 279 SHA-2 hash function as in the HMAC-SHA-2 authentication protocol. 281 6. Structure of the MIB Module 283 The MIB module specified in this memo does not define any managed 284 objects, subtrees, notifications, or tables; rather, it only defines 285 object identities (for authentication protocols) under a subtree of 286 an existing MIB. 288 7. Relationship to Other MIB Modules 290 7.1. Relationship to SNMP-USER-BASED-SM-MIB 292 RFC 3414 specifies the MIB module for USM for SNMPv3 (SNMP-USER- 293 BASED-SM-MIB), which defines authentication protocols for USM based 294 on the hash functions MD5 and SHA-1, respectively. The following MIB 295 module defines new HMAC-SHA2 authentication protocols for USM based 296 on the SHA-2 hash functions [SHA]. The use of the HMAC-SHA2 297 authentication protocols requires the usage of the objects defined in 298 the SNMP-USER-BASED-SM-MIB. 300 7.2. Relationship to SNMP-FRAMEWORK-MIB 302 [RFC3411] specifies the SNMP-FRAMEWORK-MIB, which defines a subtree 303 snmpAuthProtocols for SNMP authentication protocols. The following 304 MIB module defines new authentication protocols in the 305 snmpAuthProtocols subtree. 307 7.3. MIB Modules Required for IMPORTS 309 The following MIB module IMPORTS definitions from SNMPv2-SMI 310 [RFC2578] and SNMP-FRAMEWORK-MIB [RFC3411]. 312 8. Definitions 314 SNMP-USM-HMAC-SHA2-MIB DEFINITIONS ::= BEGIN 315 IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI 316 -- [RFC2578] snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411] 318 snmpUsmHmacSha2MIB MODULE-IDENTITY LAST-UPDATED "201510210000Z" -- 21 319 October 2015, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO 320 "WG email: OPSAWG@ietf.org Subscribe: 321 https://www.ietf.org/mailman/listinfo/opsawg Editor: Johannes Merkle 322 secunet Security Networks Postal: Mergenthaler Allee 77 323 D-65760 Eschborn Germany Phone: +49 20154543091 Email: 324 johannes.merkle@secunet.com 326 Co-Editor: Manfred Lochter Bundesamt fuer Sicherheit in der 327 Informationstechnik (BSI) Postal: Postfach 200363 328 D-53133 Bonn Germany Phone: +49 228 9582 5643 Email: 329 manfred.lochter@bsi.bund.de" 331 DESCRIPTION "Definitions of Object Identities needed 332 for the use of HMAC-SHA2 by SNMP's User-based Security Model. 334 Copyright (c) 2015 IETF Trust and the persons identified as authors of 335 the code. All rights reserved. 337 Redistribution and use in source and binary forms, with or without 338 modification, is permitted pursuant to, and subject to the license terms 339 contained in, the Simplified BSD License set forth in Section 4.c of the 340 IETF Trust's Legal Provisions Relating to IETF Documents 341 (http://trustee.ietf.org/license-info)." 343 REVISION "201510210000Z" -- 21 October 2015, midnight DESCRIPTION 344 "Version correcting the MODULE-IDENTITY value, published as RFC TBD" 345 -- RFC Ed.: replace TBD with actual RFC number & remove this line 346 REVISION "201508130000Z" -- 13 August 2015, midnight DESCRIPTION 347 "Initial version, published as RFC 7630" ::= { mib-2 235 } 349 usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION 350 "The Authentication Protocol usmHMAC128SHA224AuthProtocol uses 351 HMAC-SHA-224 and truncates output to 128 bits." REFERENCE "- Krawczyk, 352 H., Bellare, M., and R. Canetti, HMAC: Keyed-Hashing for Message 353 Authentication, RFC 2104. - National Institute of Standards and 354 Technology, Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." ::= { 355 snmpAuthProtocols 4 } 357 usmHMAC192SHA256AuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION 358 "The Authentication Protocol usmHMAC192SHA256AuthProtocol uses 359 HMAC-SHA-256 and truncates output to 192 bits." REFERENCE "- Krawczyk, 360 H., Bellare, M., and R. Canetti, HMAC: Keyed-Hashing for Message 361 Authentication, RFC 2104. - National Institute of Standards and 362 Technology, Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." ::= { 363 snmpAuthProtocols 5 } 365 usmHMAC256SHA384AuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION 366 "The Authentication Protocol usmHMAC256SHA384AuthProtocol uses 367 HMAC-SHA-384 and truncates output to 256 bits." REFERENCE "- Krawczyk, 368 H., Bellare, M., and R. Canetti, HMAC: Keyed-Hashing for Message 369 Authentication, RFC 2104. - National Institute of Standards and 370 Technology, Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." ::= { 371 snmpAuthProtocols 6 } 373 usmHMAC384SHA512AuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION 374 "The Authentication Protocol usmHMAC384SHA512AuthProtocol uses 375 HMAC-SHA-512 and truncates output to 384 bits." REFERENCE "- Krawczyk, 376 H., Bellare, M., and R. Canetti, HMAC: Keyed-Hashing for Message 377 Authentication, RFC 2104. - National Institute of Standards and 378 Technology, Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." ::= { 379 snmpAuthProtocols 7 } 381 END 382 9. Security Considerations 384 9.1. Use of the HMAC-SHA-2 Authentication Protocols in USM 386 The security considerations of [RFC3414] also apply to the HMAC-SHA-2 387 authentication protocols defined in this document. 389 9.2. Cryptographic Strength of the Authentication Protocols 391 At the time of publication of this document, all of the HMAC-SHA-2 392 authentication protocols provide a very high level of security. The 393 security of each HMAC-SHA-2 authentication protocol depends on the 394 parameters used in the corresponding HMAC computation, which are the 395 length of the key (if the key has maximum entropy), the size of the 396 hash function's internal state, and the length of the truncated MAC. 397 For the HMAC-SHA-2 authentication protocols, these values are as 398 follows (values are given in bits). 400 +------------------------------+---------+----------------+---------+ 401 | Protocol | Key | Size of | MAC | 402 | | length | internal state | length | 403 +------------------------------+---------+----------------+---------+ 404 | usmHMAC128SHA224AuthProtocol | 224 | 256 | 128 | 405 | usmHMAC192SHA256AuthProtocol | 256 | 256 | 192 | 406 | usmHMAC256SHA384AuthProtocol | 384 | 512 | 256 | 407 | usmHMAC384SHA512AuthProtocol | 512 | 512 | 384 | 408 +------------------------------+---------+----------------+---------+ 410 Table 1: HMAC Parameters of the HMAC-SHA-2 Authentication Protocols 412 The security of the HMAC scales with both the key length and the size 413 of the internal state: longer keys render key guessing attacks more 414 difficult, and a larger internal state decreases the success 415 probability of MAC forgeries based on internal collisions of the hash 416 function. 418 The role of the truncated output length is more complicated: 419 according to [BCK], there is a trade-off in that 421 by outputting less bits the attacker has less bits to predict in a 422 MAC forgery but, on the other hand, the attacker also learns less 423 about the output of the compression function from seeing the 424 authentication tags computed by legitimate parties. 426 Thus, truncation weakens the HMAC against forgery by guessing but, at 427 the same time, strengthens it against chosen message attacks aiming 428 at MAC forgery based on internal collisions or at key guessing. RFC 429 2104 and [BCK] allow truncation to any length that is not less than 430 half the size of the internal state. 432 Further discussion of the security of the HMAC construction is given 433 in RFC 2104. 435 9.3. Derivation of Keys from Passwords 437 If secret keys to be used for HMAC-SHA-2 authentication protocols are 438 derived from passwords, the derivation SHOULD be performed using the 439 password-to-key algorithm from Appendix A.1 of RFC 3414 with MD5 440 being replaced by the SHA-2 hash function H used in the HMAC-SHA-2 441 authentication protocol. Specifically, the password is converted 442 into the required secret key by the following steps: 444 o forming a string of length 1,048,576 octets by repeating the value 445 of the password as often as necessary, truncating accordingly, and 446 using the resulting string as the input to the hash function H. 447 The resulting digest, termed "digest1", is used in the next step. 449 o forming a second string by concatenating digest1, the SNMP 450 engine's snmpEngineID value, and digest1. This string is used as 451 input to the hash function H. 453 9.4. Access to the SNMP-USM-HMAC-SHA2-MIB 455 The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values 456 for use in other MIB modules. It does not define any objects that 457 can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by 458 itself, have any effect on the security of the Internet. 460 The values defined in this module are expected to be used with the 461 usmUserTable defined in the SNMP-USER-BASED-SM-MIB [RFC3414]. The 462 considerations in Section 11.5 of RFC 3414 should be taken into 463 account. 465 10. IANA Considerations 467 IANA has assigned an OID for the MIB as follows. 469 +--------------------+-------------------------+ 470 | Descriptor | OBJECT IDENTIFIER value | 471 +--------------------+-------------------------+ 472 | snmpUsmHmacSha2MIB | { mib-2 235 } | 473 +--------------------+-------------------------+ 475 Table 2: OID of MIB 477 Furthermore, IANA has assigned a value in the SnmpAuthProtocols 478 registry for each of the following protocols. 480 +------------------------------+-------+-----------+ 481 | Description | Value | Reference | 482 +------------------------------+-------+-----------+ 483 | usmHMAC128SHA224AuthProtocol | 4 | RFC XXX | 484 | usmHMAC192SHA256AuthProtocol | 5 | RFC XXX | 485 | usmHMAC256SHA384AuthProtocol | 6 | RFC XXX | 486 | usmHMAC384SHA512AuthProtocol | 7 | RFC XXX | 487 +------------------------------+-------+-----------+ 489 Table 3: Code Points Assigned to HMAC-SHA-2 Authentication Protocols 491 -- RFC Ed.: replace XXX with actual RFC number and remove this line 493 11. References 495 11.1. Normative References 497 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 498 Hashing for Message Authentication", RFC 2104, 499 DOI 10.17487/RFC2104, February 1997, 500 . 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 508 Schoenwaelder, Ed., "Structure of Management Information 509 Version 2 (SMIv2)", STD 58, RFC 2578, 510 DOI 10.17487/RFC2578, April 1999, 511 . 513 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 514 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 515 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 516 . 518 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 519 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 520 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 521 . 523 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 524 (USM) for version 3 of the Simple Network Management 525 Protocol (SNMPv3)", STD 62, RFC 3414, 526 DOI 10.17487/RFC3414, December 2002, 527 . 529 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 530 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 531 DOI 10.17487/RFC6234, May 2011, 532 . 534 [SHA] National Institute of Standards and Technology, "Secure 535 Hash Standard (SHS)", FIPS PUB 180-4, 536 DOI 10.6028/NIST.FIPS.180-4, March 2012, 537 . 540 11.2. Informative References 542 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 543 DOI 10.17487/RFC1321, April 1992, 544 . 546 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 547 "Introduction and Applicability Statements for Internet- 548 Standard Management Framework", RFC 3410, 549 DOI 10.17487/RFC3410, December 2002, 550 . 552 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 553 Architecture for Describing Simple Network Management 554 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 555 DOI 10.17487/RFC3411, December 2002, 556 . 558 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 559 Network Management Protocol (SNMP)", STD 62, RFC 3417, 560 DOI 10.17487/RFC3417, December 2002, 561 . 563 [BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keyed Hash 564 Functions for Message Authentication", Advances in 565 Cryptology - CRYPTO 96, Lecture Notes in Computer 566 Science 1109, Springer-Verlag Berlin Heidelberg, 567 DOI 10.1007/3-540-68697-5_1, 1996. 569 Authors' Addresses 571 Johannes Merkle (editor) 572 Secunet Security Networks 573 Mergenthaler Allee 77 574 65760 Eschborn 575 Germany 577 Phone: +49 201 5454 3091 578 EMail: johannes.merkle@secunet.com 580 Manfred Lochter 581 BSI 582 Postfach 200363 583 53133 Bonn 584 Germany 586 Phone: +49 228 9582 5643 587 EMail: manfred.lochter@bsi.bund.de