DNS Extensions H. Rafiee INTERNET-DRAFT Hasso Plattner Institute Updates RFC 2845 (if approved) M. v. Loewis Intended Status: Standards Track Hasso Plattner Institute C. Meinel Hasso Plattner Institute Expires: May 22, 2013 November 22, 2012 Transaction SIGnature (TSIG) using CGA Algorithm in IPv6 Abstract The first step in the Transaction SIGnature (TSIG) (RFC 2845) process is the generation of a shared secret to be used between a DNS server and a host. The second step is the manual exchange of the shared secret between the DNS server and the host. This document, CGA-TSIG, proposes a possible way to automate the now manual process used for the authentication of a node with a DNS server during the DNS Update process by using the same parameters as are used in generating a secure address in IPv6 networks, i.e., Cryptographically Generated Addresses (CGA) (RFC 3972). CGA-TSIG facilitates this authentication process and reduces the time needed for DNS Updates. The current signature generation process and verification mechanism in TSIG are thus replaced with CGA. This algorithm is added, as an extension, to TSIG to eliminate the human intervention needed for generation and exchange of keys between a DNS server and a host when SEcure Neighbor Discovery (SEND) (RFC 3971) is used. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 20, 2013. Rafiee, et al. Expires May 22, 2013 [Page 1] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3.1. IP Spoofing and Reflector Attacks . . . . . . . . . . . . 4 3.2. DNS Dynamic Update Spoofing . . . . . . . . . . . . . . . 4 3.3. Resolver Configuration Attack . . . . . . . . . . . . . . 4 3.4. Shared Secret (key pairs) Exposing . . . . . . . . . . . 5 3.5. Replay attack . . . . . . . . . . . . . . . . . . . . . . 5 4. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 5 4.1. CGA Generation Algorithm . . . . . . . . . . . . . . . . 5 4.2. Modification to TSIG protocol . . . . . . . . . . . . . . 7 4.2.1. Modified TSIG Record format . . . . . . . . . . . . . 7 4.2.1.1. Generation of the DNS Update request/response . 10 4.2.1.2. Verification of the DNS Update Request/Response 12 4.2.1.3. Generation of DNS Query Response . . . . . . . . 13 4.2.1.4. Verification of DNS Query Response . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Rafiee, et al. Expires May 22, 2013 [Page 2] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 1. Introduction Transaction SIGnature (TSIG) [RFC2845] is a protocol that provides endpoint authentication and data integrity by using one-way hashing and shared secret keys to establish a trust relationship between two hosts which, can be, either a client and a server, or two servers. The TSIG keys are manually exchanged between these two hosts and they must be maintained in a secure manner. This protocol is used to secure a Dynamic Update or to give assurance to the slave name server that the zone transfer is from the original master name server and that it has not been spoofed by hackers. It does this by verifying the signature using a cryptographic key that is shared with the receiver. The TSIG protocol can be extended using newly defined algorithms. This document defines an algorithm based on Cryptographically Generated Addresses (CGA) [RFC3972]. CGA is one of the important options available in SEcure Neighbor Discovery (SEND) [RFC3971] that can easily provide nodes with the necessary proof of address ownership by providing a cryptographic binding between a host and its IP address without the introduction of new infrastructure. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 3. Problem Statement The DNS Update process is vulnerable to several types of spoofing attacks, such as man in the middle, reflector , source IP spoofing, etc. TSIG secures this process by providing the transaction level authentication necessary by using a shared secret. The problem is that this protocol is not widely used. The current problem with the use of TSIG is the manual process that is required for the generation and exchange of the shared secrets. For each paired host there needs to be one shared secret and the administrator needs to add it manually to the DNS configuration file for each of these hosts. So, whenever these two hosts change their IP addresses, because of Rafiee, et al. Expires May 22, 2013 [Page 3] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 privacy issues as explained in RFC-4941 [RFC4941] or when moving to another subnet within the same network, this manual process will need to be invoked. The purpose of CGA-TSIG is to minimize the amount of human intervention required to accomplish this exchange and, as a byproduct, to reduce the processes vulnerability to attacks introduced by human errors when SEcure Neighbor Discovery (SEND) is used for addressing purposes. The same problem exists between a client and a DNS resolver. When a client sends a DNS query to a resolver, an attacker can send a response to this client with the spoofed source IP address of this resolver. The client checks the resolver's source IP address. If the attacker sends its response faster than the legitimate resolver, then the client's cache will be updated by the attacker's response. The client does not have any way of authenticating the resolver. In this scenario, CGA-TSIG offers a solution. It assures the client that the query response comes from the real originator of that and not from the attacker. There are several attacks that CGA-TSIG can prevent. Here we will evaluate some of them. 3.1. IP Spoofing and Reflector Attacks During the DNS Update process it is important for both communicating parties to know that the one they are communicating with is the owner of that IP address and that the messages have not been sent from a spoofed IP address. This can be fulfilled by using the CGA algorithm that utilizes the node to verify the address ownership of the other node. The reflector attack is a kind of distributed Denial of Service attack. It uses the IP address of the victim as a source of the DNS message and sends several queries to the DNS server which then redirects this traffic to the victim thus keeping the victim busy processing these packets. Using the CGA signature and authentication approach will prevent this type of attack. 3.2. DNS Dynamic Update Spoofing Because the signature contains both CGA parameters and the DNS update message, proof is offered of the sender's address ownership (CGA parameters) and the validity of the update message. 3.3. Resolver Configuration Attack In CGA-TSIG, the DNS server or the client might not need further configuration. This may reduce the possibility of human errors being inserted into the DNS configuration file. Since this type of attack Rafiee, et al. Expires May 22, 2013 [Page 4] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 is predicated on human error, the chances of it occurring when our proposed extension is used are minimized. 3.4. Shared Secret (key pairs) Exposing On-the-fly key pair generation is recommended to decrease the chances of giving attackers unauthorized access to private keys on a node. 3.5. Replay attack Using Time Signed in the signature modifies the content of the signature each time the node generates it and sends it to the DNS server. This value is the node's current time in UTC. If the attacker tries to spoof this value with another timestamp, to show that the update message is current, the DNS server checks this message by verifying and regenerating the signature (when the private key of the other DNS server is manually set in this DNS server). In this case steps 2 and 8 of verification process fail. Therefore the replay attack is also prevented. 4. Algorithm Overview CGA is a one-way hashing algorithm used to generate Interface IDs for IPv6 addresses in a secure manner. An interface ID consists of the rightmost 64 bits of the 128 bit IPv6 address. CGA verifies the address ownership of the sender by finding a relationship between the sender's IP address and his public key [1,2]. +------------------------------------------------+ | Subnet Prefix | Interface ID | | (8 octets) | (8 octets) | +------------------------------------------------+ Figure 1 IPv6 addresses 4.1. CGA Generation Algorithm A node proceeds with the following steps in order to generate the CGA (When a node wants to generate new address, this process must be repeated and the CGA parameters should be cached in the server for further usage by CGA-TSIG): 1. Key pairs, called public/private keys, and a new random number, called a modifier, are generated [key pair format: Section 3. Rafiee, et al. Expires May 22, 2013 [Page 5] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 RFC3972] - It is recommended that key pairs be generated on the fly the first time a node wants to generate its IP address. This eliminates the need for having the keys manually generated and saved, in a particular path, in the node, before the start of IP address generation. - It is recommended that the node change its IP address frequently for privacy and security issues[3] . When the node's IP address is temporary, the attacker has less time to process brute force attacks against CGA or to track this node. 2. The modifier is concatenated with other parameters such as a zero value prefix (64 bits), a zero value collision count (8 bits) and the RSA public key +-----------------------------------------------------------+ | Modifier | Subnet Prefix |collision count | Public key | |(16 octets)| (8 octets) | (1 octet) | (variable) | +-----------------------------------------------------------+ Figure 2 CGA Parameters 3. The Secure Hash Algorithm (SHA1) is executed using the output from step 2. The first leftmost 112 bits of the resulting digest is called Hash2. 4. The computational complexity of Hash2 depends on the Sec value. The Sec value is an unsigned 3-bit integer having a value between 0 and 7 (0 being the least secure while 7 the most) which indicates the security level of the generated address against brute-force attacks. The use of a security value of one is recommended. According to our experimental results, it takes less than 500 milliseconds to generate a CGA when the Sec value is equal to 1. This Sec value is also acceptable if the nodes' IP address is temporary [3]. The 16xSec leftmost bits of Hash2 are compared to zero. If the condition is not met, the modifier is incremented by one and steps 2 through 4 are repeated. If the condition is met, the next step is executed 5. The modifier is concatenated with the prefix, the collision count, and the public key. SHA1 is executed using the resulting output to create Hash1. The CGA algorithm then uses the leftmost 64 bits from Hash1 and sets the first leftmost 3 bits to the sec value. It also sets bits 7 and 8 (bits u and g) which are called the Interface ID (IID) 6. The subnet prefix is then concatenated with the IID and the Duplicate Address Detection (DAD) process is executed in order to detect address collision on the network. The node then includes the Rafiee, et al. Expires May 22, 2013 [Page 6] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 CGA parameters (modifier, subnet prefix, collision count, public key) with the messages to give other nodes the ability to verify the address ownership of the sender by finding a relationship between the sender's IP address and his public key. 4.2. Modification to TSIG protocol Normally, to initiate a secure DNS Update process between a DNS server and a host (another DNS server or a client), a minimum of four messages are required to establish a secure channel (especially for another secure DNS Update mechanism, DNSSEC). A modification to RFC-2845, CGA-TSIG, decreases the number of messages needed in the exchange. The messages used in RFC-2930 (TKEY RR) are not needed when CGA-TSIG is used. The CGA-TSIG extension uses the creation of a TSIG Resource Record (RR). This RR uses the same data as is used to generate a new IP address in a node -- for example, the key pairs (public/private keys), and the output value of the CGA generation function (Interface ID). These values should be cached in the node's memory for later use. 4.2.1. Modified TSIG Record format The modified TSIG RR uses the same format as the other RRs in use in the DNS field. The DNS RR format is explained in section 3.2.1 RFC-1035, where the algorithm type must be set to TSIG. The RDATA is also extended in order to store the CGA parameters, IP tag, and the modified CGA signature. The RDATA's algorithm type must be set to CGA-TSIG, a detailed explanation of the RDATA standard fields can be found in section 2.3 RFC-2845. This document focuses only on the new extensions added to RDATA. These new fields are CGA-TSIG Len and CGA-TSIG DATA. TSIG RR is added to an additional section of the DNS messages. The general format for DNS messages is explained in RFC1035 [section 4.1 RFC-1035]. +---------------------------------------+ | Algorithm type | | (CGA-TSIG) | +---------------------------------------+ | Time Signed | | | +---------------------------------------+ | Fudge | | | +---------------------------------------+ | MAC Size | | | Rafiee, et al. Expires May 22, 2013 [Page 7] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 +---------------------------------------+ | Mac | | | +---------------------------------------+ | Original ID | | | +---------------------------------------+ | Error | | | +---------------------------------------+ | OTHER LEN | | | +---------------------------------------+ | OTHER DATA | | | +---------------------------------------+ Figure 3 Modified TSIG RDATA CGA-TSIG DATA Field and CGA-TSIG Len are placed in the initial part of Other DATA. Figure 4 shows the layout. +---------------------------------------+ | CGA-TSIG Len | | | +---------------------------------------+ | CGA-TSIG DATA | | | +---------------------------------------+ | Other Options | | | +---------------------------------------+ Figure 4 Other DATA CGA-TSIG DATA Field Name Data Type Notes -------------------------------------------------------------- Algorithm type u_int16_t Name of the algorithm [RFC3972] RSA (by default) CGA IP tag 16 octet the tag used to identify the IP address Parameters Len Octet the length of CGA parameters CGA Parameters variable Section 3.1 this document CGA Signature Len Octet the length of CGA signature CGA Signature variable Section 3.2.1 This document IP tag is a node's old IP address. A client's public key can be associated with several IP addresses on a server. A DNS server keeps a client's public key and IP addresses in a data field formated as shown in figure 6. This allows the client to update his own RRs using Rafiee, et al. Expires May 22, 2013 [Page 8] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 multiple IP addresses While at the same time allowing him to change IP addresses. If a client wants to add RRs to the server by using a new IP address, the IP tag field will be set to binary zeroes and the server will add the new IP address being passed to it to the CGATSIG table on database. If the client wants to replace an existing IP address in CGATSIG table on the server with a new one, then the IP tag field will be populated with the IP address wihich is to be replaced. The server will then look for the IP address referenced by the IP tag in the CGATSIGips table (or file) and replace that IP address with the new one. Note: When a host sends a DNS Update message to a DNS server for the first time, the DNS server must save the public key for this client in CGATSIGkeys. +---------------------------------------+ | Algorithm type | | | +---------------------------------------+ | IP tag | | (16 byte) | +---------------------------------------+ | CGA Parameter Len | | (1 byte) | +---------------------------------------+ | CGA Parameters | | (variable) | +---------------------------------------+ | CGA Signature Len | | (1 byte) | +---------------------------------------+ | CGA Signature | | (variable) | +---------------------------------------+ Figure 5 CGA-TSIG DATA Field create table cgatsigkeys ( id INT auto_increment, pubkey VARCHAR(300), primary key(id) ); create table cgatsigips ( id INT auto_increment, idkey INT, IP VARCHAR(20), FOREIGN KEY (idkey) REFERENCES cgatsigkeys(id) primary key(id) ); Rafiee, et al. Expires May 22, 2013 [Page 9] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 Figure 6 CGA-TSIG tables on mysql backend database 4.2.1.1. Generation of the DNS Update request/response Both the DNS update request and response messages must contain the CGA-TSIG option. To generate the CGA-TSIG DATA, a DNS server and a host must follow steps 1 and 2. It is recommended that the CGA parameters be cached in an XML file in the format as shown in figure 7. The modifier is the final modifier in the byte and each byte separated by a comma (for example : 284,25,14,...). Algorithmtype is the algorithm used in signing the message. Zero is the default algorithm, i.e., RSA. Secval is the CGA Sec value that is, by default, one. GIP is the global IP address of this node (for example: 2001:abc:def:1234:567:89a). oGIP is the old IP address of this node, before the generation of the new IP address. Keys are the path where the CGA-TSIG algorithm can find the PEM format of the public/private keys (for example: /home/myuser/keys.pem ).
Figure 7 XML file contains the cached DATA 1.Obtain required parameters from cache. The CGA-TSIG algorithm obtains the old IP address, modifier, subnet prefix, public key from the cache (XML file). It concatenates the old IP address with the CGA parameters, i.e., modifier, subnet prefix, public key and collision count (the order of CGA parameters are shown in figure 2). If the old IP address is not available, CGA-TSIG must set the old IP address (IP tag) to zero. In the case of multiple DNS servers (authentication of two DNS servers), there are three possible scenarios with regard to the authentication process, which differs from that of the authentication of a node (client,) with one DNS serve,r because of the need for human intervention. a. Add the DNS servers' IP address to a slave configuration file Rafiee, et al. Expires May 22, 2013 [Page 10] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 A DNS server administrator should only manually add the IP address of the master DNS server to the configuration file of the slave DNS server. When the DNS update message is processed, the slave DNS server can authenticate the master DNS server based on the source IP address and then, prove the ownership of this address by using CGA. This scenario is valid until the IP address in any of these DNS servers changes. To automate this step's process, the DNS Update message sender's public key must be saved on the other DNS server, after the source IP address has been successfully verified for the first time. In this case, when the sender generates a new IP address by executing the CGA algorithm using the same public key, the other DNS server can still verify it and add its new IP address to the DNS configuration file automatically. b. Retrieve public/private keys from a third party Trusted Authority (TA) The message exchange option of SEND [RFC3971] may be used for the retrieval of the third party certificate. This may be done automatically from the TA by using the Certificate Path Solicitation and the Certificate Path Advertisement messages. Like in scenario b, saving the certificate on the DNS server for later use in the generation of its address or in the DNS update process. In this case, whenever any of these servers wants to generate a new IP address, the DNS update process can still be done automatically without the need for human intervention. 2. Generate signature For signature generation, all CGA parameters (modifier, public key, collision count and subnet prefix), that are concatenated with the DNS update message, IP tag and the Time Signed field, are signed by using a RSA algorithm and the private key which was generated in the first step. This signature must be added as an initial option to the Other DATA field. Time Signed is the same timestamp as is used in RDATA. This value is the UTC date and time value obtained from the signature generator. This approach will prevent replay attacks by changing the content of the signature each time a node wants to send a DNS Update Request. The Update Message contains all of the DNS update message with the exclusion of the TSIG Resource Records (RRs). A DNS update message consists of a header, a zone, a prerequisite, an update and additional data. The header contains the control information [RFC2136], the zone identifies the zones to which this update should be applied [Section 4.1.2 RFC1035], the prerequisite prescribes the RRs that must be in the DNS database, the update contains the RR that needs to be modified or added and the additional data is the data that is not part of the DNS update, but is necessary in order to process this update. Rafiee, et al. Expires May 22, 2013 [Page 11] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 +-----------------------------------------------------------+ | Modifier | Subnet Prefix |collision count | Public key | | (128 bits)| (64 bits) | (8 bit) | (variable) | +-----------------------------------------------------------+ | IP tag |Time Signed | DNS Update Message | | (128 bits)| | | +-----------------------------------------------------------+ Figure 8 CGA-TSIG Signature 4.2.1.2. Verification of the DNS Update Request/Response Sender authentication is necessary to prevent attackers from making unauthorized modifications to DNS servers by use of spoofed DNS Update messages. The verification process has the following steps: 1. Check the subnet prefix The leftmost 64 bits of IPv6 addresses constitute the subnet prefix. The receiver obtains the subnet prefix from the source IP address in the sender's message. Then, the subnet prefix is obtained from the CGA parameters in the TSIG Other DATA field of the received message. A comparison is then made between these two subnet prefixes. If the subnet prefixes match step 2 is executed, otherwise the node is considered as an attacker and the message should be discarded without further action. 2. Check the Time Signed The Time Signed value is obtained from the TSIG RDATA and is denoted t1. The current system time is then obtained and converted to UTC time and is denoted t2. If t1 is in the range of t2 and t2 minus 2 minutes (see formula 1, 2 minutes may vary according to the transmission lag time) step 3 is executed, otherwise, the message is considered a spoofed message and the message should be discarded without further action. The range of two seconds is used because the update message may experience a delay during its transmission over TCP or UDP. Both times must use UTC time to avoid any differences in the time based on different geographical locations. t2-2 <= t1 <= t2 (1) 3. Compare Hash1 to the Interface ID The receiver should obtain all CGA parameters from the TSIG Other DATA field and execute SHA1 against them. The leftmost 64 bits of the resulting output constitutes Hash1. Hash1 is then compared to the Rafiee, et al. Expires May 22, 2013 [Page 12] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 rightmost 64 bits of the sender's IP address, which is known as the Interface ID (IID). Any differences in the first three leftmost bits of the IID (Sec value) and the u and the g bits (Section 3.1) are ignored. u and g are bits 7 and 8 of the first byte of the IID. If they match step 4 is executed, otherwise, the source is considered as a spoofed source IP address and the message should be discarded without further action. 4. Evaluate Hash2 with CGA parameters The receiver obtains the CGA parameters. The collision count and the subnet prefix are set to zero and SHA1 is executed on the resulting data in order to obtain a result of which the leftmost 112 bits are denoted as Hash2. The leftmost 16xSec bits of Hash2 are compared to zero. If the condition is met step 5 is executed, otherwise, the CGA parameters should be consider as spoofed CGA parameters and the message should be discarded without further action. 5. Verify the signature The signature contained in the TSIG Other DATA field of the DNS update message should be verified. This can be done by retrieving the public key from the TSIG Other DATA and using it to verify the signature. If the verification process is successful and the node does not want to update another node's RR, then the Update Message will be processed. If the signature verification is successful and the node wants to update another node's RRs, then step 6 is executed. If the verification fails, then the message should be discarded without further action. 6. Verify the Source IP address If a node wants to update a/many RR(s) on another DNS server, like a master DNS server wanting to update RRs on the slave DNS server, the requester's source IP address must be checked against the one in the DNS configuration file. If it is the same the Update Message should be processed, otherwise, step 7 is executed. 7. Verify the public key The DNS server checks whether or not the public key retrieved from the TSIG Other DATA is the same as what was available in CGATSIGkeys table. If it is the same the Update Message should be processed, otherwise, the message should be discarded without further action. 4.2.1.3. Generation of DNS Query Response When a host, such as a client or a mail server, wants to resolve a domain or IP address, it generates a DNS query messages and sends its request to the known resolver. The CGA-TSIG DATA field is not required in this message because the resolver responds to anonymous Rafiee, et al. Expires May 22, 2013 [Page 13] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 queries. But the resolver's response should contain the CGA-TSIG DATA field. The generation of the CGA-TSIG DATA field is explained in section 4.2.1.1. 4.2.1.4. Verification of DNS Query Response When a resolver responds to the host's query request for the first time, the client saves its public key in a file. This allows the client to verify this resolver when it changes its IP address due to privacy or security issues. The resolver's responses should contain the CGA-TSIG DATA field in order to enable this client to verify him. The verification steps are the same as the first 5 steps explained in section 4.2.1.2. 5. Security Considerations The solution explained in this draft, CGA-TSIG, is an approach that can secure DNS messages from spoofing type attacks as explained in section 3. Note: If a host does not support CGA-TSIG, the CGA-TSIG DATA Field should be ignored. It is recommended that both communicating nodes support this option in order to diminish the possibility for the occurrence of the attacks explained in the next sections. The problem that can arise here are attacks against the CGA algorithm. In this section we explain the possibility of attacks against CGA itself, and explain the available solutions we considered in this draft. a) Discover an Alternative Key Pair Hashing of the Victim's Node Rafiee, et al. Expires May 22, 2013 [Page 14] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 Address In this case an attacker would have to find an alternate key pair hashing of the victim?s address. The success of this attack will rely on the security properties of the underlying hash function, i.e., an attacker will need to break the second pre-image resistance of that hash function. The attacker will perform a second pre-image attack on a specific address in order to match other CGA parameters with Hash1 and Hash2. The cost of doing so is (2^59+1) * 2^(16?1). If the user uses a sufficient security level, it will be not feasible for an attacker to carry out this attack due to the cost involved. Changing the IP address frequently, also, decrease the chance of this attack. b) DoS to Kill a CGA Node Sending a valid or invalid CGA signed message with high frequency across the network can keep the destination node(s) busy with the verification process. This type of DoS attack is not specific to CGA, but it can be appied to any request-response protocol. One possible solution to mitigate this attack is to add a controller at the verifier side to determine the maximum number of messages that the receiver can accept within a certain period of time from a specific node. If this threshold rate is exceeded, the receiver drops the new incoming messages from that node. c) CGA Privacy Implication Due to the high computational complexity necessary for the creation of a CGA, it is likely that once a node generates an acceptable CGA it will continue to use it at that subnet. The result is that nodes using CGAs are still susceptible to privacy related attacks. One solution to these types of attacks is setting a lifetime for the address as explained in RFC4941. 6. IANA Considerations The IANA has allowed for choosing new algorithm(s) for use in the TSIG Algorithm name. Algorithm name refers to the algorithm described in this document. The requirement to have this name registered with IANA is specified 7. Conclusions In TSIG, not all processing is done automatically and some steps might even need to be done offline. To address this issue, and to automate this process when Secure Neighbor Discovery (SEND) (RFC3971) is used, this document is introduced as an extension to the TSIG protocol (CGA-TSIG) in order to take advantage of the use of CGA for the DNS Update authentication process of a node within a DNS server. Rafiee, et al. Expires May 22, 2013 [Page 15] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 CGA-TSIG also decreases the number of messages needed in the exchange between the DNS server and the DNS client during the update process. This enhances the performance of the DNS update process. Since CGA does not need Public Key Infrastructure (PKI) framework to verify the node's address ownerships, the authentication of a node with a DNS server in the DNS update process is automated. This document also makes use of SEND for the authentication of two DNS servers against each other when processing DNS Update messages. However ,the first step should be done manually the first time it is used to afford greater security for this process. 8. Acknowledgements The author would like to thank all those who helped directly in improving of this draft and all supporters of this draft 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)," RFC 3972, March 2005. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC1035] Mockapetris, P., "Domain Names - Implementation And Specification", RFC 1035, November 1987. [RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC2136] Vixie, P. (Editor), Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. Rafiee, et al. Expires May 22, 2013 [Page 16] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 9.2 Informative References [1] Aura, T., "Cryptographically Generated Addresses (CGA)", Lecture Notes in Computer Science, Springer, vol. 2851/2003, pp. 29-43, 2003. [2] Montenegro, G. and Castelluccia, C., "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses," ISOC Symposium on Network and Distributed System Security (NDSS 2002), the Internet Society, 2002. [3] AlSa'deh, A., Rafiee, H., Meinel, C., "IPv6 Stateless Address Autoconfiguration: Balancing Between Security, Privacy and Usability". Lecture Notes in Computer Science, Springer(5th International Symposium on Foundations & Practice of Security (FPS). October 25 - 26, 2012 Montreal, QC, Canada), 2012. Rafiee, et al. Expires May 22, 2013 [Page 17] INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012 Authors' Addresses Hosnieh Rafiee Hasso-Plattner-Institute Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Phone: +49 (0)331-5509-546 Email: rafiee@hpi.uni-potsdam.de Dr. Christoph Meinel (Professor) Hasso-Plattner-Institute Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Email: meinel@hpi.uni-potsdam.de Dr. Martin von Loewis Hasso-Plattner-Institute Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Email: martin@v.loewis.de Rafiee, et al. Expires May 22, 2013 [Page 18]