idnits 2.17.1 draft-ietf-ospf-auth-trailer-ospfv3-11.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 (Nov 21, 2011) is 4533 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) == Outdated reference: A later version (-11) exists of draft-ietf-ospf-security-extension-manual-keying-01 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 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 Intended status: Standards Track V. Manral 5 Expires: May 24, 2012 Hewlett Packard 6 A. Lindem 7 Ericsson 8 Nov 21, 2011 10 Supporting Authentication Trailer for OSPFv3 11 draft-ietf-ospf-auth-trailer-ospfv3-11 13 Abstract 15 Currently OSPFv3 uses IPsec as the only mechanism for authenticating 16 protocol packets. This behavior is different from authentication 17 mechanisms present in other routing protocols (OSPFv2, IS-IS, RIPng). 18 In some environments, it has been found that IPsec is difficult to 19 configure and maintain, and cannot be used. This document proposes 20 an alternative mechanism to authenticate OSPFv3 protocol packets so 21 that OSPFv3 does not depend upon only IPsec for authentication. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 24, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 4 59 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 5 61 2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. IPv6 Source Address Protection . . . . . . . . . . . . . . 6 63 3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 8 64 4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 10 65 4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 10 66 4.1.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . 11 67 4.2. OSPFv3 Header Checksum . . . . . . . . . . . . . . . . . . 12 68 4.3. Cryptographic Authentication Procedure . . . . . . . . . . 12 69 4.4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . 12 70 4.5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 13 71 4.6. Message Verification . . . . . . . . . . . . . . . . . . . 15 72 5. Migration and Backward Compatibility . . . . . . . . . . . . . 17 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 81 1. Introduction 83 Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF 84 for IPv6 (OSPFv3) [RFC5340], does not include the AuType and 85 Authentication fields in its headers for authenticating protocol 86 packets. Instead, OSPFv3 relies on the IPsec protocols 87 Authentication Header (AH)[RFC4302] and Encapsulating Security 88 Payload (ESP) [RFC4303] to provide integrity, authentication, and/or 89 confidentiality. 91 [RFC4552] describes how IPv6 AH and ESP extension headers can be used 92 to provide authentication and/or confidentiality to OSPFv3. 94 However, there are some environments, e.g., Mobile Ad-hoc Networks 95 (MANETs), where IPsec is difficult to configure and maintain, and 96 this mechanism cannot be used. 98 [RFC4552] discusses, at length, the reasoning behind using manually 99 configured keys, rather than some automated key management protocol 100 such as IKEv2 [RFC5996]. The primary problem is the lack of suitable 101 key management mechanism, as OSPFv3 adjacencies are formed on a one- 102 to-many basis and most key management mechanisms are designed for a 103 one-to-one communication model. This forces the system administrator 104 to use manually configured security associations (SAs) and 105 cryptographic keys to provide the authentication and, if desired, 106 confidentiality services. 108 Regarding replay protection [RFC4552] states that: 110 "As it is not possible as per the current standards to provide 111 complete replay protection while using manual keying, the proposed 112 solution will not provide protection against replay attacks." 114 Since there is no replay protection provided there are a number of 115 vulnerabilities in OSPFv3 that have been discussed in [RFC6039]. 117 Since there is no deterministic way to differentiate between 118 encrypted and unencrypted ESP packets by simply examining the packet, 119 it could become tricky for some implementations to prioritize certain 120 OSPFv3 packets (Hellos for example) over the others. 122 This document proposes a new mechanism that works similar to OSPFv2 123 [RFC5709]for providing authentication to the OSPFv3 packets and 124 attempts to solve the problems related to replay protection and 125 deterministically disambiguating different OSPFv3 packets as 126 described above. 128 This document adds support for Secure Hash Algorithms (SHA) defined 129 in the US NIST Secure Hash Standard (SHS), which is defined by NIST 130 FIPS 180-3. [FIPS-180-3] includes SHA-1, SHA-224, SHA-256, SHA-384, 131 and SHA-512. The Hashed Message Authentication Code (HMAC) 132 authentication mode defined in NIST FIPS 198 is used [FIPS-198]. 134 It is believed that HMAC defined in [RFC2104] is mathematically 135 identical to [FIPS-198] and it is also believed that algorithms in 136 [RFC6234] are mathematically identical to [FIPS-198]. 138 1.1. Requirements Section 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC2119 [RFC2119]. 144 2. Proposed Solution 146 To perform non-IPsec cryptographic authentication, OSPFv3 routers 147 append a special data block, henceforth referred to as the 148 authentication trailer, to the end of the OSPFv3 packets. The length 149 of the authentication trailer is not included into the length of the 150 OSPFv3 packet, but is included in the IPv6 payload length, as shown 151 in the figure below . 153 +---------------------+ -- -- +----------------------+ 154 | IPv6 Header Length | ^ ^ | IPv6 Header Length | 155 | HL = PL + LL | | | | HL = PL + LL + AL | 156 | | v v | | 157 +---------------------+ -- -- +----------------------+ 158 | OSPFv3 Header | ^ ^ | OSPFv3 Header | 159 | Length = PL | | | | Length = PL | 160 | | | | | | 161 |.....................| | Packet | |......................| 162 | | | Length | | | 163 | OSPFv3 Packet | | | | OSPFv3 Packet | 164 | | v v | | 165 +---------------------+ -- -- +----------------------+ 166 | | ^ ^ | | 167 | Optional LLS | | LLS Data | | Optional LLS | 168 | LLS Block Len = LL | | Block | | LLS Block Len = LL | 169 | | v Length v | | 170 +---------------------+ -- -- +----------------------+ 171 ^ | | 172 AL = HL - (PL + LL) | | Authentication | 173 | | AL = Fixed Trailer + | 174 v | Digest Length | 175 -- +----------------------+ 177 Figure 1: Authentication Trailer in OSPFv3 179 The presence of the Link Local Signaling (LLS) [RFC5613] block, is 180 determined by the L-bit setting in OSPFv3 options field in OSPFv3 181 Hello and Database Description packets. If present, the LLS block is 182 included along with the OSPFv3 packet in the cryptographic 183 authentication computation. 185 2.1. AT-Bit in Options Field 187 A new AT-bit (AT stands for Authentication Trailer) is introduced 188 into the OSPFv3 Options field. OSPFv3 routers MUST set the AT-bit in 189 OSPFv3 Hello and Database Description packets to indicate that all 190 the packets on this link will include an authentication trailer. For 191 OSPFv3 Hello and Database Description packets, the AT-bit indicates 192 the AT is present. For other OSPFv3 packet types, the OSPFv3 AT bit 193 setting from the OSPFv3 Hello/Database Description setting is 194 preserved in the OSPFv3 neighbor data structure. OSPFv3 packet types 195 that don't include an OSPFv3 options field will use the setting from 196 the neighbor data structure to determine whether or not the AT is 197 expected. 199 0 1 2 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ 202 | | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6| 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ 205 Figure 2: OSPFv3 Options Field 207 The AT-bit MUST be set in all OSPFv3 Hello and Database Description 208 packets that contain an authentication trailer as shown in the figure 209 above. 211 2.2. Basic Operation 213 The procedure followed for computing the Authentication Trailer is 214 much the same as described in [RFC5709] and [RFC2328]. One 215 difference is that the LLS block, if present, is included in the 216 cryptographic authentication computation. 218 The way the authentication data is carried in the Authentication 219 Trailer is very similar to how it is done in case of [RFC2328]. The 220 only difference between the OSPFv2 authentication trailer and the 221 OSPFv3 authentication trailer is that information in addition to the 222 message digest is included. The additional information in the OSPFv3 223 Authentication Trailer is included in the message digest computation 224 and, therefore, protected by OSPFv3 cryptographic authentication as 225 described herein. 227 Consistent with OSPFv2 cryptographic authentication [RFC2328], both 228 OSPFv3 header checksum calculation and verification are omitted when 229 the OSPFv3 authentication mechanisms described in this specification 230 are used. 232 2.3. IPv6 Source Address Protection 234 While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, 235 the IPv6 source address is learned from OSPFv3 hello packets and 236 copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is 237 susceptible to Man-in-the-Middle attacks where the IPv6 source 238 address has been modified. To thwart such attacks, the IPv6 source 239 address will be included in the message digest calculation and 240 protected by OSPFv3 authentication. Refer to Section 4.5 for 241 details. This is different than the procedure specified in [RFC5709] 242 but consistent with [I-D.ietf-ospf-security-extension-manual-keying]. 244 3. OSPFv3 Security Association 246 An OSPFv3 Security Association (SA) contains a set of parameters 247 shared between any two legitimate OSPFv3 speakers. 249 Parameters associated with an OSPFv3 SA: 251 o Security Association Identifier (SA ID) 253 This is a 32-bit unsigned integer used to uniquely identify an 254 OSPFv3 SA, as manually configured by the network operator. 256 The receiver determines the active SA by looking at the SA ID 257 field in the incoming protocol packet. 259 The sender, based on the active configuration, selects an SA to 260 use and puts the correct Key ID value associated with the SA in 261 the OSPFv3 protocol packet. If multiple valid and active OSPFv3 262 SAs exist for a given interface, the sender may use any of those 263 SAs to protect the packet. 265 Using SA IDs makes changing keys while maintaining protocol 266 operation convenient. Each SA ID specifies two independent parts, 267 the authentication algorithm and the authentication key, as 268 explained below. 270 Normally, an implementation would allow the network operator to 271 configure a set of keys in a key chain, with each key in the chain 272 having fixed lifetime. The actual operation of these mechanisms 273 is outside the scope of this document. 275 Note that each SA ID can indicate a key with a different 276 authentication algorithm. This allows the introduction of new 277 authentication mechanisms without disrupting existing OSPFv3 278 adjacencies. 280 o Authentication Algorithm 282 This signifies the authentication algorithm to be used with the 283 OSPFv3 SA. This information is never sent in clear text over the 284 wire. Because this information is not sent on the wire, the 285 implementer chooses an implementation specific representation for 286 this information. 288 Currently, the following algorithms are supported: 290 HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. 292 o Authentication Key 294 This value denotes the cryptographic authentication key associated 295 with the OSPFv3 SA. The length of this key is variable and 296 depends upon the authentication algorithm specified by the OSPFv3 297 SA. 299 o KeyStartAccept 301 The time that this OSPFv3 router will accept packets that have 302 been created with this OSPFv3 Security Association. 304 o KeyStartGenerate 306 The time that this OSPFv3 router will begin using this OSPFv3 307 Security Association for OSPFv3 packet generation. 309 o KeyStopGenerate 311 The time that this OSPFv3 router will stop using this OSPFv3 312 Security Association for OSPFv3 packet generation. 314 o KeyStopAccept 316 The time that this OSPFv3 router will stop accepting packets 317 generated with this OSPFv3 Security Association. 319 In order to achieve smooth key transition, KeyStartAccept SHOULD be 320 less than KeyStartGenerate and KeyStopGenerate SHOULD be less than 321 KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left 322 unspecified, the time will default to 0 and the key will be used 323 immediately. If KeyStopGenerate or KeyStopAccept are left 324 unspecified, the time will default to infinity and the key's lifetime 325 will be infinite. When a new key replaces an old, the 326 KeyStartGenerate time for the new key MUST be less than or equal to 327 the KeyStopGenerate time of the old key. 329 Key storage SHOULD persist across a system restart, warm or cold, to 330 avoid operational issues. In the event that the last key associated 331 with an interface expires, it is unacceptable to revert to an 332 unauthenticated condition, and not advisable to disrupt routing. 333 Therefore, the router SHOULD send a "last Authentication Key 334 expiration" notification to the network manager and treat the key as 335 having an infinite lifetime until the lifetime is extended, the key 336 is deleted by network management, or a new key is configured 338 4. Authentication Procedure 340 4.1. Authentication Trailer 342 The authentication trailer that is appended to the OSPFv3 protocol 343 packet is described below: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Auth Type | Auth Data Len | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Security Association ID (SA ID) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Cryptographic Sequence Number (High Order 32 Bits) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Cryptographic Sequence Number (Low Order 32 Bits) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 | Authentication Data (Variable) | 358 ~ ~ 359 | | 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 3: Authentication Trailer Format 365 The various fields in the Authentication trailer are: 367 o Auth Type 369 16-bit field identifying the type of authentication. The 370 following values are defined in this specification: 372 0 - Reserved. 373 1 - HMAC Cryptographic Authentication as described herein. 375 o Auth Data Len 377 The length in octets of the Authentication Trailer (AT) including 378 both the 16 octet fixed header and the variable length message 379 digest. 381 o Security Association Identifier (SA ID) 383 32-bit field that maps to the authentication algorithm and the 384 secret key used to create the message digest appended to the 385 OSPFv3 protocol packet. 387 Though the SA ID implicitly implies the algorithm, the HMAC output 388 size should not be used by implementers as an implicit hint 389 because additional algorithms may be defined in the future that 390 have the same output size. 392 o Cryptographic Sequence Number 394 64-bit strictly increasing sequence number that is used to guard 395 against replay attacks. The 64-bit sequence number MUST be 396 incremented for every OSPFv3 packet sent by the OSPFv3 router. 397 Upon reception, the sequence number MUST be greater than the 398 sequence number in the last OSPFv3 packet accepted from the 399 sending OSPFv3 neighbor. Otherwise, the OSPFv3 packet is 400 considered a replayed packet and dropped. 402 OSPFv3 routers implementing this specification MUST use available 403 mechanisms to preserve the sequence number's strictly increasing 404 property for the deployed life of the OSPFv3 router (including 405 cold restarts). One mechanism for accomplishing this would be to 406 use the high order 32 bits of the sequence number as a wrap/boot 407 count that is incremented anytime the OSPFv3 router loses its 408 sequence number state. Sequence number wrap is described in 409 Section 4.1.1. 411 o Authentication Data 413 Variable data that is carrying the digest for the protocol packet 414 and optional LLS block. 416 4.1.1. Sequence Number Wrap 418 When incrementing the sequence number for each transmitted OSPFv3 419 packet, the sequence number should be treated as an unsigned 64-bit 420 value. If the lower order 32-bit value wraps, the higher order 32- 421 bit value should be incremented and saved in non-volatile storage. 422 If by some chance the OSPFv3 router is deployed long enough that 423 there is a possibility that the 64-bit sequence number may wrap, all 424 keys, independent of key distribution mechanism, MUST be reset to 425 avoid the possibility of replay attacks. Once the keys have been 426 changed, the higher order sequence number can be reset to 0 and saved 427 to non-volatile storage. 429 4.2. OSPFv3 Header Checksum 431 Both OSPFv3 header checksum calculation and verification are omitted 432 when the OSPFv3 authentication mechanisms described in this 433 specification are used. This implies: 435 o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum 436 computation is omitted and the OSPFv3 header checksum SHOULD be 437 set to 0 prior to computation of the OSPFv3 Authentication Trailer 438 message digest. 440 o For received OSPFv3 packets including an OSPFv3 Authentication 441 Trailer, OSPFv3 header checksum verification MUST be omitted. 442 However, if the OSPFv3 packet does include a non-zero OSPFv3 443 header checksum, it will not be modified by the receiver and will 444 simply be included in the OSPFv3 Authentication Trailer message 445 digest verification. 447 4.3. Cryptographic Authentication Procedure 449 As noted earlier, the SA ID maps to the authentication algorithm and 450 > the secret key used to generate and verify the message digest. 451 This specification discusses the computation of OSPFv3 Cryptographic 452 Authentication data when any of the NIST SHS family of algorithms is 453 used in the Hashed Message Authentication Code (HMAC) mode. 455 The currently valid algorithms (including mode) for OSPFv3 456 Cryptographic Authentication include: 458 HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 460 Of the above, implementations of this specification MUST include 461 support for at least HMAC-SHA-256 and SHOULD include support for 462 HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC- 463 SHA-512. 465 Implementations of this standard MUST use HMAC-SHA-256 as the default 466 authentication algorithm. 468 4.4. Cross Protocol Attack Mitigation 470 In order to prevent cross protocol replay attacks for protocols 471 sharing common keys, the two octet OSPFv3 Cryptographic Protocol ID 472 is appended to the authentication key prior to use. Other protocols 473 using cryptographic authentication as specified herein MUST similarly 474 append their respective Cryptographic Protocol IDs to their keys in 475 this step. Refer to IANA Considerations (Section 7). 477 4.5. Cryptographic Aspects 479 In the algorithm description below, the following nomenclature, which 480 is consistent with [FIPS-198], is used: 482 H is the specific hashing algorithm (e.g. SHA-256). 484 K is the Authentication Key from the OSPFv3 security association. 486 Ks is a Protocol Specific Authentication Key obtained by appending 487 Authentication Key (K) with the two-octet OSPFv3 Cryptographic 488 Protocol ID appended. 490 Ko is the cryptographic key used with the hash algorithm. 492 B is the block size of H, measured in octets rather than bits. 494 Note that B is the internal block size, not the hash size. 496 For SHA-1 and SHA-256: B == 64 498 For SHA-384 and SHA-512: B == 128 500 L is the length of the hash, measured in octets rather than bits. 502 XOR is the exclusive-or operation. 504 Opad is the hexadecimal value 0x5c repeated B times. 506 Ipad is the hexadecimal value 0x36 repeated B times. 508 Apad is a value which is the same length as the hash output or 509 message digest. The first 16 octets contain the IPv6 source address 510 followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. 511 This implies that hash output is always a length of at least 16 512 octets. 514 1. Preparation of the Key 516 The OSPFv3 Cryptographic Protocol ID is appended to the 517 Authentication Key (K) yielding a Protocol Specific 518 Authentication Key (Ks). In this application, Ko is always L 519 octets long, and is computed as follows: 521 If the Protocol Specific Authentication Key (Ks) is L octets 522 long, then Ko is equal to K. If the Protocol Specific 523 Authentication Key (Ks) is more than L octets long, then Ko is 524 set to H(Ks). If the Protocol Specific Authentication Key (Ks) 525 is less than L octets long, then Ko is set to the Protocol 526 Specific Authentication Key (Ks) with zeros appended to the end 527 of the Protocol Specific Authentication Key (Ks) such that Ko is 528 L octets long. 530 2. First Hash 532 First, the OSPFv3 packet's Authentication Data field in the 533 Authentication Trailer (which is very similar to the appendage 534 described in RFC 2328, Section D.4.3, Page 233, items(6)(a) and 535 (6)(d)) is filled with the value Apad. 537 Then, a First-Hash, also known as the inner hash, is computed as 538 follows: 540 First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet)) 542 Implementation Notes: 544 Note that the First-Hash above includes the Authentication 545 Trailer, as well as the OSPFv3 packet, as per RFC 2328, 546 Section D.4.3 and, if present, the LLS block[RFC5613]. 548 The definition of Apad (above) ensures it is always the same 549 length as the hash output. This is consistent with RFC 2328. 550 The "(OSPFv3 Packet)" mentioned in the First-Hash (above) does 551 include both the optional LLS block and the OSPFv3 Authentication 552 Trailer. 554 The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; 555 for SHA-384, 48 octets; and for SHA-512, 64 octets. 557 3. Second Hash 559 Then a second hash, also known as the outer hash, is computed as 560 follows: 562 Second-Hash = H(Ko XOR Opad || First-Hash) 564 4. Result 566 The resulting Second-Hash becomes the authentication data that is 567 sent in the Authentication Trailer of the OSPFv3 packet. The 568 length of the authentication data is always identical to the 569 message digest size of the specific hash function H that is being 570 used. 572 This also means that the use of hash functions with larger output 573 sizes will also increase the size of the OSPFv3 packet as 574 transmitted on the wire. 576 Implementation Note: 578 RFC 2328, Appendix D specifies that the Authentication Trailer 579 is not counted in the OSPF packet's own Length field, but is 580 included in the packet's IP Length field. Similar to this, 581 the Authentication Trailer is not included in OSPFv3's own 582 Length field, but is included in IPv6's payload length. 584 4.6. Message Verification 586 A router would determine that OSPFv3 is using an Authentication 587 trailer by examining the AT-bit in the Options field in the OSPFv3 588 header for Hello and Database Description packets. The specification 589 in the Hello and Database description options indicates that other 590 OSPFv3 packets will include the authentication trailer. 592 The Authentication Trailer (AT) is accessed using the OSPFv3 packet 593 header length to access the data after the OSPFv3 packet and, if an 594 LLS Data Block [RFC5613] is present, using the LLS Data Block Length 595 to access the data after the LLS Data Block. The L-bit in the OSPFv3 596 options in Hello and Database Description packets is examined to 597 determine if an LLS Data Block is present. If an LLS block is 598 present (as specified by the L-bit), it is included along with the 599 OSPFv3 Hello or Database Description packet in the cryptographic 600 authentication computation. 602 Due to the placement of the AT following the LLS block and the fact 603 that the LLS block is included in the cryptographic authentication 604 computation, OSPFv3 routers supporting this specification MUST 605 minimally support examining the L-bit in the OSPFv3 options and using 606 the length in the LLS block to access the AT. It is RECOMMENDED that 607 OSPFv3 routers supporting this specification fully support OSPFv3 608 Link Local Signaling, [RFC5613]. 610 If usage of the Authentication Trailer (AT), as specified herein, is 611 configured for an OSPFv3 link, OSPFv3 Hello and Database Description 612 packets with the AT-bit clear in the options will be dropped. All 613 OSPFv3 packet types will be dropped if AT is configured for the link 614 and the IPv6 header length is less than the amount necessary to 615 include an authentication trailer. 617 If the cryptographic sequence number in the AT is less than or equal 618 to the last sequence number successfully received from the neighbor, 619 the OSPFv3 packet MUST be dropped and an error event SHOULD be 620 logged. 622 Authentication algorithm dependent processing needs to be performed, 623 using the algorithm specified by the appropriate OSPFv3 SA for the 624 received packet. 626 Before an implementation performs any processing it needs to save the 627 values of the Authentication data field from the Authentication 628 Trailer appended to the OSPFv3 packet. 630 It should then set the Authentication Data field with Apad before the 631 authentication data is computed (as described in Section 4.5). The 632 calculated data is compared with the received authentication data in 633 the Authentication trailer and the packet MUST be discarded if the 634 two do not match. In such a case, an error event SHOULD be logged. 636 After the OSPFv3 packet has been successfully authenticated, 637 implementations MUST store the 64-bit cryptographic sequence number 638 for future replay checks. 640 5. Migration and Backward Compatibility 642 All OSPFv3 routers participating on a link SHOULD be migrated to 643 OSPFv3 Authentication at the same time. As with OSPFv2 644 authentication, a mismatch in the SA ID, Authentication Type, or 645 message digest will result in failure to form an adjacency. For 646 multi-access links, communities of OSPFv3 routers could be migrated 647 using different interface instance IDs. However, at least one router 648 would need to form adjacencies between both the OSPFv3 routers 649 including and not including the authentication trailer. This would 650 result in sub-optimal routing, as well as, added complexity and is 651 only recommended in cases where authentication is desired on the link 652 and it isn't feasible to migrate all the routers on the link at the 653 same time. 655 In support of uninterrupted deployment, an OSPFv3 router implementing 656 this standard MAY implement a transition mode where it includes the 657 Authentication Trailer in the packets but does not verify this 658 information. This is provided as a transition aid for networks in 659 the process of migrating to the mechanism described in this document. 661 6. Security Considerations 663 The document proposes extensions to OSPFv3 that would make it more 664 secure than [RFC5340]. It does not provide confidentiality as a 665 routing protocol contains information that does not need to be kept 666 secret. It does, however, provide means to authenticate the sender 667 of the packets which is of interest to us. It addresses all the 668 security issues that have been identified in [RFC6039]. 670 It should be noted that authentication method described in this 671 document is not being used to authenticate the specific originator of 672 a packet, but is rather being used to confirm that the packet has 673 indeed been issued by a router that had access to the authentication 674 key. 676 Deployments SHOULD use sufficiently long and random values for the 677 authentication key so that guessing and other cryptographic attacks 678 on the key are not feasible in their environments. Furthermore, it 679 is RECOMMENDED that authentication keys incorporate at least 128 680 pseudo-random bits to minimize the risk of such attacks. In support 681 of these recommendations, management systems SHOULD support 682 hexadecimal input of authentication keys. 684 The mechanism described here is not perfect and does not need to be 685 perfect. Instead, this mechanism represents a significant increase 686 in the work function of an adversary attacking the OSPFv3 protocol, 687 while not causing undue implementation, deployment, or operational 688 complexity. 690 Refer to [RFC4552] for additional considerations on manual keying. 692 7. IANA Considerations 694 IANA is requested to allocate an AT-bit in the "OSPFv3 Options 695 Registry" as described in Section 2.1. 697 IANA is also requested to create new OSPFv3 "Authentication Trailer 698 Types Registry" 700 +-------------+----------------------+--------------------+ 701 | Value/Range | Designation | Assignment Policy | 702 +-------------+----------------------+--------------------+ 703 | 0 | Reserved | Reserved | 704 | | | | 705 | 1 | HMAC Cryptographic | Already assigned | 706 | | Authentication | | 707 | | | | 708 | 2-65535 | Unassigned | Standards Action | 709 +-------------+----------------------+--------------------+ 711 OSPFv3 Authentication Types 713 Finally, IANA is requested to create new general registry 714 "Cryptographic Protocol ID". This new registry will provide unique 715 protocol specific values for cryptographic applications, such as but 716 not limited to, prevention of cross protocol replay attacks. Values 717 can be assigned for both native IPv4/IPv6 protocols and UDP/TCP 718 protocols. 720 +-------------+----------------------+--------------------+ 721 | Value/Range | Designation | Assignment Policy | 722 +-------------+----------------------+--------------------+ 723 | 0 | Reserved | Reserved | 724 | | | | 725 | 1 | OSPFv3 | Already assigned | 726 | | | | 727 | 2-65535 | Unassigned | Standards Action | 728 +-------------+----------------------+--------------------+ 730 Cryptographic Protocol ID 732 8. References 734 8.1. Normative References 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, March 1997. 739 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 741 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 742 for IPv6", RFC 5340, July 2008. 744 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 745 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 746 Authentication", RFC 5709, October 2009. 748 8.2. Informative References 750 [FIPS-180-3] 751 US National Institute of Standards & Technology, "Secure 752 Hash Standard (SHS)", FIPS PUB 180-3 , October 2008. 754 [FIPS-198] 755 US National Institute of Standards & Technology, "The 756 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 757 198 , March 2002. 759 [I-D.ietf-ospf-security-extension-manual-keying] 760 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 761 "Security Extension for OSPFv2 when using Manual Key 762 Management", 763 draft-ietf-ospf-security-extension-manual-keying-01 (work 764 in progress), October 2011. 766 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 767 Hashing for Message Authentication", RFC 2104, 768 February 1997. 770 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 771 December 2005. 773 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 774 RFC 4303, December 2005. 776 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 777 for OSPFv3", RFC 4552, June 2006. 779 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 781 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 783 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 784 "Internet Key Exchange Protocol Version 2 (IKEv2)", 785 RFC 5996, September 2010. 787 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 788 with Existing Cryptographic Protection Methods for Routing 789 Protocols", RFC 6039, October 2010. 791 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 792 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 794 Appendix A. Acknowledgments 796 First and foremost, thanks to the authors of RFC5709[RFC5709] from 797 which this work was derived. 799 Thanks to Sam Hartman for discussions on replay mitigation and the 800 use of a 64-bit strictly increasing sequence number. Also, thanks to 801 Sam for comments during IETF last call with respect to the OSPFv3 SA 802 and sharing of key between protocols. 804 Thanks to Michael Barnes for numerous comments and strong input on 805 the coverage of LLS by the Authentication Trailer (AT). 807 Thanks to Rajesh Shetty for numerous comments including the 808 suggestion to include an Authentication Type field in the 809 Authentication Trailer for extendibility. 811 Thanks to Uma Chunduri for suggesting that we may want to protect the 812 IPv6 source address even though OSPFv3 uses the Router ID for 813 neighbor identification. 815 Thanks to Srinivasan K L, Shraddha H, Alan Davey, and Glen Kent for 816 their review comments. 818 Thanks to Alan Davey, Russ White, Stan Ratliff, and others for their 819 support of the draft. Also, thanks to Alan for WG last call 820 comments. 822 Thanks to Alia Atlas for comments made under the purview of the 823 Routing Directorate review. 825 Thanks to Stephen Farrell for comments during the IESG review. 826 Stephen was also involved in the discussion of cross protocol 827 attacks. 829 The RFC text was produced using Marshall Rose's xml2rfc tool. 831 Authors' Addresses 833 Manav Bhatia 834 Alcatel-Lucent 835 Bangalore, 836 India 838 Phone: 839 Email: manav.bhatia@alcatel-lucent.com 841 Vishwas Manral 842 Hewlett Packard 843 USA 845 Phone: 846 Email: vishwas.manral@hp.com 848 Acee Lindem 849 Ericsson 850 102 Carric Bend Court 851 Cary, NC 27519 852 USA 854 Phone: 855 Email: acee.lindem@ericsson.com