Dear Ray, Thanks a lot for your careful review. My responses to your concerns follow:
>The claim in Section 3.1 that replay attacks are avoided by having a timestamp window of 10 minutes seems rather exaggerated. >10 minutes is an eternity in some computer networks. If I was an attacker, I would be happy to wait and detect the 10 minute window when I could cause disruption. That may be enough time to do >serious damage in some systems. I considered the worst case scenario where a network might have a very high delay rate. I will investigate further to determinate an appropriate time to use. >The claim in section 3.2 that DoS attacks are avoided by rate limiting NDP messages also seems rather exaggerated. >How would a rate filter know in advance which messages to discard without processing all of the SSAS signatures? Only the source IP address needs to be checked. If the receiver receives several NA messages in a short period of time (seconds) with this IP address, then the future messages would be discarded. An additional option would be to specify the number of messages a node can receive per minute. This number would be dependent on the CPU power (how many messages this node can handle per minute so that the other operation of this node are not affected, because the verification time is usually fixed.) >The claim in the Security Considerations of /the probability of an attacker finding the same value is 0.00016, a very small value./ would seem to be a bit exaggerated. This seems to ignore birthday >attacks. And especially since it appears from the text that the consequence of making this match is that the information leaked to the attacker directly relates to 32 bits of the private key. Is that a >correct reading? Actually the attacker would need to generate a public key that has 4 sequential bytes (starting from a specific part of the public key (specific index)) matching those in IP address. It is not feasible or very likely that an attacker would try to find the private key for this node because, in this case, he would need to do a brute force attack against the 1024-bit key in order to find the matching number to that private key. This option is not really viable because this public key is just valid for a certain period of time and will then change. The birthday attack would also be difficult because, again, the attacker would need to generate a public key and not just 32 sequential bits. What he generated would have to match the bits starting from its specific index in order to match the 32 bits of the IP address. To summarize, the attacker would need to generate a 1024 bit public key where the 32 sequential bits start at a specific point in order to match the IP address. The mathematical proof that I used depicts the very worst case scenario where we are just matching 32 against 32. What also needs to be considered is what the probability is of a public key matching a private key while at the same time matching the specific sequential 32 bits of this public key while also matching the 32 last most bits of IP address. > There are many LANs containing many thousands of nodes, and as an attacker I'd be happy to passively monitor long term if it meant I could glean (significant portions of) one public key (that did >not rotate very often and once discovered would potentially be extremely useful). In order to avoid the use of an index of 1 (not rotate often issue) as the starting index of public key, I will change that section to this: If the second byte of a partial ID is greater than the size of the public key array in bytes, minus 4, then choose that byte and shift its contents 2 bits to the right (the first two bits will be zero) and consider this number the starting index of the public key array of bytes. This ensures that the value of that byte will be less than 124. >The recommendation of a /maximum of 2 days/ for public key times ignores the practical need in many systems for very long lived sessions, and the difficulty of securely rotating public keys on >distributed systems. If we choose 20 days, the probability would be 0.001609325408935546875 and that is still a small value. The value of two was chosen as an average life time. I also explained in the draft that it is recommended to generate public/private keys on the fly. This means that the implementation of the SSAS algorithm will do a better job of supporting automatic key generation without increasing administration tasks. As stated in other RFCs, the old IP address will still be valid for the current session, but will not be valid for the start of new sessions. The status of this old IP address should be changed to deprecated. I will add this to the draft to clarify the lifetime of the IP address. If there is any further questions or concerns, I will be happy to answer them. Thank you, Hosnieh -----Original Message----- From: Ray Hunter [mailto:v6...@globis.net] Sent: Saturday, January 05, 2013 5:42 PM To: Hosnieh Rafiee Cc: ipv6@ietf.org Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt I have read this draft. Following all IMVHO. The claim in Section 3.1 that replay attacks are avoided by having a timestamp window of 10 minutes seems rather exaggerated. 10 minutes is an eternity in some computer networks. If I was an attacker, I would be happy to wait and detect the 10 minute window when I could cause disruption. That may be enough time to do serious damage in some systems. The claim in section 3.2 that DoS attacks are avoided by rate limiting NDP messages also seems rather exaggerated. How would a rate filter know in advance which messages to discard without processing all of the SSAS signatures? Overloading of the NDP mechanism could still potentially cause nodes to time out their caches, and/or prevent new peerings from forming. And including encryption in NDP may actually make it easier to overload the NDP process rather than harder (because the defender has to do relatively more work than the attacker in the situation where encryption is employed compared to if there was no encryption). The claim in the Security Considerations of /the probability of an attacker finding the same value is 0.00016, a very small value./ would seem to be a bit exaggerated. This seems to ignore birthday attacks. And especially since it appears from the text that the consequence of making this match is that the information leaked to the attacker directly relates to 32 bits of the private key. Is that a correct reading? There are many LANs containing many thousands of nodes, and as an attacker I'd be happy to passively monitor long term if it meant I could glean (significant portions of) one public key (that did not rotate very often and once discovered would potentially be extremely useful). The recommendation of a /maximum of 2 days/ for public key times ignores the practical need in many systems for very long lived sessions, and the difficulty of securely rotating public keys on distributed systems. In summary, I am currently unconvinced whether this ID as it stands significantly moves the state of the art forward compared to existing mechanisms. regards, RayH Hosnieh Rafiee wrote: > Dear All, > > This draft addresses the following problem: > Unfortunately the existing drafts do not consider the integration of security and privacy for the generation of the Interface ID (IID). This draft tries to offer a solution to this problem while at the same time considering the generation and verification times and complexity of the existing algorithms. Please take a look. Comments are greatly appreciated. > Thank you, > Hosnieh > > > > Filename: draft-rafiee-6man-ssas > Revision: 00 > Title: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS) > Creation date: 2013-01-02 > WG ID: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt > Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas > Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-00 > > > Abstract: > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. The problem with the former approach is the > computational cost involved for the IID generation. The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
