idnits 2.17.1 draft-ietf-ospf-security-extension-manual-keying-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 24, 2012) is 4384 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 (-10) exists of draft-ietf-karp-crypto-key-table-00 == Outdated reference: A later version (-06) exists of draft-ietf-karp-ospf-analysis-00 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 S. Hartman 5 Expires: October 26, 2012 Painless Security 6 D. Zhang 7 Huawei Technologies co., LTD. 8 A. Lindem 9 Ericsson 10 April 24, 2012 12 Security Extension for OSPFv2 when using Manual Key Management 13 draft-ietf-ospf-security-extension-manual-keying-02 15 Abstract 17 The current OSPFv2 cryptographic authentication mechanism as defined 18 in the OSPF standards is vulnerable to both inter-session and intra- 19 session replay attacks when its uses manual keying. Additionally, 20 the existing cryptographic authentication schemes do not cover the IP 21 header. This omission can be exploited to carry out various types of 22 attacks. 24 This draft proposes changes to the authentication sequence number 25 mechanism that will protect OSPFv2 from both inter-session and intra- 26 session replay attacks when its using manual keys for securing its 27 protocol packets. Additionally, we also describe some changes in the 28 cryptographic hash computation so that we eliminate most attacks that 29 result because OSPFv2 does not protect the IP header. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 26, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 4 66 2. Replay Protection using Extended Sequence Numbers . . . . . . 4 67 3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5 68 4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6 69 4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7 70 4.2. Key Selection for Multicast OSPF Packet Transmission . . . 7 71 4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8 72 5. Mechanism to secure the IP header . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 The OSPFv2 cryptographic authentication mechanism as described in 83 [[RFC2328]] uses per-packet sequence numbers to provide protection 84 against replay attacks. The sequence numbers increase monotonically 85 so that the attempts to replay the stale packets can be thwarted. 86 The sequence number values are maintained as a part of adjacency 87 states. Therefore, if an adjacency is broken down, the associated 88 sequence numbers get reinitialized and the neighbors start all over 89 again. Additionally, the cryptographic authentication mechanism does 90 not specify how to deal with the rollover of a sequence number when 91 its value would wrap. These omissions can be taken advantage of by 92 attackers to implement various replay attacks ([RFC6039]). In order 93 to address these issues, we propose extensions to the authentication 94 sequence number mechanism. Compared with the cryptographic 95 authentication mechanism proposed in [RFC5709], the solution proposed 96 does not impose any more security presumption. 98 The cryptographic authentication as described in [RFC2328] and later 99 updated in [RFC5709] does not include the IP header. This also can 100 be exploited to launch several attacks as the source address in the 101 IP header is no longer protected. The OSPF specification, for 102 broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires 103 the implementations to look at the source address in the IP header to 104 determine the neighbor from witch the packet was received. Changing 105 the IP source address of a packet which can confuse the receiver and 106 can be exploited to produce a number of denial of service attacks 107 [RFC6039]. If the packet is interpreted as coming from a different 108 neighbor, the sequence number received from the neighbor may be 109 updated. This may disrupt communication with the legitimate 110 neighbor. Hello packets may be reflected to cause a neighbor to 111 appear to have one-way communication. Old Database descriptions may 112 be reflected in cases where the per-packet sequence numbers are 113 sufficiently divergent in order to disrupt an adjacency 114 [I-D.ietf-karp-ospf-analysis]. This is referred to as the IP layer 115 issue in [I-D.ietf-karp-threats-reqs]. 117 [RFC2328] states that implementations MUST offer keyed MD5 118 authentication. It is likely that this will be deprecated in favor 119 of the stronger algorithms described in [RFC5709] in future 120 deployments [I-D.ietf-opsec-igp-crypto-requirements]. 122 This draft proposes a simple change in the cryptographic 123 authentication mechanism, as currently described in [RFC5709], to 124 prevent such IP layer attacks. 126 1.1. Requirements Section 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC2119 [RFC2119]. 132 When used in lowercase, these words convey their typical use in 133 common language, and are not to be interpreted as described in 134 RFC2119 [RFC2119]. 136 2. Replay Protection using Extended Sequence Numbers 138 In order to provide replay protection against both inter-session and 139 intra-session replay attacks, the OSPFv2 sequence number is expanded 140 to 64-bits with the least significant 32-bit value containing a 141 strictly increasing sequence number and the most significant 32-bit 142 value containing the boot count. OSPFv2 implementations are required 143 to retain the boot count in non-volatile storage for the deployment 144 life the OSPF router. The requirement to preserve the boot count is 145 also placed on SNMP agents by the SNMPv3 security architecture (refer 146 to snmpEngineBoots in [RFC4222]. 148 Since there is no room in the OSPFv2 packet for a 64-bit sequence 149 number, it will occupy the 8 octets following the OSPFv2 packet and 150 MUST be included when calculating the OSPFv2 packet digest. These 151 additional 8 bytes are not included in the OSPFv2 packet header 152 length but are included in the OSPFv2 header Authentication Data 153 length and the IPv4 packet header length. 155 The lower order 32-bit sequence number MUST be incremented for every 156 OSPF packet sent by the OSPF router. Upon reception, the sequence 157 number MUST be greater than the sequence number in the last OSPF 158 packet of that type accepted from the sending OSPF neighbor. 159 Otherwise, the OSPF packet is considered a replayed packet and 160 dropped. OSPF packets of different types may arrive out of order if 161 they are priorized as recommended in [RFC3414]. 163 OSPF routers implementing this specification MUST use available 164 mechanisms to preserve the sequence number's strictly increasing 165 property for the deployed life of the OSPFv3 router (including cold 166 restarts). This is achieved by maintaining a boot count in non- 167 volatile storage and incrementing it each time the OSPF router loses 168 its prior sequence number state. The SNMPv3 snmpEngineBoots variable 169 [RFC4222] MAY be used for this purpose. However, maintaining a 170 separate boot count solely for OSPF sequence numbers has the 171 advantage of decoupling SNMP reinitialization and OSPF 172 reinitialization. Also, in the rare event that the lower order 32- 173 bit sequence number wraps, the boot count can be incremented to 174 preserve the strictly increasing property of the aggregate sequence 175 number. Hence, a separate OSPF boot count is RECOMMENDED. 177 3. OSPF Packet Extensions 179 The OSPF packet header includes an authentication type field, and 64- 180 bits of data for use by the appropriate authentication scheme 181 (determined by the type field). Authentication types 0, 1 and 2 are 182 defined [RFC2328]. This section of this defines Authentication type 183 TBD (3 is recommended). 185 When using this authentication scheme, the 64-bit Authentication 186 field in the OSPF packet header as defined in section D.3 of 187 [RFC2328] is changed as shown below. The sequence number is removed 188 and the Key ID is extended to 32 bits and moved to the former 189 position of the sequence number. 191 Additionally, the 64-bit sequence number is moved to the first 64- 192 bits following the OSPFv2 packet and is protected by the 193 authentication digest. These additional 64 bits or 8 octets are 194 included in the IP header length but not the OSPF header packet 195 length. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Version # | Type | Packet length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Router ID | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Area ID | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Checksum | AuType | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | 0 | Auth Data Len | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Key ID | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 | OSPF Protocol Packet | 214 ~ ~ 215 | | 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Sequence Number (Boot Count) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Sequence Number (Strictly Increasing Packet Counter) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 ~ Authentication Data ~ 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 7 - Extended Sequence Number Packet Extensions 229 4. OSPF Packet Key Selection 231 This section describes how the proposed security solution selects 232 long-lived keys from key tables. [I-D.ietf-karp-crypto-key-table]. 233 Generally, a key used for OSPFv2 packet authentication should satisfy 234 the following requirements: 236 o The key time period as defined by NotBefore and NotAfter must 237 include the current time. 239 o The key can be used for the desired security algorithm. 241 In the remainder of this section, additional requirements for keys 242 are enumerated for different scenarios. 244 4.1. Key Selection for Unicast OSPF Packet Transmission 246 Assume that a router R1 tries to send a unicast OSPF packet from its 247 interface I1 to the interface R2 of a remote router R2 using security 248 protocol P via interface I at time T. Firstly consider the 249 circumstances where R1 and R2 are not connected with a virtual link. 250 R1 then needs to select a long long-lived symmetric key from its key 251 table. Because the key should be shared by the by both R1 and R2 to 252 protect the communication between I1 and I2, the key should satisfy 253 the following requirements: 255 o The Peer field includes the router ID of R2. 257 o the PeerKeyID field is not "unknown". 259 o The Interfaces field includes I1. 261 o the Direction field is either "out" or "both". 263 When R1 and R2 are connected to a virtual link, the third condition 264 is a little more complex. Because the virtual link can be regarded 265 as an unnumbered point-to-point network, the IP address of the 266 interface actually used to send the packet (i.e., I1) is discovered 267 during routing table calculation. Therefore, when the system 268 operator configures keys to protect the virtual link, I1 is unknown 269 and can be any OSPF interface in the OSPF virtual link's transit 270 area. Therefore, the key should be identified solely by the local 271 and remote router IDs rather than by the interface on which the 272 packet is sent. The third requirement list above should be changed 273 to "the Interface field includes the router ID". 275 4.2. Key Selection for Multicast OSPF Packet Transmission 277 If a router R1 sends an OSPF packet from its interface I1 to a 278 multicast address (e.g., AllSPFRouters, AllDRouters), it needs to 279 select a key according to the following requirements: 281 o The Peer field includes the multicast address. 283 o The PeerKeyID field is "group". 285 o The Interfaces field includes I1. 287 o The Direction field is either "out" or "both". 289 4.3. Key Selection for OSPF Packet Reception 291 When Cryptographic Authentication is employed, the ID of the 292 authentication key is included in the authentication field of the 293 OSPF packet header. Using this key ID, it is relatively easy for a 294 receiver to locate the key. The simple requirements are: 296 o The Peer field includes the router ID of the sender. 298 o The PeerKeyID field includes the key ID obtained from the 299 authentication field. 301 o The Direction field is either "in" or "both". 303 5. Mechanism to secure the IP header 305 This document updates the definition of Apad which is currently a 306 constant defined in [RFC5709] to the source address from the IP 307 header of the OSPFv2 protocol packet. The overall cryptographic 308 authentication process defined in [RFC5709] remains unchanged. To 309 reduce the potential for confusion, this section minimizes the 310 repetition of text from RFC 5709 and is incorporated here by 311 reference [RFC5709]. 313 RFC 5709, Section 3.3, describes how the cryptographic authentication 314 must be computed. It requires OSPFv2 packet's Authentication Trailer 315 (which is the appendage described in RFC 2328, Section D.4.3, Page 316 233, items (6)(a) and (6)(d)) to be filled with the value Apad where 317 Apad is a hexadecimal constant value 0x878FE1F3 repeated (L/4) times, 318 where L is the length of the hash being used and is measured in 319 octets rather than bits. 321 Routers at the sending side must initialize Apad to a value of the 322 source address that would be used when sending out the OSPFv2 packet, 323 repeated L/4 times, where L is the length of the hash, measured in 324 octets. The basic idea is to incorporate the source address from the 325 IP header in the cryptographic authentication computation so that any 326 change of IP source address in a replayed packet can be detected. 328 At the receiving end, implementations MUST initialize Apad as the 329 source address from IP Header of the incoming OSPFv2 packet, repeated 330 L/4 times, instead of the constant that's currently defined in 331 [RFC5709]. Besides changing the value of Apad, this document does 332 not introduce any other changes to the authentication mechanism 333 described in [RFC5709]. This would prevent all attacks where a rogue 334 OSPF router changes the IP source address of an OSPFv2 packet and 335 replays it on the same multi-access interface or another interface 336 since the IP source address is now protected and such changes would 337 cause the authentication check to fail and the replayed packet to be 338 rejected. 340 6. Security Considerations 342 This document attempts to fix the manual key management procedure 343 that currently exists within OSPFv2, as part of the Phase 1 of the 344 KARP Working Group. Therefore, only the OSPFv2 manual key management 345 mechanism is considered. Any solution that takes advantage of the 346 automatic key management mechanism is beyond the scope of this 347 document. 349 The proposed sequence number extension offers most of the benefits of 350 of more complicated mechanisms involving challenges. There are, 351 however, a couple drawbacks to this approach. First, it requires the 352 OSPF implementation to be able to save its boot count in non-volatile 353 storage. If the non-volatile storage is ever repaired or upgraded 354 such that the contents are lost or the OSPFv2 router is replaced with 355 a model, the keys MUST be changed to prevent replay attacks. 357 Second, if a router is taken out of service completely (either 358 intentionally or due to a persistent failure), the potential exists 359 for reestablishment of an OSPFv2 adjacency by replaying the entire 360 OSPFv2 session establishment. This scenario is however, extremely 361 unlikely, since it would imply an identical OSPFv2 adjacency 362 formation packet exchange. The replay of OSPFv2 hello packets alone 363 for an OSPFv2 router that has been taken out of service should not 364 result in any serious attack as the only consequence is superfluous 365 processing. Of course, this attack could also be thwarted by 366 changing the relevant manual keys. 368 This document also provides a solution to prevent certain denial of 369 service attacks that can be launched by changing the source address 370 in the IP header of the OSPFv2 protocol packet. 372 7. IANA Considerations 374 This document requests a new code point from the "OSPF Shortest Path 375 First (OSPF) Authentication Codes" registry: 377 o TBD - Cryptographic Authentication with Extended Sequence Numbers. 378 The value 3 is recommended. 380 8. References 381 8.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 388 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 389 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 390 Authentication", RFC 5709, October 2009. 392 8.2. Informative References 394 [I-D.ietf-karp-crypto-key-table] 395 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 396 Cryptographic Keys", draft-ietf-karp-crypto-key-table-00 397 (work in progress), November 2010. 399 [I-D.ietf-karp-ospf-analysis] 400 Hartman, S. and D. Zhang, "Analysis of OSPF Security 401 According to KARP Design Guide", 402 draft-ietf-karp-ospf-analysis-00 (work in progress), 403 March 2011. 405 [I-D.ietf-karp-threats-reqs] 406 Lebovitz, G., Bhatia, M., and R. White, "The Threat 407 Analysis and Requirements for Cryptographic Authentication 408 of Routing Protocols' Transports", 409 draft-ietf-karp-threats-reqs-02 (work in progress), 410 April 2011. 412 [I-D.ietf-opsec-igp-crypto-requirements] 413 Bhatia, M. and V. Manral, "Summary of Cryptographic 414 Authentication Algorithm Implementation Requirements for 415 Routing Protocols", 416 draft-ietf-opsec-igp-crypto-requirements-04 (work in 417 progress), October 2010. 419 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 420 (USM) for version 3 of the Simple Network Management 421 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 423 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 424 Version 2 Packets and Congestion Avoidance", BCP 112, 425 RFC 4222, October 2005. 427 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 428 with Existing Cryptographic Protection Methods for Routing 429 Protocols", RFC 6039, October 2010. 431 Authors' Addresses 433 Manav Bhatia 434 Alcatel-Lucent 435 Bangalore, 436 India 438 Phone: 439 Email: manav.bhatia@alcatel-lucent.com 441 Sam Hartman 442 Painless Security 444 Email: hartmans@painless-security.com 446 Dacheng Zhang 447 Huawei Technologies co., LTD. 448 Beijing, 449 China 451 Phone: 452 Fax: 453 Email: zhangdacheng@huawei.com 454 URI: 456 Acee Lindem 457 Ericsson 458 102 Carric Bend Court 459 Cary, NC 27519 460 USA 462 Phone: 463 Email: acee.lindem@ericsson.com