idnits 2.17.00 (12 Aug 2021) /tmp/idnits63537/draft-ietf-ospf-rfc6506bis-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 : ---------------------------------------------------------------------------- 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 8, 2013) is 3147 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) ** Obsolete normative reference: RFC 6506 (Obsoleted by RFC 7166) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Obsoletes: 6506 (if approved) V. Manral 5 Intended status: Standards Track Hewlett Packard 6 Expires: April 11, 2014 A. Lindem 7 Ericsson 8 October 8, 2013 10 Supporting Authentication Trailer for OSPFv3 11 draft-ietf-ospf-rfc6506bis-01.txt 13 Abstract 15 Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism 16 for authenticating protocol packets. This behavior is different from 17 authentication mechanisms present in other routing protocols (OSPFv2, 18 Intermediate System to Intermediate System (IS-IS), RIP, and Routing 19 Information Protocol Next Generation (RIPng)). In some environments, 20 it has been found that IPsec is difficult to configure and maintain 21 and thus cannot be used. This document defines an alternative 22 mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does 23 not only depend upon IPsec for authentication. This document 24 obsoletes RFC 6506. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 11, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.2. Summary of Changes from RFC 6506 . . . . . . . . . . . . . 5 75 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 7 76 2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 7 77 2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 78 2.3. IPv6 Source Address Protection . . . . . . . . . . . . . . 8 79 3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 10 80 4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 13 81 4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 13 82 4.1.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . 14 83 4.2. OSPFv3 Header Checksum and LLS Data Block Checksum . . . . 15 84 4.3. Cryptographic Authentication Procedure . . . . . . . . . . 15 85 4.4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . 16 86 4.5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 16 87 4.6. Message Verification . . . . . . . . . . . . . . . . . . . 18 88 5. Migration and Backward Compatibility . . . . . . . . . . . . . 21 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 94 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 97 1. Introduction 99 Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF 100 for IPv6 (OSPFv3) [RFC5340] does not include the AuType and 101 Authentication fields in its headers for authenticating protocol 102 packets. Instead, OSPFv3 relies on the IPsec protocols 103 Authentication Header (AH) [RFC4302] and Encapsulating Security 104 Payload (ESP) [RFC4303] to provide integrity, authentication, and/or 105 confidentiality. 107 [RFC4552] describes how IPv6 AH and ESP extension headers can be used 108 to provide authentication and/or confidentiality to OSPFv3. 110 However, there are some environments, e.g., Mobile Ad Hoc Networks 111 (MANETs), where IPsec is difficult to configure and maintain, and 112 this mechanism cannot be used. 114 [RFC4552] discusses, at length, the reasoning behind using manually 115 configured keys, rather than some automated key management protocol 116 such as Internet Key Exchange version 2 (IKEv2) [RFC5996]. The 117 primary problem is the lack of a suitable key management mechanism, 118 as OSPFv3 adjacencies are formed on a one-to-many basis and most key 119 management mechanisms are designed for a one-to-one communication 120 model. This forces the system administrator to use manually 121 configured security associations (SAs) and cryptographic keys to 122 provide the authentication and, if desired, confidentiality services. 124 Regarding replay protection, [RFC4552] states that: 126 Since it is not possible using the current standards to provide 127 complete replay protection while using manual keying, the proposed 128 solution will not provide protection against replay attacks. 130 Since there is no replay protection provided there are a number of 131 vulnerabilities in OSPFv3 that have been discussed in [RFC6039]. 133 Since there is no deterministic way to differentiate between 134 encrypted and unencrypted ESP packets by simply examining the packet, 135 it could be difficult for some implementations to prioritize certain 136 OSPFv3 packet types, e.g., Hello packets, over the other types. 138 This document defines a new mechanism that works similarly to OSPFv2 139 [RFC5709] to provide authentication to the OSPFv3 packets and 140 attempts to solve the problems related to replay protection and 141 deterministically disambiguating different OSPFv3 packets as 142 described above. 144 This document adds support for the Secure Hash Algorithms (SHAs) 145 defined in the US NIST Secure Hash Standard (SHS), which is specified 146 by NIST FIPS 180-3. [FIPS-180-3] includes SHA-1, SHA-224, SHA-256, 147 SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC) 148 authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used. 150 It is believed that HMAC as defined in [RFC2104] is mathematically 151 identical to [FIPS-198-1]; it is also believed that algorithms in 152 [RFC6234] are mathematically identical to [FIPS-198-1]. 154 1.1. Requirements 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 1.2. Summary of Changes from RFC 6506 162 This document includes the following changes from RFC 6506 [RFC6506]: 164 1. Sections 2.2 and 4.2 explicitly state that the Link-Local 165 Signaling (LLS) block checksum calculation is omitted when an 166 OSPFv3 authentication trailer is used for OSPFv3 authentication. 167 The LLS block is included in the authentication digest 168 calculation and computation of a checksum is unnecessary. 169 Clarification of this issue was documented in an errata. 171 2. Section 3 previously advocated usage of an expired key for 172 transmitted OSPFv3 packets when no valid keys existed. This 173 statement has been removed. 175 3. Section 4.5 includes a correction to the key preparation to use 176 the protocol specific key (Ks) rather than the key (K) as the 177 initial key (Ko). This problem was also documented in an errata. 179 4. Section 4.5 also includes a discussion of the choice of key 180 length to be the hash length (L) rather than the block size (B). 181 The discussion of this choice was included to clarify an issue 182 raised in a rejected errata. 184 5. Section 4.1 and 4.6 indicate that sequence number checking is 185 dependent on OSPFv3 packet type in order to account for packet 186 prioritization as specified in [RFC4222]. This was an omission 187 from RFC 6506 [RFC6506]. 189 6. Section 4.6 explicitly states that OSPFv3 packets with a non- 190 existent or expired Security Association (SA) will be dropped. 192 7. Section 5 includes guidance on precisely the actions required for 193 an OSPFv3 router providing a backward compatible transition mode. 195 2. Proposed Solution 197 To perform non-IPsec Cryptographic Authentication, OSPFv3 routers 198 append a special data block, henceforth referred to as the 199 Authentication Trailer, to the end of the OSPFv3 packets. The length 200 of the Authentication Trailer is not included in the length of the 201 OSPFv3 packet but is included in the IPv6 payload length, as shown in 202 Figure 1. 204 +---------------------+ -- -- +----------------------+ 205 | IPv6 Payload Length | ^ ^ | IPv6 Payload Length | 206 | PL = OL + LL | | | | PL = OL + LL + AL | 207 | | v v | | 208 +---------------------+ -- -- +----------------------+ 209 | OSPFv3 Header | ^ ^ | OSPFv3 Header | 210 | Length = OL | | | | Length = OL | 211 | | | OSPFv3 | | | 212 |.....................| | Packet | |......................| 213 | | | Length | | | 214 | OSPFv3 Packet | | | | OSPFv3 Packet | 215 | | v v | | 216 +---------------------+ -- -- +----------------------+ 217 | | ^ ^ | | 218 | Optional LLS | | LLS Data | | Optional LLS | 219 | LLS Block Len = LL | | Block | | LLS Block Len = LL | 220 | | v Length v | | 221 +---------------------+ -- -- +----------------------+ 222 ^ | | 223 AL = PL - (OL + LL) | | Authentication | 224 | | AL = Fixed Trailer + | 225 v | Digest Length | 226 -- +----------------------+ 228 Figure 1: Authentication Trailer in OSPFv3 230 The presence of the Link-Local Signaling (LLS) [RFC5613] block is 231 determined by the L-bit setting in the OSPFv3 Options field in OSPFv3 232 Hello and Database Description packets. If present, the LLS data 233 block is included along with the OSPFv3 packet in the Cryptographic 234 Authentication computation. 236 2.1. AT-Bit in Options Field 238 A new AT-bit (AT stands for Authentication Trailer) is introduced 239 into the OSPFv3 Options field. OSPFv3 routers MUST set the AT-bit in 240 OSPFv3 Hello and Database Description packets to indicate that all 241 the packets on this link will include an Authentication Trailer. For 242 OSPFv3 Hello and Database Description packets, the AT-bit indicates 243 the AT is present. For other OSPFv3 packet types, the OSPFv3 AT-bit 244 setting from the OSPFv3 Hello/Database Description setting is 245 preserved in the OSPFv3 neighbor data structure. OSPFv3 packet types 246 that don't include an OSPFv3 Options field will use the setting from 247 the neighbor data structure to determine whether or not the AT is 248 expected. 250 0 1 2 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ 253 | | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6| 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ 256 Figure 2: OSPFv3 Options Field 258 The AT-bit, as shown in the figure above, MUST be set in all OSPFv3 259 Hello and Database Description packets that contain an Authentication 260 Trailer. 262 2.2. Basic Operation 264 The procedure followed for computing the Authentication Trailer is 265 much the same as described in [RFC5709] and [RFC2328]. One 266 difference is that the LLS data block, if present, is included in the 267 Cryptographic Authentication computation. 269 The way the authentication data is carried in the Authentication 270 Trailer is very similar to how it is done in case of [RFC2328]. The 271 only difference between the OSPFv2 Authentication Trailer and the 272 OSPFv3 Authentication Trailer is that information in addition to the 273 message digest is included. The additional information in the OSPFv3 274 Authentication Trailer is included in the message digest computation 275 and is therefore protected by OSPFv3 Cryptographic Authentication as 276 described herein. 278 Consistent with OSPFv2 Cryptographic Authentication [RFC2328] and 279 Link-Local Signaling Cryptographic Authentication [RFC5613], checksum 280 calculation and verification are omitted for both the OSPFv3 header 281 checksum and the LLS Data Block when the OSPFv3 authentication 282 mechanism described in this specification is used. 284 2.3. IPv6 Source Address Protection 286 While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, 287 the IPv6 source address is learned from OSPFv3 Hello packets and 288 copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is 289 susceptible to Man-in-the-Middle attacks where the IPv6 source 290 address is modified. To thwart such attacks, the IPv6 source address 291 will be included in the message digest calculation and protected by 292 OSPFv3 authentication. Refer to Section 4.5 for details. This is 293 different than the procedure specified in [RFC5709] but consistent 294 with [MANUAL-KEY]. 296 3. OSPFv3 Security Association 298 An OSPFv3 Security Association (SA) contains a set of parameters 299 shared between any two legitimate OSPFv3 speakers. 301 Parameters associated with an OSPFv3 SA are as follows: 303 o Security Association Identifier (SA ID) 305 This is a 16-bit unsigned integer used to uniquely identify an 306 OSPFv3 SA, as manually configured by the network operator. 308 The receiver determines the active SA by looking at the SA ID 309 field in the incoming protocol packet. 311 The sender, based on the active configuration, selects an SA to 312 use and puts the correct Key ID value associated with the SA in 313 the OSPFv3 protocol packet. If multiple valid and active OSPFv3 314 SAs exist for a given interface, the sender may use any of those 315 SAs to protect the packet. 317 Using SA IDs makes changing keys while maintaining protocol 318 operation convenient. Each SA ID specifies two independent parts, 319 the authentication algorithm and the Authentication Key, as 320 explained below. 322 Normally, an implementation would allow the network operator to 323 configure a set of keys in a key chain, with each key in the chain 324 having a fixed lifetime. The actual operation of these mechanisms 325 is outside the scope of this document. 327 Note that each SA ID can indicate a key with a different 328 authentication algorithm. This allows the introduction of new 329 authentication mechanisms without disrupting existing OSPFv3 330 adjacencies. 332 o Authentication Algorithm 334 This signifies the authentication algorithm to be used with this 335 OSPFv3 SA. This information is never sent in clear text over the 336 wire. Because this information is not sent on the wire, the 337 implementer chooses an implementation-specific representation for 338 this information. 340 Currently, the following algorithms are supported: 342 * HMAC-SHA-1, 343 * HMAC-SHA-256, 345 * HMAC-SHA-384, and 347 * HMAC-SHA-512. 349 o Authentication Key 351 This value denotes the Cryptographic Authentication Key associated 352 with this OSPFv3 SA. The length of this key is variable and 353 depends upon the authentication algorithm specified by the OSPFv3 354 SA. 356 o KeyStartAccept 358 The time that this OSPFv3 router will accept packets that have 359 been created with this OSPFv3 SA. 361 o KeyStartGenerate 363 The time that this OSPFv3 router will begin using this OSPFv3 SA 364 for OSPFv3 packet generation. 366 o KeyStopGenerate 368 The time that this OSPFv3 router will stop using this OSPFv3 SA 369 for OSPFv3 packet generation. 371 o KeyStopAccept 373 The time that this OSPFv3 router will stop accepting packets 374 generated with this OSPFv3 SA. 376 In order to achieve smooth key transition, KeyStartAccept SHOULD be 377 less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than 378 KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left 379 unspecified, the time will default to 0, and the key will be used 380 immediately. If KeyStopGenerate or KeyStopAccept are left 381 unspecified, the time will default to infinity, and the key's 382 lifetime will be infinite. When a new key replaces an old, the 383 KeyStartGenerate time for the new key MUST be less than or equal to 384 the KeyStopGenerate time of the old key. 386 Key storage SHOULD persist across a system restart, warm or cold, to 387 avoid operational issues. In the event that the last key associated 388 with an interface expires, it is unacceptable to revert to an 389 unauthenticated condition and not advisable to disrupt routing. 390 Therefore, the router SHOULD send a "last Authentication Key 391 expiration" notification to the network operator and treat the key as 392 having an infinite lifetime until the lifetime is extended, the key 393 is deleted by the network operator, or a new key is configured. 395 4. Authentication Procedure 397 4.1. Authentication Trailer 399 The Authentication Trailer that is appended to the OSPFv3 protocol 400 packet is described below: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Authentication Type | Auth Data Len | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Reserved | Security Association ID | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Cryptographic Sequence Number (High-Order 32 Bits) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Cryptographic Sequence Number (Low-Order 32 Bits) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 | Authentication Data (Variable) | 415 ~ ~ 416 | | 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 3: Authentication Trailer Format 422 The various fields in the Authentication Trailer are: 424 o Authentication Type 426 16-bit field identifying the type of authentication. The 427 following values are defined in this specification: 429 0 - Reserved. 430 1 - HMAC Cryptographic Authentication as described herein. 432 o Auth Data Len 434 The length in octets of the Authentication Trailer (AT) including 435 both the 16-octet fixed header and the variable length message 436 digest. 438 o Reserved 440 This field is reserved. It SHOULD be set to 0 when sending 441 protocol packets and MUST be ignored when receiving protocol 442 packets. 444 o Security Association Identifier (SA ID) 446 16-bit field that maps to the authentication algorithm and the 447 secret key used to create the message digest appended to the 448 OSPFv3 protocol packet. 450 Though the SA ID implicitly implies the algorithm, the HMAC output 451 size should not be used by implementers as an implicit hint 452 because additional algorithms may be defined in the future that 453 have the same output size. 455 o Cryptographic Sequence Number 457 64-bit strictly increasing sequence number that is used to guard 458 against replay attacks. The 64-bit sequence number MUST be 459 incremented for every OSPFv3 packet sent by the OSPFv3 router. 460 Upon reception, the sequence number MUST be greater than the 461 sequence number in the last accepted OSPFv3 packet of the same 462 OSPFv3 packet type from the sending OSPFv3 neighbor. Otherwise, 463 the OSPFv3 packet is considered a replayed packet and dropped. 464 OSPFv3 packets of different types may arrive out of order if they 465 are prioritized as recommended in [RFC4222]. 467 OSPFv3 routers implementing this specification MUST use available 468 mechanisms to preserve the sequence number's strictly increasing 469 property for the deployed life of the OSPFv3 router (including 470 cold restarts). One mechanism for accomplishing this would be to 471 use the high-order 32 bits of the sequence number as a wrap/boot 472 count that is incremented anytime the OSPFv3 router loses its 473 sequence number state. Sequence number wrap is described in 474 Section 4.1.1. 476 o Authentication Data 478 Variable data that is carrying the digest for the protocol packet 479 and optional LLS data block. 481 4.1.1. Sequence Number Wrap 483 When incrementing the sequence number for each transmitted OSPFv3 484 packet, the sequence number should be treated as an unsigned 64-bit 485 value. If the lower-order 32-bit value wraps, the higher-order 486 32-bit value should be incremented and saved in non-volatile storage. 487 If by some chance the OSPFv3 router is deployed long enough that 488 there is a possibility that the 64-bit sequence number may wrap, all 489 keys, independent of their key distribution mechanism, MUST be reset 490 to avoid the possibility of replay attacks. Once the keys have been 491 changed, the higher-order sequence number can be reset to 0 and saved 492 to non-volatile storage. 494 4.2. OSPFv3 Header Checksum and LLS Data Block Checksum 496 Both the checksum calculation and verification are omitted for the 497 OSPFv3 header checksum and the LLS Data Block checksum [RFC5613] when 498 the OSPFv3 authentication mechanism described in this specification 499 is used. This implies: 501 o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum 502 computation is omitted, and the OSPFv3 header checksum SHOULD be 503 set to 0 prior to computation of the OSPFv3 Authentication Trailer 504 message digest. 506 o For OSPFv3 packets including an LLS Data Block to be transmitted, 507 the OSPFv3 LLS Data Block checksum computation is omitted, and the 508 OSPFv3 LLS Data Block checksum SHOULD be set to 0 prior to 509 computation of the OSPFv3 Authentication Trailer message digest. 511 o For received OSPFv3 packets including an OSPFv3 Authentication 512 Trailer, OSPFv3 header checksum verification MUST be omitted. 513 However, if the OSPFv3 packet does include a non-zero OSPFv3 514 header checksum, it will not be modified by the receiver and will 515 simply be included in the OSPFv3 Authentication Trailer message 516 digest verification. 518 o For received OSPFv3 packets including an LLS Data Block and OSPFv3 519 Authentication Trailer, LLS Data Block checksum verification MUST 520 be omitted. However, if the OSPFv3 packet does include an LLS 521 Block with a non-zero checksum, it will not be modified by the 522 receiver and will simply be included in the OSPFv3 Authentication 523 Trailer message digest verification. 525 4.3. Cryptographic Authentication Procedure 527 As noted earlier, the SA ID maps to the authentication algorithm and 528 the secret key used to generate and verify the message digest. This 529 specification discusses the computation of OSPFv3 Cryptographic 530 Authentication data when any of the NIST SHS family of algorithms is 531 used in the Hashed Message Authentication Code (HMAC) mode. 533 The currently valid algorithms (including mode) for OSPFv3 534 Cryptographic Authentication include: 536 o HMAC-SHA-1, 538 o HMAC-SHA-256, 539 o HMAC-SHA-384, and 541 o HMAC-SHA-512. 543 Of the above, implementations of this specification MUST include 544 support for at least HMAC-SHA-256 and SHOULD include support for 545 HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and 546 HMAC-SHA-512. 548 Implementations of this specification MUST use HMAC-SHA-256 as the 549 default authentication algorithm. 551 4.4. Cross-Protocol Attack Mitigation 553 In order to prevent cross-protocol replay attacks for protocols 554 sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID 555 is appended to the Authentication Key prior to use. Other protocols 556 using Cryptographic Authentication as specified herein MUST similarly 557 append their respective Cryptographic Protocol IDs to their keys in 558 this step. Refer to the IANA Considerations (Section 7). 560 4.5. Cryptographic Aspects 562 In the algorithm description below, the following nomenclature, which 563 is consistent with [FIPS-198-1], is used: 565 H is the specific hashing algorithm (e.g., SHA-256). 567 K is the Authentication Key from the OSPFv3 Security Association. 569 Ks is a Protocol-Specific Authentication Key obtained by appending 570 Authentication Key (K) with the two-octet OSPFv3 Cryptographic 571 Protocol ID. 573 Ko is the cryptographic key used with the hash algorithm. 575 B is the block size of H, measured in octets rather than bits. Note 576 that B is the internal block size, not the hash size. 578 For SHA-1 and SHA-256: B == 64 580 For SHA-384 and SHA-512: B == 128 582 L is the length of the hash, measured in octets rather than bits. 584 XOR is the exclusive-or operation. 586 Opad is the hexadecimal value 0x5c repeated B times. 588 Ipad is the hexadecimal value 0x36 repeated B times. 590 Apad is a value that is the same length as the hash output or message 591 digest. The first 16 octets contain the IPv6 source address followed 592 by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This 593 implies that hash output is always a length of at least 16 octets. 595 1. Preparation of the Key 597 The OSPFv3 Cryptographic Protocol ID is appended to the 598 Authentication Key (K) yielding a Protocol-Specific 599 Authentication Key (Ks). In this application, Ko is always L 600 octets long. While [RFC2104] supports a key that is up to B 601 octets long, this application uses L as the Ks length consistent 602 with [RFC4822], [RFC5310], and [RFC5709]. According to 603 [FIPS-198-1], Section 3, keys greater than L octets do not 604 significantly increase the function strength. Ks is computed as 605 follows: 607 If the Protocol-Specific Authentication Key (Ks) is L octets 608 long, then Ko is equal to Ks. If the Protocol-Specific 609 Authentication Key (Ks) is more than L octets long, then Ko is 610 set to H(Ks). If the Protocol-Specific Authentication Key 611 (Ks) is less than L octets long, then Ko is set to the 612 Protocol-Specific Authentication Key (Ks) with zeros appended 613 to the end of the Protocol-Specific Authentication Key (Ks) 614 such that Ko is L octets long. 616 2. First-Hash 618 First, the OSPFv3 packet's Authentication Data field in the 619 Authentication Trailer is filled with the value Apad. This is 620 very similar to the appendage described in [RFC2328], Section 621 D.4.3, Items (6)(a) and (6)(d)). 623 Then, a First-Hash, also known as the inner hash, is computed as 624 follows: 626 First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet)) 628 When XORing Ko and Ipad, Ko will be padded with zeros to the 629 length of Ipad. 631 Implementation Note: The First-Hash above includes the 632 Authentication Trailer, as well as the OSPFv3 packet, as per 633 [RFC2328], Section D.4.3, and, if present, the LLS data block 634 [RFC5613]. 636 The definition of Apad (above) ensures it is always the same 637 length as the hash output. This is consistent with RFC 2328. 638 Note that the "(OSPFv3 Packet)" referenced in the First-Hash 639 function above includes both the optional LLS data block and the 640 OSPFv3 Authentication Trailer. 642 The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; 643 for SHA-384, 48 octets; and for SHA-512, 64 octets. 645 3. Second-Hash 647 Then a Second-Hash, also known as the outer hash, is computed as 648 follows: 650 Second-Hash = H(Ko XOR Opad || First-Hash) 652 When XORing Ko and Opad, Ko will be padded with zeros to the 653 length of Ipad. 655 4. Result 657 The resulting Second-Hash becomes the authentication data that is 658 sent in the Authentication Trailer of the OSPFv3 packet. The 659 length of the authentication data is always identical to the 660 message digest size of the specific hash function H that is being 661 used. 663 This also means that the use of hash functions with larger output 664 sizes will also increase the size of the OSPFv3 packet as 665 transmitted on the wire. 667 Implementation Note: [RFC2328], Appendix D specifies that the 668 Authentication Trailer is not counted in the OSPF packet's own 669 Length field but is included in the packet's IP Length field. 670 Similar to this, the Authentication Trailer is not included in 671 the OSPFv3 header length but is included in the IPv6 header 672 payload length. 674 4.6. Message Verification 676 A router would determine that OSPFv3 is using an Authentication 677 trailer by examining the AT-bit in the Options field in the OSPFv3 678 header for Hello and Database Description packets. The specification 679 in the Hello and Database Description options indicates that other 680 OSPFv3 packets will include the Authentication Trailer. 682 The Authentication Trailer (AT) is accessed using the OSPFv3 packet 683 header length to access the data after the OSPFv3 packet and, if an 684 LLS data block [RFC5613] is present, using the LLS data block length 685 to access the data after the LLS data block. The L-bit in the OSPFv3 686 options in Hello and Database Description packets is examined to 687 determine if an LLS data block is present. If an LLS data block is 688 present (as specified by the L-bit), it is included along with the 689 OSPFv3 Hello or Database Description packet in the cryptographic 690 authentication computation. 692 Due to the placement of the AT following the LLS data block and the 693 fact that the LLS data block is included in the Cryptographic 694 Authentication computation, OSPFv3 routers supporting this 695 specification MUST minimally support examining the L-bit in the 696 OSPFv3 options and using the length in the LLS data block to access 697 the AT. It is RECOMMENDED that OSPFv3 routers supporting this 698 specification fully support OSPFv3 Link-Local Signaling [RFC5613]. 700 If usage of the Authentication Trailer (AT), as specified herein, is 701 configured for an OSPFv3 link, OSPFv3 Hello and Database Description 702 packets with the AT-bit clear in the options will be dropped. All 703 OSPFv3 packet types will be dropped if AT is configured for the link 704 and the IPv6 header length is less than the amount necessary to 705 include an Authentication Trailer. 707 Locate the receiving interface's OSPFv3 SA using the SA ID in the 708 received AT. If the SA is not found, or if the SA is not valid for 709 reception (i.e., current time < KeyStartAccept or current time >= 710 KeyStopAccept), the OSPFv3 packet is dropped. 712 If the cryptographic sequence number in the AT is less than or equal 713 to the last sequence number in the last OSPFv3 packet of the same 714 OSPFv3 type successfully received from the neighbor, the OSPFv3 715 packet MUST be dropped, and an error event SHOULD be logged. OSPFv3 716 packets of different types may arrive out of order if they are 717 prioritized as recommended in [RFC4222]. 719 Authentication-algorithm-dependent processing needs to be performed, 720 using the algorithm specified by the appropriate OSPFv3 SA for the 721 received packet. 723 Before an implementation performs any processing, it needs to save 724 the values of the Authentication Data field from the Authentication 725 Trailer appended to the OSPFv3 packet. 727 It should then set the Authentication Data field with Apad before the 728 authentication data is computed (as described in Section 4.5). The 729 calculated data is compared with the received authentication data in 730 the Authentication Trailer. If the two do not match, the packet MUST 731 be discarded and an error event SHOULD be logged. 733 After the OSPFv3 packet has been successfully authenticated, 734 implementations MUST store the 64-bit cryptographic sequence number 735 for each OSPFv3 packet type received from the neighbor. The saved 736 cryptographic sequence numbers will be used for replay checking for 737 subsequent packets received from the neighbor. 739 5. Migration and Backward Compatibility 741 All OSPFv3 routers participating on a link SHOULD be migrated to 742 OSPFv3 Authentication at the same time. As with OSPFv2 743 authentication, a mismatch in the SA ID, Authentication Type, or 744 message digest will result in failure to form an adjacency. For 745 multi-access links, communities of OSPFv3 routers could be migrated 746 using different Interface Instance IDs. However, at least one router 747 would need to form adjacencies between both the OSPFv3 routers 748 including and not including the Authentication Trailer. This would 749 result in sub-optimal routing as well as added complexity and is only 750 recommended in cases where authentication is desired on the link and 751 migrating all the routers on the link at the same time isn't 752 feasible. 754 In support of uninterrupted deployment, an OSPFv3 router implementing 755 this specification MAY implement a transition mode where it includes 756 the Authentication Trailer in transmitted packets but does not verify 757 this information in received packets. This is provided as a 758 transition aid for networks in the process of migrating to the 759 authentication mechanism described in this specification. More 760 specifically: 762 1. OSPFv3 routers in transition mode will include the OSPFv3 763 authentication trailer in transmitted packets and set the AT-Bit 764 in the options field of transmitted Hello and Database 765 Description packets. OSPFv3 routers receiving these packets and 766 not having authentication configured will ignore the 767 authentication trailer and AT-bit. 769 2. OSPFv3 routers in transition mode will also calculate and set the 770 OSPFv3 header checksum and the LLS block checksum in transmitted 771 packets so that they will not be dropped by OSPFv3 routers 772 without authentication configured. 774 3. OSPFv3 routers in transition mode will authenticate received 775 packets that either have the AT-Bit set in the options field for 776 Hello or Database Description packets or are from a neighbor that 777 previously set the AT-Bit in the options field of successfully 778 authenticated Hello and Database Description packets. 780 4. OSPFv3 routers in transition mode will also accept packets 781 without the options field AT-Bit set in Hello and Database 782 Description packets. These packets will be assumed to be from 783 OSPFv3 routers without authentication configured and they will 784 not be authenticated. Additionally, the OSPFv3 header checksum 785 and LLS block checksum will be validated. 787 6. Security Considerations 789 The document proposes extensions to OSPFv3 that would make it more 790 secure than [RFC5340]. It does not provide confidentiality as a 791 routing protocol contains information that does not need to be kept 792 secret. It does, however, provide means to authenticate the sender 793 of the packets that are of interest. It addresses all the security 794 issues that have been identified in [RFC6039]. 796 It should be noted that the authentication method described in this 797 document is not being used to authenticate the specific originator of 798 a packet but is rather being used to confirm that the packet has 799 indeed been issued by a router that has access to the Authentication 800 Key. 802 Deployments SHOULD use sufficiently long and random values for the 803 Authentication Key so that guessing and other cryptographic attacks 804 on the key are not feasible in their environments. Furthermore, it 805 is RECOMMENDED that Authentication Keys incorporate at least 128 806 pseudo-random bits to minimize the risk of such attacks. In support 807 of these recommendations, management systems SHOULD support 808 hexadecimal input of Authentication Keys. 810 The mechanism described herein is not perfect and does not need to be 811 perfect. Instead, this mechanism represents a significant increase 812 in the effort required for an adversary to successfully attack the 813 OSPFv3 protocol while not causing undue implementation, deployment, 814 or operational complexity. 816 Refer to [RFC4552] for additional considerations on manual keying. 818 7. IANA Considerations 820 IANA has allocated the AT-bit (0x000400) in the "OSPFv3 Options (24 821 bits)" registry as described in Section 2.1. 823 IANA has created the "OSPFv3 Authentication Trailer Options" 824 registry. This new registry initially includes the "OSPFv3 825 Authentication Types" registry, which defines valid values for the 826 Authentication Type field in the OSPFv3 Authentication Trailer. The 827 registration procedure is Standards Action. 829 +-------------+-----------------------------------+ 830 | Value/Range | Designation | 831 +-------------+-----------------------------------+ 832 | 0 | Reserved | 833 | | | 834 | 1 | HMAC Cryptographic Authentication | 835 | | | 836 | 2-65535 | Unassigned | 837 +-------------+-----------------------------------+ 839 OSPFv3 Authentication Types 841 Finally, IANA has created the "Keying and Authentication for Routing 842 Protocols (KARP) Parameters" category. This new category initially 843 includes the "Authentication Cryptographic Protocol ID" registry, 844 which provides unique protocol-specific values for cryptographic 845 applications, such as but not limited to, prevention of cross- 846 protocol replay attacks. Values can be assigned for both native 847 IPv4/IPv6 protocols and UDP/TCP protocols. The registration 848 procedure is Standards Action. 850 +-------------+----------------------+ 851 | Value/Range | Designation | 852 +-------------+----------------------+ 853 | 0 | Reserved | 854 | | | 855 | 1 | OSPFv3 | 856 | | | 857 | 2-65535 | Unassigned | 858 +-------------+----------------------+ 860 Cryptographic Protocol ID 862 8. References 864 8.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 871 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 872 for IPv6", RFC 5340, July 2008. 874 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 875 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 876 Authentication", RFC 5709, October 2009. 878 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 879 Authentication Trailer for OSPFv3", RFC 6506, 880 February 2012. 882 8.2. Informative References 884 [FIPS-180-3] 885 US National Institute of Standards and Technology, "Secure 886 Hash Standard (SHS)", FIPS PUB 180-3, October 2008. 888 [FIPS-198-1] 889 US National Institute of Standards and Technology, "The 890 Keyed-Hash Message Authentication Code (HMAC)", FIPS 891 PUB 198, July 2008. 893 [MANUAL-KEY] 894 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 895 "Security Extension for OSPFv2 when using Manual Key 896 Management", Work in Progress, October 2011. 898 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 899 Hashing for Message Authentication", RFC 2104, 900 February 1997. 902 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 903 Version 2 Packets and Congestion Avoidance", BCP 112, 904 RFC 4222, October 2005. 906 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 907 December 2005. 909 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 910 RFC 4303, December 2005. 912 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 913 for OSPFv3", RFC 4552, June 2006. 915 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 916 Authentication", RFC 4822, February 2007. 918 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 919 and M. Fanto, "IS-IS Generic Cryptographic 920 Authentication", RFC 5310, February 2009. 922 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 923 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 925 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 926 "Internet Key Exchange Protocol Version 2 (IKEv2)", 927 RFC 5996, September 2010. 929 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 930 with Existing Cryptographic Protection Methods for Routing 931 Protocols", RFC 6039, October 2010. 933 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 934 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 936 Appendix A. Acknowledgments 938 First and foremost, thanks to the US National Institute of Standards 939 and Technology for their work on the SHA [FIPS-180-3] and HMAC 940 [FIPS-198-1]. 942 Thanks also need to go to the authors of the HMAC-SHA authentication 943 RFCs including [RFC4822], [RFC5310], and [RFC5709]. The basic HMAC- 944 SHA procedures were originally described by Ran Atkinson and Tony Li 945 in [RFC4822]. 947 Also, thanks to Ran Atkinson for help in the analysis of RFC 6506 948 errata. 950 Thanks to Srinivasan K L and Marek Karasek for their identification 951 and submission of RFC 6506 errata. 953 Thanks to Sam Hartman for discussions on replay mitigation and the 954 use of a 64-bit strictly increasing sequence number. Also, thanks to 955 Sam for comments during IETF last call with respect to the OSPFv3 SA 956 and sharing of key between protocols. 958 Thanks to Michael Barnes for numerous comments and strong input on 959 the coverage of LLS by the Authentication Trailer (AT). 961 Thanks to Marek Karasek for providing the specifics with respect to 962 backward compatible transition mode. 964 Thanks to Michael Dubrovskiy and Anton Smirnov for comments on draft 965 revisions. 967 Thanks to Rajesh Shetty for numerous comments, including the 968 suggestion to include an Authentication Type field in the 969 Authentication Trailer for extendibility. 971 Thanks to Uma Chunduri for suggesting that we may want to protect the 972 IPv6 source address even though OSPFv3 uses the Router ID for 973 neighbor identification. 975 Thanks to Srinivasan KL, Shraddha H, Alan Davey, Russ White, Stan 976 Ratliff, and Glen Kent for their support and review comments. 978 Thanks to Alia Atlas for comments made under the purview of the 979 Routing Directorate review. 981 Thanks to Stephen Farrell for comments during the IESG review. 982 Stephen was also involved in the discussion of cross-protocol 983 attacks. 985 Authors' Addresses 987 Manav Bhatia 988 Alcatel-Lucent 989 Bangalore 990 India 992 Email: manav.bhatia@alcatel-lucent.com 994 Vishwas Manral 995 Hewlett Packard 996 USA 998 Email: vishwas.manral@hp.com 1000 Acee Lindem 1001 Ericsson 1002 102 Carric Bend Court 1003 Cary, NC 27519 1004 USA 1006 Email: acee.lindem@ericsson.com