idnits 2.17.1 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-01.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 is 1 instance of too long lines in the document, the longest one being 15 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC7630, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2015) is 3110 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 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: April 23, 2016 October 21, 2015 8 HMAC-SHA-2 Authentication Protocols in USM for SNMPv3 9 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-01 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 April 23, 2016. 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 Protocol . 4 55 4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.2.1. Processing an Outgoing Message . . . . . . . . . . . 5 57 4.2.2. Processing an Incoming Message . . . . . . . . . . . 6 58 5. Key Localization and Key Change . . . . . . . . . . . . . . . 6 59 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 6 60 7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7 61 7.1. Relationship to SNMP-USER-BASED-SM-MIB . . . . . . . . . 7 62 7.2. Relationship to SNMP-FRAMEWORK-MIB . . . . . . . . . . . 7 63 7.3. MIB Modules Required for IMPORTS . . . . . . . . . . . . 7 64 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 9.1. Use of the HMAC-SHA-2 Authentication Protocols in USM . . 9 67 9.2. Cryptographic Strength of the Authentication Protocols . 9 68 9.3. Derivation of Keys from Passwords . . . . . . . . . . . . 10 69 9.4. Access to the SNMP-USM-HMAC-SHA2-MIB . . . . . . . . . . 11 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 the Simple Network Management Protocol version 3 (SNMPv3) 82 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 a Hashed Message Authentication Code (HMAC) 88 based on the SHA-2 family of hash functions [SHA] and truncated to 89 128 bits for SHA-224, to 192 bits for SHA-256, to 256 bits for 90 SHA-384, and to 384 bits for SHA-512. These protocols are 91 straightforward adaptations of the authentication protocols HMAC- 92 MD5-96 and HMAC-SHA-96 to the SHA-2-based HMAC. 94 This document obsoletes RFC 7630, in which the MIB MODULE-IDENTITY 95 value was incorrectly specified. 97 2. The Internet-Standard Management Framework 99 For a detailed overview of the documents that describe the current 100 Internet-Standard Management Framework, please refer to section 7 of 101 RFC 3410 [RFC3410]. 103 Managed objects are accessed via a virtual information store, termed 104 the Management Information Base or MIB. MIB objects are generally 105 accessed through the Simple Network Management Protocol (SNMP). 106 Objects in the MIB are defined using the mechanisms defined in the 107 Structure of Management Information (SMI). This memo specifies a MIB 108 module that is compliant to the SMIv2, which is described in STD 58, 109 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 110 [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 RFC 6234 [RFC6234]) in the HMAC mode (described in RFC 2104 [RFC2104] 124 and RFC 6234), truncating the output to 128 bits for SHA-224, 192 125 bits for SHA-256, 256 bits for SHA-384, and 384 bits for SHA-512. 126 RFC 6234 also provides source code for all the SHA-2 algorithms and 127 HMAC (without truncation). It also includes test harness and 128 standard test vectors for all the defined hash functions and HMAC 129 examples. 131 The following protocols are defined: 133 usmHMAC128SHA224AuthProtocol: uses SHA-224 and truncates the 134 output to 128 bits (16 octets); 136 usmHMAC192SHA256AuthProtocol: uses SHA-256 and truncates the 137 output to 192 bits (24 octets); 139 usmHMAC256SHA384AuthProtocol: uses SHA-384 and truncates the 140 output to 256 bits (32 octets); 142 usmHMAC384SHA512AuthProtocol: uses SHA-512 and truncates the 143 output to 384 bits (48 octets). 145 Implementations conforming to this specification MUST support 146 usmHMAC192SHA256AuthProtocol and SHOULD support 147 usmHMAC384SHA512AuthProtocol. The protocols 148 usmHMAC128SHA224AuthProtocol and usmHMAC256SHA384AuthProtocol are 149 OPTIONAL. 151 4.1. Deviations from the HMAC-SHA-96 Authentication Protocol 153 All the HMAC-SHA-2 authentication protocols are straightforward 154 adaptations of the HMAC-MD5-96 and HMAC-SHA-96 authentication 155 protocols. Specifically, they differ from the HMAC-MD5-96 and HMAC- 156 SHA-96 authentication protocols in the following aspects: 158 o The SHA-2 hash function is used to compute the message digest in 159 the HMAC computation according to RFC 2104 and RFC 6234, as 160 opposed to the MD5 hash function [RFC1321] and SHA-1 hash function 161 [SHA] used in HMAC-MD5-96 and HMAC-SHA-96, respectively. 162 Consequently, the length of the message digest prior to truncation 163 is 224 bits for the SHA-224-based protocol, 256 bits for the 164 SHA-256-based protocol, 384 bits for the SHA-384-based protocol, 165 and 512 bits for the SHA-512-based protocol. 167 o The resulting message digest (output of HMAC) is truncated to 169 * 16 octets for usmHMAC128SHA224AuthProtocol 171 * 24 octets for usmHMAC192SHA256AuthProtocol 173 * 32 octets for usmHMAC256SHA384AuthProtocol 175 * 48 octets for usmHMAC384SHA512AuthProtocol 177 as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC- 178 SHA-96. 180 o The user's secret key to be used when calculating a digest MUST be 182 * 28 octets long and derived with SHA-224 for the SHA-224-based 183 protocol usmHMAC128SHA224AuthProtocol 185 * 32 octets long and derived with SHA-256 for the SHA-256-based 186 protocol usmHMAC192SHA256AuthProtocol 188 * 48 octets long and derived with SHA-384 for the SHA-384-based 189 protocol usmHMAC256SHA384AuthProtocol 191 * 64 octets long and derived with SHA-512 for the SHA-512-based 192 protocol usmHMAC384SHA512AuthProtocol 194 as opposed to the keys being 16 and 20 octets long in HMAC-MD5-96 195 and HMAC-SHA-96, respectively. 197 4.2. Processing 199 This section describes the procedures for the HMAC-SHA-2 200 authentication protocols. The descriptions are based on the 201 definition of services and data elements defined for HMAC-SHA-96 in 202 RFC 3414 with the deviations listed in Section 4.1. 204 Values of constants M (the length of the secret key in octets) and N 205 (the length of the Message Authentication Code (MAC) output in 206 octets), and the hash function H used below are: 208 usmHMAC128SHA224AuthProtocol: M=28, N=16, H=SHA-224; 210 usmHMAC192SHA256AuthProtocol: M=32, N=24, H=SHA-256; 212 usmHMAC256SHA384AuthProtocol: M=48, N=32, H=SHA-384; 214 usmHMAC384SHA512AuthProtocol: M=64, N=48, H=SHA-512. 216 4.2.1. Processing an Outgoing Message 218 This section describes the procedure followed by an SNMP engine 219 whenever it must authenticate an outgoing message using one of the 220 authentication protocols defined above. Values of the constants M 221 and N, and the hash function H are as defined in Section 4.2 and are 222 selected based on which authentication protocol is configured for the 223 given USM usmUser Table entry. 225 1. The msgAuthenticationParameters field is set to the serialization 226 of an OCTET STRING containing N zero octets; it is serialized 227 according to the rules in RFC 3417 [RFC3417]. 229 2. Using the secret authKey of M octets, the HMAC is calculated over 230 the wholeMsg according to RFC 6234 with hash function H. 232 3. The N first octets of the above HMAC are taken as the computed 233 MAC value. 235 4. The msgAuthenticationParameters field is replaced with the MAC 236 obtained in the previous step. 238 5. The authenticatedWholeMsg is then returned to the caller together 239 with the statusInformation indicating success. 241 4.2.2. Processing an Incoming Message 243 This section describes the procedure followed by an SNMP engine 244 whenever it must authenticate an incoming message using one of the 245 HMAC-SHA-2 authentication protocols. Values of the constants M and 246 N, and the hash function H are as defined in Section 4.2 and are 247 selected based on which authentication protocol is configured for the 248 given USM usmUser Table entry. 250 1. If the digest received in the msgAuthenticationParameters field 251 is not N octets long, then a failure and an errorIndication 252 (authenticationError) are returned to the calling module. 254 2. The MAC received in the msgAuthenticationParameters field is 255 saved. 257 3. The digest in the msgAuthenticationParameters field is replaced 258 by the N zero octets. 260 4. Using the secret authKey of M octets, the HMAC is calculated over 261 the wholeMsg according to RFC 6234 with hash function H. 263 5. The N first octets of the above HMAC are taken as the computed 264 MAC value. 266 6. The msgAuthenticationParameters field is replaced with the MAC 267 value that was saved in step 2. 269 7. The newly calculated MAC is compared with the MAC saved in step 270 2. If they do not match, then a failure and an errorIndication 271 (authenticationFailure) are returned to the calling module. 273 8. The authenticatedWholeMsg and statusInformation indicating 274 success are then returned to the caller. 276 5. Key Localization and Key Change 278 For any of the protocols defined in Section 4, key localization and 279 key change SHALL be performed according to RFC 3414 [RFC3414] using 280 the same SHA-2 hash function as in the HMAC-SHA-2 authentication 281 protocol. 283 6. Structure of the MIB Module 285 The MIB module specified in this memo does not define any managed 286 objects, subtrees, notifications, or tables; rather, it only defines 287 object identities (for authentication protocols) under a subtree of 288 an existing MIB. 290 7. Relationship to Other MIB Modules 292 7.1. Relationship to SNMP-USER-BASED-SM-MIB 294 RFC 3414 specifies the MIB module for USM for SNMPv3 (SNMP-USER- 295 BASED-SM-MIB), which defines authentication protocols for USM based 296 on the hash functions MD5 and SHA-1, respectively. The following MIB 297 module defines new HMAC-SHA2 authentication protocols for USM based 298 on the SHA-2 hash functions [SHA]. The use of the HMAC-SHA2 299 authentication protocols requires the usage of the objects defined in 300 the SNMP-USER-BASED-SM-MIB. 302 7.2. Relationship to SNMP-FRAMEWORK-MIB 304 RFC 3411 [RFC3411] specifies the SNMP-FRAMEWORK-MIB, which defines a 305 subtree snmpAuthProtocols for SNMP authentication protocols. The 306 following MIB module defines new authentication protocols in the 307 snmpAuthProtocols subtree. 309 7.3. MIB Modules Required for IMPORTS 311 The following MIB module IMPORTS definitions from SNMPv2-SMI 312 [RFC2578] and SNMP-FRAMEWORK-MIB [RFC3411]. 314 8. Definitions 316 SNMP-USM-HMAC-SHA2-MIB DEFINITIONS ::= BEGIN 317 IMPORTS 318 MODULE-IDENTITY, OBJECT-IDENTITY, 319 mib-2 FROM SNMPv2-SMI -- [RFC2578] 320 snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411] 322 snmpUsmHmacSha2MIB MODULE-IDENTITY 323 LAST-UPDATED "201510210000Z" -- 21 October 2015, midnight 324 ORGANIZATION "SNMPv3 Working Group" 325 CONTACT-INFO "WG email: OPSAWG@ietf.org 326 Subscribe: 327 https://www.ietf.org/mailman/listinfo/opsawg 328 Editor: Johannes Merkle 329 secunet Security Networks 330 Postal: Mergenthaler Allee 77 331 D-65760 Eschborn 332 Germany 333 Phone: +49 20154543091 334 Email: johannes.merkle@secunet.com 336 Co-Editor: Manfred Lochter 337 Bundesamt fuer Sicherheit in der 338 Informationstechnik (BSI) 339 Postal: Postfach 200363 340 D-53133 Bonn 341 Germany 342 Phone: +49 228 9582 5643 343 Email: manfred.lochter@bsi.bund.de" 345 DESCRIPTION "Definitions of Object Identities needed 346 for the use of HMAC-SHA2 by SNMP's User-based 347 Security Model. 349 Copyright (c) 2015 IETF Trust and the persons identified 350 as authors of the code. All rights reserved. 352 Redistribution and use in source and binary forms, with 353 or without modification, is permitted pursuant to, and 354 subject to the license terms contained in, the Simplified 355 BSD License set forth in Section 4.c of the IETF Trust's 356 Legal Provisions Relating to IETF Documents 357 (http://trustee.ietf.org/license-info)." 359 REVISION "201510210000Z" -- 21 October 2015, midnight 360 DESCRIPTION "Version correcting the MODULE-IDENTITY value, published as RFC TBD" 361 -- RFC Ed.: replace TBD with actual RFC number & remove this line 362 REVISION "201508130000Z" -- 13 August 2015, midnight 363 DESCRIPTION "Initial version, published as RFC 7630" 365 ::= { mib-2 235 } 367 usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY 368 STATUS current 369 DESCRIPTION "The Authentication Protocol 370 usmHMAC128SHA224AuthProtocol uses HMAC-SHA-224 and 371 truncates output to 128 bits." 372 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 373 Keyed-Hashing for Message Authentication, RFC 2104. 374 - National Institute of Standards and Technology, 375 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 376 ::= { snmpAuthProtocols 4 } 378 usmHMAC192SHA256AuthProtocol OBJECT-IDENTITY 379 STATUS current 380 DESCRIPTION "The Authentication Protocol 381 usmHMAC192SHA256AuthProtocol uses HMAC-SHA-256 and 382 truncates output to 192 bits." 383 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 384 Keyed-Hashing for Message Authentication, RFC 2104. 385 - National Institute of Standards and Technology, 386 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 387 ::= { snmpAuthProtocols 5 } 389 usmHMAC256SHA384AuthProtocol OBJECT-IDENTITY 390 STATUS current 391 DESCRIPTION "The Authentication Protocol 392 usmHMAC256SHA384AuthProtocol uses HMAC-SHA-384 and 393 truncates output to 256 bits." 394 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 395 Keyed-Hashing for Message Authentication, RFC 2104. 396 - National Institute of Standards and Technology, 397 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 398 ::= { snmpAuthProtocols 6 } 400 usmHMAC384SHA512AuthProtocol OBJECT-IDENTITY 401 STATUS current 402 DESCRIPTION "The Authentication Protocol 403 usmHMAC384SHA512AuthProtocol uses HMAC-SHA-512 and 404 truncates output to 384 bits." 405 REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC: 406 Keyed-Hashing for Message Authentication, RFC 2104. 407 - National Institute of Standards and Technology, 408 Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." 409 ::= { snmpAuthProtocols 7 } 411 END 413 9. Security Considerations 415 9.1. Use of the HMAC-SHA-2 Authentication Protocols in USM 417 The security considerations of RFC 3414 [RFC3414] also apply to the 418 HMAC-SHA-2 authentication protocols defined in this document. 420 9.2. Cryptographic Strength of the Authentication Protocols 422 At the time of publication of this document, all of the HMAC-SHA-2 423 authentication protocols provide a very high level of security. The 424 security of each HMAC-SHA-2 authentication protocol depends on the 425 parameters used in the corresponding HMAC computation, which are the 426 length of the key (if the key has maximum entropy), the size of the 427 hash function's internal state, and the length of the truncated MAC. 428 For the HMAC-SHA-2 authentication protocols, these values are as 429 follows (values are given in bits). 431 +------------------------------+---------+----------------+---------+ 432 | Protocol | Key | Size of | MAC | 433 | | length | internal state | length | 434 +------------------------------+---------+----------------+---------+ 435 | usmHMAC128SHA224AuthProtocol | 224 | 256 | 128 | 436 | usmHMAC192SHA256AuthProtocol | 256 | 256 | 192 | 437 | usmHMAC256SHA384AuthProtocol | 384 | 512 | 256 | 438 | usmHMAC384SHA512AuthProtocol | 512 | 512 | 384 | 439 +------------------------------+---------+----------------+---------+ 441 Table 1: HMAC Parameters of the HMAC-SHA-2 Authentication Protocols 443 The security of the HMAC scales with both the key length and the size 444 of the internal state: longer keys render key guessing attacks more 445 difficult, and a larger internal state decreases the success 446 probability of MAC forgeries based on internal collisions of the hash 447 function. 449 The role of the truncated output length is more complicated: 450 according to [BCK], there is a trade-off in that 452 by outputting less bits the attacker has less bits to predict in a 453 MAC forgery but, on the other hand, the attacker also learns less 454 about the output of the compression function from seeing the 455 authentication tags computed by legitimate parties. 457 Thus, truncation weakens the HMAC against forgery by guessing but, at 458 the same time, strengthens it against chosen message attacks aiming 459 at MAC forgery based on internal collisions or at key guessing. RFC 460 2104 and [BCK] allow truncation to any length that is not less than 461 half the size of the internal 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 forming a second string 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 has assigned an OID for the MIB as follows. 500 +--------------------+-------------------------+ 501 | Descriptor | OBJECT IDENTIFIER value | 502 +--------------------+-------------------------+ 503 | snmpUsmHmacSha2MIB | { mib-2 235 } | 504 +--------------------+-------------------------+ 506 Table 2: OID of MIB 508 Furthermore, IANA has assigned a value in the SnmpAuthProtocols 509 registry for each of the following protocols. 511 +------------------------------+-------+-----------+ 512 | Description | Value | Reference | 513 +------------------------------+-------+-----------+ 514 | usmHMAC128SHA224AuthProtocol | 4 | RFC 7630 | 515 | usmHMAC192SHA256AuthProtocol | 5 | RFC 7630 | 516 | usmHMAC256SHA384AuthProtocol | 6 | RFC 7630 | 517 | usmHMAC384SHA512AuthProtocol | 7 | RFC 7630 | 518 +------------------------------+-------+-----------+ 520 Table 3: Code Points Assigned to HMAC-SHA-2 Authentication Protocols 522 11. References 523 11.1. Normative References 525 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 526 Hashing for Message Authentication", RFC 2104, 527 DOI 10.17487/RFC2104, February 1997, 528 . 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, 532 DOI 10.17487/RFC2119, March 1997, 533 . 535 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 536 Schoenwaelder, Ed., "Structure of Management Information 537 Version 2 (SMIv2)", STD 58, RFC 2578, 538 DOI 10.17487/RFC2578, April 1999, 539 . 541 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 542 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 543 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 544 . 546 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 547 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 548 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 549 . 551 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 552 (USM) for version 3 of the Simple Network Management 553 Protocol (SNMPv3)", STD 62, RFC 3414, 554 DOI 10.17487/RFC3414, December 2002, 555 . 557 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 558 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 559 DOI 10.17487/RFC6234, May 2011, 560 . 562 [SHA] National Institute of Standards and Technology, "Secure 563 Hash Standard (SHS)", FIPS PUB 180-4, 564 DOI 10.6028/NIST.FIPS.180-4, March 2012, 565 . 568 11.2. Informative References 570 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 571 DOI 10.17487/RFC1321, April 1992, 572 . 574 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 575 "Introduction and Applicability Statements for Internet- 576 Standard Management Framework", RFC 3410, 577 DOI 10.17487/RFC3410, December 2002, 578 . 580 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 581 Architecture for Describing Simple Network Management 582 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 583 DOI 10.17487/RFC3411, December 2002, 584 . 586 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 587 Network Management Protocol (SNMP)", STD 62, RFC 3417, 588 DOI 10.17487/RFC3417, December 2002, 589 . 591 [BCK] Bellare, M., Canetti, R., and H. Krawczyk, "Keyed Hash 592 Functions for Message Authentication", Advances in 593 Cryptology - CRYPTO 96, Lecture Notes in Computer 594 Science 1109, Springer-Verlag Berlin Heidelberg, 595 DOI 10.1007/3-540-68697-5_1, 1996. 597 Authors' Addresses 599 Johannes Merkle (editor) 600 Secunet Security Networks 601 Mergenthaler Allee 77 602 65760 Eschborn 603 Germany 605 Phone: +49 201 5454 3091 606 EMail: johannes.merkle@secunet.com 607 Manfred Lochter 608 BSI 609 Postfach 200363 610 53133 Bonn 611 Germany 613 Phone: +49 228 9582 5643 614 EMail: manfred.lochter@bsi.bund.de