DNS Extensions H. Rafiee INTERNET-DRAFT Huawei Updates RFC 2845 (if approved) M. v. Loewis Intended Status: Standards Track C. Meinel Hasso Plattner Institute Expires: December 2, 2014 June 2, 2014 CGA-TSIG: An Algorithm for Secure DNS Authentication and DNS Confidentiality <draft-rafiee-intarea-cga-tsig-08.txt> Abstract This document describes a new mechanism for secure DNS authentication and DNS data confidentiality. The purpose of this document is to reduce human interaction during different DNS scenarios such as the communications of resolvers to stub resolvers, recursive resolvers to Authoritative Name Server, Dynamic DNS updates, (especially updating PTR and FQDN records (RFC4703)) and zone transfers. This document also considered for the support of both IPv4 and 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 December 2, 2014. Copyright Notice Copyright (c) 2014 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 Rafiee, et al. Expires December 2, 2014 [Page 1]
INTERNET DRAFT TSIG using CGA June 2, 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Current Solutions and Requirements . . . . . . . . . . . 5 1.2.1. Transaction SIGnature (TSIG) . . . . . . . . . . . . 5 1.2.2. DNS Security Extension (DNSSEC) . . . . . . . . . . . 5 2. Conventions Used In This Document . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 7 4.1. CGA-TSIG . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. The CGA-TSIG DATA Structure . . . . . . . . . . . . 7 4.1.2. CGA-TSIG Data . . . . . . . . . . . . . . . . . . . 9 4.1.2.1. IPv6 Specific Data . . . . . . . . . . . . . . . 9 4.1.2.2. IPv4 Specific Data . . . . . . . . . . . . . . . 10 4.1.3. Generation of CGA-TSIG DATA . . . . . . . . . . . . 10 4.2. CGA-TSIGe . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. The CGA-TSIGe DATA Structure . . . . . . . . . . . . 11 4.2.1.1. Public Key Request . . . . . . . . . . . . . . . 12 4.2.1.2. Public Key Response . . . . . . . . . . . . . . . 13 4.2.2. Generation of CGA-TSIGe DATA . . . . . . . . . . . . 13 4.2.2.1. IPv6 Specifics . . . . . . . . . . . . . . . . . 13 4.2.2.2. IPv4 Scenario . . . . . . . . . . . . . . . . . . 16 4.2.3. Process of Encrypted DNS Message . . . . . . . . . . 17 5. CGA-TSIG/CGA-TSIGe Use Case Scenarios . . . . . . . . . . . . 17 5.1. DNS Zone Transfer . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Verification Process . . . . . . . . . . . . . . . . 18 5.2. The FQDN Or PTR Update (IPv6 only) . . . . . . . . . . . 20 5.2.1. Verification Process . . . . . . . . . . . . . . . . 20 5.3. DNS Resolving Scenario (stub to recursive) . . . . . . . 21 5.3.1. Client Verification Process (CGA-TSIGe only) . . . . 21 5.3.2. Resolver Verification Process . . . . . . . . . . . . 22 5.4. DNS Resolving Scenario (Authoritative NS to Recursive NS) 23 6. SeND Is Not Supported (IPv6 only) . . . . . . . . . . . . . . 23 7. CGA-TSIG/CGA-TSIGe Sample Applications . . . . . . . . . . . 24 7.1. IP Spoofing . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Resolver Configuration Attack . . . . . . . . . . . . . . 24 7.3. Exposing A Shared Secret . . . . . . . . . . . . . . . . 25 7.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . 25 7.5. Data Confidentiality . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Rafiee, et al. Expires December 2, 2014 [Page 2]
INTERNET DRAFT TSIG using CGA June 2, 2014 10.1. A Sample Key Storage For CGA-TSIG . . . . . . . . . . . 26 10.2. Stored parameters in the node . . . . . . . . . . . . . 27 10.3. CGA Generation Script . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Rafiee, et al. Expires December 2, 2014 [Page 3]
INTERNET DRAFT TSIG using CGA June 2, 2014 1. Introduction Transaction SIGnature (TSIG) [RFC2845] is a protocol that provides endpoint authentication and data integrity through the use of one-way hashing and shared secret keys in order to establish a trust relationship between two or more hosts, which can be either a client and a server, or two servers. The TSIG keys, which are manually exchanged between a group of hosts, need to be maintained in a secure manner. This protocol is mostly used today to secure a Dynamic DNS Update, or to assure a Slave Server that the zone transfer is from the original Master Server and that it has not been corrupted. It does this by verifying the signature using a cryptographic key that is shared with the receiver. Handling this shared secret in a secure manner and exchanging it does not appear to be easy. This is especially true if the IP addresses are dynamic or the shared secret is exposed to the attacker. To address these existing problems with TSIG, as well as considering DNS data protection (privacy), and to solve existing problems with the current DNS security extensions, this document proposes two algorithms which support both IPv4 and IPv6 scenarios. In the IPv6 scenario, the algorithms use Cryptographically Generated Addresses (CGA) [RFC3972] or Secure Simple Addressing Scheme for IPv6 Autoconfiguration (SSAS) as a new algorithm in the TSIG Resource Record (RR). CGA is an important option available in Secure Neighbor Discovery (SeND) [RFC3971], which provides 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. This document addresses the DNS data confidentiality by using both asymmetric and symmetric cryptography. This document updates the following sections in TSIG document: - 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 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. 1.1. Problem Statement Rafiee, et al. Expires December 2, 2014 [Page 4]
INTERNET DRAFT TSIG using CGA June 2, 2014 There are several different methods where DNS records can become compromised. Some examples of methods are DNS Spoofing; DNS Amplification Attacks; Resolver Source IP Spoofing; Unauthorized DNS Update; User Privacy Attack; and Human Intervention. 1.2. Current Solutions and Requirements 1.2.1. Transaction SIGnature (TSIG) Advantages: - Provide a secure level authentication - Signs DNS messages Disadvantages: - Not scalable and applicable for specific scenarios. Currently there is little deployment of TSIG for resolver authentication with clients. One reason is that resolvers respond to anonymous queries and can be located in any part of the network. - Offline exchange of shared secrets. For each group of hosts there needs to be one shared secret and the administrator will need to manually add it to the DNS configuration file for each of these hosts. This manual process will need to be invoked in the case where one of these hosts is compromised and the shared secret is well known to the attacker. It will also have to be invoked in the case where any of these hosts needs to change their IP addresses, such as privacy issues explained in RFC4941 [RFC4941], or when moving networks, etc. The manual TSIG process for the exchange of shared secrets makes it difficult to configure each new client with the shared secret of a DNS server like a resolver. Another problem with TSIG would be when this shared secret is leaked and makes it necessary to repeat this process. - Does not easily protect DNS data confidentiality. TSIG provides the node with transaction level authentication and it is not used for encrypting the content of DNS messages. 1.2.2. DNS Security Extension (DNSSEC) Advantages: - Signs DNS messages and provide data integrity - Authorize a node to update certain zone file Disadvantages: Rafiee, et al. Expires December 2, 2014 [Page 5]
INTERNET DRAFT TSIG using CGA June 2, 2014 - Offline generation of the signature DNSSEC [RFC6840] needs manual step for the configuration. For instance, when a DNSSEC needs to sign the zone offline. - IP spoofing The public key verification in DNSSEC creates a chicken-and- egg situation. In other words, the key for verifying messages should be obtained from the DNSSEC server itself. This is why a query requester needs to verify the key. If this does not happen, DNSSEC is vulnerable to an IP spoofing attack. - Does not easily protect DNS data confidentiality for the resolver scenario Since a part of configuration is manual and DNS resolver needs to answer to anonymous queries, it is not possible to exchange the DNS keys with anonymous nodes over the internet. Even though it was possible, there is still no clear solution to encrypt all the data during DNS resolving scenario. 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 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. 3. Terminology The terms used in this document have the following standard meaning: - Bot: a malicious program that is installed on a node and allows an attacker to control some functions of that node to send malicious Rafiee, et al. Expires December 2, 2014 [Page 6]
INTERNET DRAFT TSIG using CGA June 2, 2014 messages. - Name Server: A server that supports DNS service. - Recursive Name Server: A Name Server that responds to all queries. - Stub Resolver: A DNS resolver that is unable to resolve queries recursively, and relies on a Recursive DNS Server to resolve queries. - Authoritative Name Server: Provides answers to DNS queries that it contains in its system configuration. There are two types of Authoritative Name Servers: 1. Master Server (Primary ): A Master Server stores the original copies of all zone records. Each Slave Server gets updated via a special automatic updating mechanism within the DNS protocol. All Slave Servers maintain identical copies of the master records. 2. Slave Server (Secondary): A Slave Server is an exact replica of the master server. - Root Name Server: An Authoritative Name Server for the root domain (i.e., '.' (dot)) - Client: a client can be any computer (server, laptop, etc) that only supports stub DNS servers and not other DNS services. It can be a mail server, web server or a laptop computer. - Node: a node can be anything such as a client, a DNS server (resolver, authoritative) or a router. - Host: all nodes except routers 4. Algorithm Overview The following sections explain the CGA-TSIG 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 section 4.2) is used when all parts of a DNS message Rafiee, et al. Expires December 2, 2014 [Page 7]
INTERNET DRAFT TSIG using CGA June 2, 2014 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 | | | +---------------------------------------+ | 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 | | | Rafiee, et al. Expires December 2, 2014 [Page 8]
INTERNET DRAFT TSIG using CGA June 2, 2014 +---------------------------------------+ Figure 2: Other DATA section of RDATA field 4.1.2. CGA-TSIG Data The following table explains the CGA-TSIG data structure. Fields that are marked (varies) are different depending on IPv6 or IPv4. CGA-TSIG DATA Field Name Data Type Notes -------------------------------------------------------------- AsyAlgorithm 15 octet Asymetric algorithm. IANA numeric value for RSA algorithm 1.2.840.113549.1.1.1[RFC4055] Type u_int16_t (varies) Name of algorithm IP Tag 4 octet (varies) Tag used to identify the IP address Parameters Len octet Length of parameters Parameters variable (varies) Signature Len octet Length of CGA signature Signature variable Section 3.2.1 of this document Old Pubkey Len variable Length of old public key field Old Pubkey variable Old public key in ASN.1 DER format (same format as public key) Old Signature Len variable Length of old signature field Old Signature variable Old signature generated by old public key. The IP Tag is one of the old IP addresses of the Node. A client's public key can be associated with several IP addresses on a server. The DNS server SHOULD store the IP addresses and the public keys to indicate their association. If a client wants to add RRs by using a new IP address, then the IP tag field will be zeroed out. The server will then store the new IP address that was passed to it in storage. If the client wants to replace an existing IP address in a DNS Server with a new one, then the IP Tag field will be populated with the IP address which is to be replaced. The DNS server will then look for the IP address referenced by the IP tag stored and replace it with the new one. This enables the client to update his own RRs using multiple IP addresses while, at the same time, giving him the ability to change IP addresses. If a Node changes its public key, then it MUST add the old public key to the Old Pubkey field. It MUST also retrieve the current time from the Time Signed field, sign it using the old private key, and then add the signature to the old signature field. This enables the verifier node to authenticate a host with a new public key. The verification steps are explained in detail in sections 5.1., 6.1 and 7.1. 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. IP Tag for IPv6 is 16 octets. Rafiee, et al. Expires December 2, 2014 [Page 9]
INTERNET DRAFT TSIG using CGA June 2, 2014 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 SHA 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 6. 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 need to be cached in order to generate the signature. If this node changes its IP address, it also needs to cache the old IP address. 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 10.2. appendix) 2. Generate Signature The 128-bit CGA Message Type tag value for SeND is 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. This value is concatenated with the entire DNS message (Please refer to figure 3 and figure 4) and the private key obtained from the cache. 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]. 3. Generate Old Signature If the Nodes generated new key pairs, they need to add the old public key, signed by the old private key, to the CGA-TSIG DATA. A Node will sign the new public key with the old private key, and then will add the contents of this signature to the old signature field of CGA-TSIG DATA. This step MUST be skipped when the Node did not generate new key pairs. +-----+------+--------+ |Type |Length|Reserved| |1byte|1 byte| 1 byte | Rafiee, et al. Expires December 2, 2014 [Page 10]
INTERNET DRAFT TSIG using CGA June 2, 2014 +---------------------+ | Header | | 12 bytes | +---------------------+ | Zone section | | variable length | +---------------------+ | prerequisite | | variable length | +---------------------+ | Update section | | variable length | +---------------------+ | Additional Data | | variable length | +---------------------+ Figure 3 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 4 DNS Query message (section 4.) 4.2. CGA-TSIGe One possible solution to provide the DNS server with data confidentiality during DNS update or other DNS query processes is the use of symmetric encryption with CGA-TSIG that is called CGA-TSIGe. 4.2.1. The CGA-TSIGe DATA Structure The Node MUST set the Algorithm Type in TSIG RDATA to CGA-TSIGe. Other sections of CGA-TSIGe DATA are similar to CGA-TSIG DATA. This section only explains the differences between CGA-TSIG and CGA-TSIGe. Figure 5 shows CGA-TSIGe DATA structure. The value of Message Hash is the concatenation of the 3 bits hashing algorithm identifier with the Rafiee, et al. Expires December 2, 2014 [Page 11]
INTERNET DRAFT TSIG using CGA June 2, 2014 hash of the whole DNS message (see figure 3 and 4 for the whole DNS message). This is used for data integrity of the packet. For SHA256, the value of hashing algorithm SHOULD set to 1. For other hashing algorithms, this 3 bits SHOULD set to sequential value after one. The field Message Hash Len is the length of Message Hash. +---------------------------------------+ | AsyAlgorithm | | | +---------------------------------------+ | Type | | | +---------------------------------------+ | IP tag | | (16 bytes) | +---------------------------------------+ | Parameter Len | | (1 byte) | +---------------------------------------+ | Parameters | | (variable) | +---------------------------------------+ | Signature Len | | (1 byte) | +---------------------------------------+ | Signature | | (variable) | +---------------------------------------+ | old pubkey Len | | (1 byte) | +---------------------------------------+ | old pubkey | | (variable) | +---------------------------------------+ | old Signature Len | | (1 byte) | +---------------------------------------+ | old Signature | | (variable) | +---------------------------------------+ | Message Hash Len | | (1 byte) | +---------------------------------------+ | Message Hash | | (variable) | +---------------------------------------+ Figure 5 CGA-TSIGe DATA Field 4.2.1.1. Public Key Request In the TSIG RDATA section, the Algorithm Name MUST be set to 'CGA-TSIGe', and the CGA-TSIGe Len field MUST be set to zero. This alerts the DNS server that the other Node needs its public key for Rafiee, et al. Expires December 2, 2014 [Page 12]
INTERNET DRAFT TSIG using CGA June 2, 2014 encryption purposes. This format is used if a Node does not want to use DNSKEY RR [RFC3757] to retrieve the public key of the DNS server. 4.2.1.2. Public Key Response The DATA structure is similar to CGA-TSIG. There is only a flag field which indicates that it is a response to the public key request message. +---------------------------------------+ | AsyAlgorithm | | | +---------------------------------------+ | Type | | | +---------------------------------------+ | Parameter Len | | (1 byte) | +---------------------------------------+ | Parameters | | (variable) | +---------------------------------------+ | Signature | | (variable) | +---------------------------------------+ | Signature Len | | (1 byte) | +---------------------------------------+ | Signature | | (variable) | +---------------------------------------+ | Flag | | (1 bit) | +---------------------------------------+ Figure 6 CGA-TSIGe DATA Field (public key response) 4.2.2. Generation of CGA-TSIGe DATA 4.2.2.1. IPv6 Specifics Nodes can securely obtain the IP address of DNS resolvers from the DHCPv6 server (use SAVI-DHCP [savi-dhcp]); or from a DNS option of Router Advertisement message [RFC6106] after authenticating with the router via a trusted authority. The IP addresses can be generated using CGA, SSAS or other mechanisms. (tjw:Last Sentence) This is the same approach that a Node can use for obtaining a DNS server IP address during a Dynamic DNS update. However, for a zone transfer to avoid any malicious update to DNS server, it is RECOMMENDED that this IP address is set manually on the DNS server for the first time. Rafiee, et al. Expires December 2, 2014 [Page 13]
INTERNET DRAFT TSIG using CGA June 2, 2014 1. Retrieve Public Key of DNS Server To encrypt the DNS message using a symmetric algorithm for performance purposes, first, a Node needs to retrieve the public key of the DNS server. It is possible to use the current DNSKEY RR [RFC3757] to send the public key of the DNS server. When the client wants to update any records on the DNS server, it first sends a DNS message asking for the public key of the DNS Server. The DNS Server then answers this query and includes the public key contained in the DNSKEY RR with the SEP flag set to zero (0). This indicates that it is not the zone key. It is also possible to use the RR format explained in section 4.2.1 of this document. The DNS server SHOULD include CGA-TSIGe DATA so that the client can verify its IP address. In this case, there will be a binding between a DNS Server's public key and its IP address. If the Node can verify the DNS Server public key (explained below), it goes to step 2. Otherwise it discards the DNS message without further action. 2. Obtain Required Parameters From Cache. This step is the same as what is explained in section 4.1.3. 3. Generation of Secret Key After a successful verification, the Node generates a 16 byte random number called a secret key. The Node can use any algorithm explained in [RFC4086] to generate a good randomized value. It encrypts the secret key using the DNS Server public key. Then, the Node sets the MAC in TSIG RDATA to the digest of secret key and set the MAC Size to the length of this digest. The DNS Server knows what to do with MAC field from the Algorithm Type in TSIG. If it is CGA-TSIGe, then it looks for this encrypted secret key. 4. Encryption of DNS message The Node uses the secret key generated in the previous step to encrypt the header, zone section, prerequisite, and update section for the DNS update message (see figure7) or encrypt header, question, answer, authority of a DNS Query (see figure 8). It then calculates the length of a digest as a number of bytes in multiples of 8. For example, if the digest is 242 bytes then 242 = (30 * 8) + 2. Therefore, 6 bytes are added as padding, and then 31 is placed at the beginning of digest (see figure 9). If there is no padding for the digest then one zero-filled byte will be added at the end of digest. This allows the DNS Server to interpret this digest as a long string. +-----+------+--------+ |Type |Length|Reserved| |1byte|1 byte| 1 byte | +---------------------+ | Header | | 12 bytes | Rafiee, et al. Expires December 2, 2014 [Page 14]
INTERNET DRAFT TSIG using CGA June 2, 2014 +---------------------+ | Encrypted sections | | variable length | +---------------------+ | Additional Data | | variable length | +---------------------+ Figure 7 Encrypted DNS update message +-----+------+--------+ |Type |Length|Reserved| |1byte|1 byte| 1 byte | +---------------------+ | Header | | 12 bytes | +---------------------+ | Encrypted sections | | variable length | +---------------------+ | Additional Data | | variable length | +---------------------+ Figure 8 Encrypted DNS Query message +---------------------+ | Len of digest | | (1 byte) | +---------------------+ | digest | | variable length | +---------------------+ Figure 9 Digest format in DNS question section The Node then adds a new header with the following sample data. This will allow the DNS Server to process this message. CGA-TSIGe actually uses the whole encrypted section as one single question followed by additional data. Field Sub-field Value Intrepretation ------------------------------------------------------- ID 0xdb42 Response should have ID 0xdb42 Flags 0x0100 QR 0 It's a query OPCODE 0 Standard query TC 0 Not truncated RD 1 Recursion requested RA 0 Not meaningful for query Z 0 Reserved RCODE 0 Not meaningful for query QDCOUNT 0x0001 One question follows ANCOUNT 0x0000 No answers follow NSCOUNT 0x0000 No records follow ARCOUNT 0x0001 No additional records follow Rafiee, et al. Expires December 2, 2014 [Page 15]
INTERNET DRAFT TSIG using CGA June 2, 2014 The digest will be interpreted like the following table. Data Intrepretation ------------------------------------------ 0x1f String of length 248 follows 0x777777.. String is xxxxxx 0x00 End of this string 5. Generation of Message Hash In a case where a DNS Server responds to anonymous queries, as in a DNS Resolver scenario, the Node executes SHA256 by default on the whole DNS message. This includes the additional section and the TSIG RR as a part of additional section of DNS message. It then computes the Message Hash Len. In this case the message does not need to be signed by the Node using its private key. This is because the DNS Server does not expect to verify the Node and it only checks for the message integrity (tjw:and confidentiality). In the case a message contains Message Hash, the Node MUST set the Parameters Len , Signature Len, Old Pubkey Len and Old Signature Len to zero (0) and it SHOULD skips steps 6 and 7. 6. Generation of Signature This step is the same as what is explained in section 4.1.3. 7. Generation of Old Signature This step is the same as what is explained in section 4.1.3. 4.2.2.2. IPv4 Scenario The key pairs needs to be cached in order to generate a signature. If this Node changes its IP address, it also needs to cache the old IP address. Similar to the IPv6 scenario, the Node can obtain the hash of (public key + IPv4) and the IPv4 address of the DNS server from a DHCPv4 server. It can use [savi-dhcp]. If this Node is in unsecured environment, it can manually add the hash of (public key + IPv4 address) of its trusted DNS server. This is especially true in the Resolver scenario. The implementers SHOULD define a possibility for users to change the default value for CGA-TSIGe. 1. Retrieves Public Key of DNS server This is similar to IPv6 scenario. 2. Obtain Required Parameters From Cache. This step is the same as what is explained in section 4.1.4. 3. Generation of Secret Key 4. Encryption of DNS Message Rafiee, et al. Expires December 2, 2014 [Page 16]
INTERNET DRAFT TSIG using CGA June 2, 2014 5. Generation of Message Hash All Three are similar to IPv6 scenario. 6. Generation of Signature This step is the same as what is explained in section 4.1.4. 7. Generation of Old Signature This step is the same as what is explained in section 4.1.4. 4.2.3. Process of Encrypted DNS Message When the DNS server receives the message from any node with TSIG RDATA Algorithm type set to CGA-TSIGe, it executes the following steps: 1- Retrieves The Secret Key The DNS server retrieves the secret key from MAC field. It then decrypts this secret key using its own private key. 2- Decrypts the DNS Message The DNS server decrypts the DNS server message using this secret key and the symmetric algorithm, which by default is AES. The DNS server can then start the verification process explained in the next section. 5. CGA-TSIG/CGA-TSIGe Use Case Scenarios 5.1. DNS Zone Transfer This section discusses the use of CGA-TSIGe for the secure authentication and encryption of DNS messages exchanged between a Master Server and a Slave Server. In the case of processing a DNS zone update ([AI]XFR) for multiple DNS servers (authenticating 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. This is needed for human intervention. Since the zone contains important information, both DNS servers MUST use CGA-TSIGe and encrypt the values. The only exception is when CGA-TSIG is required for secure authentication and the data encryption is handled by other protocols. a. Add The DNS servers' IP address To A Slave Server Configuration (IPv6 only) Rafiee, et al. Expires December 2, 2014 [Page 17]
INTERNET DRAFT TSIG using CGA June 2, 2014 A DNS server administrator should only manually add the IP address of the Master Server to the configuration file of the Slave Server. When the DNS update message is processed, the Slave Server can authenticate the Master Server based on the source IP address and then, prove the ownership of this address by use of the CGA-TSIGe option from the TSIG RR. This scenario will be valid until the IP address in any of these DNS servers, changes. To automate this process, the sender's public key of the DNS Update message 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) (IPv6 only) The message exchange option of SeND [RFC3971] may be used for the retrieval of third party certificates. This may be done automatically from the TA by using the Certificate Path Solicitation and Certificate Path Advertisement messages. Like in section 5.2, the certificate should be saved on the DNS server for later use. Whenever any of those servers want to generate a new IP address, the DNS update process can be accomplished without human intervention. c. Store The Hash of (public key + IPv4 address) to DNS configuration file (IPv4 and IPv6) An administrator needs to manually generate the hash of the concatenation of public key with the IPv4 address of the authorized node the DNS configuration file. Whenever a node wants to change its IP address or public key, the DNS server can generates this value automatically and compare with the old value it has and then after a successful verification steps (it will be explain in next section), it will replace the old hash value with the new one. 5.1.1. Verification Process 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-TSIGe DATA should be verified. This can be done by retrieving the public key and signature from CGA-TSIGe 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. Rafiee, et al. Expires December 2, 2014 [Page 18]
INTERNET DRAFT TSIG using CGA June 2, 2014 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 concatenates the Public Key with the IP address of the update requester and executes the SHA256 algorithm (by default) or another algorithm identified in Type section of CGA-TSIG DATA RRTYPE. It then compares it with the hash value available in the DNS configuration. If they are the same, the Update Message should be processed, otherwise, go to step 5. 5. Generate The Hash of (Old Public Key + IPv4 Address) (IPv4 only) If the Old Public Key Length is zero, then skip this step and discard the DNS update message. If the Old Public Key Length is not zero, then the DNS server retrieves the hashing algorithm Type from the CGA-TSIGe DATA structure. It then concatenates Old Public Key with the IP address of the update requester and execute the SHA256 algorithm (by default) or another algorithm identified in Type section of CGA-TSIGe DATA. It then compares it with the hash value available in the DNS configuration. If they are the same, the Update Message should be processed, otherwise, go to step 8. 6. 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. Rafiee, et al. Expires December 2, 2014 [Page 19]
INTERNET DRAFT TSIG using CGA June 2, 2014 7. Verify The Public Key (IPv6 only) The DNS server checks whether or not the public key retrieved from CGA-TSIGe 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. 8. Verify The Old Public Key (IPv4 and IPv6) If the Old Public Key Length is zero, skip this step and discard the DNS update message. If the Old Public Key Length is not zero, then the DNS server will retrieve the Old Public Key from CGA-TSIGe DATA and check to see if it is the same as what was saved in the DNS server's cache. If they are the same, execute step 6, otherwise discard the message. 7. Verify The Old Signature (IPv4 and IPv6) The Old Signature contained in CGA-TSIGe DATA should be verified. This can be done by retrieving the Old Public Key and the Old Signature from CGA-TSIGe DATA and then using this Old Public Key to verify the Old Signature. If the verification is successful, the Update Message should be processed and the New Public Key should be replaced with the Old Public Key in the DNS server. If the verification process fails, discard the message. 5.2. The FQDN Or PTR Update (IPv6 only) Normally the DHCPv6 server will update the client's RRs on their behalf in the scenario where SeND is used as a secure NDP, the Nodes will need to do this process unless a stateless DHCPv6 server is available. CGA-TSIG/CGA-TSIGe can be used to give Nodes the ability of doing this process themselves. In this case the clients need to include the CGA-TSIG/CGA-TSIGe option to allow the DNS server to verify them. The verification process is the same as that explained in the next section except for step 4. 5.2.1. Verification Process The verification steps are the same as those is explained in section 5.1.1, but removing step 4 and modifying step 5. 1. Verify The Signature 2. Check The Time Signed 3. Execute The CGA Verification 4. Verify The Public Key Rafiee, et al. Expires December 2, 2014 [Page 20]
INTERNET DRAFT TSIG using CGA June 2, 2014 The DNS server checks if the public key retrieved from CGA-TSIG/CGA-TSIGe DATA is the same as what was available in cache. If no entry is found for this public key, and the FQDN or PTR is also not available in the DNS server, then the DNS server will store the public key of this Node and add this Node's PTR and FQDN. Otherwise if any PTR is available, and the Node IP tag is empty, or there is currently another public key associated with the Node's FQDN, then the update will be skipped. Otherwise, if the Old Public Key Length is not zero, go to step 5. 5. Verify The Public Key 6. Verify The Old Public Key 7. Verify The Old Signature 5.3. 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, then it needs to set the Algorithm Type to CGA-TSIGe and follows the step explained in section 4.2.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. 5.3.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 MAC section of the Other DATA section of TSIG Rafiee, et al. Expires December 2, 2014 [Page 21]
INTERNET DRAFT TSIG using CGA June 2, 2014 RRType. 5.3.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 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.1.1. 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 Resolver's Public Key with the Resolver's IP address, and computes the SHA algorithm on the result. The client compares this value 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. 7. Verify The Old Public Key (IPv4 and IPv6) If the Old Public Key Length is zero (0), discard this message without further action. If the Old Public Key Length is not zero(0), then the host will retrieve the Old Public Key from Rafiee, et al. Expires December 2, 2014 [Page 22]
INTERNET DRAFT TSIG using CGA June 2, 2014 CGA-TSIG/CGA-TSIGe DATA and will check whether or not it is the same as what was saved in the host's storage where the Public Keys and IP addresses are stored. If it is the same, then step 8 will be executed. 8. Verify The Old Signature (IPv4 and IPv6) The Old Signature contained in CGA-TSIG/CGA-TSIGe DATA can be verified by retrieving the Old Public Key and Old Signature from CGA-TSIG/CGA-TSIGe DATA and then using this Old Public Key to verify the Old Signature. If the verification is successful, the DNS Message should be processed and the New Public Key should be replaced with the Old Public Key of the Resolver in the host. If the verification process fails, then the message will be discarded. 5.4. 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.3.1. 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 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 4.2.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. 6. SeND Is Not Supported (IPv6 only) In the case where there are no cache parameters available during the IP Address generation, there are then two 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 4.2. The Node SHOULD skip the first section of the verification processes explained in section 5.1.1, section 5.2.1, and section 5.3.1. 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 Rafiee, et al. Expires December 2, 2014 [Page 23]
INTERNET DRAFT TSIG using CGA June 2, 2014 not necessarily need to support SeND. They only need to support CGA-TSIG. In the third scenario, as explained in section 4.1.4, the Node can use the same approach used for IPv4 and retrieve the hash of (Public Key + IPv6 Address) from the DHCPv6 server. 7. CGA-TSIG/CGA-TSIGe Sample Applications The purpose of CGA-TSIG and CGA-TSIGe is to minimize the human intervention required to accomplish a shared secret or key exchange, with the end result of providing data confidentiality to prevent DNS spoofing. Minimizing the amount of human intervention reduces the vulnerability to attacks introduced by human errors. As explained above, CGA-TSIG and CGA-TSIGe can be used in different scenarios. For the FQDN update scenario, CGA-TSIG is useful in dynamic networks where the nodes want to change their IP addresses frequently in order to maintain privacy. If the Dynamic Host Configuration Protocol (DHCP) is in use, then the DHCP server can do this update on behalf of the nodes in this network on a DNS server. But with the Neighbor Discovery Protocol (NDP), there is no feature available that allows the host security update process for its own FQDN. In this case, CGA-TSIG can be a solution. In the Resolver scenario, the Resolver can add the TSIG Resource Record (RR) to the DNS query response and use the CGA-TSIG/CGA-TSIGe algorithm to authenticate the result or DNS data protection. CGA-TSIG assures the client that the query response comes from the true originator and not from an attacker. CGA-TSIG/CGA-TSIGe also ensures the integrity/and confidentiality of the data by signing and encrypting the data. 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. 7.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 approaches. 7.2. Resolver Configuration Attack Rafiee, et al. Expires December 2, 2014 [Page 24]
INTERNET DRAFT TSIG using CGA June 2, 2014 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. 7.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. 7.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. 7.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. 8. 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 3. 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 Rafiee, et al. Expires December 2, 2014 [Page 25]
INTERNET DRAFT TSIG using CGA June 2, 2014 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. 9. 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 4.1, Type should allow for the use of future optional algorithms with regard to SeND. The default value for CGA might be 1. Other algorithms would be assigned a new number sequentially. For example, a new algorithm called SSAS [4,5] could be assigned a value of 2. IANA also needs to define a numeric algorithm number for ECC. The similar way that is defined for RSA. 10. Appendix 10.1. A Sample Key Storage For CGA-TSIG create table cgatsigkeys ( id INT auto_increment, Rafiee, et al. Expires December 2, 2014 [Page 26]
INTERNET DRAFT TSIG using CGA June 2, 2014 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 10.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 ). <?xml version="1.0" encoding="UTF-8"?> <Details> <CGATSIG> <modifier value=""/> <algorithmtype value="1.2.840.113549.1.1.1"/> <secval value="1"/> <GIP value=""/> <oGIP value=""/> <Keys value=""/> </CGATSIG> </Details> XML file contains the cached DATA 10.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); Rafiee, et al. Expires December 2, 2014 [Page 27]
INTERNET DRAFT TSIG using CGA June 2, 2014 //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; 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<length_byte;i++) num[i]=rand() %254; } 11. Acknowledgements Rafiee, et al. Expires December 2, 2014 [Page 28]
INTERNET DRAFT TSIG using CGA June 2, 2014 The continual improvement of this document is as a result of the helps and assistance of its supporters. The authors would like to thank all those people who directly helped in improving this draft and all supporters of this draft, especially Ralph Droms, Andrew Sullivan, Ted Lemon, Brian Haberman, Erik Nordmark, Brian Dickson. The authors would like also to special acknowledge the supports of NLnet Labs director and researchers; Olaf Kolkman, Matthijs Mekking and their master student Marc Buijsman. The authors would like to express their special appreciation and thanks to Tim Wicinski who spent a lot of time to review, revise and improve this draft. 12. References 12.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. [RFC2845] Vixie, P., Gudmundsson, O. , Eastlake 3rd, D., Wellington, B., " Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC6106] Jeong, J., Park, S., Beloeil, L., Madanapalli, S.,"IPv6 Router Advertisement Options for DNS Configuration",RFC 6106, November 2010. Rafiee, et al. Expires December 2, 2014 [Page 29]
INTERNET DRAFT TSIG using CGA June 2, 2014 [RFC4086] Eastlake, D., Schiller, J., and Crocker, D., "Randomness Requirements for Security", BCP 106, RFC 4086,June 2005. [RFC4055] Schaad, J., Kaliski, B., and Housley, R., "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055,June 2005. [RFC6840] Weiler, S. and Blacka, D., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840,February 2013. [RFC3757] Kolkman, O., Schlyter, J., and Lewis, E., "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",RFC 3757,April 2004. 12.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. [4] Rafiee, H., Meinel, C., "A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS)". Work in progress, http://tools.ietf.org/html/draft-rafiee-6man-ssas, 2013. [5] Rafiee, H., Meinel, C., "A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS)", 11th International conference on Privacy, Security and Trust (IEEE PST), 2013. [6] AlSa'deh, A., Rafiee, H., Meinel, C., "Cryptographically Generated Addresses (CGAs): Possible Attacks and Proposed Mitigation Approaches," in proceedings of 12th IEEE International Conference on Computer and Information Technology (IEEE CIT'12), pp.332-339, 2012. [7] Rafiee, H., Meinel, C., "A Secure, Flexible Framework for DNS Authentication in IPv6 Autoconfiguration" in proceedings of The Rafiee, et al. Expires December 2, 2014 [Page 30]
INTERNET DRAFT TSIG using CGA June 2, 2014 12th IEEE International Symposium on Network Computing and Applications (IEEE NCA13), 2013. [savi-dhcp] Bi, J., Wu, J., Yao, G, Baker, F.,"SAVI Solution for DHCP", http://tools.ietf.org/html/draft-ietf-savi-dhcp-23, April 2014 Rafiee, et al. Expires December 2, 2014 [Page 31]
INTERNET DRAFT TSIG using CGA June 2, 2014 Authors' Addresses Hosnieh Rafiee http://www.rozanak.com Phone: +49 176 57 58 75 75 Email: ietf@rozanak.com Christoph Meinel Hasso-Plattner-Institute Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Email: meinel@hpi.uni-potsdam.de Martin von Loewis Hasso-Plattner-Institute Prof.-Dr.-Helmert-Str. 2-3 Potsdam, Germany Rafiee, et al. Expires December 2, 2014 [Page 32]