idnits 2.17.1 draft-hartman-snmp-sha2-02.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 (July 31, 2014) is 3550 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6039' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'Dobb96a' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'Dobb96b' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-design-guide' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'MD5-attack' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'NIST-HMAC-SHA' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC4822' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC5310' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 408, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft M. Wasserman 4 Intended status: Experimental Painless Security 5 Expires: February 1, 2015 D. Zhang 6 Huawei 7 M. Bhatia 8 A-L 9 D. He 10 Huawei 11 July 31, 2014 13 Authenticating version 3 of the Simple Network Management Protocol 14 (SNMPv3) using HMAC-SHA-2 procedures 15 draft-hartman-snmp-sha2-02 17 Abstract 19 This document describes the mechanism to authenticate SNMPv3 protocol 20 packets using Hashed Message Authentication Mode (HMAC) with the SHA- 21 256, SHA-384, and SHA-512 algorithms. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 1, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 3 65 3. Authentication Protocols using SHA-2 . . . . . . . . . . . . 4 66 3.1. Elements of Authentication Protocols . . . . . . . . . . 4 67 3.1.1. Users . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1.2. SNMP Messages Using this Authentication Protocol . . 5 69 3.2. Services Provided by the Authentication Module . . . . . 5 70 3.2.1. Services for Generating an Outgoing SNMP Message . . 5 71 3.2.2. Services for Processing an Incoming SNMP Message . . 6 72 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Procedures at the Sending Side . . . . . . . . . . . . . 6 74 4.2. Procedure at the Receiving Side . . . . . . . . . . . . . 7 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 8.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The cryptographic authentication mechanism proposed in [RFC3414] 86 specifies the support of MD5 [RFC1321] and Secure Hash Algorithm 87 (SHA-1) algorithms for authenticating SNMPv3 packets. The recent 88 escalating series of attacks on MD5 and SHA-1 [SHA-1-attack1] 89 [SHA-1-attack2] raise concerns about their remaining useful lifetime 90 [RFC6151] [RFC6194]. 92 These attacks may not necessarily result in direct vulnerabilities 93 for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes 94 because the colliding message may not correspond to a syntactically 95 correct SNMP protocol packet. Regardless, there is a need felt to 96 deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor 97 of stronger digest algorithms. 99 This document adds support for Secure Hash Algorithms (SHA) defined 100 in the US NIST Secure Hash Standard (SHS), which is defined by NIST 101 FIPS 180-2 [FIPS-180-2]. [FIPS-180-2] includes SHA-1, SHA-224, SHA- 102 256, SHA-384, and SHA-512. The HMAC authentication mode defined in 103 NIST FIPS 198 is used [FIPS-198]. 105 2. Cryptographic Aspects 107 In the algorithm description below, the following nomenclature, which 108 is consistent with [FIPS-198], is used: 110 H is the specific hashing algorithm (e.g. SHA-256). 112 K is the secret key for authentication. 114 Ko is the cryptographic key used with the hash algorithm. 116 B is the block size of H, measured in octets rather than bits. Note 117 that B is the internal block size, not the hash size. 119 For SHA-1 and SHA-256: B == 64 121 For SHA-384 and SHA-512: B == 128 123 L is the length of the hash, measured in octets rather than bits. 125 XOR is the exclusive-or operation. 127 Opad is the hexadecimal value 0x5c repeated B times. 129 Ipad is the hexadecimal value 0x36 repeated B times. 131 Apad is the hexadecimal value of source IPv4 address repeated (L/4) 132 times (repeated (L/16) for IPV6 addresses). 134 (1) Preparation of the Key 136 In this application, Ko is always L octets long. 138 If the Authentication Key (K) is L octets long, then Ko is equal to 139 K. If the Authentication Key (K) is more than L octets long, then Ko 140 is set to H(K). If the Authentication Key (K) is less than L octets 141 long, then Ko is set to the Authentication Key (K) with zeros 142 appended to the end of the Authentication Key (K) such that Ko is L 143 octets long. 145 (2) First Hash 147 First, the AuthenticationParameters field is filled with the value of 148 Apad and is set to the serialization, according to the rules in 149 [RFC3417]. 151 Then, a first hash, also known as the inner hash, is computed as 152 follows: 154 First-Hash = H(Ko XOR Ipad || (SNMP Packet)) 156 (3) Second Hash T 158 Then a second hash, also known as the outer hash, is computed as 159 follows: 161 Second-Hash = H(Ko XOR Opad || First-Hash) 163 (4) Result 165 The resultant Second-Hash becomes the Authentication Data that is 166 sent in the AuthenticationParameters field. The length of the 167 AuthenticationParameters field is always identical to the message 168 digest size of the specific hash function H that is being used. 170 3. Authentication Protocols using SHA-2 172 This section introduces how the authentication protocols using SHA-2 173 work. The protocols are identical to the authentication protocols 174 proposed in the [RFC3414] except the authentication algorithms used 175 in generating digests. 177 3.1. Elements of Authentication Protocols 179 3.1.1. Users 181 Authentication using the authentication protocols makes use of a 182 defined set of userNames. For any user on whose behalf a message 183 must be authenticated at a particular SNMP engine, that SNMP engine 184 must have knowledge of that user. An SNMP engine that wishes to 185 communicate with another SNMP engine must also have knowledge of a 186 user known to that engine, including knowledge of the applicable 187 attributes of that user. 189 A user and its attributes are defined as follows: 191 A string representing the name of the user. 193 A user's secret key to be used when calculating a digest. 194 Specifically, the value SHOULD be 32 octets for HMAC-SHA-256, 48 195 octets for HMAC-SHA-384, and 64 octets for HMAC- SHA-512. 197 3.1.2. SNMP Messages Using this Authentication Protocol 199 Messages using this authentication protocol carry a 200 msgAuthenticationParameters field as part of the 201 msgSecurityParameters. For this protocol, the 202 msgAuthenticationParameters field is the serialized OCTET STRING 203 representing the SHA-2 output done over the wholeMsg. Specifically, 204 the length of this field is 32 octets for HMAC-SHA-256, 48 octets for 205 HMAC-SHA-384, and 64 octets for HMAC- SHA-512. The digest is 206 calculated over the wholeMsg so if a message is authenticated, which 207 also means that all the fields in the message are intact and have not 208 been tampered with. 210 3.2. Services Provided by the Authentication Module 212 3.2.1. Services for Generating an Outgoing SNMP Message 214 The authentication protocol assumes that the selection of the authKey 215 is done by the caller and that the caller passes the secret key to be 216 used. Upon completion the authentication module returns 217 statusInformation and, if the message digest was correctly 218 calculated, the wholeMsg with the digest inserted at the proper 219 place. The abstract service primitive is: 221 statusInformation = -- success or failure 222 authenticateOutgoingMsg( 223 IN authKey -- secret key for authentication 224 IN wholeMsg -- unauthenticated complete message 225 OUT authenticatedWholeMsg -- complete authenticated message 226 ) 228 The abstract data elements are: 230 statusInformation: An indication of whether the authentication 231 process was successful. If not it is an indication of the problem. 233 authKey: The secret key to be used by the authentication algorithm. 235 wholeMsg: The message to be authenticated. 237 authenticatedWholeMsg: The authenticated message (including inserted 238 digest) on output. 240 3.2.2. Services for Processing an Incoming SNMP Message 242 The authentication protocol assumes that the selection of the authKey 243 is done by the caller and that the caller passes the secret key to be 244 used. Upon completion the authentication module returns 245 statusInformation and, if the message digest was correctly 246 calculated, the wholeMsg as it was processed. The abstract service 247 primitive is: 249 statusInformation = -- success or failure 250 authenticateIncomingMsg( 251 IN authKey -- secret key for authentication 252 IN authParameters -- as received on the wire 253 IN wholeMsg -- as received on the wire 254 OUT authenticatedWholeMsg -- complete authenticated message 255 ) 257 The abstract data elements are: 259 statusInformation: An indication of whether the authentication 260 process was successful. If not it is an indication of the problem. 262 authKey: The secret key to be used by the authentication algorithm. 264 authParameters: The authParameters from the incoming message. 266 wholeMsg: The message to be authenticated on input and the 267 authenticated message on output. 269 authenticatedWholeMsg: The whole message after the authentication 270 check is complete. 272 4. Elements of Procedure 274 4.1. Procedures at the Sending Side 276 Before a SNMPv3 device sends an SNMP packet out, the device needs to 277 select an appropriate key for authentication if a keyed digest for 278 the packet is required. If no appropriate key is available, the SNMP 279 packet MUST be discarded. 281 If an appropriate key for authentication is available, the device 282 then finds the authentication algorithm (HMAC-SHA-256, HMAC-SHA-384 283 or HMAC-SHA-512) associated with the key. 285 Then, the operations illustrated in Section 2 are performed. 287 The authenticatedWholeMsg is then returned to the caller together 288 with statusInformation indicating success. 290 4.2. Procedure at the Receiving Side 292 Upon receiving an SNMP packet with a msgAuthenticationParameters 293 field appended, a device needs to locate an appropriate key for 294 authentication to verify the packet. 296 If there is no key found or the length of the digest received in the 297 msgAuthenticationParameters field does not match the length 298 associated with authentication algorithm, the received packet MUST be 299 discarded. 301 An authentication algorithm dependent process then needs to be 302 performed by using the algorithm specified by the appropriate key for 303 the received packet. 305 Before the device performs any processing, it needs to save the 306 content of the AuthenticationParameters field and set the 307 AuthenticationParameters field with Apad. 309 Then, the operations illustrated in Section 2 are performed. The 310 calculated data is compared with the received authentication data in 311 the packet. 313 The packet MUST be discarded if the calculated and the received 314 authentication data do not match. In this case, a failure and an 315 errorIndication (authenticationFailure) are returned to the calling 316 module. Otherwise, the authenticatedWholeMsg and statusInformation 317 indicating success are then returned to the caller. 319 5. IANA Considerations 321 This document makes no request of IANA. 323 Note to RFC Editor: this section may be removed on publication as an 324 RFC. 326 6. Security Considerations 328 7. Acknowledgements 330 This work makes use of signifitent texts from that RFC3414. 332 8. References 334 8.1. Normative References 336 [FIPS-180-2] 337 National Institute of Standards and Technology, FIPS PUB 338 180-2, "The Keyed-Hash Message Authentication Code 339 (HMAC)", August 2002. 341 [FIPS-198] 342 National Institute of Standards and Technology, FIPS PUB 343 198, "The Keyed-Hash Message Authentication Code (HMAC)", 344 March 2002. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 350 Management Protocol (SNMP)", STD 62, RFC 3417, December 351 2002. 353 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 354 with Existing Cryptographic Protection Methods for Routing 355 Protocols", RFC 6039, October 2010. 357 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 358 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 359 RFC 6151, March 2011. 361 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 362 Considerations for the SHA-0 and SHA-1 Message-Digest 363 Algorithms", RFC 6194, March 2011. 365 8.2. Informative References 367 [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. 369 [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", 370 CryptoBytes", 1996. 372 [I-D.ietf-karp-design-guide] 373 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 374 Routing Protocols (KARP) Design Guidelines", draft-ietf- 375 karp-design-guide-10 (work in progress), December 2011. 377 [MD5-attack] 378 Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for 379 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 380 2004. 382 [NIST-HMAC-SHA] 383 National Institute of Standards and Technology, Available 384 online at http://csrc.nist.gov/groups/ST/hash/policy.html, 385 "NIST's Policy on Hash Functions", 2006. 387 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 388 April 1992. 390 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 391 Hashing for Message Authentication", RFC 2104, February 392 1997. 394 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 395 (USM) for version 3 of the Simple Network Management 396 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 398 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 399 Requirements for Security", BCP 106, RFC 4086, June 2005. 401 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 402 Authentication", RFC 4822, February 2007. 404 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 405 and M. Fanto, "IS-IS Generic Cryptographic 406 Authentication", RFC 5310, February 2009. 408 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 409 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 411 [SHA-1-attack1] 412 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 413 Full SHA-1", 2005. 415 [SHA-1-attack2] 416 Wang, X., Yao, A., and F. Yao, "New Collision Search for 417 SHA-1", 2005. 419 Authors' Addresses 420 Sam Hartman 421 Painless Security 422 356 Abbott Street 423 North Andover, MA 01845 424 USA 426 Email: hartmans@painless-security.com 427 URI: http://www.painless-security.com 429 Margaret Wasserman 430 Painless Security 431 356 Abbott Street 432 North Andover, MA 01845 433 USA 435 Phone: +1 781 405 7464 436 Email: mrw@painless-security.com 437 URI: http://www.painless-security.com 439 Dacheng Zhang 440 Huawei 441 Beijing 442 China 444 Email: zhangdacheng@huawei.com 446 Manav Bhatia 447 A-L 448 India 450 Email: manav.bhatia@alcatel-lucent.com 452 Danping He 453 Huawei 454 Beijing 455 China 457 Email: ana.hedanping@huawei.com