Network Working Group 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: April 18, 2013 October 15, 2012 Transaction SIGnature (TSIG) using CGA Algorithm in IPv6 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 April 18, 2013. 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. Abstract The first step of Transaction SIGnature (TSIG) (RFC 2845) is to generate a shared secret and exchange it manually between a DNS server and a host. This document, CGA-TSIG, proposes a possible way to automate the now manual process for the authentication of a node with a DNS server during the DNS Update process by using the same Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 1] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Conventions used in this document . . . . . . . . . . . . . . . 3 3 Algorithm Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.1 CGA Generation Algorithm . . . . . . . . . . . . . . . . . 4 3.2. Modification to TSIG protocol . . . . . . . . . . . . . . 4 3.2.1. Modified TSIG Record format . . . . . . . . . . . . . 5 3.2.1.1 Generation of the DNS Update request/response . . . 6 3.2.1.2 Verification of the DNS Update Request/Response . . 7 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 4.1 IP Spoofing and Reflector Attacks . . . . . . . . . . . . 10 4.2 DNS Dynamic Update Spoofing . . . . . . . . . . . . . . . 10 4.3 Resolver Configuration Attack . . . . . . . . . . . . . . 10 4.4 Shared Secret (key pairs) Exposing . . . . . . . . . . . . 10 4.5 Replay attack . . . . . . . . . . . . . . . . . . . . . . 10 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 7.2 Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.1. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 2] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 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 named server that the zone transfer is from the original master named server and that it has not been spoofed by hackers. It does this by verifying the signature with a cryptographic key shared with that of the receiver. The TSIG protocol can be extended using newly defined algorithms. This document defines an algorithm based on the Cryptographically Generated Addresses (CGA) [RFC3972]. CGA is one of the important options 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 any new infrastructure. 2 Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 3 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 Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 3] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 3.1 CGA Generation Algorithm A node proceeds with the following steps to generate the CGA: 1. Key pairs, called public/private keys, and a random number, called a modifier, are generated [key pair format: Section 3. RFC3972] It is recommended that key pairs be generated on the fly for the following reasons: - To decrease the randomization of IP addresses - To eliminate the need to have the keys manually generated and saved in a particular path, in the node, before the start of IP address generation - To decrease the chance of private key theft 2. The modifier is concatenated with other parameters such as a zero value prefix (64 bits), a zero value collision count (1 bit) and the RSA public key +----------------------------------------------------------+ | Modifier | Subnet Prefix |collision count | Public key | |(2 octets)| (8 octets) | (1 bit) | (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 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 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 that 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) and calls this 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 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. 3.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. A modification to RFC-2845, CGA-TSIG, decreases the number of messages needed in the Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 4] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 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 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). It is recommended that these values be cached in the node's memory for later use. 3.2.1. Modified TSIG Record format The modified TSIG RR uses the same format as other RRs in use in the DNS field. This 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 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. +---------------------------------------+ | Algorithm type | | (CGA-TSIG) | +---------------------------------------+ | Time Signed | | | +---------------------------------------+ | Fudge | | | +---------------------------------------+ | MAC Size | | | +---------------------------------------+ | 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 Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 5] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 [RFC3972] RSA (by default) CGA 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 +---------------------------------------+ | Algorithm type | | | +---------------------------------------+ | CGA Parameter Len | | (1 byte) | +---------------------------------------+ | CGA Parameters | | (variable) | +---------------------------------------+ | CGA Signature Len | | (1 byte) | +---------------------------------------+ | CGA Signature | | (variable) | +---------------------------------------+ Figure 5 CGA-TSIG DATA Field 3.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. In the case where key pairs and CGA parameters are cached during the generation of the IP address by using SEND, the value for the first two steps can be obtained from cache. 1.Execute steps 1 through 4 of section 3.1. It is recommended that the same algorithm be used to generate both CGA key pairs and to generate and sign the CGA in the CGA-TSIG DATA Field. 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 server because of the need for human intervention. a. Add DNS servers' IP address to a slave configuration file 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 may 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. Manually exchange the public/private keys An administrator of the Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 6] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 DNS servers may need to manually save the public/private keys of a master DNS server in the slave DNS server. This approach does not have the disadvantage of the first approach since, any time any DNS server wants to change its IP address, it will use the public/private keys. c. 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 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. +----------------------------------------------------------+ | Modifier | Subnet Prefix |collision count | Public key | | (16 bits)| (64 bits) | (1 bit) | (variable) | +----------------------------------------------------------+ | Time Signed | DNS Update Message | | | | +----------------------------------------------------------+ Figure 6 CGA-TSIG Signature 3.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. Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 7] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 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 seconds (see formula 1, 2 seconds 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 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. Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 8] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 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 saved manually by the administrator. If it is the same, step 8 is executed, otherwise, the message should be discarded without further action. 8. Re-generate the signature The signature is regenerated to ensure the confidentiality of the data. The DNS server retrieves the CGA parameters, the Time Signed and the Update Message from the content of the DNS Update Request. These fields are then concatenated. The algorithm type is obtained from the Other Data field of the TSIG RDATA which, by default, should be the RSA, and then a signature is generated using the private key of the sender obtained from the local storage in the DNS server (the key pairs manually saved by administrator). This signature is compared with the signature obtained from the TSIG Other DATA. If there is a match, then the Update Message is processed, otherwise, the message should be discarded without further action. Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 9] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 4 Security Considerations There are several attacks that CGA-TSIG can prevent. Here we evaluate some of these attacks. 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. 4.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 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 also 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 traffic to this victim thus keeping the victim busy processing these packets. Using the CGA signature and authentication approach will prevent this type of attack. 4.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. 4.3 Resolver Configuration Attack In CGA-TSIG, the DNS server or the client might not need further configuration. This may reduce the possibility for human errors being inserted into the DNS configuration file. Since this type of attack is predicated on human error, the chances of it occurring when our proposed extension is used are minimized. 4.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. 4.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 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, Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 10] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 this type of attack is also prevented. 5 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 6 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. 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. 7 References 7.1 Normative References [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. Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 11] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 2012 [RFC1035] Mockapetris, P., "Domain Names - Implementation And Specification", RFC 1035, November 1987. [RFC2136] Vixie, P. (Editor), Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. 7.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. Appendix A. A.1. Copyright Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 12] INTERNET DRAFT TSIG using CGA in IPv6 October 15, 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.vonloewis@hpi.uni-potsdam.de Rafiee, v. Loewis & Meinel-Expires April 18, 2013 [Page 13]