idnits 2.17.1 draft-rafiee-6man-cga-attack-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Intended Status: Informational Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (May 8, 2015) is 3276 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '3' is mentioned on line 74, but not defined == Missing Reference: '11' is mentioned on line 170, but not defined == Missing Reference: 'ADDRCONF' is mentioned on line 192, but not defined == Unused Reference: 'RFC2119' is defined on line 301, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 318, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Rafiee 3 INTERNET-DRAFT 4 Intended Status: Informational Track C. Meinel 5 Hasso Plattner Institute 6 Expires: November 8, 2015 May 8, 2015 8 Possible Attack on Cryptographically Generated Addresses (CGA) 9 11 Abstract 13 This document describes the possible attacks with the use of 14 Cryptographically Generated Addresses. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute working 23 documents as Internet-Drafts. The list of current Internet-Drafts is 24 at http://datatracker.ietf.org/drafts/current. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 8, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. This document is subject to 37 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 38 Documents (http://trustee.ietf.org/license-info) in effect on the 39 date of publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Sec value vulnerability . . . . . . . . . . . . . . . . . . . 3 50 3. Key size Vulnerability . . . . . . . . . . . . . . . . . . . 6 51 4. Modifier can be zero . . . . . . . . . . . . . . . . . . . . 6 52 5. Variable length Prefixes . . . . . . . . . . . . . . . . . . 6 53 6. Use case Scenario for CGA attack . . . . . . . . . . . . . . 6 54 6.1. Duplicate Address Detection Process . . . . . . . . . . . 6 55 6.2. Nodes communications . . . . . . . . . . . . . . . . . . 6 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 60 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 Cryptographically Generated Addresses (CGA) [RFC3972] is one of the 67 important options of Secure Neighbor Discovery (SeND) [RFC3971] in 68 IPv6 networks. CGA provides the node with the proof of the IP address 69 ownership by finding a binding between the public key and the node's 70 IP address. Therefore, It can protect the nodes from network layer IP 71 spoofing attack and prevent forging the identity (if it is only based 72 on the IP address). However, CGA, itself is vulnerable to some types 73 of attacks such as DoS, replay attack (The use of timestamp would 74 mitigate this attack), etc. [3]. The goal of this document is not to 75 focus on the well-known attacks but the CGA vulnerabilities that is 76 the result of the text in CGA specification to warn implementers 77 about these possible attacks. 79 2. Sec value vulnerability 81 CGA values are the fingerprint of public key. They are generated by 82 executing a hash function on public key and some other parameters. 83 Since the default algorithm for generating this hash is SHA-1, the 84 attacker node only needs to do brute force attacks against 59 bits. 85 CGA algorithm uses sec value (a value between 0 to 7) to increase the 86 brute force search space from 59 bits to maximum 171 bits (59+sec*16) 87 and as a result complicates the brute force attacks to break CGA. 88 Nevertheless, in practice, only sec value 0 and 1 can be used because 89 it takes hours to years to generate CGA sec value higher than 1 [2]. 91 Unfortunately, in practice, it does not matter what sec value the 92 victim node chooses and the use of sec value only complicates the IP 93 address generation process for the victim node. This is because the 94 attacker will only use sec value 0 and SHA1 algorithm. 96 It is true that the attacker has a source IP address that only in 3 97 bits sec value differs from the victim node's source IP address 98 (because the attacker uses only sec value zero). But since the 99 verifier node only checks the target address (the source address can 100 be different from the target address). If sender's target address 101 matches the verifier node's address, it starts the verification 102 process on the sender's source address (but not on target address) 103 and ignores 3 bits sec value during verification process. This allow 104 an attacker to use different sec value than what the legitimate node 105 has and set the target address to the exact value as source address 106 of the legitimate node. There is no comparison of source and target 107 addresses. Therefore, the attack is successful. The attacker node can 108 persist on his own IP address after a successful verification by CGA 109 verifier node, forces CGA node to generate a new IP address and again 110 the attacker repeats this process. After 3 times repeating this 111 process, the legitimate node will give up and cannot set any IP 112 address. 114 This attack is not only possible during the first time a node joins 115 to a new network and wants to generate its IP address, but also 116 during the time other nodes check node's reachability in their 117 caches. Since all the nodes verify this attacker node the same way as 118 the legitimate CGA node processed the verification. From their 119 aspects, these two nodes are the same. Therefore, an attacker can 120 forge the identity of any legitimate CGA node in the network (by 121 doing offline bruteforce attack on their IP addresses and finding the 122 similar value). When any two nodes in the network wants to 123 communicate together and they sends any ICMPv6 message as a start of 124 this communication, an attacker can forge the identity of any of 125 these CGA node and start communicating with other node. 127 The mentioned flaw occurs during verification processes in all 128 verifier nodes. The node needs to verify other nodes in two different 129 conditions -- during DAD process and during checking the neighbors' 130 reachability in cache. This means that the CGA security is only the 131 security of CGA sec value 0 that is 2^59 bits. 133 The reason are as follow: 135 1- Section 5 RFC 3972 137 It uses the term ?the address?, The address refers to the source 138 address. (please refer to Number 4 to know the reason) 140 2- step 4, Section 5 RFC 3972 :The CGA verifier node ignores 3 bits 141 sec value in source address and 2 bits u and g 143 Based on NDP specification, the verifier node checks to see whether 144 or not the target address is the same as its own IP address. If it is 145 the same and the node supports CGA, then it starts CGA verification. 146 Based on step 4 section 5 RFC 3972, the CGA node compares the source 147 address (IID section) of the sender node to his own IID. The verifier 148 node ignores 3 bits sec value. So, the attacker can set the target 149 address to the real CGA address of the victim node disregard its sec 150 value and set the source address to his own CGA value that is only 151 different in the 3 leftmost bits. Since the verification is 152 successful, the attacker can spoof the IP address of CGA node. 154 3 - No comparison of source address and target address 156 Based on the Neighbor Discovery Protocol (NDP) specification on 157 section 7 RFC 4861 [RFC4861, RFC4862], there is nothing about to 158 compare the source IP address with the target address. In SeND 159 specification [RFC3971], there are rules for the sender node. 160 However, the verifier node never checks those rules. This is why the 161 attacker can ignore them. So, the attacker can create the SeND 162 message by using his own CGA address that differs only in sec value. 163 The attacker selects the victim node's source address as his own 164 target address and sends this message. 166 4- Section 5.1.2 RFC 3971 168 "If the interface has been configured to use CGA, the receiving node 169 MUST verify the source address of the packet by using the algorithm 170 described in Section 5 of [11]. The inputs to the algorithm are the 171 claimed address, as defined in the previous section, and the CGA 172 Parameters field.". 174 This is where I explained in Number 1 that "the address" refers to 175 the source IP address. 177 5- Section 7.2.3 RFC 4861 179 SeND only adds 4 options to NDP but does not change the initial way 180 to process the NDP messages. 182 "- The Target Address is a ?valid? unicast or anycast address 184 assigned to the receiving interface [ADDRCONF], 186 - The Target Address is a unicast or anycast address for which the 188 node is offering proxy service, or 190 - The Target Address is a ?tentative? address on which Duplicate 192 Address Detection is being performed [ADDRCONF]." 194 It is usually the new CGA victim node that needs to process Duplicate 195 Address Detection (DAD). In other words, the attacker has a valid 196 unicast target address that is similar to what is chosen by the 197 victim CGA node. There is no place in the standard NDP specifications 198 to explain that the target address should be compared to the source 199 address. The reason is because sometimes the target address is 200 temporary. Unfortunately in SeND specification, this check was not 201 done too because it only follows ND specification. 203 6- Section 7.2 RFC 3972: SeND cannot also protect the node against 204 this problem 206 The author of CGA specification was aware of this problem: 208 "For each valid CGA Parameters data structure, there are 4*(Sec+1) 209 different CGAs that match the value. This is because decrementing the 210 Sec value in the three leftmost bits of the interface identifier does 211 not invalidate the address, and the verifier ignores the values of 212 the ?u? and ?g? bits. In SEND, this does not have any security or 213 implementation implications." 215 But the assumption was that SeND can protect the nodes from this 216 attack by the use of a valid certification. But unfortunately, 217 certification is only to authorize routers and not for all nodes in 218 the network. The other solution is to use Microsoft Active Directory 219 (AD). But in practice not all places use or will use this approach. 221 3. Key size Vulnerability 223 The lower limit for key size is 384 bits. The attacker can choose the 224 lowest size public key so that he can better play with the public key 225 bits and easier and faster generates the similar hash of the CGA 226 node. 228 4. Modifier can be zero 230 The attacker does not need to generate a really good random value. 231 Since for him it is only important to match the hash value. This is 232 especially true for the scenario where the attacker needs to do brute 233 force attacks against all 64 bits and sec value is not ignored. 235 5. Variable length Prefixes 237 The assumption in CGA algorithm is that the subnet prefix is 64 bits. 238 This really makes the verification process easier and straight 239 forward. But if any networks wants to have a variable length prefix, 240 then CGA verifier node must know which part of this address is IID 241 and which part is prefix. If it can receive this information from an 242 authorized router, then there might be no risk for the verifier node. 243 But if this value supposed to receive from the sender node, then the 244 problem would be where to add such information. If it is as a new 245 option in CGA, then the attacker can spoof this value and sign it 246 with its own private key and claim different prefix. But if this 247 value is as a part of IID, then the problem would be the number of 248 bits required to carry the prefix length. This process will decrease 249 the number of bits to carry the CGA value and will lead to reducing 250 CGA security. (59- number of bits to carry the prefix length) 252 6. Use case Scenario for CGA attack 254 In the following subsections, some of these attacks are explained in 255 more detail. 257 6.1. Duplicate Address Detection Process 259 When a node generates his IP address, it process the DAD in order to 260 avoid collision on the network. The attacker might be able to 261 generate the CGA value the same of the legitimate CGA node and claim 262 the ownership of that IP address. The CGA nodes only tries 3 times 263 and then it gives up. 265 6.2. Nodes communications 266 When two nodes want to start communication, they try to find the IP 267 address of eachother by sending multicast NS/NA messages. The 268 attacker can offline generates the value of victim which differs only 269 in 3 bits sec value and then impersonate the victim node and try to 270 communicate with other node. This attack is likely possible 271 especially when the attacker can send this response faster than the 272 real node or the real node is offline at the time of this request by 273 other node. 275 7. Security Considerations 277 - 279 8. IANA Considerations 281 - 283 9. Appendix 285 - CGA multicore attack 287 This is where you can find CGA attacks (multicore). 289 http://www.hpi.uni-potsdam.de/meinel/security_tech/ipv6_security/ipv6ssl.html 291 10. Acknowledgements 293 The author would like to acknowledge Fabian Braeunlein, one of a 294 bachelor student at Hasso Plattner Institute who assists us, during 295 this busy moments, for writing the attacking codes. 297 11. References 299 11.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to 302 Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC3972] Aura, T., "Cryptographically Generated Addresses 305 (CGA)," RFC 3972, March 2005. 307 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, 308 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 310 [RFC4861] Narten, T., Nordmark, E., Simpson, W., Soliman, 311 H., "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 312 September 2007. 314 [RFC4862] Thomson, S., Narten, T., Jinmei, T., "IPv6 315 Stateless Address Autoconfiguration", RFC 4862, September 316 2007. 318 [1] AlSa'deh, A., Rafiee, H., Meinel, C., "Cryptographically 319 Generated Addresses (CGAs): Possible Attacks and Proposed 320 Mitigation Approaches," in proceedings of 12th IEEE International 321 Conference on Computer and Information Technology (IEEE CIT'12), 322 pp.332-339, 2012. 324 [2] Bos, J., Oezen, O., Hubaux, J., "Analysis and Optimization of 325 Cryptographically Generated Addresses", In Proceedings of the 326 12th International Conference on Information Security (2009), 327 ACM, pp. 17 ? 32. 329 [ugbits] Carpenter, B., Jiang, S., "Significance of IPv6 330 Interface Identifiers", RFC 7136, February 2014. 332 [variableprefix] Carpenter, B., Chown, T, Gont, F., 333 Jiang, S., Petrescu, A., Yourtchenko, A.," Analysis 334 of the 64-bit Boundary in IPv6 Addressing", 335 http://tools.ietf.org/html/draft-ietf-6man-why64 , 336 April 2014 338 Authors' Addresses 340 Hosnieh Rafiee 341 http://www.rozanak.com 342 Munich, Germany 343 Phone: +49 (0)162 204 74 58 344 Email: ietf@rozanak.com 346 Christoph Meinel 347 Hasso-Plattner-Institute 348 Prof.-Dr.-Helmert-Str. 2-3 349 Potsdam, Germany 350 Email: meinel@hpi.uni-potsdam.de