DNS Extensions H. Rafiee INTERNET-DRAFT Updates RFC 2845 (if approved) C. Meinel Intended Status: Standards Track Hasso Plattner Institute Expires: November 8, 2015 May 8, 2015 CGA-TSIG/e: Algorithms for Secure DNS Authentication and Optional DNS Confidentiality Abstract This document describes a new mechanism for secure DNS authentication and a possible mechanism for DNS data confidentiality in various scenarios especially DNS resolvers. It also focuses on reducing human interaction during secure authentication and DNS message encryption. This document supports both IPv4 and IPv6 enabled networks. 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 November 8, 2015. Copyright Notice Copyright (c) 2015 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 Rafiee, et al. Expires November 8, 2015 [Page 1] INTERNET DRAFT New algorithms in TSIG May 8, 2015 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. Changes to this document [only for authors/editors] . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Functional description of CGA-TSIG/e Mechanisms . . . . . 5 3. Conventions Used In This Document . . . . . . . . . . . . . . 7 4. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 8 4.1. CGA-TSIG . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. The CGA-TSIG DATA Structure . . . . . . . . . . . . 8 4.1.2. CGA-TSIG DATA . . . . . . . . . . . . . . . . . . . 9 4.1.2.1. IPv6 Specific Data . . . . . . . . . . . . . . . 10 4.1.2.2. IPv4 Specific Data . . . . . . . . . . . . . . . 10 4.1.3. Generation of CGA-TSIG DATA . . . . . . . . . . . . 10 5. General Verification Steps . . . . . . . . . . . . . . . . . 11 6. CGA-TSIG/CGA-TSIGe Use Case Scenarios . . . . . . . . . . . . 13 6.1. DNS Resolving Scenario (stub to recursive) . . . . . . . 13 6.1.1. Client Verification Process (CGA-TSIGe only) . . . . 14 6.1.2. Resolver Verification Process . . . . . . . . . . . . 14 6.2. DNS Resolving Scenario (Authoritative NS to Recursive NS) 15 7. SeND Is Not Supported (IPv6 only) . . . . . . . . . . . . . . 16 8. CGA-TSIG/e Attack Protections . . . . . . . . . . . . . . . . 16 8.1. IP Spoofing . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Resolver Configuration Attack . . . . . . . . . . . . . . 17 8.3. Exposing A Shared Secret . . . . . . . . . . . . . . . . 17 8.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . 17 8.5. Data Confidentiality . . . . . . . . . . . . . . . . . . 17 9. Update to TSIG Specification . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. A Sample Key Storage For CGA-TSIG . . . . . . . . . . . 19 12.2. Stored parameters in the node . . . . . . . . . . . . . 19 12.3. CGA Generation Script . . . . . . . . . . . . . . . . . 20 12.4. CGA-TSIGe (DNS privacy) . . . . . . . . . . . . . . . . 21 12.4.1. The CGA-TSIGe DATA Structure . . . . . . . . . . . 21 12.4.1.1. Public Key Request . . . . . . . . . . . . . . . 22 12.4.1.2. Public Key Response . . . . . . . . . . . . . . 22 12.4.2. Generation of CGA-TSIGe DATA . . . . . . . . . . . 23 12.4.2.1. IPv6 Specifics . . . . . . . . . . . . . . . . . 23 12.4.2.1.1. Generation of Query Request Message . . . . 23 12.4.2.1.2. Generation of Query Response Message . . . . 26 12.4.2.2. IPv4 Scenario . . . . . . . . . . . . . . . . . 26 12.4.2.2.1. Generation of Query Request Message . . . . 27 12.4.2.2.2. Generation of Query Response Message . . . . 27 12.4.3. Process of Public Key Response Message . . . . . . . 27 12.4.3.1. IPv6 only Scenarios . . . . . . . . . . . . . . 27 Rafiee, et al. Expires November 8, 2015 [Page 2] INTERNET DRAFT New algorithms in TSIG May 8, 2015 12.4.3.2. IPv4 only Scenarios . . . . . . . . . . . . . . 28 12.4.4. Process of Encrypted Query Request Message . . . . . 28 12.4.5. Process of Encrypted Query Response Message . . . . 28 12.5. Other Optional Use case scenarios . . . . . . . . . . . 28 12.5.1. The FQDN Or PTR Update (IPv6 only) . . . . . . . . . 29 12.5.1.1. Verification Process . . . . . . . . . . . . . . 29 12.5.2. DNS Zone Transfer . . . . . . . . . . . . . . . . . 30 12.5.2.1. Verification Process . . . . . . . . . . . . . . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 31 14.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Rafiee, et al. Expires November 8, 2015 [Page 3] INTERNET DRAFT New algorithms in TSIG May 8, 2015 1. Changes to this document [only for authors/editors] This section should be removed before any publication. - Introduction section: added explanation about secure authentication and the exact focus of this document. updated explanation to DNS privacy problems and added a reference to DNS privacy problem statement document, removed problem statement section since it is already mentioned in introduction. Removed terminology and added reference to existing DNS terminology draft - Overview of CGA-TSIG algorithm section: explained different operations via questions and answers to keep the readers focus on the main functions. - Appendix section: moved DNS privacy to appendix section. moved FQDN and PTR scenario to appendix section in other supported scenario. - CGA-TSIG section: removed IP tag, old signature and old public key. Removed the text about DNS update - CGA-TSIGe section: removed IP tag, old signature and old public key. 2. Introduction Authentication is a key feature that protects both DNS server and client from several attacks ? identity spoofing, unauthorized update of DNS records, phishing, etc. This is especially critical in different DNS scenarios. This draft only focuses on three DNS scenarios that are during Dynamic DNS (DDNS) [RFC2136] of updating PTR and Fully Qualified Domain Name (FQDN) resource records (RRs) and any other values on DNS Servers , DNS zone update ([AI]XFR) for multiple DNS servers (authenticating two DNS servers), and during authentication of recursive DNS servers on clients. TSIG [RFC2845] is based on MAC authentication. It uses one way hashing and a shared secret for the authentication of DNS messages especially during DDNS. In this mechanism there need to be a shared secret shared among all clients and DNS servers that want to process DDNS. The configuration and sharing this shared secret among all these nodes are manual. If the shared secret is known to attacker, then the manual step for sharing this shared secret should be repeated. TSIG is also unable to protect a node against some well-known DNS attacks. One example is DNS amplification attack. To address the above problems and securing the last miles of the internet where DNSSEC might not be able to protect it easily, this document introduces CGA-TSIG algorithm. The purpose of CGA-TSIG is automation (minimizing human interaction) and secure authentication. Rafiee, et al. Expires November 8, 2015 [Page 4] INTERNET DRAFT New algorithms in TSIG May 8, 2015 Besides, DNS messages might contain important data which might allow an attacker to analyze the behavior of users in a network or pursue further attacks. These data might be confidential and need protection. There are recently a lot of concerns about DNS privacy and hiding the data exchanges between stub resolvers' and DNS server from prying eyes (either in active or passive attacks). In appendix of this document, the small changes that needed in CGA-TSIG algorithm to also consider DNS privacy is introduced and call this new algorithm as CGA-TSIGe. CGA-TSIGe protects a node against DNS privacy attacks explained in [dns-privacy]. It does this by providing a node with a mechanism to securely verify the DNS resolver (to avoid spoofed DNS messages) and encrypt the whole DNS message. It uses the current available Resource Records (RRs) to carry any parameters requires for this process. After encryption process, this encrypted message is encapsulated in a new DNS message (new DNS header is added to it) and the required parameters are added in the additional section of this new DNS message for decryption purposes in the receiver node. CGA-TSIGe uses both asymmetric and symmetric cryptography. Asymmetric cryptography is used for encrypting the 16 byte secret key. This secret key then can be used as a key for the symmetric encryption algorithm in order to encrypt the whole DNS message. This process will increase the DNS performance by avoiding the encryption of a large DNS message using a public key cryptography. Both CGA-TSIG and CGA-TSIGe support both IPv4 and IPv6 enabled network and considered as new algorithms in the TSIG Resource Record (RR). 2.1. Functional description of CGA-TSIG/e Mechanisms - Purpose 1-secure authentication, 2-minimize human interaction and 3- provide data confidentiality required to accomplish a shared secret or key exchange. If only number 1 and 2 is the purpose, then the algorithm is called CGA-TSIG. When 1,2, and 3 all together is the purpose, then the algorithm is called CGA-TSIGe (it is explained in Appendix). Since this protocol is added to "Other Data" section of TSIG RR, when a DNS client or server does not support CGA-TSIG, it easily ignores CGA-TSIG option without returning any error and returns back to compatibility mode, i.e., using DNS server without encryption. - How client and server receives the IP address/hash of public key of DNS server? There are two possibilities: 1- From a DNS option in router advertisement message [RFC6106] 2- From a DHCP/v6 server protected via SAVI approaches [savi-dhcp] or any monitoring node Rafiee, et al. Expires November 8, 2015 [Page 5] INTERNET DRAFT New algorithms in TSIG May 8, 2015 - What if the network is not trusted (e.g. untrusted DHCP server, untrusted router, untrusted DNS server) This is only applicable for resolver scenario. User can easily introduce the IP address of trusted resolver (or select home resolver from the list of trusted resolvers in its computer). For automation purpose, the implementation SHOULD provide a possibility to store a short list of trusted resolvers so that the client can pick one of them. - How CGA-TSIG/e Prevents Spoofing and authenticate DNS servers or clients (depends on scenario) In the IPv6 scenario, the algorithms use Cryptographically Generated Addresses (CGA) [RFC3972] or Secure Simple Addressing Scheme for IPv6 Autoconfiguration (SSAS) [4, 5]. Both CGA and SSAS provide the nodes with the necessary proof of IP address ownership by providing a cryptographic binding between a host's public key and its IP address without the need for the introduction of infrastructure. In other word, by receiving any message from a DNS resolver, client can verify its signature and since the key is bound to the IP address, the client can make sure that the value is from the same resolver as it already received the IP address from DHCP server or an option in router advertisement message. In IPv4 scenarios, the algorithms use the hash of public key as an authentication approach. For example, in resolver scenario, the client receives the DNS resolver?s hash of (IPv4 + public key) from a DHCPv4 server that is protected by SAVI approaches or other monitoring approaches. When the client receives the key from DNS server it calculates the hash of (IPv4 + public key) and compare this value with what it received from DHCP server. If it matches, then the client can trust any value received from the DNS server. - How Client and server do key exchange in DNS privacy scenario (Appendix) Client sends an empty message and adding TSIG in additional part and set the algorithm to CGA-TSIGe. This message then can be sent to DNS server. DNS server then knows it should submit its key to client, sign it with its own private key. - In CGA-TSIGe, if the whole message is encrypted, How the DNS server knows how to decrypt the message Rafiee, et al. Expires November 8, 2015 [Page 6] INTERNET DRAFT New algorithms in TSIG May 8, 2015 After a client receives the public key of DNS server in a secure manner (as explained in prior paragraphs), it generates a random number and call this number a secret key (it is similar to session key in TLS or SSL). It, then, encrypts the whole DNS message and encapsulates it in a new DNS message (that is adding new header and additional section). In additional section of this new DNS message, it includes CGA-TSIGe and all its required parameters. In other word, the whole encrypted messages is like a query section in new DNS message. Then the secret key is encrypted using the public key of DNS server and this message is submitted to the DNS server. When the DNS server receives this message, if the additional section includes CGA-TSIGe, then it first decrypts the secret key using public key cryptography and then decrypts the whole DNS message using this secret key and a symmetric algorithm such as AES. 3. 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 sign in the document should be interpreted as "change to". IPv6 only: this indicates that the explained approach can be used only in IPv6 scenario IPv4 only: this indicates that the explained approach can be used only in IPv4 scenario IPv4 and IPv6: This indicates that the explained approach can be used in both IPv4 and IPv6 scenario and there are no differences. | This sign in this document should be interpreted as ?concatenation?. Note: This document uses the names CGA-TSIG and CGA-TSIGe. But it does not mean that the algorithm in use in this document is only CGA. The "CGA" name was taken from the first versions of this draft and continued to be appeared in the latest versions of this draft. This draft also uses TSIG as a carrier protocol to avoid changing the current DNS protocol. The terms used in this documents are defined in [dns-terms]. Rafiee, et al. Expires November 8, 2015 [Page 7] INTERNET DRAFT New algorithms in TSIG May 8, 2015 4. Algorithm Overview The following section explain the CGA-TSIG (secure authentication) data structure in IPv4 and IPv6 scenarios. A CGA-TSIG data structure is an option to the TSIG Resource Record (RR). 4.1. CGA-TSIG 4.1.1. The CGA-TSIG DATA Structure The CGA-TSIG data structure SHOULD be added to the Other DATA section of the RDATA field in the TSIG Resource Record (RR) (see figures 1 and 2). The DNS RRTYPE MUST be set to TSIG [RFC2845]. The RDATA Algorithm Name MUST be set to CGA-TSIG. The CGA-TSIG name is used when there is no need for DNS data confidentiality. The CGA-TSIGe (Please refer to Appendix) is used when all parts of a DNS message should be encrypted to provide data confidentiality. The Name MUST be set to root (.). This is the smallest possible value that can be used. The MAC Size MUST be set to 0 when the Algorithm Name is CGA-TSIG. A detailed explanation of the standard RDATA fields can be found in section 2.3 [RFC2845]. This document focuses only on the new structure added to the Other DATA section. These new fields are CGA-TSIG Len and CGA-TSIG DATA. The TSIG RR is added to an additional section of the DNS message. +---------------------------------------+ | Algorithm Name | | (CGA-TSIG) | +---------------------------------------+ | Time Signed | | | +---------------------------------------+ | Fudge | | | +---------------------------------------+ | MAC Size | | | +---------------------------------------+ | MAC | | | +---------------------------------------+ | Original ID | | | +---------------------------------------+ | Error | | | +---------------------------------------+ | Other Len | | | Rafiee, et al. Expires November 8, 2015 [Page 8] INTERNET DRAFT New algorithms in TSIG May 8, 2015 +---------------------------------------+ | Other Data | | | +---------------------------------------+ Figure 1: Modified TSIG RDATA The CGA-TSIG DATA Field and the CGA-TSIG Len will occupy the first two slots of Other DATA. Figure 2 shows the layout. Any extra options/data should be placed after CGA-TSIG field. CGA-TSIG Len is the length of CGA-TSIG DATA in byte. +---------------------------------------+ | CGA-TSIG Len | | (2 bytes) | +---------------------------------------+ | CGA-TSIG DATA | | | +---------------------------------------+ | Other Options | | | +---------------------------------------+ Figure 2: Other DATA section of RDATA field 4.1.2. CGA-TSIG DATA Figure 3 explains detail structure of CGA-TSIG DATA section. Fields that are marked (*) are different depending on IPv6 or IPv4. +---------------------------------------+ | AsyAlgorithm | | (15 bytes) | +---------------------------------------+ | Type * | | (u_int16_t) | +---------------------------------------+ | Parameters Len | | (1 byte) | +---------------------------------------+ | Parameters * | | (variable) | +---------------------------------------+ | Signature Len | | (1 bytes) | +---------------------------------------+ | Signature | | (variable) | +---------------------------------------+ Figure 3: structure of CGA-TSIG DATA section - AsyAlgorithm: Asymmetric algorithm. IANA numeric value for RSA algorithm 1.2.840.113549.1.1.1[RFC4055]. For ECC, IANA needs to define a new number. - Type: Name of algorithm Rafiee, et al. Expires November 8, 2015 [Page 9] INTERNET DRAFT New algorithms in TSIG May 8, 2015 - Parameters Len: Length of parameters - Signature Len: Length of public key cryptography signature - Signature: Please refer to section 4.1.3 of this document 4.1.2.1. IPv6 Specific Data For IPv6, the Type field indicates the Interface ID generation algorithm that is used in SeND (An Interface ID is the 64 rightmost bits of an IPv6 address). The field allows for future development. The default value for CGA is 1 and for SSAS is 2. 4.1.2.2. IPv4 Specific Data For IPv4, the Type field indicates the hashing function used to generate the hash of (public key + IPv4). By default, it is SHA256. This value SHOULD be set to 1 for SHA256 and other numeric incremental value for other hashing algorithms. This allows for future hashing functions. 4.1.3. Generation of CGA-TSIG DATA In order to use CGA-TSIG as an authentication approach, some of the parameters need to be cached during IP address generation. If no parameters are available in the cache, please see section 7. 1. Obtain Require Parameters From Cache. For IPv6, if the Type Field above is CGA, then the parameters that SHOULD be cached are the modifier, algorithm type, location of the public/private keys and the IP addresses of the host. For IPv4, the location to the key pairs needs to be cached in order to generate the signature. Note: If the node is a DNS server (resolver or Authoritative Name Server) that does not support SeND but wants to use the CGA-TSIG algorithm, a script can be used to generate the CGA parameters. (Please refer to the section 12.2. appendix) 2. Generate Signature The signature is generated by concatenation of the following values where Type is the 128-bit Message Type tag value. This value for CGA (SeND) is 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. Plain text= Type | Entire DNS message (Please refer to figure 4 and figure 5) Rafiee, et al. Expires November 8, 2015 [Page 10] INTERNET DRAFT New algorithms in TSIG May 8, 2015 Then the node uses its own private key obtained from the cache as explained in last step to sign the plain text. This signature MUST be added to the signature field of the CGA-TSIG DATA record. The Time Signed field uses the same timestamp in RDATA. This will prevent replay attacks by changing the signature each time a Node sends a DNS message. The format of DNS messages is explained in section 4.1.3 [RFC1035]. +-----+------+--------+ |Type |Length|Reserved| |1byte|1 byte| 1 byte | +---------------------+ | Header | | 12 bytes | +---------------------+ | Zone section | | variable length | +---------------------+ | prerequisite | | variable length | +---------------------+ | Update section | | variable length | +---------------------+ | Additional Data | | variable length | +---------------------+ Figure 4 DNS update message +-----+------+--------+ |Type |Length|Reserved| |1byte|1 byte| 1 byte | +---------------------+ | Header | | 12 bytes | +---------------------+ | Question | | variable length | +---------------------+ | Answer | | variable length | +---------------------+ | Authority | | variable length | +---------------------+ | Additional Data | | variable length | +---------------------+ Figure 5 DNS Query message (section 4.) 5. General Verification Steps Rafiee, et al. Expires November 8, 2015 [Page 11] INTERNET DRAFT New algorithms in TSIG May 8, 2015 This section explains general verification steps and can be used as a reference for verification in different scenarios. The modification of these steps is possible according the use case scenarios (next section). Sender authentication is necessary in order to prevent attackers from making unauthorized modifications to DNS servers through the use of spoofed DNS messages. The verification process uses the following steps: 1. Verify The Signature (IPv4 and IPv6) The Signature contained in CGA-TSIG DATA should be verified. This can be done by retrieving the public key and signature from CGA-TSIG DATA and using this public key to verify the signature. If the verification process is successful, then execute step 2. Otherwise, the message should be discarded. 2. Check The Time Signed (IPv4 and IPv6) The Time Signed value is obtained from TSIG RDATA and is called t(1). The current system time is then obtained and converted to UTC time and is called t(2). Fudge time is obtained from TSIG RDATA and is called t(fudge). If t(1) is in the range of t(2) and t(2) minus/plus t(fudge) (see formula 1), then step 3 will be executed. Otherwise, the message will be considered spoofed and discarded. The range is used in consideration of the delays that can occur during its transmission over TCP or UDP. Both times must use UTC time in order to avoid differences in time based on different geographical locations. (t(1) - t(fudge)) <= t(2) <=(t(1) + t(fudge)) Formula: (1) 3. Execute The CGA Verification (IPv6 only) These steps are in section 5 of [RFC3972]. If the sender of the DNS message uses another algorithm, instead of CGA, then this step becomes the verification step for that algorithm. If the verification process is successful, then step 6 will be executed. Otherwise the message will be discarded without further action. 4. Generate The Hash of (public key | IP address) (IPv4 only) The DNS server retrieves the hashing Algorithm Type from the CGA-TSIGe DATA structure. It then uses the following concatenations. Digest = hash(public key | IP address of the update requester) Where hash is SHA256 algorithm (by default) or another algorithm identified in Type section of CGA-TSIG DATA structure. It then compares digest with the hash value available in the DNS Rafiee, et al. Expires November 8, 2015 [Page 12] INTERNET DRAFT New algorithms in TSIG May 8, 2015 configuration. If they are the same, the Update Message should be processed, otherwise, go to step 5. 5. Verify The Source IP Address (IPv6 only) The source IP Address of the Update requester MUST be checked against the one contained in the DNS configuration. If they are the same, the Update Message should be processed, otherwise, proceed to step 7. 6. Verify The Public Key (IPv6 only) The DNS server checks whether or not the public key retrieved from CGA-TSIG DATA is the same as what is available in the cache where the public keys and IP addresses are saved. If this Public Key is not found in the cache, then the update will be rejected. Otherwise, when the Old Public Key Length is not zero go to step 8. 6. CGA-TSIG/CGA-TSIGe Use Case Scenarios 6.1. DNS Resolving Scenario (stub to recursive) A DNS query request sent by a host, such as a client or a mail server, does not need to generate CGA-TSIG DATA because the resolver responds to anonymous queries. The Resolver's response SHOULD contain the CGA-TSIG DATA field in order to verify him. However, the client needs to include the TSIG RDATA and set the Algorithm Type to CGA-TSIG, and it MUST set the CGA-TSIG Len to zero (0). This allows the resolver to include CGA-TSIG in the client. If the Node needs to deploy DNS data confidentiality (please refer to section 12.4.), then it needs to set the Algorithm Type to CGA-TSIGe and follows the step explained in section 12.4.2. In this particular scenario, the Node MUST set Message Hash in CGA-TSIGe. This allows the DNS server to ensure data integrity without going to the process of message decryption. In the generation of the CGA-TSIG/CGA-TSIGe for a Resolver, there is no need to include the IP Tag. This is because the Resolvers do not usually have several IP addresses so the client does not need to keep several IP addresses for the same resolver. +----------------+ +----------------+ | DNS Resolver | | DNS client | | | Ask for public key | | | | <------------------- | | | | Here you are | | | | -------------------> | | | | | Verification | | | | explained in | | | | section 12.4.3 | | | | | Rafiee, et al. Expires November 8, 2015 [Page 13] INTERNET DRAFT New algorithms in TSIG May 8, 2015 | | | Generation of | | | | Query request | | | |set message hash| | | |explained in | | | |section 12.4.2 | | | Encrypted DNS message| | | | <------------------- | | | Verification | | | | explained in | | | | section 6.1.1| | | | | | | | DNS message | | | | decryption | | | | explained in | | | | section 12.4.4| | | | Encrypt Query| | | | response | | | | explained in | | | | section 12.4.2| | | | |Encrypted Query response| | | | -------------------> | | | | | Verification | | | | explained in | | | | section 6.1.2 | | | | | | | | DNS message | | | | decryption | | | | explained in | | | | section 12.4.5 | +----------------+ +----------------+ Figure 11. DNS resolving scenario using CGA-TSIGe (Data confidentiality and secure authentication) 6.1.1. Client Verification Process (CGA-TSIGe only) 1. Retrieves Hashing Algorithm From CGA-TSIGe The resolver retrieves the hashing algorithm from CGA-TSIGe Type field. 2. Executes Hashing Algorithm on DNS Message The Resolver computes the SHA algorithm on the whole DNS message. It compares this with the value obtained from Message Hash of CGA-TSIGe. If they are the same, it decrypts the message using the shared secret obtained from the digest_secret_key section of the Other DATA section of TSIG RRType. 6.1.2. Resolver Verification Process When a Resolver responds to the client's query request for the first time, the client saves its Public Key in a file. This allows the Rafiee, et al. Expires November 8, 2015 [Page 14] INTERNET DRAFT New algorithms in TSIG May 8, 2015 client to verify this Resolver when it changes its IP Address due to privacy or security concerns. The steps 2 and 3 of the verification process are the same as those steps explained in section 5. These steps are as follows: 1. Verify The Hash of Public Key (IPv4 only) The client retrieves the SHA Algorithm Type from the Type section of CGA-TSIG/CGA-TSIGe, concatenates the following values: digest= hash(Resolver's Public Key | the Resolver's IP address) Where hash is a hash function (by default; SHA256). The client compares the digest with the value in its cache (received securely from a DHCP server or manually set by client). If they are the same, it stores its Public Key in its cache, and continues onto the next step. Otherwise the message will be discarded. 2. Verify The Signature (IPv4 and IPv6) The Signature contained in CGA-TSIG/CGA-TSIGe DATA can be verified by retrieving the Public Key and Signature from the CGA-TSIG/CGA-TSIGe DATA. If the verification process is successful, continue onto step 3, otherwise the message will be discarded. 3. Check The Time Signed (IPv4 and IPv6) 4. Execute The CGA Verification (IPv6 only) 5. Verify The Source IP Address (IPv6 only) If the Resolver's source IP address is the same as that which is known for the host or the length of Old Public Key is not zero (0), then step 6 will be executed. Otherwise the message SHOULD be discarded without further action. 6. Verify The Public Key (IPv6 only) The client checks whether or not the Public Key retrieved from CGA-TSIG/CGA-TSIGe DATA matches any Public Key that was previously saved in the storage where the Public Key and IP addresses of Resolvers are saved. If there is a match, then the message is processed. If not, then step 7 will be executed. 6.2. DNS Resolving Scenario (Authoritative NS to Recursive NS) This verification step of Authoritative Name Server to Recursive Name Server is the same as that explained in section 5. In this case the Recursive Name Server does not need to generate CGA-TSIG DATA, but the Root Name Server does need to include it in order to enable the Recursive Name Server to verify it. The Recursive Name Server needs to include the TSIG RDATA and set the Algorithm Type to CGA-TSIG. It Rafiee, et al. Expires November 8, 2015 [Page 15] INTERNET DRAFT New algorithms in TSIG May 8, 2015 MUST set the CGA-TSIG Len to zero (0). This allows the Root Name Server to know when to include CGA-TSIG for verification process in client. In case the node needs to use DNS data confidentiality, then it needs to set the Algorithm Type to CGA-TSIGe and follows the step explained in section 12.4.2. In this particular scenario, the Node MUST set the Message Hash in CGA-TSIGe. This allows the DNS server to ensure the data integrity of this message without going to the process of message decryption. 7. SeND Is Not Supported (IPv6 only) In the case where there are no cache parameters available during the IP Address generation, there are then three scenarios that come into play here. In the first scenario there is the case where the sender of a DNS message needs to generate a key pair and generate the CGA-TSIG or CGA-TSIGe data structure as explained in section 4.1 or section 12.4. The Node SHOULD skip the first section of the verification processes explained in section 5, section 6.1.1, and section 6.1.2. In the second scenario, as explained in section 4.1.3 (step 1), it is not necessary for the server to support the SeND or CGA algorithm. The DNS administrator can make a one-time use of a CGA script to generate the CGA parameters and then manually configure the IP address of the DNS server. Later, the DNS server can use those values as a means for authenticating other Nodes. The verifier Nodes also do not necessarily need to support SeND. They only need to support CGA-TSIG. In the third scenario, as explained in section 12.4.2.2., the Node can use the same approach used for IPv4 and retrieve the hash of (Public Key + IPv6 Address) from the DHCPv6 server. 8. CGA-TSIG/e Attack Protections There are several types of attacks that CGA-TSIG/CGA-TSIGe can prevent. The use of CGA-TSIG will reduce the number of messages needed between a client and a server in order to establish a secure channel. To exchange the shared secret between a DNS Resolver and a client, when TSIG is used, a minimum of four (4) messages are required. By modifying [RFC2845] to use CGA-TSIG, this will decrease the number of messages needed . The messages used in [RFC2930] (TKEY RR) are not needed when CGA-TSIG is used. 8.1. IP Spoofing This prevents the attack by finding a binding between the IP address and the Public Key for both IPv4 and IPv6 , with different Rafiee, et al. Expires November 8, 2015 [Page 16] INTERNET DRAFT New algorithms in TSIG May 8, 2015 approaches. 8.2. Resolver Configuration Attack When using CGA-TSIG/CGA-TSIGe, the DNS server (or client), would not need further configuration. This reduces the possibility of human errors being introduced into the DNS configurations. Since this type of attack is predicated on human error, the chances of it occurring are minimized. 8.3. Exposing A Shared Secret Using CGA-TSIG/CGA-TSIGe will decrease the number of manual steps required in generating the new shared secret and in exchanging it among the hosts to update the old shared secret. This manual step is required after a shared secret is leaked. 8.4. Replay Attack Using the Time Signed value in the Signature modifies the content of the Signature each time the Node generates and sends it to the DNS server. If the attacker attempts to spoof the timestamp, the DNS server will check this message by verifying the signature. In this case, the verification process will fail preventing the replay attack. 8.5. Data Confidentiality Encrypting the whole DNS message will deny the attacker from knowing the content of DNS messages. This will avoid zone walking and many other attacks on DNS RRs. 9. Update to TSIG Specification To support CGA-TSIG/e as a new algorithm in TSIG, updates needs to be made in the following sections of TSIG specification. In case any node does not support CGA-TSIG/e, it only ignores these new algorithms. - Section 4.2: The server MUST not generate a signed response to an unsigned request => The server MUST not generate a signed response to an unsigned request, unless the Algorithm Name filed contains CGA-TSIG or CGA-TSIGe. - Section 4.5.2: It MUST include the client's current time in the time signed field, the server's current time (a u_int48_t) in the other data field, and 6 in the other data length field => It MUST include the client's current time in the time signed field, the Rafiee, et al. Expires November 8, 2015 [Page 17] INTERNET DRAFT New algorithms in TSIG May 8, 2015 server's current time (a u_int48_t) in the other data field, and if the Algorithm Name is CGA-TSIG or CGA-TSIGe, then add the length of this client's current time to the total length of Other DATA field. The client's current time in this case will be placed after the CGA-TSIG/CGA-TSIGe Data. 10. Security Considerations The approach explained in this draft, CGA-TSIG, is a solution for securing DNS messages from spoofing type attacks like those explained in section 1.1. A problem that may arise here concerns attacks against the CGA algorithm. In this section we will explain the possibility of such attacks against CGA [5] and explain the available solutions that we considered in this draft. a) Discover an Alternative Key Pair Hashing of the Victim's Node Address In this case an attacker would have to find an alternate key pair hashing of the victim's address. The probability for success of this type of 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 using Hash1 and Hash2. The cost of doing this 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 type of attack due to the cost involved. Changing the IP address frequently will also decrease the chance for this type of attack succeeding. 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 applied to any request-response protocol. One possible solution ,to mitigate this attack, is to add a controller to the verifier side of the process to determine how many messages a node has received over a certain period of time from a specific node. If a determined threshold rate is exceeded, then the node will stop further receipt of 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 its use 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 RFC 4941. Rafiee, et al. Expires November 8, 2015 [Page 18] INTERNET DRAFT New algorithms in TSIG May 8, 2015 11. 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. In section 5.1, Type should allow for the use of future optional algorithms with regard to SeND. The default value is CGA. For this algorithm and other algorithms, (such as SSAS [4, 5], there needs to be a new number sequentially. IANA also needs to define a numeric algorithm number for ECC. The similar way that is defined for RSA. 12. Appendix 12.1. A Sample Key Storage For CGA-TSIG 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) ); CGA-TSIG tables on mysql backend database 12.2. Stored parameters in the node Here is a sample format of stored parameters in the node. For example, the modifier is stored as bytes and each byte might be separated by a comma (for example : 284,25,14,...). Algorithmtype is the algorithm used in signing the message. Zero is the default algorithm for 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 contains the path where the CGA-TSIG algorithm can find the PEM format used for the public/private keys (for example: /home/myuser/keys.pem ). Rafiee, et al. Expires November 8, 2015 [Page 19] INTERNET DRAFT New algorithms in TSIG May 8, 2015
XML file contains the cached DATA 12.3. CGA Generation Script Here introduces a sample CGA generation script for the nodes that does not support SeND. byte[] modifier; typedef int bool; #define true 1 #define false 0 // length_of_digest : 8 leftmost bytes of digest. //this function sets sec value on the first byte of digest //since interface ID is only 8 bytes, it returns only 8 leftmost bytes of digest byte[] set_secvalue(byte[] digest,int length_of_digest); //this function compares the 16 by cga_sec_value bits of digest to zero bool compare(byte[] digest, int cga_sec_value); //this function executes hashing function on cga_parameters byte[] sha1(byte[] cga_parameters); //this function reads public key from a file byte[] read_public_key(char[] public_key_path); //this function increments the modifier by one increment(byte[] modifier); //this function concatenates the input values. byte[] concat(byte[], byte[],....); //Write in a file CacheCGAparameters(byte[] ipv6_address, byte[] modifier, char[] public_key_path, int cga_sec_value, byte[] public_key_algorithm); //--------------main function ------------------------ int main(char[] interface_name) { byte[] cga=cgagen("\\xxx\key.pub",prefix); byte[] ipv6_address=concat(prefix,cga); //set the CGA address on a desired interface setIP(ipv6_address,"eth0\0"); CacheCGAparameters(ipv6_address,modifier,public_key_path, cga_sec_value, '1.2.840.113549.1.1.1'); } //------------------sample function for CGA Generation-------------- byte[] cgagen(char[] public_key_path, byte[] prefix, int cga_sec_value) { bool flag=true; byte[] cga; Rafiee, et al. Expires November 8, 2015 [Page 20] INTERNET DRAFT New algorithms in TSIG May 8, 2015 byte[] public_key=read_public_key(public_key_path); modifier= randomnumber(16); while(flag) { //concatinate all values byte[] cgaparameters=concat(modifier,prefix,0,public_key); byte[] digest=sha1(cgaparameters); if(compare(digest,cga_sec_value)==false) increment(modifier); else flag=false; } cga=set_secvalue(digest,8); return cga; } //-------------Sample function for random number generator---- //random generator explained in ra_privacy draft byte[] randomnumber(int length_byte) { byte[] num=new byte[length_byte]; srand(time(NULL)); for(int i=0;i