idnits 2.17.1 draft-zheng-mpls-ldp-hello-crypto-auth-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5036, 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 (Using the creation date from RFC5036, updated by this document, for RFC5378 checks: 2004-10-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4782 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) == Missing Reference: 'RFC 5036' is mentioned on line 85, but not defined == Unused Reference: 'RFC2104' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC2385' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC4634' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC5709' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 385, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-198' -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group L. Zheng 2 Internet Draft M. Chen 3 Intended status: Standards Track Huawei Technologies 4 Updates: RFC 5036 (if approved) 5 Expires: September 2011 March 14, 2011 7 LDP Hello Cryptographic Authentication 9 draft-zheng-mpls-ldp-hello-crypto-auth-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 14, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This document introduces a new Cryptographic Authentication TLV 52 which is used in LDP Hello message as an optional parameter. It 53 enhances the authentication mechanism for LDP by securing the Hello 54 message against spoofing attack. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [RFC2119]. 62 Table of Contents 64 1. Introduction .................................................. 2 65 2. Cryptographic Authentication TLV .............................. 4 66 2.1. Optional Parameter for Hello Message ..................... 4 67 2.2. Cryptographic Authentication TLV Encoding ................ 4 68 3. Cryptographic Aspects ......................................... 5 69 3.1. Cryptographic Key ........................................ 6 70 3.2. Hash ..................................................... 6 71 3.3. Result ................................................... 7 72 4. Processing Hello Message Using Cryptographic Authentication ... 7 73 4.1. Transmission Using Cryptographic Authentication .......... 7 74 4.2. Receipt Using Cryptographic Authentication ............... 7 75 5. Security Considerations ....................................... 8 76 6. IANA Considerations ........................................... 8 77 7. Acknowledgments ............................................... 9 78 8. References .................................................... 9 79 8.1. Normative References ..................................... 9 80 8.2. Informative References .................................. 9 81 Authors' Addresses .............................................. 10 83 1. Introduction 85 The Label Distribution Protocol (LDP) [RFC 5036] utilizes LDP 86 sessions that run between LDP peers. The peers may be directly 87 connected at the link level or may be remote. A label switching 88 router (LSR) that speaks LDP may be configured with the identity of 89 its peers or may discover them using the LDP Hello message sent 90 encapsulated in UDP that may be addressed to "all routers on this 91 subnet" or to a specific IP address. Periodic Hello messages are 92 also used to maintain the relationship between LDP peers necessary 93 to keep the LDP session active. 95 Unlike all other LDP messages, the Hello messages are sent using UDP 96 not TCP. This means that they cannot benefit from the security 97 mechanisms available with TCP. [RFC5036] does not provide any 98 security mechanisms for use with Hello messages except to note that 99 some configuration may help protect against bogus discovery events. 101 Spoofing a Hello packet for an existing adjacency can cause the 102 valid adjacency to time out and in turn can result in termination of 103 the associated session. This can occur when the spoofed Hello 104 specifies a smaller Hold Time, causing the receiver to expect Hellos 105 within this smaller interval, while the true neighbor continues 106 sending Hellos at the previously agreed lower frequency. Spoofing a 107 Hello packet can also cause the LDP session to be terminated 108 directly, which can occur when the spoofed Hello specifies a 109 different Transport Address, other than the previously agreed one 110 between neighbors. Spoofed Hello messages is observed and reported 111 as real problem in production networks. 113 As described in [RFC5036], the threat of spoofed Basic Hellos can be 114 reduced by accepting Basic Hellos only on interfaces to which LSRs 115 that can be trusted, and ignoring Basic Hellos not addressed to the 116 "all routers on this subnet" multicast group. Spoofing attacks via 117 Extended Hellos are potentially more serious threat. An LSR can 118 reduce the threat of spoofed Extended Hellos by filtering them and 119 accepting only those originating at sources permitted by an access 120 list. However, performing the filtering using access lists requires 121 LSR resource, and the LSR is still vulnerable to the IP source 122 address spoofing. 124 This document introduces a new Cryptographic Authentication TLV 125 which is used in LDP Hello message as an optional parameter. It 126 enhances the authentication mechanism for LDP by securing the Hello 127 message against spoofing attack, and an LSR can be configured to 128 only accept Hello messages from specific peers when authentication 129 is in use. 131 Using this Cryptographic Authentication TLV, one or more secret keys 132 (with corresponding key IDs) are configured in each system. For each 133 LDP Hello packet, the key is used to generate and verify a HMAC Hash 134 that is stored in the LDP Hello packet. For cryptographic hash 135 function, this document proposes to use SHA-1, SHA-256, SHA-384, and 136 SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-3]. 137 The HMAC authentication mode defined in NIST FIPS 198 is used [FIPS- 138 198]. Of the above, implementations MUST include support for at 139 least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and MAY 140 include support for either of HMAC-SHA-384 or HMAC-SHA-512. 142 2. Cryptographic Authentication TLV 144 2.1. Optional Parameter for Hello Message 146 [RFC5036] defines the encoding for the Hello message. Each Hello 147 message contains zero or more Optional Parameters, each encoded as a 148 TLV. Three Optional Parameters are defined by [RFC5036]. This 149 document defines a new Optional Parameter: the Cryptographic 150 Authentication parameter. 152 Optional Parameter Type 153 ------------------------------- -------- 154 IPv4 Transport Address 0x0401 (RFC5036) 155 Configuration Sequence Number 0x0402 (RFC5036) 156 IPv6 Transport Address 0x0403 (RFC5036) 157 Cryptographic Authentication 0x0404 (this document, TBD by 158 IANA) 159 The Cryptographic Authentication TLV Encoding is described in 160 section 2.2. 162 2.2. Cryptographic Authentication TLV Encoding 164 0 1 2 3 165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |0|0| Auth (0x0404) | Length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Auth Type | Reserved | Auth Key ID | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 ~ Authentication Data ~ 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 - Type: 0x0404 (TBD by IANA), Cryptographic Authentication 176 - Length: Specifying the length in octets of the value field. 178 - Auth Type: The authentication type in use 179 0 - HMAC-SHA-1 180 1 - HMAC-SHA-256 181 2 - HMAC-SHA-384 182 3 - HMAC-SHA-512 183 4-255 - Reserved for future use 184 (TBD by IANA) 186 - Reserved: MUST be set to zero on transmit, and ignored on receipt 188 - Auth Key ID: The authentication key ID in use for this packet. 189 This allows one or more keys to be active simultaneously. 191 - Authentication Data: 193 This field carries the digest computed by the Cryptographic 194 Authentication algorithm in use. The length of the Authentication 195 Data varies based on the cryptographic algorithm in used, which is 196 shown as below: 198 Auth type Length 199 ---------------------- ---------- 200 HMAC-SHA1 20 bytes 201 HMAC-SHA-256 32 bytes 202 HMAC-SHA-384 48 bytes 203 HMAC-SHA-512 64 bytes 205 3. Cryptographic Aspects 207 In the algorithm description below, the following nomenclature, 208 which is consistent with [FIPS-198], is used: 210 - H is the specific hashing algorithm specified by Auth Type (e.g. 211 SHA-256). 213 - K is the Authentication Key for the Hello packet. 215 - Ko is the cryptographic key used with the hash algorithm. 217 - B is the block size of H, in octets. 219 For SHA-1 and SHA-256: B == 64 221 For SHA-384 and SHA-512: B == 128 223 - L is the length of the hash outputs, in octets. 225 - XOR is the exclusive-or operation. 227 - Ipad is the byte 0x36 repeated B times. 229 - Opad is the byte 0x5c repeated B times. 231 - Apad is the byte 0x878FE1F3 repeated (L/4) times. 233 3.1. Cryptographic Key 235 As described in RFC 2104, the authentication key K can be of any 236 length up to B. Applications that use keys longer than B bytes will 237 first hash the key using H and then use the resultant L byte string 238 as the actual key to HMAC. 240 In this application, Ko is always L octets long. If the 241 Authentication Key (K) is L octets long, then Ko is equal to K. If 242 the Authentication Key (K) is more than L octets long, then Ko is 243 set to H(K). If the Authentication Key (K) is less than L octets 244 long, then Ko is set to the Authentication Key (K) with trailing 245 zeros such that Ko is L octets long. 247 3.2. Hash 249 First, the Authentication Data field in the Cryptographic 250 Authentication TLV is filled with the value Apad and the Auth Type 251 field is set accordingly per Cryptographic Authentication algorithm 252 in use. 254 Then, to compute HMAC over the Hello packet it performs: 256 H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet))) 258 Hello Packet here is the entire LDP Hello packet including the IP 259 header. 261 3.3. Result 263 The resultant Hash becomes the Authentication Data that is 264 sent in the Authentication Data field of the Cryptographic 265 Authentication TLV. The length of the Authentication Data field is 266 always identical to the message digest size of the specific hash 267 function H that is being used. 269 4. Processing Hello Message Using Cryptographic Authentication 271 4.1. Transmission Using Cryptographic Authentication 273 Prior to transmitting Hello message, the Auth Type field is set to 274 indicate the authentication type in use. The Length in the 275 Cryptographic Authentication TLV header is set as per the 276 authentication algorithm that is being used. It is set to 24 for 277 HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384 and 68 for 278 HMAC-SHA-512. 280 The Auth Key ID field is set to the ID of the current authentication 281 key. The HMAC Hash is computed as explained in Section 3. The 282 resulting Hash is stored in the Authentication Data field prior to 283 transmission. The authentication key MUST NOT be carried in the 284 packet. 286 4.2. Receipt Using Cryptographic Authentication 288 The receiving LSR applies acceptability criteria for received Hellos 289 using cryptographic authentication. If the Cryptographic 290 Authentication TLV is unknown to the receiving LSR, the received 291 packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036]. 293 If the Cryptographic Authentication TLV in a received Hello packet 294 does not contain a known and acceptable Auth Type value, then the 295 received packet MUST be discarded. If the Auth Key ID field does not 296 match the ID of a configured authentication key, the received packet 297 MUST be discarded. 299 Before the receiving LSR performs any processing, it needs to save 300 the values of the Authentication Data field. The receiving LSR then 301 replaces the contents of the Authentication Data field with Apad, 302 computes the Hash, using the authentication key specified by the 303 received Auth Key ID field, as explained in Section 3. If the 304 locally computed Hash is equal to the received value of the 305 Authentication Data field, the received packet is accepted for other 306 normal checks and processing as described in [RFC5036]. Otherwise, 307 the received packet MUST be discarded. 309 5. Security Considerations 311 Section 1 of this document describes the security issues arising 312 from the use of unsecured LDP Hello messages. In order to combat 313 those issues, it is RECOMMENDED that all deployments use the 314 Cryptographic Authentication TLV to secure the Hello message. 316 The quality of the security provided by the Cryptographic 317 Authentication TLV depends completely on the strength of the 318 cryptographic algorithm in use, the strength of the key being used, 319 and the correct implementation of the security mechanism in 320 communicating LDP implementations. Also, the level of security 321 provided by the Cryptographic Authentication TLV varies based on the 322 authentication type used. 324 6. IANA Considerations 326 IANA maintains a registry of LDP message parameters with a sub- 327 registry to track LDP TLV Types. This document request IANA to 328 assign a new TLV Types as follows: 330 TLV Type 332 Cryptographic Authentication 0x0404 (TBD) 334 This document also request IANA to assign a new registry titled "LDP 335 Hello Authentication Type", its recommended values as follows: 337 Value LDP Hello Authentication Type Name 338 ------- ----------------------------------- 339 0 HMAC-SHA1 340 1 HMAC-SHA-256 341 2 HMAC-SHA-384 342 3 HMAC-SHA-512 343 4-255 Unassigned 344 (TBD) 346 7. Acknowledgments 348 The authors would like to thank Liu Xuehu for his work on background 349 and motivation for LDP Hello authentication. The authors also would 350 like to thank Adrian Farrel, Thomas Nadeau, So Ning, Eric Rosen, Sam 351 Hartman and Manav Bhatia for their valuable comments. 353 8. References 355 8.1. Normative References 357 [RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message 358 Authentication", RFC 2104, February 1997. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 364 Specification", RFC 5036, October 2007. 366 [FIPS-180-3] National Institute of Standards and Technology, "Secure 367 Hash Standard (SHS)", FIPS PUB 180-3, October 2008. 369 [FIPS-198] US National Institute of Standards & Technology, "The 370 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 371 198, March 2002. 373 8.2. Informative References 375 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 376 Signature Option", RFC 2385, August 1998. 378 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 379 (SHA and HMAC-SHA)", RFC 4634, July 2006. 381 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 382 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 383 Authentication", RFC 5709, October 2009. 385 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", 386 RFC 5880, June 2010. 388 Authors' Addresses 390 Lianshu Zheng 391 Huawei Technologies Co., Ltd. 392 Huawei Building, No.3 Xinxi Road, 393 Hai-Dian District, 394 Beijing 100085 395 China 397 Email: verozheng@huawei.com 399 Mach(Guoyi) Chen 400 Huawei Technologies Co., Ltd. 401 Huawei Building, No.3 Xinxi Road, 402 Hai-Dian District, 403 Beijing 100085 404 China 406 Email: mach@huawei.com